Re: Alternative UI of Project Explorer

I think the main question is whether or not it is safe to assume that 
one project is open at a time is a reasonable constraint. I believe that 
the web apps team is splitting up a web apps project into lots of 
smaller sub-projects that are included in a project group. If this is 
the case, it may be unreasonable to force the user to switch between 
projects all the time.

I do like the idea of making a cleaner separation between the Sources 
node and the Packages node. Regardless of what happens, we may want to 
shift Sources to a different tab. I believe that when we discussed this 
before though in a thread about how the Add Sources functionality 
worked, Chris said that web apps projects could not have a completely 
Physical view of their contents, but I never got the specifics.

-John

Jan Becicka wrote:

> Hello,
> Usability Study of the Second Prototype 
> <http://ui.netbeans.org/usability/April_21_03/JavaProjectReport.html>
> shows several problems. One of those issues was the concept of active 
> project:
>
>> The concept of the Active Project was not understood and contributed
>> to problems for each of the participants. In the best cases it took the
>> participant several minutes to understand that there was an Active
>> Project. Most of the participants never came across the idea Active
>> Project and had to fumble around for a long time before finding context
>> sensitive actions that allowed them to bypass using the concept.
>
>
> Svata Dedic designed alternative "Project Explorer". His projects can 
> be found at <http://lit.fsid.cvut.cz/~svata/nb4dev/index.html>. The 
> Project Explorer can be downloaded in form of a nbm module at 
> <http://lit.fsid.cvut.cz/~svata/nb4dev/modules/projects-ide2.nbm>
>
> This proposal was probably overlooked on this mailing list, but I 
> think it is very interesting and someone (probably from UI team) 
> should definitely look at it. I think it could solve lot of issues. 
> Let's look at the UI study in details:
>
>
>> BUILDING AND RUNNING PROJECTS
>>
>> Issue: A participant uses "Build Active Project" toolbar button or
>> main menu item to build a non-active project.
>>
>> Analysis: Active project is not understood. Partly because the active
>> project is not highlighted well enough -the little noticed '[active]'
>> text next to the project name is lost in the jumble of text and nodes
>> in the project explorer.
>>
>> This problem is exacerbated because the IDE starts up with an example
>> project that is set active (and new projects do not automatically get
>> the active setting).
>>
>> Recommendation(s): Make the active project title bold and re-order
>> the project nodes to improve discoverability of both Resources and
>> Output node as well as create some visual space between the bolded
>> title and the content of the Sources node.
>
> .
> .
> .
>
>> Issue: A participant doesn't notice that the build output results
>> belong to a different project than he wants to build.
>>
>> Analysis: Symptom of the Active Project issue.
>>
>> Recommendation(s): See above + do a better job of making the compiled
>>
>> project title noticeable in the output window. See bug 33604
>>
>> Issue: A participant doesn't compile a project, only a class using a
>> shortcut, main menu, or contextual menu of the class.
>>
>> Analysis: Work around for Active project issue.
>>
>> Recommendation(s): See above. See bug 33604
>
>
>
> The main idea of Svata's alternative Project Explorer is simple. The 
> user will work only with one project at given time (however other 
> projects can be still opened). And this is reason why Project Explorer 
> shows only one project - the Active one. What you see is what you get. 
> Project switching is implemented as combo box. See pictures:
> http://projects.netbeans.org/servlets/GetAttachment?msgId=510784&attachId=1&listName=dev 
>
> http://projects.netbeans.org/servlets/GetAttachment?msgId=510784&attachId=2&listName=dev 
>
>
> The advantage is obvious: there is no doubt which project is active.
>
>
>> The visual representation of the active project need to be improved
>> 100 fold. Bolding the project title is probably the least that should
>> be done to signify that the project is active. Other visual cues
>> might involve changing the explorer background behind non-active
>> projects to a light shade of gray (not enough to look disabled but to
>> draw focus to the active project with the white background).
>>
>> Project wide actions need to be clearly labeled and have easy to
>> understand rules to avoid the current context ambiguity between build
>> and run (build applying to the current selection and run applying to
>> the active project). Create a small set of duplicated actions in the
>> main menu should be enough -Build, Run, Debug (with the standard
>> shortcuts) apply to the Active project and Build <project name>, Run
>> <project name>, Debug <project name> would apply to the currently
>> selected or context-active project.
>
>
>
> Visual representation of active project in Svata's Project Explorer is 
> clear. Simply what you see in Project Explorer is Active.
>
> Moreover this Explorer could significantly improve usability of 
> Sources, Output and Resources Node. Explorer has (or will have) 4 
> tabs: most important Packages tab (java oriented view on project 
> sources), Sources tab (file oriented view), Resources and Output tab. 
> This layout is similar to VS.NET, isn't it?
>
> Let's take usability study again:
>
>> Other Issues - Communication
>>
>> Project structure is unclear and hard to decipher with even one or
>> two small projects open.
>
> .
> .
> .
>
>> Conclusions
>> # Reorder Top Level Project Nodes
>>
>> Changing the order of the project nodes should help bring more
>> attention to the Resources and Output nodes. When the Sources node is
>> expanded these two nodes get lost in the lower parts of the explorer
>> (even with a small project) and overlooked. The argument at the time
>> was to move them down because they won't be used much -but for just
>> that reason they should be kept at the top. The two are unlikely to
>> be expanded so sources will likely be visible and by having them
>> between the Sources node and the Project node they should be much
>> more discoverable.
>
>
> Having Resources and Output nodes on separated tabs could bring more 
> attantion to themselves I think. Moreover Explorer tree will flatten 
> and the user will not get lost in the huge tree.
>
> UI guys, did you look at it? If not, please do it. I don't say, that 
> Svata's Project Explorer is perfect, but it definitely worth trying.
>
> Jan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>