When a widget is just not right ( was RE: [ID Discuss] Re-orderingrows in a table.)
26 Feb 2004 - 6:00pm
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.
> 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/