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

[macias]

Below is an idea by Diego.

I like this idea, but with small correction -- two buttons "add (to
group)", second "ungroup".

* add -- adding to current container, in case of no container create
default one
* default -- GAI (because it does not have hidden elements like TAI)
* ungroup -- ungroup all windows, by default not put in the deco (it
could be distraction to weekends users, and container is easy to
ungroup by hand, by tearing it apart)

Cheers,

----------  Forwarded Message  ----------

Subject: Re: NWI: metaphor needed?
Date: Wednesday 01 July 2009
From: Diego Moya

I think a good way to control windows pertaining to the same group is
with a new button similar the "Maximize/Restore" button in the window
title bar.

A new button for "Tile/Split" in each window would allow to change
quickly between showing tiled or free all applications in the group,
just as convenient as maximizing a window.

It would work also for creating groups. If the Tile button is pressed
on a window not pertaining to a group, it would trigger the
"Incremental adding" behavior, creating a grid with the current app
and a "hollow" placehorder with detailed instructions on how to create
a tiled arrangement of applications.

(see Incremental adding section in the NWI document:
http://techbase.kde.org/Projects/Usability/NWI#Incremental_adding
)

This would make NWI highly discoverable, intuitive for novice users,
and quick and easy to handle.

After pressing "split" all the applications in the grid would still be
included in a "virtual group", so that pressing "Tile" again would
restore the grid with all associated applications. This would also
help to bring together all windows in the group to another virtual
desktop.

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:
> I like [idea from Diego], but with small correction -- two buttons "add (to
> group)", second "ungroup".
>
> * add -- adding to current container, in case of no container create
> default one

What is "current container"? Or would this be a button on a container to
absorb a window (with second click)?

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.

For icons, what do you think of...

Wrap:
   _
  / _
|   \
  \_  |
    _/

Unwrap:
_
  \   _
   | /
_/ |
     \_

(Basically, two half-circles (or maybe angle brackets), with slight
vertical offset.)

> * default -- GAI (because it does not have hidden elements like TAI)

...missed description of this?

> * ungroup -- ungroup all windows, by default not put in the deco (it
> could be distraction to weekends users, and container is easy to
> ungroup by hand, by tearing it apart)

Would this be in the container titlebar, to dissolve that container and
drop its children into its parent? IMO we should definitely have such a
button available. Personally I think I /would/ add it by default, but
that's not a strong opinion.

Diego Moya wrote:
> After pressing "split" all the applications in the grid would still be
> included in a "virtual group", so that pressing "Tile" again would
> restore the grid with all associated applications. This would also
> help to bring together all windows in the group to another virtual
> desktop.

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.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
You're on your own for the pony. -- Richard Hughes, on feature requests

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Matthew Woehlke wrote:
> For icons, what do you think of...
> [snip]

Well, that got horribly mangled. Trying again, maybe some other
characters first on the line help:

..  Wrap:
..     _
..    / _
..   |   \
..    \_  |
..      _/
..
..  Unwrap:
..   _
..    \   _
..     | /
..   _/ |
..       \_

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
You're on your own for the pony. -- Richard Hughes, on feature requests

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Wednesday 08 July 2009 00:26:03 Matthew Woehlke wrote:

> Maciej Pilichowski wrote:
> > I like [idea from Diego], but with small correction -- two
> > buttons "add (to group)", second "ungroup".
> >
> > * add -- adding to current container, in case of no container
> > create default one
>
> 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.

> 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.

You mean wrap = convert? Hmm this means adding another button. And
only for such workflow (no irony below, just emphasis).

* convert app into container
* oh, I have container now
* add another app to this container (using 1st button)

vs.

* add another app to this "container" (using 1st button; container
actually will be created on fly)

I doubt the first scenario is productive, will be often used, thus I
think adding button only for this is too expensive.

> For icons, what do you think of...
>
> Wrap:
>    _
>   / _
>
> |   \
>
>   \_  |
>     _/
>
> Unwrap:
> _
>   \   _
>
>    | /
>
> _/ |
>      \_
>
> (Basically, two half-circles (or maybe angle brackets), with slight
> vertical offset.)

I like more half-circles (because it is some way similar to chain).
And I got the idea from the first time :-))

> > * default -- GAI (because it does not have hidden elements like
> > TAI)
>
> ...missed description of this?

I don't follow :-) My point was that if you add app to app GAI should
be created by default because it is obvious for user what happened.

> > * ungroup -- ungroup all windows, by default not put in the deco
> > (it could be distraction to weekends users, and container is easy
> > to ungroup by hand, by tearing it apart)
>
> Would this be in the container titlebar, to dissolve that container
> and drop its children into its parent?

Yes.

> IMO we should definitely
> have such a button available. Personally I think I /would/ add it
> by default, but that's not a strong opinion.

Ok, my is not strong either :-))

> Diego Moya wrote:
> > After pressing "split" all the applications in the grid would
> > still be included in a "virtual group", so that pressing "Tile"
> > again would restore the grid with all associated applications.
> > This would also help to bring together all windows in the group
> > to another virtual desktop.
>
> I'm not sure about this, it makes sense,

For me no -- because I don't see a purpose. If you want to bring
together all windows you don't have to do anything, just bring
them -- containers, not containers, it does not matter.

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Wednesday 08 July 2009 00:26:03 Matthew Woehlke wrote:
>> Maciej Pilichowski wrote:
>>> I like [idea from Diego], but with small correction -- two
>>> buttons "add (to group)", second "ungroup".
>>>
>>> * add -- adding to current container, in case of no container
>>> create default one
>> 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.

Okay, that makes sense.

>> 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.
>
> You mean wrap = convert? Hmm this means adding another button. And
> only for such workflow (no irony below, just emphasis).
>
> * convert app into container
> * oh, I have container now
> * add another app to this container (using 1st button)
>
> vs.
>
> * add another app to this "container" (using 1st button; container
> actually will be created on fly)
>
> I doubt the first scenario is productive, will be often used, thus I
> think adding button only for this is too expensive.

Hmm... but then, what container type do you get? Maybe it is better that
leaves have only 'new container' button (which lets you pick N windows
and change type while picking, as previously described), and containers
have only 'add a window' button.

>>> * default -- GAI (because it does not have hidden elements like
>>> TAI)
>> ...missed description of this?
>
> I don't follow :-) My point was that if you add app to app GAI should
> be created by default because it is obvious for user what happened.

I see now. Well, if you like the above, this doesn't matter.

>> Diego Moya wrote:
>>> After pressing "split" all the applications in the grid would
>>> still be included in a "virtual group", so that pressing "Tile"
>>> again would restore the grid with all associated applications.
>>> This would also help to bring together all windows in the group
>>> to another virtual desktop.
>> I'm not sure about this, it makes sense,
>
> For me no -- because I don't see a purpose. If you want to bring
> together all windows you don't have to do anything, just bring
> them -- containers, not containers, it does not matter.

Hmm, yeah, let's forget about the "bring all to another virtual
desktop"; I agree, don't want to do that.

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' ;-).)

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
.sig omitted due to budget cuts.

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[Diego Moya]

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.
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Diego Moya wrote:
> 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?

- One or two to select container type (just like any menu, you can
click+drag, or click twice)
- If using interactive group, one per window, plus one (or a keystroke)
to indicate you are done

> - 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.

No. You'd be in a "pick windows" mode that would be obviously different
from 'normal working' mode. (With composite, probably something like
expose mode.) If you cancel, you cancel and have to start over, there
wouldn't be any "unexpected behavior".

>> 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).

Hmm... maybe. Though color coding is difficult (a11y problems at
minimum, possibly u7y problems as well). When do you forget a "virtual
group"?

> I was thinking a "Grid" icon:
>
> ------------
> |       |  |
> |       |  |
> |       |--|
> |       |  |
> ------------
>
> More visual, less abstract

...much harder to fit in ~8x8 pixels? ;-)

> But your Wrap/unwrap icon has the advantage to work for all kind of
> containers.

True.

> Other advantages & disadvantages?

Well it's deco-specific anyway, so not worth too much discussion :-).
Not at this point, anyway.

> 2009/7/8 Maciej Pilichowski:
>> On Wednesday 08 July 2009 00:26:03 Matthew Woehlke wrote:
>>> 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)

There should be some obvious visual indicator of what is happening.

> - How many clicks to use?

Two: click button, click window to absorb. (Hmm, but now I wonder how
this is better than just drag-and-drop?)

> 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.

How does the WM know I didn't want to start creating a second group?

The previous proposal was one action to say "I am going to make a
container", one click per window, one action to say "okay, I am done for
now". I don't see a problem doing this in a way you have an initial
window. That's only one more action than your suggestion, without the
ambiguity. Would that be satisfactory?

> - 3rd, 4th, 8th windows... added to the container with one click each.

You know you can also do this with drag-and-drop... :-)

> Their decorations all get the same color.
> - To split one window from the container, press its

Hmm, "tear off" button... don't think that came up yet, think I like it...

> - 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.

Hmm, so you are thinking something like... hmm, how to describe it, a
container type where the children float above it. Actually... I think
this would work best as an actual container type. Sort of FAI but not
keeping the windows inside it. Still not sure it's a good idea :-), but...

(That would have the advantage that everything still shows up e.g. in
task switchers as grouped, still behaves as grouped, etc., which seems
to be what you want. But can be moved around as if not grouped.)

...which makes me realize, I guess 'move to desktop' removes windows
from containers. (Well... which it would, because you're moving the
window to a different parent, since a desktop is just a parent. The
alternative is to disallow it for windows in containers.)

>> 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.

Hmm. Okay, don't know if we thought about maximize/minimize before. Not
sure how to manage it for minimize in GAI, but for maximize I think it
makes sense to make it sort of ZUI; maximize child makes it fill the
containers (maybe with option that it should maximize container also, if
not), restore obviously undoes that.

So... my question is, what do I get from splitting that I don't get from
just maximize? (Or maybe full-screen?) If I want to focus on one app, I
can just maximize/full-screen. If I want to rearrange, why do I need to
break container to do that? (Let's assume it isn't because rearranging
container is "too hard" in-place; doing it for that reason would be
treating symptom without addressing problem.) Especially what benefit is
there vs. making container FAI?

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
.sig omitted due to budget cuts.

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[Diego Moya]

> Hmm. Okay, don't know if we thought about maximize/minimize before. Not
> sure how to manage it for minimize in GAI, but for maximize I think it
> makes sense to make it sort of ZUI; maximize child makes it fill the
> containers (maybe with option that it should maximize container also, if
> not), restore obviously undoes that.

Window in a container: maximize -> application covers all the group rectangle.
Window not in container: maximize -> application covers the full screen.

That's one reason why changing between wrapped/unwrapped quickly is important.


> So... my question is, what do I get from splitting that I don't get from
> just maximize? (Or maybe full-screen?) If I want to focus on one app, I
> can just maximize/full-screen. If I want to rearrange, why do I need to
> break container to do that? (Let's assume it isn't because rearranging
> container is "too hard" in-place; doing it for that reason would be
> treating symptom without addressing problem.) Especially what benefit is
> there vs. making container FAI?

One use case:

- Two main applications, with several supporting information apps (say
text files in Kate) that are secondary to the task.
- Mode A: I want to have all windows arranged on screen: create a Grid
container and tile all them.
- Mode B: I want to focus in the two main apps: "unwrap" the group.
The main apps occupy half the screen each, the supporting apps are
hidden behind.

Change between mode A and B as many times as you need, with just one
click. With the possibility to change anytime to a different task and
other applications, and go back to this group instantly by bringing
the wrapped/unwrapped group to the top again.


> Hmm, so you are thinking something like... hmm, how to describe it, a
> container type where the children float above it. Actually... I think
> this would work best as an actual container type. Sort of FAI but not
> keeping the windows inside it. Still not sure it's a good idea :-), but...

The metaphor you're looking for is "layers in an image editing tool".


> You'd be in a "pick windows" mode that would be obviously different
> from 'normal working' mode. (With composite, probably something like
> expose mode.) If you cancel, you cancel and have to start over, there
> wouldn't be any "unexpected behavior".

I still prefer the modeless interface in my proposal. This would allow
the user to interleave unrelated actions between the initial container
creation and the later addition of other windows to it.

You would require two different buttons then, each with a consistent
meaning: one to "create new group" and one to "add window to  group",
where the group can be one of:
a) the last selected group (and the "add to group" button changes to
reflect its code color)
b) a dropdown showing all available groups.

This would also solve the problem of when to change adding to a new
group. Of course if only drag&drop is used, you can avoid "add window
to group" and have only the "create group" button. And it would still
be modeless.


>> Just color-code windows pertaining to the same group, or add some
>> other visual reminder (same icon).
>
> Hmm... maybe. Though color coding is difficult (a11y problems at
> minimum, possibly u7y problems as well). When do you forget a "virtual
> group"?
That's why I also suggested matching icons/emblems to go with the
color. The color coding is not to be acted upon, this is only as a
reminder, since the user created the groups herself on this session.
You destroy the group when the user explicitly closes it.


>>> 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.

Same here, the user created the groups, they have a meaning related to
the task for which apps where put together. With the constant
reminders of color and grouped taskbar, I don't think this would
create confusion. It's something to be tested, though.


>> I was thinking a "Grid" icon:
>> More visual, less abstract
>
> ...much harder to fit in ~8x8 pixels? ;-)

You haven't seen ZX Spectrum graphics, do you? :-P


> Two: click button, click window to absorb. (Hmm, but now I wonder how
> this is better than just drag-and-drop?)

One click is better than one drag&drop; two might be worse, except for
disabled users who can't do drags. So it depends on the target users.
For accessibility I'd say, go with a click-only interface if possible
- with drag & drop just as an accelerator.
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Diego Moya wrote:

>> Hmm. Okay, don't know if we thought about maximize/minimize before. Not
>> sure how to manage it for minimize in GAI, but for maximize I think it
>> makes sense to make it sort of ZUI; maximize child makes it fill the
>> containers (maybe with option that it should maximize container also, if
>> not), restore obviously undoes that.
>
> Window in a container: maximize -> application covers all the group rectangle.
> Window not in container: maximize -> application covers the full screen.
>
> That's one reason why changing between wrapped/unwrapped quickly is important.

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 :-).)

>> So... my question is, what do I get from splitting that I don't get from
>> just maximize? (Or maybe full-screen?) If I want to focus on one app, I
>> can just maximize/full-screen. If I want to rearrange, why do I need to
>> break container to do that? (Let's assume it isn't because rearranging
>> container is "too hard" in-place; doing it for that reason would be
>> treating symptom without addressing problem.) Especially what benefit is
>> there vs. making container FAI?
>
> One use case:
>
> - Two main applications, with several supporting information apps (say
> text files in Kate) that are secondary to the task.
> - Mode A: I want to have all windows arranged on screen: create a Grid
> container and tile all them.
> - Mode B: I want to focus in the two main apps: "unwrap" the group.
> The main apps occupy half the screen each, the supporting apps are
> hidden behind.

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.

With yours you have maybe slight advantage because the above can't give
you free-floating apps in "focus" mode without more work, but you also
have possibility that focus is wrong. I'm not sure if it's worth it, but
at any rate you can still do it with "DAI" container type (FAI but
without the geometric container; apps in DAI container behave as if
dialogs, always).

>> You'd be in a "pick windows" mode that would be obviously different
>> from 'normal working' mode. (With composite, probably something like
>> expose mode.) If you cancel, you cancel and have to start over, there
>> wouldn't be any "unexpected behavior".
>
> 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 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".

> You would require two different buttons then, each with a consistent
> meaning: one to "create new group" and one to "add window to  group",
> where the group can be one of:
> a) the last selected group (and the "add to group" button changes to
> reflect its code color)
> b) a dropdown showing all available groups.

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.)

> Of course if only drag&drop is used, you can avoid "add window
> to group" and have only the "create group" button. And it would still
> be modeless.

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.)

>> Two: click button, click window to absorb. (Hmm, but now I wonder how
>> this is better than just drag-and-drop?)
>
> One click is better than one drag&drop; two might be worse, except for
> disabled users who can't do drags. So it depends on the target users.
> For accessibility I'd say, go with a click-only interface if possible
> - with drag & drop just as an accelerator.

Yes, good point.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
.sig omitted due to budget cuts.

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[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.
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Wednesday 08 July 2009 18:15:13 Matthew Woehlke wrote:

> > * convert app into container
> > * oh, I have container now
> > * add another app to this container (using 1st button)
> >
> > vs.
> >
> > * add another app to this "container" (using 1st button;
> > container actually will be created on fly)
> >
> > I doubt the first scenario is productive, will be often used,
> > thus I think adding button only for this is too expensive.
>
> Hmm... but then, what container type do you get?

By default GAI. You could change this in SS (default) or you could
change it in the hollow pane (just an idea).

> Maybe it is better
> that leaves have only 'new container' button (which lets you pick N
> windows and change type while picking, as previously described),
> and containers have only 'add a window' button.

So basically you agree with me, because this button could be one
button. New container and add a window in those cases would lead to
the same results.

> 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 don't what virtual group is and what is the purpose of it. I've read
Diego explanations but still I don't get it.

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Wednesday 08 July 2009 20:41:33 Diego Moya wrote:

> 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)

There is hollow pane shown so it is hard to miss it.

> - How many clicks to use?

+1, activate grouping
+2, add window (ctrl+LMB)

total = 3.

> - 2nd window. Press "groupize" icon, app gets added to the hollow
> application hole.

Cannot do this because of the ambiguity. "Groupize" means create start
creating group -- not add to the group.

> - 3rd, 4th, 8th windows... added to the container with one click
> each.

Cannot do this. Regular operations, like bring window to front, should
be possible.

> Their decorations all get the same color.

The idea was to get them immediately to container.

> - To split one window from the container, press its

Broken sentence.

> - 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.

What is the purpose of it?

> - To destroy the container in a permanent way, press its "close"
> button. Windows get free and lose their color coding.

No, close should close container with applications as well. If you
want to ungroup, then ungroup.

Symbols should not change their meaning.

> > 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.

If you want to regroup, you regroup, if you want to tear off any
window, you can do this too. I still don't see a point. Do you have
any scenario in mind?

> This is useful to switch focus between just one app and
> all apps in the group.

? You mean all apps at the same time have focus?

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Wednesday 08 July 2009 21:22:07 Matthew Woehlke wrote:

> > - 3rd, 4th, 8th windows... added to the container with one click
> > each.
>
> You know you can also do this with drag-and-drop... :-)

Or selecting them at once (shift+LMB).

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Wednesday 08 July 2009 23:58:44 Diego Moya wrote:

> > Hmm. Okay, don't know if we thought about maximize/minimize
> > before. Not sure how to manage it for minimize in GAI, but for
> > maximize I think it makes sense to make it sort of ZUI; maximize
> > child makes it fill the containers (maybe with option that it
> > should maximize container also, if not), restore obviously undoes
> > that.
>
> Window in a container: maximize -> application covers all the group
> rectangle.

I am not sure about that.
a) TAI -- easy, not min/max
b) FAI -- 50% easy, max fill entire container, min -- described in the
summary, there are several options
c) GAI -- if it would behave like FAI this means other windows are
_hidden_, it is very easy to forget them because there is no explicit
info about them

So I am leaning (for GAI) towards another solution -- all other
windows/panes should be "minimized", i.e. get their minimal sizes,
and the rest should take the maximized window.

Or -- odd, but maybe it would be great productivity -- treat TAI as
maximized GAI. And then in TAI it would be possible to restore (even
if TAI is started as TAI).

The main point in my considerations&ideas is to avoid hidden state.

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Diego Moya wrote:

> 2009/7/9 Matthew Woehlke wrote:
>> Diego Moya wrote:
>>> 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".

Okay, it is a "state". Personally I prefer an obvious mode to a less
obvious state. Maybe that's me?

> It's not clearly defined what other actions (open/close application,
> maximize/minimize, edit text...) will do while you're in this mode.

Other actions are disabled. This is like a switcher; you pick some
windows, you are done. You don't do anything else in the middle. It's
meant to be something that is done quickly.

> Will it remain active forever unless you cancel it?

Yes. Same as how switcher works.

>> 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?

...not trying to remember what will happen if you click 'add' button?

> The main visual identification would be that of grouped windows in the
> taskbar.

What if I don't have a task bar? :-)

> 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.

Good point. Right now the write-up specifies it is still there, but with
working NWI it is probably worth considering to turn it off by default.
(Especially if we add DAI container which would allow grouping without
the other mechanics of containers.)

> 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.

It would be ten actions. One to say "I am going to create a container",
eight for the windows, and one to say "I am done".

...Unless you are doing other things in between adding each of the
windows, but then we are back to needing to remember what container is
"active".

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
child: Do not try to read the .sig. That is impossible. Instead you must
realize the truth.
init: What truth?
child: There is no .sig.

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Wednesday 08 July 2009 23:58:44 Diego Moya wrote:
>> Window in a container: maximize -> application covers all the group
>> rectangle.
>
> I am not sure about that.
> c) GAI -- if it would behave like FAI this means other windows are
> _hidden_, it is very easy to forget them because there is no explicit
> info about them
>
> So I am leaning (for GAI) towards another solution -- all other
> windows/panes should be "minimized", i.e. get their minimal sizes,
> and the rest should take the maximized window.

Well, you can hide parts of split views... same problem :-). However I
was thinking there should be indication in title bar that there are
other windows.

> Or -- odd, but maybe it would be great productivity -- treat TAI as
> maximized GAI. And then in TAI it would be possible to restore (even
> if TAI is started as TAI).

Actually if deco puts other window tabs in title bar, this is maybe
possible. Works for me, anyway. (But you could make same argument that
maximized FAI should be special case of TAI... Hmm... Actually if we did
this for root, and we add can have plasma widgets on title bars, we
don't need a panel any more ;-).)

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
child: Do not try to read the .sig. That is impossible. Instead you must
realize the truth.
init: What truth?
child: There is no .sig.

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Wednesday 08 July 2009 18:15:13 Matthew Woehlke wrote:
>>> * convert app into container
>>> * oh, I have container now
>>> * add another app to this container (using 1st button)
>>>
>>> vs.
>>>
>>> * add another app to this "container" (using 1st button;
>>> container actually will be created on fly)
>>>
>>> I doubt the first scenario is productive, will be often used,
>>> thus I think adding button only for this is too expensive.
>> Hmm... but then, what container type do you get?
>
> By default GAI. You could change this in SS (default) or you could
> change it in the hollow pane (just an idea).
>
>> Maybe it is better
>> that leaves have only 'new container' button (which lets you pick N
>> windows and change type while picking, as previously described),
>> and containers have only 'add a window' button.
>
> So basically you agree with me, because this button could be one
> button. New container and add a window in those cases would lead to
> the same results.

Yes, I think so.

>> 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 don't what virtual group is and what is the purpose of it. I've read
> Diego explanations but still I don't get it.

As I understand it, it functions like FAI but without the geometry of
container. That is, windows are grouped (from technical side, they are
in a container), but they are drawn as if floating on root window.

I can see some uses, but I'm also not 100% convinced.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
child: Do not try to read the .sig. That is impossible. Instead you must
realize the truth.
init: What truth?
child: There is no .sig.

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Thursday 09 July 2009 18:25:08 Matthew Woehlke wrote:

> Well, you can hide parts of split views... same problem :-).

They are usually prepared to have scrollbars. We won't have such
situation.

But more problems for you :-) What happens (how container should look)
after minimizing maximized window in GAI?

I still think it would be more obvious if maximize would mean -- make
it as big as possible.

In a sense it the meaning is the same for FAI, but because windows are
unrelated the size can be as big as container.

> Actually if deco puts other window tabs in title bar, this is maybe
> possible. Works for me, anyway. (But you could make same argument
> that maximized FAI should be special case of TAI...

It is not necessary - windows are not related, so the window can be
maximized to 100%.

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:
> On Thursday 09 July 2009 18:25:08 Matthew Woehlke wrote:
>> Well, you can hide parts of split views... same problem :-).
>
> They are usually prepared to have scrollbars. We won't have such
> situation.

?

If a UI is done with a splitter layout, I can use the splitter to make
one half of the split hidden. I don't know where there are scrollbars here.

> But more problems for you :-) What happens (how container should look)
> after minimizing maximized window in GAI?

Do you mean restore (un-maximize)? I would be okay with an actual
minimize function but not sure how it should work; would also be okay
not having it.

Un-maximize just goes back to "normal" state. If you're thinking that
there should be a minimize, if you use it in maximize mode then you
would get next window shown, maximized. (IOW all child windows in GAI
become maximized or not at same time.)

> I still think it would be more obvious if maximize would mean -- make
> it as big as possible.

Isn't that essentially what it does?

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Friday 10 July 2009 19:09:20 Matthew Woehlke wrote:

> Maciej Pilichowski wrote:
> > On Thursday 09 July 2009 18:25:08 Matthew Woehlke wrote:
> >> Well, you can hide parts of split views... same problem :-).
> >
> > They are usually prepared to have scrollbars. We won't have such
> > situation.
>
> ?
>
> If a UI is done with a splitter layout, I can use the splitter to
> make one half of the split hidden. I don't know where there are
> scrollbars here.

Before writing previous post I checked the Konqueror. Normally you
cannot minimize the dialog less than its minimal size. But you could
do this with pane. Because it does not shrink, it just shows
scrollbar.

Unless you intented to put all windows inside GAI in scrollable panes.

> > But more problems for you :-) What happens (how container should
> > look) after minimizing maximized window in GAI?
>
> Do you mean restore (un-maximize)?

No. I mean -- minimize maximized window. What would happen with GAI?

> I would be okay with an actual
> minimize function but not sure how it should work;

We didn't discussed it yet, so I don't know what you have in mind :-))

> > I still think it would be more obvious if maximize would mean --
> > make it as big as possible.
>
> Isn't that essentially what it does?

It depends -- in FAI it does not have to take other windows into
account. So the question is -- in GAI should it ignore the rest of
the siblings, or not. I rather opt -- for not ignoring, which
translates "the possible -- to the extent the siblings let you".

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel