Re: Alternative UI of Project Explorer

John Jullion-Ceccarelli wrote:

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

This not the way Svata's Explorer goes, the IDE has more than one open 
project, but only one is visible and you have easy way how to switch them.

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

This is a question, what is better to force the user to scroll by mouse 
and to lost herself in the plenty of open projects or to switch projects.
BTW the project switch exchange whole ExplorerPanel, so it keeps node 
selections, what is favourable behaviour.

>
>
> 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]
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>