Community
Participate
Working Groups
Improve UI affordances. There are a number of areas of the UI where Eclipse is not providing enough cues to the user (e.g., no cue for available help, no cue for maximize/restore view, no cue for mandatory/optional fields in wizards). Make a systematic pass though the UI to improve its affordances. [Platform UI] [Theme: User experience]
Dejan Glozic: "Right now, getting context help in Eclipse wizards requires pressing F1 key. Since keys are accelerators for commands accessible with other primary command vectors, why is it that we don't have a way to get this command executed explicitly (through some kind of a 'Help' button)? I know that F1 is standard but so is 'Ctrl+C' and you still have 'Copy' menu item and often the equivalent tool bar button. ..." Konrad Kolosowski: This is nice improvement since not everybody is aware of F1 (or Ctrl+F1 or HELP or whatever this is on every platform ). The key mapping may even prevent these shortcuts to work, as is the case with default KDE mapping in RedHat8,9 or Suse 8.1. Having a button would definitely help. I think a button equivalent to F1 will require special support from SWT. Currently F1 invokes help handler on the widget in focus. If a separate button is provided, it either should not grab the focus from widget that had it before, or work in the way that involves clicking the help button and subsequently any widget of interest. That would need to invoke a help handler. May be there is some other paradigm on different platforms that SWT should handle natively. I would suggest involving SWT, or at least consulting with them if their support is needed.
Adding reference to 28072 'Show keybindings on menus', which is candidate UI affordance for 3.0
I fully agree with is plan for improvement. Especially the suggestion for HELP buttons! As I wrote in bug 43818/37666: "Eclipse is a GREAT platform but difficult and scary for new users. One of the key reasons it is scary, is that the basic HELP feature is missing. I am not taking about something advanced - just what just about what every easy-to-use (Windows) application in the universe has.... What I am refering to is simple HELP buttons and/or icons!!! What I would like eclipse to have is a HELP button on EVERY eclipse dialog. The user presses it and the eclipse help screen is launched, pointing to the corresponding section in the documentation. Help buttons/icons will only help usability of eclipse in general (a lot in fact), it is absolutely required for the new friendly "rich client applications" targeted towards non-developers (many of which would never think of pressing F1 or be satisfied with the incomplete help F1 currently provides). If eclipse GUI components does not have HELP BUTTONS/ICON they may be unusable for many end-users and eclipse will be a less interesting rich client platform. so please HELP :-)"
This relates to 28072/15079 (talking about hover/context menus) but is a little more general. As I recently overcame the learning curve as a first time user, I found that I would try and use the context menu wherever possible. e.g. right-click and "Open declaration". I had a few (related) issues) a) Couldn't find keyboard shortcuts for context menu actions (now they are shown in 3.0 ,okay) b) Initially couldn't find how to redefine keyboard shortcuts. What really threw me was the "Window->Keyboard shortcuts" menu. This would be the obvious place to look ; I didn't know then that *everything* was in Preferences. I did eventually find it in Help system.- more under "bindings" than "shortcuts". A hint in the "Welcome" page would be nice, or a shortcut in the menu which takes you to the preferences. c) I learnt that to find the shortcuts for a context-menu you had to find the original menu, e.g. Navigate->Open Declaration. It would be useful if there was someway to find where a context-menu item actually comes from ; I found that i was missing out on lots of navigate,refactor,source options since I was only using context menus. I'd suggest (if possible) a hover hint on context menus (say after a second or so) which appears without obscuring the rest of the menu. This could give the keyboard shortcut and original menu location. d) Taking the menu hover hint further from (c), you could give a description of what "Refactor->Use Supertype Where possible" actually does!! in the hint Perhaps, so that users don't get stuck into a narrow tool set, other commands could be suggested in the tooltip (a bit like ebay or amazon) ; "if you like refactor->rename, then try these other commands from the full menu".
any comments? are these worthwhile ideas? i can raise some additional (feature request) bugs if anyone thinks they're worth raising. - but this looked like a good bug to put some ideas onto. Thanks :-)
These are all good suggestions. It would help to have separate bug reports for them to track them individually. b) A "Customize..." item in the Keyboard Shortcuts menu would be a good breadcrumb. Having it in the Welcome experience is worth considering too, though we generally want to avoid overwhelming the first-time user with advanced options. Perhaps a single "Customizing the product" item point to a decent help section would be good. Dejan? c) The context menu contains frequently used, context-sensitive items, not all available items. These may correspond to items from different main menus. However, I understand the problem in guessing the appropriate category in the key bindings pref page if you primarily use context menus. It would help to be able to look up a command by name here. d) Interesting idea. We used to show a description of the armed menu item in the status line (some other apps do this too, e.g. IE), but nobody noticed these. This could work similarly to the Javadoc hover you get when using code assist in a Java editor.
The new wizard dialog now shows a ? icon if help is available for the selected wizard. We could use the same approach for other dialogs that have F1 help available. Whatever we do, the affordances for help should be consistent across the Workbench.
In response to Nick's comments to me above, I have so far raised b) 55865 (keyboard shortcuts awareness) & c) 55866 (hover hints on context menus / descriptions)
deferring
On second thought, I should not have deferred this bug but rather, described where we have been successful and ensured that some of the other items do not get lost. UI Affordance improvements: 1) Help - see Comment #7, ui affordance for help in the new wizard is a starting point. Also the support for CheatSheets contains help hooks. 2) View/Editor minimize & maximize - affordances have been added for these 3) Key Bindings - see Comment #2, when a user adds a key binding it will show up in the menu if there is an associated menu item. bugs logged for future ongoing work: bug 55865 (keyboard shortcuts awareness) bug 55866 (hover hints on context menus / descriptions) bug 65367
Also, we have also submitted a fix for: bug 22071 [Editor Mgmt] Graphical hint for pinned editor which should be noted here.
Adding Susan re: mandatory/optional fields.
