Re: Project Groups - UI proposal ready

And some feedback from Todd Fast (moved from IZ to the list for easier
discussion):

-------

> - I am not comfortable with the idea of basic and advanced modes, at least in
> terms of presenting them directly to the user via something like a menu item.
> These seem more like a choice when creating a group, so why not instead use a
> toggle in the Create New Group dialog (when the user hits the toggle, he's
> presented with more or fewer options)? The user shouldn't need to check a box in
> one place just to customize a feature in another place.
> 
> - Groups should definitely stay away from any sort of build dependency
> determination--it's way too easy to screw up complex builds. For example, the
> composite application project in Enterprise Pack has to do some interesting
> things during a build, and it would not be easy to externalize that information.
> This seems like much less of an issue if groups are not presented directly in
> the project view and are just invisible sets of projects that are opened as a
> unit (i.e. there's no node on which to put a "Build" action for the group).
> 
> - I'm not really clear on the value of the autosynch feature. It requires a lot
> of explanation to the user for what seems like a dubious feature. I think the
> whole story could be simplified by removing the autosynch feature, and just give
> the user the ability to snapshot the current set of projects to the current
> group, or to a new group. As a user, I really don't care about the subtlety of
> marking a group as tracking what projects I open, especially for then switching
> between that group and others. I would quickly lose track of which groups are
> autosynching and which aren't, much less why. Can you give an example use case
> where autosynch *on a named group* would be helpful?
> 
> The use case that autosynch seems to be trying to address is in the shutting
> down of the IDE and restarting, in which the user would like to see the last set
> of projects he had open previously. However, does solving this use case require
> inventing a new group kind and pushing those kinds of decisions onto the user?
> As a user, I don't care about giving the "last session" group a name.
> 
> As an analogy, I use a plugin called SessionSaver in Firefox, and it has the
> ability to snapshot the current set of pages and give them a name, or when I
> open up the browser after a restart, it restores the last session. It has a
> special session, called "--", that represents the session from the last
> shutdown. If autosynch is trying to solve this use case, then perhaps a similar
> approach would simplify things.
> 
> - How are dependencies for master projects determined? IIRC, there is no
> standard approach to defining project dependencies, though there is one
> implementation in the Java project infrastructure. For example, if I have a
> composite application project with dependencies on BPEL projects, XSLT service
> projects, Java EE projects, etc., how will the group system know these are
> dependent? Are you proposing a standard approach for this? If not, and this
> would only work with Java projects, for example, then I think that's a
> showstopper for the master project group concept.
> 
> - Have you given any thought to using groups to hide projects from the view,
> even though they are still open in the IDE? For example, for master projects, I
> think it will be critical to be able to hide projects from the full list of
> recursive dependencies (when it comes to opening all dependencies, the thing I
> want to do first is hide some of them, especially in NB's flat project list).
> Without this, I feel like master projects will be much less useful than they
> should be because they will tend to overwhelm users. Imagine opening a
> highly-connected NetBeans module... By the way, persisting a list of hidden
> projects may be justification for persistence of the group information in the
> project.
> 
> - I agree with Wade that groups being something outside of the sharable
> information set for projects makes the feature less useful. In team
> environments, this is a drawback, and I'm sure that some of the first questions
> or RFEs received about groups would be about sharing them. Furthermore, I know
> I'd hardly ever use groups if there were no way to easily persist that
> information between user directories. Has the idea of a special group project
> type been considered instead (I'm certain it has, but why was that option rejected)?
> 
> - An alternate proposal for groups that would eliminate the shareability issue,
> but result in a drastically different design: The Module Manager uses a simple
> category name in the module manifest to group modules into categories. This
> works quite well to reduce the complexity of the module view. Could we use a
> similar approach for projects by persisting names of groups a project is
> associated with into each project? This would allow the user to group projects
> into subtrees of the main project view and thus reduce visual complexity, though
> it would require users to manually open projects in order to see them (unless
> they are automatically opened by virtue of project dependencies). This would
> solve 90% of my personal use cases for groups, as I usually don't care how many
> projects I have open at a time except for how it affects my project list view.