Re: Re: projects ui recommendations

Svata Dedic wrote:

> Chris Le Dantec wrote:
>
>>> 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.
>>
>>
> [...]
>
>> 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).
>>
> It is an error to think about "Resources" and "Outputs" nodes only in 
> terms of managing the project setup. The way they were used in the 
> project explorer, they also provide browsing capabilities. Browsing 
> Output files may not be so useful once the user understands the IDE, 
> browsing Resources - external dependencies of the project - is quite 
> desirable.
> C.f. IntelliJ IDEA - both "sourcepath" and "classpath" project view 
> contain actually a mix of project own and external sources/ classes. 
> In Eclipse, external deps are browsed directly in the project 
> Navigator, as if they were items in the project's directory.
>
> In a sense, these use cases were supported in NetBeans 3.x, since the 
> IDE treated all filesystems (either those containing project's 
> contents and those used to introduce external deps) equally - so it 
> allowed to browse and search through the external stuff.
>
> I do not think that simply dropping the associated use cases because 
> of problems the particular UI design had should be an option, since it 
> degrades functionality compared even to NetBeans 3.1. 


output will still be browsable via the Files view. the resource browsing 
is something that could be added in for scenarios where it is vitally 
important. it was discussed by the group here and we agreed that tree 
browsing resources was not a likely activity; using code completion or 
javadoc tools is the much more likely task that users will use to browse 
resources.

>>>  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.
>>
> Chris, have you ever seen a dependency graph ? I wonder how you would 
> make such diagram fit into the Explorer window. 


sure, and it would be tricky, but my point is that it is up to the 
enterprise group to decide what is the most useful for their users.

>> 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 
>
>
> Solution is quite different from [current] Project Group: starting 
> with that there's at most ONE Solution opened at a time, while the UI 
> spec says there may be multiple Project Groups opened at a time.
> So any settings (startup project, ...) that is decided by (singleton) 
> Solution is ambiguous if set for (several) Project Groups.
>
> Solutions, for example, are the place where Configurations are created 
> or removed; the set of Configurations applies to all members 
> (projects) of the Solution. There's no such functionality in Project 
> Groups vs. Projects - set of Configurations is local to each project 
> and independent of other ones.
>
> So these two concepts are not really comparable in their delivered 
> functionality for fundamental reasons.
> Maybe we should precisely define what a Project Group stands for (now 
> IMHO: nothing more than an container that influences open/close cycle 
> of its children) to see whether the concept is useful at all or is 
> just another all-three-users case. 


there are some differences but i don't think any of them are fundamental 
in that what is done with a Solution cannot be done with a Project 
Group. right now there are no features associated with a Project Group 
so it's completely free to become something more feature laden for 
groups that need it. and it's arguable that for the time being groups 
that need the extra functionality be the one's to add it to Project 
Groups -at a later date if others see a demonstrable need for such 
features they can be moved around so more project types can take 
advantage of them.

cL

-- 

ui.netbeans.org
interaction designer
[email protected]