Re: [nbui] projects ui recommendations

Chris,

I like this. Although I do have some comments, these are fairly minor. 
Overall, I think it is a major improvement over the current state. If 
there are no major (showstopper) comments from anyone, then I suggest 
incorporating this into the Infrastructure and Java UI specifications, 
and then commenting on those.

Petr


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