unity-design team mailing list archive

[David Prieto <frandavid100@xxxxxxxxx>]

Hi Conscious user, thank you again for your insightful comments.

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

True.


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

Also true. Maybe pinning launchers to workspaces isn't such a good idea
after all. How about they're pinned outside the purple spaces, and only move
to them when launched? Kind of like this:

http://imgur.com/1lZnj.png

Here you can see the desktop as you start your computer. There are two
pinned launchers (Firefox and Hamster) but none of them is open, so they
don't appear inside any purple spaces.

http://i.imgur.com/oN9rh.png

When you click on the Firefox launcher, it moves to purple space 1. Since
that workspace is not empty anymore, a new purple space appears. Hamster's
launcher still appears outside any purple spaces.

http://i.imgur.com/wTQE4.png

If you switch to workspace 2 and click on the Hamster launcher, it moves to
purple space 2. The mockup shows that, plus another unpinned launcher
(GIMP). Since neither workspace is  empty anymore, a new purple space
appears. If you close Firefox or Hamster, their launchers move again to the
top.


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

That's true, but seems to be commonplace in the way Unity was designed. For
example, right now the user does not have a fixed point in screen to reach
the workspace switcher because it will move up and down depending on the
number of open apps.

I don't really think it's a problem, but even if it were it wouldn't be a
problem inherent to my proposal, but to Unity's design.


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

That really depends on what you consider "not being workspace-centric". Does
it mean that you only use one workspace? Or that you use several of them,
but don't really care in which of them you placed each window?

   - In the first case, the purple spaces never really get in the way.
   Please see my second mockup (http://i.imgur.com/oN9rh.png) again. If you
   only use the first workspace, active launchers would pile up in the first
   purple space. Therefore, there would be no "moving target" problem" in the
   first place.
   - As for the second case, all it would do is make it easier to locate
   your windows. Right now windows from all workspaces are mixed in the
   sidebar, so locating a specific one is more difficult than it should.
   Keep in mind that right now we have *no way* to switch between
   applications in the same workspace. We also have *no way* to switch
   workspaces (from the sidebar, that is). My proposal would, precisely, bring
   a way to do it.

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

That's completely true. I think I have one way to solve that, but I'd rather
get the other points out of the way before discussing this. Could you just
ignore this one problem for the time being, see if my new mockups solve the
other issues you raised?


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

 I also have another proposal for that, too. One that could make the
workspace switcher moot. Again, please consider the current mockups before
discussing that.

Thanks again,

David.