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
Discussion Notes 07/19/07
- Basing off configurations is a valid approach, however there are potential usability concerns like the number of configurations that get created, the length of their names, and the ability to properly describe what facet capabilities are included.
- Fixed facets are what the facet framework is aware of, not project types or spec type.
- Dynamic configurations are new in WTP 2.0 and add the flexibility to morph what facets and versions are selected based on what project type and runtime selected. Also, new in WTP 2.0, static configurations can extend another configuration, either dynamic or static.
- Exporting configurations and sharing between workspaces is a good idea.
- On the configuration editor, the runtime selection is missing, because some facets may be constrained by runtime, and we don't want the user to create an invalid configuration for their runtime.
- Any thoughts on tackling after a project is created, maybe trying to apply a configuration? This would invove proper facet uninstalls and version change operators which we currently don't have.
- There is a default facet extension pt which is associated with a runtime type and version, and picks what is selected by default.
- On the wizard page, runtime composite should go before project version, because users are typically locked into a runtime. If we tie this now to the fixed facet version, by putting version on first page, how do we weave in facet version into the default configuration without breaking current extensions?
- We should select the JDK used by what the runtime has. I think we do this today?
- Project version is tricky, this is a key piece of information, so it should be on first page, but facet framework knows nothing of project types or spec versions so how do we come up with new default configurations ext pt to drive the screen flow properly?
- EAR Membership also presents another interesting problem because it drives facet and runtime chages. When it gets switched, it can change a bunch of stuff, would need to revisit so that it doesn't mess up the new flow? Maybe move to the J2EE facet install page and remove from first page?
- We should allow the changing of spec version levels on J2EE projects.
- Is it worth showing the current UI and ideas to the Foundation's UI Best Practices Group? The implementation details maybe too complex?
- Let's still stay high level and not worry about implementation details yet.
- Do we have enough resources? What can we contain?
- Review existing bugzilla enhancement requests and those described here and break down the lists.
- Draft long term plan and goals. Prioritize set of proposed usability line items.
- Come up with obstacles to make these ideas possible. A big obstacle is the spec version on first page and how we map data flow as it relates among these four main fields. Can ear membership be removed from first page?