Re: Alternative UI of Project Explorer

I think that current all-in-one UI design could be better for initial 
setup of projects and it's dependencies. But this setup does the user 
only once. When she creates the projects (later she does only some minor 
customizations). For day-to-day work Svata's Explorer looks better IMHO.

Regards,
Jan


cL wrote:
> i have seen the design and it has it's merits. i'm not convinced that 
> pushing Resources and Outputs to other tabs will increase their 
> discoverability but it's also something to consider. another thing to 
> consider is that without the idea of an active project it is a bit more 
> labor intensive to work with inter-dependent projects. e.g. if you have 
> three projects that are all connected to each other (via b.t. outputs as 
> resources) typically only one of those is the one you care to run. with 
> an active project the runnable project is set active while work 
> continues on other projects. without an active project the user will 
> need to switch to the desired project before running.  it's an extra 
> step that may, in the long run, not make that big of a difference all 
> things considered but it is something we need to be aware of.
> 
> one thing to note is that whatever the final design is it has to meet a 
> fairly large and diverse group of requirements. the project switcher in 
> that Svata suggested will be put on the table with other ideas and we'll 
> have to sort out the pros and cons of each.
> 
> cheers,
> cL
> 
> 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]
>>
>