Re: Packages node UI spec - underspecified and hard to read

Svata et al:

Svata Dedic wrote:
[snip]
> * Collapsing - where it happens ?
> Does it happen only from at the level of direct children of
> the Packages node ? Anywhere in the structure, where there are
> several empty levels ? Coalesce infinite number of levels (up to
> the first non-empty), or some limited number of levels ?

the collapsing should only happen on direct children of the Packages node.

there should be no collapsing of nodes under other individual package nodes.

> 
> * Dynamic behaviour of collapsing
> If last data item in a level is deleted, should the structure collapse
> into a single node ?

it should collapse only if the parent of the node is the collapsed node.

> If a data item appears, such as result of some tool operation or
> external operation, should be the structure expanded ?

yes. following the rule above if there was a collapsed package 
o.nb.m.f.b and sources turned up in o.nb.m then packages f and b would 
be nested hierarchically under o.nb.m.

> 
> The following standard operations are not covered at all by the UI spec:
> 
> * Rename, Delete, Copy, Cut: these actions is not present in the
> [individual] Package node's action list. Will they not be there ?

they should all be there and rather straight forward: the act on nodes 
even if the node is a composite of more than one thing. so 
rename/delete/copy/cut on a collapsed node manipulates all packages that 
node represents -a warning box will prompt the user in the case of 
delete and cut since everything contained will also be affected.

> 
> * Rename: What the user should see in "Rename" dialog ?
> Full package's name or just the last component ? If the former,
> how exactly will the rename operation proceed, if the user
> changes names of more components of the full package's name,
> enters fewers components or more components ?

it shouldn't matter if the user enters fewer or more components 
-whatever belonged in the outer most package still belongs in the outer 
most package regardless of what it is called. so if the collapsed node 
is o.nb.m.f.g and it gets renamed to o.nb.m.f.b.f the whatever was in g 
is now in f and the additional components are created on disk.

> 
> * What will "delete" operation on the node do ? Delete everything from
> the topmost folder(s) collapsed into the node ? Delete only folders
> that correspond to the last component ? Different "delete" action UI ? How
> it should look ?

if you delete a package then you delete its contents. deleting the 
collapsed node will delete everything it contains -this is why we'll 
warn the user.

> What should be done when the node is destroyed programmatically (abstract
> delete action for the node) ?

same thing but i'll need a more concrete example.

> 
> * How exactly will Paste action work on the collapsed node ? Paste into
> folder that correspond to the last collapsed component ? Give the user a
> choice when there's more matching folders ? Offer a choice to paste to
> any level of the collapsed structure ?

i imagine we'll need to go the route of the last option and provide a 
little dialog that lets the user specify where to paste the object. if 
there are multiple Java Roots making up the collapsed node the user 
would need to choose which to use and which package level to paste into.

something like:

+-------------------------------------------+
|                                           |
+-------------------------------------------+
|                                           |
| Select the location to past the file to.  |
|                                           |
| Package: |_o.nb.m.f.b___________________| |
|                                           |
| Root: |_c:\this\root\thanks___________|V| |
|                                           |
|                         [ Ok ] [ Cancel ] |
+-------------------------------------------+

Packages default is the last level in the collapsed structure

Root default is the first root in the active b.t. (? -not sure about 
this but trying to make a guess that would somehow jive well with the 
rest of the setup and since the b.t. root order determines conflict 
resolution i thought i go with that)

> 
> * What will "Copy" and "Cut" operations do on a collapsed structure:
> - entire structure from the topmost folder(s) will be copied

it should grab the whole thing

> - only the lowest level will be copied
> - how to handle multiple merged folders ?

for copy it shouldn't matter since what is being copied is a package 
structure (o.nb.m.f.b) and not a specific location. when it is pasted it 
the package structure that gets pasted.

for cut -and delete too -the warning will need to prompt the user to 
select where to cut/delete from if it's merged.

+-------------------------------------------+
|                                           |
+-------------------------------------------+
|                                           |
| Cutting [Deleting] the packages will       |
| remove the package and its contents.      |
|                                           |
| The selected package exists in multiple   |
| Java Roots, please choose from where it   |
| should be cut [deleted].                  |
|                                           |
| Root: |_All Occurances________________|V| |
|                                           |
|                         [ Ok ] [ Cancel ] |
+-------------------------------------------+

the root choices are:

-All Occurances -cuts/deletes from all java roots (default)
-java roots -as many roots that fit the criteria.

> -------------------------------------------------------------------------
> Now the second point - readability of the document:

i know the doc needs serious revising. the little changes that have 
occurred over the last few months have chipped away at the overall 
coherence. in the next month or so -after we finish the usability test 
and compile the results -i plan to work the doc over big time with the 
necessary changes that we see from the test plus current developer 
feedback. one of the main points will be to use the same logical 
structure the infrastructure spec uses -it should then be easier to 
follow the two and find any gaps or inconsistencies.

to that end, i'm noting your feedback and will use it when i refactor 
the ui spec.

as always, thanks.

cL



-- 

ui.netbeans.org
interaction designer
[email protected]