Community
Participate
Working Groups
Build Identifier: All The list of wizards on the Select A Wizard dialogue is unusable unless you already know which you need. There are so many, that it's not clear which to choose or what each does. For new users and users exploring new areas, this is a usability problem of some significance. No doubt, for the community of programmers working on the same set of things day in and day out, the learning curve diminishes in importance but the yardstick for that set of users shouldn't preclude the improvement of usability for everyone else. The solution, I propose is to extend the dialogue a little and add a Webkit HTML renderer. Then all future wizard plugins can include an overview.htm, which may include a description of the wizard, its purpose and even diagrams showing say, a conceptual overview. Anything that helps a user to make an informed and quick choice. Legacy plugins can have a default overview.htm that may just reflect the name or which picks up a web based overview.htm, where possible by using the plugin's details to search for a candidate overview. PS I am a usability consultant and work with Eclipse regularly. Reproducible: Always Steps to Reproduce: 1.Check you're not searching for a particular wizard you KNOW will meet your needs but where you're confident there must be a wizard that will! 2.Click New > Other 3.Look for that wizard...
> The list of wizards on the Select A Wizard dialogue is unusable unless you > already know which you need. That doesn't sound like a good use case to me. Why would someone open up a New Wizard, without knowing what to create? If someone is new to a product and have no clue of how to start, then the Welcome Page and Cheat Sheets are the right place to start - not New Wizard.
(In reply to comment #1) > > The list of wizards on the Select A Wizard dialogue is unusable unless you > > already know which you need. > > > That doesn't sound like a good use case to me. Why would someone open up a > New Wizard, without knowing what to create? If someone is new to a product and > have no clue of how to start, then the Welcome Page and Cheat Sheets are the > right place to start - not New Wizard. The user is likely to know the concept or goal of the wizard they're after but not necessarily its name. Being clearer and providing more information right in the context where a user needs it cannot be a bad thing. Jumping out of context to read information is a bad usability move and is one of the reasons documentation is seen as a last resort. From your comments, I presume you're in the category of expert users who rarely use something new. You're not representative of the majority of users I have observed.
Just to add to what I said earlier and in response to Prakash G.R. I ran a weeks usability study on some new Eclipse capability we are shipping. In general (four out of the five) subjects habitually closed the Welcome page (missing the opportunity for samples, examples, &c.) and only very rarely resorted to the Infocenter for help. Their primary mode of operation is to explore the interface and this is where the added contextually specific information comes into its own. I don't suggest that there is only one mode of behaviour but I get concerned by the attitude that there's a best way, knowing that different users have their own 'best ways' and we should support them where possible.
This is an interesting idea. When the user browses for new software (through eclipse market place, or install new software, etc.) it is common that the software provides a description of what it's used for, and why you want it. (It's selling itself at this point). There are also ways to link for docs and description. Your proposal suggests that even installed functionality could use some discovery/selling points so that users could find out why they might want to choose a wizard, etc. That said, I think we'd have to see a patch from the community to consider doing anything, given limited resources. Key to the patch is to demonstrate (as you suggest) where the data should come (a default template, the feature description of the contributing feature, etc.) if none is provided. I think hitting the web for the info adds complexity (and honestly reduces the likelihood) to the implementation, as then we have to reexamine use of the UI thread, consider the disconnected case, etc. etc. Even in the "install new software" scenario, where users know they are browsing an external catalog, we have usability issues, so we'd have to be careful about that. For features that are already installed in the product, I would hope that the overview info is present in the system.
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.
