Community
Participate
Working Groups
Bug #232200 brought up subtle design problem in our use of checkbox lists in preference pages where only one item can be checked. Strictly speaking, a checkbox list should only be used when multiple items can be "on". In this case the checkbox list is misleading and case in point I misinterpreted what was going on in the pref page as a result. If I had attempted to select more than one I would see the checkbox move, so in this way I'd learn how it worked, but the fact that its indistinguishable from a multiple selection control is the issue. In the case of bug #232200 they could not use a single selection list because they also want to use the selection as the target for buttons alongside the list. There's there's two forms of selection going on: 1) Which item will be the active one selected through use of the pref page. 2) Which item will be the target for the buttons beside the list. We should spec out a common approach to this, there are likely many places where we solved this with a checkbox tree.
Mylyn has this problem as well: http://www.eclipse.org/mylyn/new/images/0.7.0/task-repository-association.gif
Does it have to be a ceckbox (or radio box)? On the "File Associations" preference page, we have a list of associated editors, one of which is the default. In this case, marking the label with '(default)' together with a "Default" button solves the problem without check boxes or radio boxes. Mik, why don't you use a combo box?
(In reply to comment #2) > Mik, why don't you use a combo box? I need both images and platform decorations in that list, and afaik I can't get those into a combo box.
I've filed bug 233166 to request tables with SWT.RADIO from SWT, since I think that's the best way to solve this problem. It's interesting to see that Microsoft also didn't know what to do in WinXP: In the properties dialog for a printer, they use a hand-crafted check box table on the "Ports" tab...
Created attachment 101232 [details] Combo with icons > I need both images and platform decorations in that list, and afaik I can't get those into a combo box. Mik, I believe you can do this by putting the icons outside the combo.
(In reply to comment #4) > I've filed bug 233166 to request tables with SWT.RADIO from SWT, since I think > that's the best way to solve this problem. I'm not sure I've ever seen that combination but I agree it does fit the usage requirements (only one on, each line can selection source). But I think I prefer Boris' suggestion #2 of just marking one as "default" or "active", although this changes the workflow a little, requiring that the user click a "use the selected one" button. > It's interesting to see that Microsoft also didn't know what to do in WinXP: In > the properties dialog for a printer, they use a hand-crafted check box table on > the "Ports" tab... Yeah I looked through the MS Interface Guidelines book and the MS online guidelines and didn't see a recommended solution.
(In reply to comment #5) > Mik, I believe you can do this by putting the icons outside the combo. Thanks for the mockup Kim! This will be useful for us elsewhere in the UI, e.g. in the task editor which allows you to select a priority but only shows the text label and not the icon. But if doing this without rendering the icons in the combo it seems that there will be a bit of a disconnect, since you won't have the benefit of the icons when making the selection. I wonder if this would better if combined with the custom rendering of images in the combo, e.g.: http://www.javawiki.org/2006_03_03/enhancing-the-combo-widget-with-images/ ? We've been considering that (bug 181794). While it's helpful, my impression is that combos won't remove the need for single selections in a list that has images, because it's considerably easier to select an item from a list with distinct icons than to pop up a combo, especially if the combo has a scrollbar. However, in Mylyn that Task Repository properties page is the only place we encounter the need for this UI.
> > I've filed bug 233166 to request tables with SWT.RADIO from SWT, since I think > > that's the best way to solve this problem. > > I'm not sure I've ever seen that combination but I agree it does fit the usage > requirements (only one on, each line can selection source). An example that uses radios on tree items can be seen on Windows XP: Control Panel > Internet Options > Security > Custom level... But like in Printer Properties > Ports, the radios are faked (don't react like native radios when you hover or click).
(In reply to comment #6) > But I think I prefer Boris' suggestion #2 of just marking one as "default" or > "active", although this changes the workflow a little, requiring that the user > click a "use the selected one" button. We have this in a few places now (API Baseline prefs, Target Platform prefs), and it's a pain every time I have to use it: - The fat label and the "(Active)" or "(default)" suffix are non-standard, so you have to spend a lot of time to decipher the UI. - The button to mark the selection as active is far away and hidden in a flood of other buttons, thereby violating basic locality principles. - Click, seek, move, click instead of 1 click => 300% performance degradation! I'm not aware of any user complaints or confusion with the well-established checkbox tree that only lets the user select a single item. It's intuitive, quick, and nice. I know that it violates a UI guideline, but in this case, that's much less severe than the pain brought by the current hacks. In German, we call this "verschlimmbessert" (disimproved?). Until we get bug 233166, the recommendation should stay with the established single-check checkbox tree.
I agree that the checkbox approach is not the perfect match but in my opinion preferable over indicating the selection via text and font and hence cluttering the UI in two ways: - clutters the label and needs more horizontal space - steals UI real estate because an additional button is needed (we have cases where no other buttons would be present otherwise) On the existing preference pages that use text/font approach I often find myself selecting an element from the list and pressing OK, assuming this is now in indeed selected. The checkbox approach also makes it easier to have no default at all which in the font/text approach requires yet another button.
Fyi, a while back we standardized the Mylyn UIs with this need on the single-check checkbox tree.
(In reply to comment #10) > I agree that the checkbox approach is not the perfect match but in my opinion > preferable over indicating the selection via text and font and hence cluttering > the UI in two ways: > - clutters the label and needs more horizontal space > - steals UI real estate because an additional button is needed (we have cases > where no other buttons would be present otherwise) I agree that the presentation of (default) is ... well feels cheap, and it raises some NLS issues, in general I think it's a problem to modify some label. But this and the real estate issue (and number of clicks) worries me less than whether it's clear to people what's going on. Checkboxes = "multiple can be on" as you'll find I'm assuming in both Win and Mac guidelines, so single selection is misleading. > On the existing preference pages that use text/font approach I often find > myself selecting an element from the list and pressing OK, assuming this is now > in indeed selected. Interesting. Now THAT does concern me with the (default) approach, yes I can see that happening. > The checkbox approach also makes it easier to have no default at all which in > the font/text approach requires yet another button. True. I think where we've all ended up is that radio button list is the right metaphor, but while checkbox list has usability issues, they're less egregious than those with the (default) button.
> > The checkbox approach also makes it easier to have no default at all which in > > the font/text approach requires yet another button. > > True. An empty selection makes sense for both the Target Platform and the API Baseline preference page, so we don't need the radio button list at all for those two. The Windows guidelines even suggest to use check boxes in such cases, see http://msdn.microsoft.com/en-us/library/aa511452.aspx : "Use dependent check boxes if the alternatives add unnecessary complexity".
agree thanks for the ref
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Checkbox table is good enough. Closing. If bug 233166 is implemented and the empty selection is not supported, then a Table with SWT.RADIO can be used.
