When a widget is just not right ( was RE: [ID Discuss] Re-orderingrows in a table.)

26 Feb 2004 - 6:00pm
555 reads
Nick Ragouzis
2004

I agree Dave. And besides ... the checkbox idiom is exactly what's desired here.

Sandeep wrote, relevant to the option using shifting:
> Basically, user selects one row by checking the checkbox,
> and then, uses the up/down buttons to dynamically move
> the selected row.

Why in the world must the user be limited to selecting one row (i.e., in a radio button group) for the shift operation? And
would the rows thus selected have to be contiguous at the outset? And if the user used move-to-top or move-to-bottom once then
again, or repeatedly up/down after hitting the top, would you compress them at the limit? These options and operations would also
compensate for operations in a large table.

Besides ... what are radio buttons when there's no permanent mapping? (Is this Raskin's comment? I forgot.) That is, in your
case the radio buttons would appear to move with the lines.

Re: the numbering option.
In addition to what's been mentioned on the list, in a test of this challenge using 1997-era widgets I saw another phenomenon
associated with the numbering scheme -- the subjects spent extra time fiddling with the numbers. Relevant to your example "15, uh,
no 14; and that one should be 18." In my tests it was even less useful to make these fiddly adjustments -- since the scale was
logrithmic and (essentially) unbounded -- but subjects ('webmasters') did spend time on them.

--Nick

> Andrei said, why would you ever use a checkbox for a radio button?
> Sandeep said he was doing it for the wrong reasons.
>
> I recently designed an app where I did just that.
>
> Why?
>
> Well, I made the decision w/ my peers b/c while the behavior is wrong,
> we
> discovered:
> 1. this behavior is actually not well understood by our end-users 2.
> that radio buttons all stacked up in a vertical row just looks really
> weird. It creates a warping effect in attempting to read the labels
> next them and the clarity gets a lost. Compared to the checkboxes in
> the same position, it turned out to be worth it. 3. We also learned
> that expressing the modal difference between single and multi select
> was also unimportant to users. If they wanted to multi-select they
> would try whether or not there were checkboxes or radio buttons
> present.
>
> The question I would make is why radio buttons at all? Ok, someone
> came up w/ a convention, but is the convention worth maintaining for
> its own sake? Maybe my data is specific or the testing was wrong, but
> lets hypothesize that it is good data and transferable do we just
> hold to convention? Bad ones? Even seemingly architypical ones?
>
> -- dave
>
> _______________________________________________
> Interaction Design Discussion List discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already) http://interactiondesigners.com/announceList/

Syndicate content Get the feed