Community
Participate
Working Groups
This topic came up in bug #57762 comment #43 and others. First off, I think it's great that we've introduced this feature (choosing which editor to open a resource with from the dialog). My concerns are about the use of two buttons, one with a dropdown, both of which act as "OK". I agree with the comment from bug #57762 that this is introducing a new UI metaphor. This concerns me as a general practice because I think you (the developer) can only do that a very small number of times in a product. After that, you must use it pervasively so that it's common, and must be prepared to put a tonne of time into refining it. I don't see the the former happening, and question whether the cost/benefit is there for the latter. I think the usability problem boils down to the fact that we're trying to provide the illusion that it's a single button with two areas you can press in. There are a lot of opportunities for this to not work as expected. For example, you can keyboard navigate to just the dropdown. Thus, it's clear it's a separate control. Input hightlight also gives it away (either by keyboard or mouse). So too hover help since you get a different tooltip for each button. Finally, hitting <return> on the dropdown doesn't expose the list and does nothing, making it not accessible (presumably that one we could fix). This is in contrast to our toolbar split button (e.g. "New", "Run", "Debug", "Back") which has a split in it so it can accommodate both an icon and a dropdown. For this you get a single control to navigate to, a single input hightlight, a single tooltip. Back to the Open Resources dialog, picking an item from the dropdown has the effect of immediately dismissing the dialog. This felt a bit surprising, maybe because the button doesn't say "OK" or "Open", maybe because I already have a button that says "Open". The fact its snugged up beside one that does say that, isn't strong enough to imply they both do Open. There's nothing to indicate if it's only picking the choice alone, or if it's going to do the Open part too. Finally of course there's the button ordering inversion problem as described in the other bug. Thus I think we'd gain more clarity by simply having a separate dropdown control for choosing the editor to open with, and have the changing of that choice be a separate action the user would perform prior to hitting "OK" (which is what the button used to say and currently says in Open Type). I don't think this is a power user kind of task where it matters that there's one extra keypress to select the editor type separate from the dismissal. I'm just glad I can! Or rather, I don't think the added convenience of one less click outweighs the added risk/cost of confusion.
We didn't (want to) invent a new concept but simply use the well known split button that is used in Windows open dialogs. Our main fault was to ask for this and hack it ourselves. You can read the discussion of the different approaches in bug 40632. Given that we had the OK from Boris we thought it's OK. The main reason for not using the combo was that we did not want to pollute the Open Resource UI as choosing a non-default editor is not the 80% use case. Can you please attach a UI mock up of what you expect to see and describe in more detail how it should behave (tab sequence, default widget, etc.).
(In reply to comment #1) > We didn't (want to) invent a new concept but simply use the well known split > button that is used in Windows open dialogs. Can you provide a concrete example of one? > The main reason for not using the combo was that we did not want to pollute the > Open Resource UI as choosing a non-default editor is not the 80% use case. > > Can you please attach a UI mock up of what you expect to see and describe in > more detail how it should behave (tab sequence, default widget, etc.). Sorry I wish I could help with the design but I don't have the cycles at this time to provide a mockup. I was asked to provide a usability eval and hope it helps. But really, the suggestion is simply to add a combo along the bottom, I imagine along the lines suggested in but #40632. I understand the desire to avoid cluttering the dialog but I do think that in this case it's the better compromise.
Created attachment 126172 [details] Picture of Open dialog
Right thanks. So that's a single control with two hit areas. It has one input focus, single thing to tab to, specialized key sequence to get the dropdown of options (shift-down), etc. Plus I don't know what the equivalent control looks like on other platforms. We otoh we have two controls trying to provide the illusion of one. We have two input highlights, two things to tab to, a different key sequence to get the dropdown, etc. That's where it all breaks down.
> Finally, hitting <return> on the dropdown doesn't expose the list > and does nothing, making it not accessible (presumably that one we could fix). That's an oversight. Should indeed also add a selection listener to the button. The feature is accessible via the context menu in the table. > There's nothing to indicate if > it's only picking the choice alone, or if it's going to do the Open part too. The tooltip says "Open With", so I think it's clear that the actions in the menu do open the editor (same as "Open With" in the context menu, and also same as toolbar buttons with drop downs, where e.g. the items in "Debug" or "New" also execute the action). We haven't heard of user complaints about this, so it doesn't seem to be a really big issue. But the combo solution would also be OK for me (would even have the added benefit that I see the selected editor without opening the menu).
(In reply to comment #5) > > There's nothing to indicate if > > it's only picking the choice alone, or if it's going to do the Open part too. > > The tooltip says "Open With", so I think it's clear that the actions in the > menu do open the editor (same as "Open With" in the context menu, and also same > as toolbar buttons with drop downs, where e.g. the items in "Debug" or "New" > also execute the action). Yeah I saw the tooltip ... I guess what I meant was that it's odd having this extra button hanging around. Again, I think it's just a subtle confusion over there being two buttons to simulate one. I think ideally what we want is the real platform button here. At a basic level, my concern is that we shouldn't try to simulate a platform feature through clever combination of existing widgets since it's quite easy for the illusion to break down and then that leads to usability issues. We've introduce a new metaphor which is somewhat like but not quite like the platform one and that I have strong reservations about as a precedence. > We haven't heard of user complaints about this, so it doesn't seem to be a > really big issue. But the combo solution would also be OK for me (would even > have the added benefit that I see the selected editor without opening the > menu). Again, I like the feature and think it's great it was put in. I also appreciate minimal design. I do think though that the current form has the potential to create the kind of quiet confusion that we may never receive a bug report on, but which nonetheless impacts people's perception of the usability Eclipse.
OK, my position is that this needs to be a single SWT control, and baring that, we should have the dropdown combo. I can ask Linda to mock up a design for the placement of the dropdown but that will take some time (she's fully booked atm). I spoke to Steve about the possibility of it being an SWT control. He said some platforms (Vista being one) have an equivalent control, some do not. For the latter we'd need to emulate. SWT emulating is the right level since they can ensure it properly provides the illusion of a single control. That will take more investigation, but it's only worth doing if we're completely dissatisfied with the mockup design using the dropdown. There is some concern about the cost of creating a custom control if we only end up using it in one place but it's still worth discussing (e.g. maybe there's other opportunities to use it).
I'm personally also not opposed to do it with a combo, and I don't think the UI design for that solution would be an issue (no need for further mockups, IMO). For me, the only question is who's gonna implement it, and whether it's really a priority to get rid of the current solution for 3.5 (we have many much more severe open UI bloopers). The current solution was not a big deal to implement, because the menu was already available (as sub-menu). The combo solution would have to refactor that code and invent something for the "Other..." entry. And it would have to update the combo on selection change (and be fast enough that it does not impede traversal speed).
Thanks Markus. I hate to give the impression of quashing innovation. I'll get the Linda to do the mockup anyway so we have something concrete to look at. We'll figure out the "who makes the code changes" after we've converged.
Created attachment 127313 [details] Fix for menu button selection via keyboard (In reply to comment #5) > > Finally, hitting <return> on the dropdown doesn't expose the list > > and does nothing, making it not accessible (presumably that one we could fix). > > That's an oversight. Should indeed also add a selection listener to the button. > The feature is accessible via the context menu in the table. Here's a quick fix for this.
Committed Markus's patch (available in builds > I20090309-0100).
thanks
Created attachment 129395 [details] "Open with Editor" mockup including guideline information Kevin and I reviewed MS Vista Guidelines: http://msdn.microsoft.com/en-us/library/aa511458.aspx and decided on Drop Down List Box instead of Combo Box was the appropriate widget. See the comments and comparison chart I've included in the mockup.
Created attachment 129398 [details] Guideline in case split button is able to be used in a future release The guideline attached is an excerpt from the Command Buttons section of the Windows Vista UX Guidelines: http://msdn.microsoft.com/en-us/library/aa511453.aspx If the native Windows Split Button is able to be used for the Open Resource dialog in a future release, per the example shown in the .gif, the command text that is visible on the button would need to more explicitly describe the command. For the Open Resource dialog context, instead of "Open", it should read "Open with [default] editor", and the commands on the dropdown should contain "Open with [x] editor".
(In reply to comment #13) For screen space efficiency, the "Open with:" label should be placed to the left of the combo. It would IMO even be better to put them into the button bar, to the left of the Open button. Having the combo as close as possible to the Open button spares the user from traveling distances with the mouse and increases reading speed, since the editor name can be read at once with the Open (or OK) button.
I agree with Markus's comments: I'd also like to see the drop-down list in the button bar.
Created attachment 131401 [details] Mockup attempting to represent Markus'/Dani's comments Is this what you guys envisioned? If yes, seems a bit crowded, and I have this assumption that these kinds of controls + labels shouldn't appear in the button area for dialogs because, well, its supposed to just contain buttons.
Yes, looks nice. The vertical gap between status line and button bar will be a bit smaller if you just add the combo to the current layout (which would be good). I agree that the dialog becomes a bit denser, and I think that's a good thing, because it makes for a nice reading flow from the combo to the Open button. And mixing other controls into the button bar is nothing new, see e.g. the default WinXP open dialog or attachment 126172 [details] from comment 3.
Created attachment 131428 [details] Alternate mockup with button column (In reply to comment #18) > Yes, looks nice. The vertical gap between status line and button bar will be a > bit smaller if you just add the combo to the current layout (which would be > good). Yeah this was just me quickly cutting/pasting the mockup picture. > I agree that the dialog becomes a bit denser, and I think that's a good thing, > because it makes for a nice reading flow from the combo to the Open button. > > And mixing other controls into the button bar is nothing new, see e.g. the > default WinXP open dialog or attachment 126172 [details] from comment 3. Well, that's a good point, although I notice in attachment 126172 [details] and a few other examples I've found (e.g. WinZip's File->New Archive, HyperSnap File->Open) when there's additional open controls they stack the OK/Cancel buttons. So I (perhaps mistakenly) think of that as a vertical button group, with then some additional associated controls. What about this mockup to be more in line with those other examples?
I like the last two much better than having the drop down on a separate row. Of the two I prefer the last one.
(In reply to comment #20) > I like the last two much better than having the drop down on a separate row. Of > the two I prefer the last one. Me too. It makes it clearer that it's for the "Open" and can't be mistaken as being part of the button group. Sold!
Hmm, been looking at the code needed for this change and I'm starting to not like the dropdown approach: 1) The menu provides icons to indicate the editor type. AFAIK we can't put those in a combo. 2) The menu has separators, we can't add those to the combo. 3) As noted in comment #8, the code which provides the set of editors is in an action which creates a menu (OpenWithMenu, esp. fillMenu()). I admit I didn't appreciate this aspect until looking at it now. We'd want to reuse all that logic for: - computing the list of editors - knowing which is the default (so it will be the selected one in the combo) - adding and special handling "Other...". Item (3) is irksome wrt. effort required for this change, but the first two concern me because we miss out on important information to convey to the user. Darn it all we just want the correct button control from SWT! Sigh. I need to think more on whether this is worth it or not. It's great reducing UI oddities but not sure about in doing so trading off the amount of useful information available.
> Darn it all we just want the correct button control from SWT! Sigh. Too late in the cycle. It might still be a bit of a UI oddity if this was the only place in Eclipse 3.5 where the control was used. Getting the control in early in 3.6 might help this.
(In reply to comment #23) > > Darn it all we just want the correct button control from SWT! Sigh. > > Too late in the cycle. Yes I recognized that. The choices for 3.5 are: 1) refactor plus live with missing graphical hints 2) live with oddness of control as is > Getting the control in early in 3.6 might help this. This is what I was hoping for. In which case it also argues for not doing anything more in 3.5, since cost of refactoring and implementating the dropdown for it to be changed again in 3.6 doesn't seem like a good time investment.
Best would be a combo with icons (bug 93809). Second-best a native split button (bug 263659).
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
