projects ui recommendations

Hey folks,

I'm sending this out to a wide group -please respond to [email protected].

Here are the recommendations for UI changes to the Projects System. The document is the result of going through the recorded problems found in the Usability Study and matching up proposed solutions with requirements placed on Projects by groups building on top (J2SE, Mobile, Web Apps and Enterprise).

The recommendations are written out as they would be plugged into the UI specs -this is for clarity and to give an idea of how it would fit into the larger system. Once we have consensus on the changes we'll work them back into the respective UI specs along with additional clarifications to fit the whole thing together.

Please review the recommendations and provide your feedback on [email protected].

Recommendations document:

http://ui.netbeans.org/usability/April_21_03/recommendations.html

Usability Study Results:

http://ui.netbeans.org/usability/April_21_03/JavaProjectReport.html


The following is meant to give a brief summary of the the proposed solutions and how we arrived at them. For a full explanation of the problems, see the Usability Report. For a full explanation of the proposed solutions, see the Usability Recommendations.

1. Project Explorer

The main problems were poor visibility of the Active project for users, the Explorer was hard to parse, and objects sometimes appeared twice under the Sources node (as a class in a package and a file in a directory).

Solutions explored:
J-Builder type solution, which has only one project visible at one time. The visible project is the active project. The reasons against this were that Enterprise Edition needs to be able to display several projects at one time, because its solution is crafted around building several related projects at once. Also, it is necessary to have files from multiple projects open in the Source Editor at one time, which is not possible in the J-Builder solution.

Change the way Java classes are displayed, so that all java roots and their contents would only be shown under the Packages node and not under the directory (source root) nodes. This could still lead to some objects being shown twice. VCS also requires a file-based view for VCS actions.

Hide Output and Resources nodes by default. While this would reduce clutter, it was unclear that users would then know how to display them. Also, users looked for this functionality in the Project Customizer.

Proposed solution:
Separate the Explorer into two views: a Logical tab with the project logical views (for J2SE projects, the Packages node only) and Files tab with a pure file-based view of the files. Allow multiple projects to be concurrently visible in the Explorer. Keep the concept of an Active project with better indication through bolding the active project, making newly created projects active by default, and making it easier to set the project as active. Move Outputs and Resources to the Project Customizer.

2. Project Customizer

The main problem was that users looked for project settings, especially classpath and build settings, in one place (usually the Project Customizer) and did not know to look in the customizers for the other Explorer nodes.

Proposed solution:
Move all customizers from the various nodes and the Run Profiles to the Project Customizer. Don't display Outputs and Resources as Explorer nodes. The disadvantages of this approach are that you cannot browse through resources, since they are not visualized as Explorer nodes, and that you cannot do drag-and-drop of build steps into resources to create interproject links.

3. Java Root/Source Root Interaction

The concept of Java Roots confused most users, both in deciding which they should add and in how they were displayed in the Explorer.

Solutions explored:
Unify the Add action to just say Add Sources and then search for Java source roots automatically. 

Change the way Java classes are displayed, so that all java roots and their contents would only be shown under the Packages node and not under the directory (source root) nodes. See Project Explorer above.

Proposed Solution:
Unify Add command. All Java Roots are either contained in Source Roots or are themselves Source Roots; the IDE uses a heuristic to determine Java Roots contained some levels down in a Source Root tree. The Project File Location is automatically added as an implicit Source Root. All Java objects are displayed both in the Logical view and in the Files view. 

4. Profiles

Running a project was too difficult and people did not understand the Run Profile dialog. 

Solutions explored:
Keep the Run Profile dialog the same but add more explanatory text.

Proposed Solution:
Automatically create a Run Profile for a project if none exists. Automatically create a Run Profile for classes or runnable objects as part of the New wizard. Unified Run and Debug profiles and put them in the Project Customizer.

5. New Wizards

Users were confused as to which project template to use and by the context-sensitivity of the New File command. They often couldn't find which node they needed to right-click to get the right choice of file templates.

Proposed Solution:
Have just one Java Project template that can be used for both empty projects and projects from existing source; when we have templates for substantially different types of work (e.g. a visual framework project) we'll add them to the mix. 

Make the New File/Folder action available from everywhere in both Project menu and contextual menus. Have it show all file templates but have the templates that are unavailable grayed out. Have it always show target project and location information but have this information automatically filled in when the New command is invoked in a context-sensitive manner. 

The problem with these last two points is that they display information to the user that the user doesn't need or has already specified. The advantage is that they maintain consistency in the wizard and allow the user to change the target information if they inadvertently invoked the command in a context-sensitive manner (Control+N when the Explorer was selected).

6. Naming and Menu Changes

These can come last as they are dependent on how the other issues are solved.

-- 

ui.netbeans.org
interaction designer
[email protected]