Re: projects ui recommendations

Peter,

comments below.

Peter Wisnovsky wrote:

>Chris Le Dantec writes:
> > 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).
>
>Some thoughts.
>
>- I'm not sure I like the removal of the output and resource trees
>  from the explorer. The explorer paradigm seems to me to be
>  fundamentally designed to support drag-and-drop. If we remove the
>  output and resource trees, we don't seem to be exploiting this drag
>  and drop capability. Perhaps I'm more sensitive to this because in
>  SE (nee EE) we would expect that this feature might get used more
>  than in other editions, as logical applications would always be
>  decomposed into multiple projects linked by output-resource
>  relationships.
>

the working assumption when we decided to move resources and output to 
the customizer is that having the information around persistently in the 
explorer doesn't add much value for the amount of additional clutter it 
adds to the explorer. having the ability to drag and drop outputs from 
one project into the resources of another is a useful thing but even 
with very interconnected projects this activities is limited in 
frequency. as with most setup activities they aren't likely to be an 
ongoing, many time a day task (the kinds of things where drag and drop 
offer the most in user aid).

to address the ee issue it should be possible (though i don't know if it 
makes sense to do so) to have many of the inter dependencies setup via a 
template.

>  An alternative would be to have a "project relationship view" that
>  would omit sources and ONLY show outputs and resources. Perhaps even
>  a spiffy graphical view would be good...planarizing a DAG into 2-D
>  graph is much more comprehensible than a tree, which is necessarily
>  limited since a tree can only show containment graphically, not
>  arbitrary relationships.
>

this is certainly a possibility and the infrastructure spec explains how 
something like this would turn up as another tab in the explorer.

>- I confess I've never been crazy about the idea of an active
>  project. For SE the "product" corresponding (at least in our current
>  discussions) to the project group that holds the component projects
>  (web module, ejb module, etc.) is, I think, to the user the "active
>  project". For example if Netbeans itself were implemented with the
>  project system, each module would presumably be a Netbeans project
>  -- yet I would consider that I'm working on the "Sequoia project",
>  not the "jwd project".
>
>  This was one of the reasons I suggested earlier that there be a
>  versionable scope that holds projects together that is a top-level
>  singleton in the IDE...not necessary an outer project, but something
>  like a Visual Studio "Solution", WebSphere "Enterprise Application"
>  or WebLogic Workship "Application". Forcing this outer scope would
>  make adding new projects to the group much cleaner, I think, and I
>  don't think this would take away any functionality, though some
>  tasks would necessarily be accomplished differently.
>

your objection to the concept of active project seems more a disguised 
request for a vs 'Solution' like feature. to start with, we already have 
the concept of a Project Group that collects any number of projects 
together. the Project Group does not have a lot of functionality tied to 
it but it was built with extension in mind -addressing many of the 
issues you and i have chatted about off-line. that being so, there is 
still a need for an 'Active' project as a mechanism to run the desired 
project when working on several at a time. i think one part of your 
concern is the term active bcs it doesn't have an obvious sense for the 
user (active typically being the thing currently being worked on). we've 
recognized this and have come up with several other suggestions -i think 
the current term edging toward the front is 'Startup Project'. this 
certainly has more sense in the project group use as well as being more 
distinguishable as a special state than the 'Active Project' moniker 
conveyed.

cheers,
cL

-- 

ui.netbeans.org
interaction designer
[email protected]