Re: projects ui recommendations

i'm just calling attention to this again bcs it's been quiet. this is 
your chance to give feedback.

cheers,
cL

Chris Le Dantec wrote:

> 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]