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