Re: Projects tab UI

Vitezslav Stejskal wrote:
> Hi Svato,
> 
> here are my answers for your more UI oriented questions:
> 
> Svata Dedic wrote:
> 
>> Things, which are not obvious (to me) even after reading the UI spec 
>> (please consider these as clarifications requests for both 
>> functionality and the UI):
>>
>> * Could an already opened projects be added onto a Workplace ? 
> 
> Programaticaly, opening/closing the projects has nothing to do with 
> showing/hiding it on the projects tab. However, the user shouldn't see 
> any difference. So from users standpoint the answer would be: no.
> 
A ProjectDesciptor could be opened programmaticaly using 
ProjectManager.open(). Has such project to be closed before it can be 
placed (and reopened) on Workplace ?

>>
>> * Could one remove a project from the Workplace without closing it 
>> first  ? (a counterpart operation for the first one). 
> 
> Not using the public API. And again the user should see only one version 
> of 'Project Close' action, that one which closes the project and removes 
> it from the Projects tab or do you have usecases questioning this approach?
> 
I am not clear on designed role of Workplace API. Given that a project 
can be opened (manipulated, ...) without opening on Workplace, I assumed 
the Workplace is a layer above ProjectManager.

>>
>> * When a project is closed, should it disappear from the Workplace ? 
> 
> I am not sure about this. The uispec says that it should dissapear, so I 
> do follow this.
> 
The UI spec does say that the project tab contains "currently opened 
projects and project groups".
However the workplace can contain even closed projects (under the same 
UI spec), provided that they are contained within a group.

>>
>> IMHO currently "Close" on a project does not seem very consistent -- 
>> when the project is in a project group, its node remains on Workplace. 
>> If it is not, it is removed from it.
> 
> That's true, but when user closes the project in the group she doesn't 
> mean to modify this group by removing the project from it.
> 
Yes, but I am not getting why the *same* action, "Close", behaves 
differently based on whether a project is present in a Project Group.
For consistency, closed projects should remain in Workplace until they 
are removed by the user. I know it is in the UI spec, but there are no 
reasons or backing by use cases for such behaviour (as usually).

Consider this situation:
Scenario 1:
* create a project A and a project group G
* close A -> A disappears from the root level

Scenario 2:
* copy A to group G and expand G
* A is now accessible from 2 places in the Workplace node.
* Close A -> one of the appearances disappeared.

For me as "dumb" user, project groups are just way how to organize 
things (btw I was quite disappointed when I was required to give a 
filename for a project group I was creating). Why should "organized" 
project nodes behave differently from "unorganized" ones ? That's not 
very intuitive, IMHO.

I would rather follow Microsoft Visual Studio's approach -- they present 
closed projects in their Workspace and the user is in charge to 
Load/Unload/Remove them.

-Svata