Re: Alternative UI of Project Explorer

Tomas Zezula wrote:
> 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. 
> 
> 
> Svata's Explorer can keep the notion of Active Project, (the project 
> will be marked as active in the Project Bookmark List), but I don't 
> think that this is good way,
> remeber that at the beginning the ActiveProject was jast a "work around" 
> for operations that were not able to find out the current project. From 
> the UI study
> it is obvious that the notion of Active Project is not understood by 
> users and probably should not be made "the first order IDE citizen".
> 

hmmm, I thought that curently selected project (visible) _is_ active
project.

I still think that there should be a good action context concept. I mean
we have global actions and context sensitive actions. However some
actions are presented as global but in fact they need a context.
Sometimes it is acceptable  for users, for instance actions that use
explorer's selected node are ok because explorer is main component of
IDE. But ask beginer users whether they know why Tools menu is always
changing.

The problem appears when you have another context, in this case
projects. We invented Active project which is a workaround for that but
it doesn't solve the real cause of problemn which is inconsistence in
actions.

What I would like to see is a model where a context action invoked from
a context menu would behave as expected but a context action invoked
from the global should show user the context. For example, every project
related action would display project chooser, etc. Now you can say - hey
does it mean that I would have to choose a project whenever I use such
an action? No, project chooser may for instance present selected project
as a default value.

-Martin

>>
>>
>> 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. 
> 
> 
> I agree, we should go through both versions of Explorer and choose the 
> best of them.
> 
> Tomas
> 
>>
>> 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]
>>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


-- 
_______________________________________________________
Martin Ryzl <[email protected]>
Software Engineer, Forte Tools
Sun Microsystems, Inc., Software Platforms and Products
Phone +420 233 009 130 (x49130), Fax   +420 233 009 299