Re: projects ui recommendations

Peter Wisnovsky wrote:
>  > 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).
> 
> Hmm...perhaps not for Netbeans, but again, I think that, in S1S,
> because of the way we map J2EE artifacts (including web modules) to NB
> Projects and J2EE references to resource/output relationships,
> visualizing these relationships might be rather more important than in
> the NB IDE itself. Moreover, as I think Svata is getting at, there is
> a visualization component here as well. When editing complex J2EE
> applications -- or even just a complex web application --
> understanding context in a top-down way at a glance is going to be a
> big help to figuring out which artifacts relate to which other
> artifacts. By their nature it is easier to get lost in a complex
> distributed application spread over multiple projects than in a single
> web or Java project.
> 
> However I can understand the desire to not try to solve too many
> problems with the same view. A separate "dependency viewer tab could
> work out fine, as long as the use cases are addressed in a way that
> will make sense to the user. You suggest that coming up with a
> dependency viewer might be an SE ("the edition formerly known as EE")
> issue to deal with. This is possible, but is implicitly a shift
> between the two versions of the UI specification -- in the previous
> version we had regarded dependency visualization as the province of
> the Explorer. I think we can agree that what would be worst is to have
> two incompatible dependency visualization solutions: even without EJB
> modules applications built with Netbeans using the web module can
> easily have complex library dependencies, so I'm not sure this is
> really an SE-only issue.

what we need to do -and are doing over the next couple of weeks -is take 
a close look at the requirements the different application development 
groups have. we'll then be in a better position to to figure out where 
the visualization support belongs.

i don't think that means we have to use the same type of visualization 
for all solutions -it would be bad to duplicate the same solution but 
subtlety different problems will see more benefit from tailored 
solutions. something to consider at any rate.

> 
>  > 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.
> 
> I don't think templates will work here, since interdependencies will
> be added as projects develop, just as they do in the course of
> netbeans module development.

certainly dependencies grow organically as development grows, i'm just 
asking for is if there is a known starting point. that's the point where 
a template will help but certainly not be an end-all solution.

[snip]
>  > your objection to the concept of active project seems more a disguised 
>  > request for a vs 'Solution' like feature.
> 
> My goal is to raise the visibility of the required use cases to
> determine if the suggested solution -- using project groups -- can
> adaquately address the use cases, and if not, see if there is a middle
> ground that can be reached which doesn't invent something wholly new
> but that is sufficient for this release cycle. I believe that project
> groups can address some of the most important issues -- having a file
> I can open and close that represents a consistent set of projects from
> a versioned base, for example -- but I have lingering concerns about
> usability. The main issue to my mind is the amount of rope we give
> users.  As currently proposed project groups can be used well or
> badly. For example user A can just as easily create projects whose
> dependencies go outside their group as inside. In this case user B has
> a tougher time tracking everything down and assuring themself that
> they have a the same set of projects open as user A. I believe it is
> worthwhile to impose a few constraints on project groups to make
> harder to use them badly.
> 
> I guess this boils down to a "negative use case": things I shouldn't
> do should be possible, but not as easy as the "right" thing.

i completely agree. as they stand now project groups exist but have zero 
rules associated with them. that leads to lots of rope, as you point 
out. the good news is that given more specific requirements we can 
establish a reasonable set of rules that takes up much of that slack.

>  > 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.
> 
> Yes, this is more clear. "Active" suggested "selected" to me, which,
> if it really worked that way, could get really confusing if people
> said "Execute" and the system derived "active project" from the UI
> focus. "Startup project" sounds better, though I suspect some users
> will think that this is a project that get executed when the IDE
> "starts up".

Main project was tossed around too. suggestions are always welcomed -and 
i recommend that we put much of the naming to the end of the design 
process. as we gather more requirements and get a clearer picture about 
some of the functionality the way we name that functionality should 
become a bit more clear as well.

cheers,
cL