Fwd: Adding "group/split" button to the decoration

[Diego Moya]

2009/7/9 Matthew Woehlke wrote:
> Diego Moya wrote:
> I was thinking about that... but why not just maximize the container in
> that case? Same number of clicks...
> (I'd even be okay with an option that maximize a child *does* maximize
> the container as well. Then it is only one click :-).)

This way you can have both behaviors ("local" maximize vs whole screen maximize)

> Or you could lay out the apps as follows:
>
> GAI 1
>   GAI 2
>     Main app A
>     Main app B
>   ...supporting apps in GAI 1...
>
> (or whatever containers are most appropriate...)
> So you maximize/restore container 2. Same effect, no? And A+B are still
> in a container.

I suppose my subconscious was trying to avoid a "recursive containers"
layout. My "wrapped/unwrapped" solution provides a simpler mental
model (think manual vs automatic) than your "directed graph" (A
connects with B wich connects with C which connects with A B and D).
Non-engineers would thank you for the simpler model. Anyway, recursive
containers would still be possible, just not always needed for the
simple cases.



>> I still prefer the modeless interface in my proposal.
>
> ...except your proposal /isn't/ modeless, you are always in mode of
> having to remember what container "add" will add to :-).

This is not a mode. It's a button whose action's target changes
according to the last selected container, yes. But a mode is when the
current state affects *other* actions as well, such as "start adding
windows to container until I cancel the adding windows mode". It's not
clearly defined what other actions (open/close application,
maximize/minimize, edit text...) will do while you're in this mode.
Will any other action cancel the mode? Will it remain active forever
unless you cancel it? (In that case it's the same as my solution,
except there will be times when it's "broken" - the user tries to use
it but it's not active).


>> This would allow
>> the user to interleave unrelated actions between the initial container
>> creation and the later addition of other windows to it.
>
> ...which you can do by drag-and-drop, or by reactivating 'add windows'
> mode. Only difference is you explicitly say "I am done adding windows".

Why would the user want to explicitly say that? What does s/he gain
for sometimes not being able to add windows to a container?



> I am concerned that your proposal requires visual identification of
> containers. Icons are small and hard to see. Colors are not accessible;
> for people with limited color vision, it is very difficult to have more
> than a handful of readily identifiable colors. (Even with full color
> vision, more than about six is getting problematic, and that's not very
> many.)

The main visual identification would be that of grouped windows in the
taskbar. I suppose that a user using NWI wouldn't need the current
"group windows from the same application" behavior, since those
wouldn't match his task requirements (several application instances
could pertain to different tasks), what she wants is having windows
from the same task grouped even if those are from different apps.



> So is d&d enough for you? Because we definitely intend to have d&d :-).
> (With also 'click group, click window' for those that want/need it.)

I'm OK with d&d. What worries me is the "two clicks for each
grouping", that's one more click than needed for window IMO. It
doubles the "group 8 windows to a container" scenario from 8 clicks to
16. Every time you want to wrap/unwrap them, if you don't implement
the automatic "virtual group" of unwrapped but still grouped windows.