Re: [Ayatana] Handling workspaces in Unity's launcher

[Conscious User <conscioususer@xxxxxxx>]

>         2) Even for applications with a single window, I believe cases
>         where users are not interested in such association are
>         frequent.
>         Several users treat workspaces as extra space to be used as
>         needed (Gnome shell for example was designed with that
>         in mind) and not as fixed spaces.
>  
> I'm not sure I'm following you here. You say it's frequent for users
> not to want which association? You mean they don't want "four
> workspaces" but add and remove them as needed? If that's what you
> mean, I think Seb's idea addresses that gracefully, offering an easy
> way to add and remove additional workspaces right on the spot.

There are two separate points here. The first one is that sometimes
users have no interest in associating an app to a specific workspace,
but always want them to appear whenever they are working at the
moment. This is usually true for IM and microblog apps.

The second point is that if workspaces are treated as being used
"on demand", then pinning launchers on specific workspaces does
not make sense. Seb's idea does not have this problem because he
works with the concept of "state", he is not pinning launchers
but opened applications.

>         3) The size, and therefore easiness of interaction, of each
>         workspace is proportional to the number of itens inside it.
>         This makes switching to a specific workspace, literally, a
>         moving target.
> 
> True. I've made a second group of mockups, based on Seb's idea, which
> I think will solve that problem. Please take a look at them: 
>       * http://imgur.com/492ux.png
>       * http://imgur.com/zSlew.png
> In the first mockup you see the situation with only one workspace:
> There are no empty workspaces, only the one being used (with firefox
> and hamster windows) and a second, empty one, which you can click or
> drag launchers to.
> 
> When you drag a launcher to that second workspace or navigate to it
> and open an app (in the second mockup I opened GIMP), a third, empty
> workspace appears which you can in turn navigate to.
> 
> Therefore, there is always one empty desktop (plus the ones that are
> in use). Never more, never less.

I think you didn't understand my main concern. I was talking about
the area corresponding to each workspaces changing size depending
on the number of apps opened or launchers pinned. This means that
the user does not have a fixed point in screen to switch to a
workspace this way.

> I think it gives the user a way to add workspaces easily AND use them
> correctly (i.e. not having empty workspaces just laying around),
> allows the user to perform an expose only on the current workspace,
> allows easy reordering of the workspaces and allows keeping an eye of
> which apps are in the current workspace (making it easier to find them
> in the sidebar because those on other workspaces don't get in the
> way).
> 
> I do think improves the user experience.

I can see it if the user's workflow is completely workspace-centric.
It it's not, however, the taskbar is trying to do a lot of things
at the same time and none of them optimally:

- It's not optimal for switching workspaces or switching between
applications in the same workspace, because of the moving target
problem: the place where you have to click keeps changing.

- It's not optimal for switching between applications because
two instances of the same application would be separated by
workspaces. If the user has a "I want to switch to that
Firefox window where Gmail is open" and not "I want to switch
to that Firefox window in workspace 4", the separation makes
his job harder, not easier.

I do agree with the need for workspace-specific expose, though.