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

Diego Moya turingt at gmail.com
Wed Jul 8 20:41:33 CEST 2009


2009/7/8 Matthew Woehlke wrote:
> What about (in addition to above) a button to wrap a window in a new
> container? It could be a dropdown for container type and also include
> option to interactively create container.

Two questions to assess quality:

- How many clicks to use?
- Does the user have to remember the current "state"? I.e. after
pressing the first button, if I do anything else than press the second
button, operation is canceled. AND there's no visual clue of this.


> I'm not sure about this, it makes sense, but how do you know when to
> 'forget' the virtual group? Otherwise I think there is a very large risk
> for confusion if time passes between ungroup and regroup.

Just color-code windows pertaining to the same group, or add some
other visual reminder (same icon).


> Matthew Woehlke wrote:
>> For icons, what do you think of...
> ..  Wrap:
> ..     _
> ..    / _
> ..   |   \
> ..    \_  |
> ..      _/
> ..
> ..  Unwrap:
> ..   _
> ..    \   _
> ..     | /
> ..   _/ |
> ..       \_
>

I was thinking a "Grid" icon:

------------
|       |  |
|       |  |
|       |--|
|       |  |
------------

More visual, less abstract, and exactly matches the GAI container - so
after pressing it, the user instantly "gets" what the button did.

But your Wrap/unwrap icon has the advantage to work for all kind of
containers. Other advantages & disadvantages?



2009/7/8 Maciej Pilichowski:
> On Wednesday 08 July 2009 00:26:03 Matthew Woehlke wrote:
>> What is "current container"?
>
> Container which is active, has focus (i.e. app inside has focus).
>> Or would this be a button on a
>> container to absorb a window (with second click)?
>
> Exactly.

- Does the user have to remember the current "state"?  (Clicking
anywhere than on the second window cancels the operation, and there's
not a visual clue of this mode)
- How many clicks to use?


2009/7/8 Matthew Woehlke wrote:
> Hmm, yeah, let's forget about the "bring all to another virtual
> desktop"; I agree, don't want to do that.

Ok, forget about virtual desktops. Let's refine current approach:

-1st window. Press "groupize" icon. It creates a grid container about
1st window, with a "hollow application" as a remainder of grid
creation an instructions on how to add a second one.
- 2nd window. Press "groupize" icon, app gets added to the hollow
application hole.
- 3rd, 4th, 8th windows... added to the container with one click each.
Their decorations all get the same color.
- To split one window from the container, press its
- To split all windows in the container, press the container's "split"
button. Windows get free, but remain color-coded.
- To group all 8 windows again, press any of their "group" icons.
- To destroy the container in a permanent way, press its "close"
button. Windows get free and lose their color coding.


>
> What about "virtual groups", do you think that is a good idea or not? I
> lean toward "not", seems like it has potential to be confusing. (Well,
> unless implemented as 'undo WM action' ;-).)
>

I think it's a good idea because it allows you to split-regroup all
windows with a single click, just like a maximize-restore operation.
This is useful to switch focus between just one app and all apps in
the group. To avoid confusion you could:
- add the same icons to all windows in a group.
- keep windows grouped in the taskbar, even if they are free-form and
not in the container.


More information about the Kde-usability-devel mailing list