WTP 30 Facets Usability
Two of the major active themes for WTP 3.0, as outlined in the Web Tools Platform Release 3.0 Requirements, are "Improve the 'Out of the box' Experience" and "Ease of Use". To that end, one of the most widespread and initial actions a WTP user will perform is faceted project creation. It is always worth taking a step back and asking ourselves if there is room for usability improvements in this functional area. The following is one such proposal.
Imagine a scenario where the generic user never needs to go the facet selection panel. Imagine a scenario, where out of the box, the user just picks a pre-canned product project configuration and then hits finish from the first page of the new project wizard. Imagine a scenario where an advanced user maybe could have a team with one facet guru, who would be responsible for defining the custom configurations his team would use on a day to day basis to create faceted projects. This guru would open a configurations editor in the workbench preferences, select the facets he wants, save that configuration, and then export it using workbench preferences. Other team members could then import the configurations and decide which ones they want to show up in their new project wizards. Then, all they ever need to do is select the appropriate configuration from the first page of the project wizard and theoretically, hit finish right from there.
Please note the following screen mock-ups are not meant to be of pristine quality, but rather general thoughts on direction to take the wizards. It is understood visual clean up is necessary.
The Configuration Editor
The pre-defined "typical" configurations will be key. Adopter products could extend and ship with additional configurations, but WTP should have just enough base configurations. The idea is that the configuration editor really does stay an advanced option. But, we do want to make the configuration editor as easy to use as possible because we cannot assume everyone will have a "facet guru".
- This is a mock up of what the facet configuration could look like. This is a familiar look and feel based on the eclipse run/debug page.
- The facet configuration editor could create new configurations, edit existing ones, and they will show nested under the primary project type for ease of use. For usability when creating a new configuration, the facet list is filtered by what is applicable to the primary project type.
- These configurations would then be exported for use by each team member to import to their own workspaces. So, the idea is not every user would have to use this editor and be worried about such details.
Simplified Faceted Project Creation Wizard
Our goal is to hide the user from ever having to worry about facets. All they have to know is which type of project they want to create and away they go. This is the reasoning behind removing the facet selection page out of the wizard flow and into an advanced dialog.
- I generally agree with the premise of making the facets page be less prominent. It's not that users will be able to never worry about facets, but there is no reason to force everyone to interract with advanced configuration. There are two ways of taking this basic idea on. You either use a separate dialog or a checkbox that hides/shows the page in the wizard flow. I think the separate dialog approach is cleaner from UI perspective, but it's more work than the hide/show page approach. The hide/show page approach has an existing enhancement request: 143075
Can we come up with a better name for "Add/Modify Facets"?
- How about "Modify..." or "Modify Configuration..."?
- User enters project name first.
- Project location would now hidden by default, and can be expanded by clicking the "Project Location Details..." button.
- I am worried a bit about making this standard section different from other Eclipse wizards.
- The primary facet version for the type of faceted project would now be set on the first page by the user.
- This is an important usecase, but there are a lot of technical details to work out. I'd change the order and present the target runtime first and let that influence the supported spec version. Users are typically constrained by a particular runtime. Currently the defaultFacets extension point lets runtime author specify the versions of facets that are selected by default. If we add spec version as an extra bit in the equation, the extension point would need to be revised to be able to handle this case. There is not enough information currently in the model to implement this UI. Need to think more about this.
- The user would then select a target runtime, with option to create a new one.
- The user would then select a pre-canned product configuration or a configuration given to them by their organization. If an advanced user wanted to modify the facets for _this project_, they would select "Add/Modify Facets". This would take them to the facet selection page in a dialog. This facets page would no longer be the second page in the wizard flow. Once a user changes the facets, we would switch the configuration to "Custom". If the user were to then switch to a different configuration, they would lose the previous changes and get the default for that newly selected configuration. The user would have an option in the advanced dialog to open a link to the configuration editor, where the current selections would be defaulted in, and they could give the new configuration a name and save it from there.
- The configurations drop down would have hover help descriptions to the right of it like the JDT content assist does. Once selected, a detailed description will display under the combo box. The hover help is meant to display a few sentences about what support that configuration will give the project. It will not go into specific facet details, but be user understandable features or higher order descriptions.
- I am not sure i understand this suggestion. Is the idea that we would replace the paragraph beneath the drop down with a fancier UI? I heard a comment at the meeting that we would make the allocated space larger for longer descriptions. The existing UI will already resize the space if more than two lines are necessary.
- The user could then select to add to an EAR.
- The next pages in the wizard would be the facet install pages for the selected facets in the new project. The complex facet selection page will not be in this page flow. Optionally, a novice user could just hit finish from the first page.
Suggestions for the Facets Panel on a Project's Properties
- Can we rename the option to view/modify facets to be something like "Project Support (Facet Details)"?
- Why is that better?
- In the current project properties dialog page, the "add/remove project facets" button seems unnecessary. The display/information/features in the “Add/Remove Project Facets” window, should replace the “Project Facets” shown on the main page. (196484)
- This is one that's made frequently, but is not feasible technically. When a user changes facets, wizard pages related to those facet actions need to be displayed. You cannot displayed wizard pages while embeded inside a property page.
- The right side of the facets panel should be a paragraph description for the currently selected facet. The runtimes could then optionally pop out like a drawer on top of the descriptions.
- An alternative or maybe in addition to this is to integrate with dynamic help so that selecting a facet and hitting F1 will display help content for that facet... 135950
- If we do end up going the suggested route, there is enough real estate there to display more than just description. What else could we put there that would be valuable. Facet constraints is a valuable piece of information, but that takes a lot of real estate (maybe we could have a link that pops up the existing constraint display dialog).
- Does it make sense to keep the drawer construct or would it be better to switch to tabs?
- 191714 - Some facets have no need for a version, add to extension a way to say I have no need for a version, and then the version would hide from UI
- 191716 - No context sensitive help, especially for the runtime section, maybe more descriptions
- 191717 - No convert action to enable a way to add facets to an unfaceted project