Shell’s Tiled View
Not so long after Florian cleaned up the overview-relayout branch to accommodate the visual tweaks initiated by Allan, here we are again to move the target a bit (engineers love me).
Initially shell exposed two views. A tiled view for an overview of your workspaces (something we can’t expect majority will want to manage). A linear view that presents application windows for easier switching (and dropping documents on). Exposing the mode switch to the user wasn’t good design and even if we presented the tiled view only when rearranging windows or selections of windows across workspaces, it felt like too much of an odd case.
Well luckily Jon came up with what I believe is an elegant solution that works around the limitations of the linear view. In addition it also helps to gradually introduce the workspace concept to curious users who would have otherwise not bothered.
Here’s a very crude motion mockup of how the sidebar behaves:
- The workspace sidebar is hidden by default, ignored by the majority of users. It would slide out on cursor proximity and or when a drag is initiated on a window or a launcher.
- This interface relies on animation – it would be hard to grasp if things just popped from one frame to another. Things need to scale and slide to aid the spatial relation between workspaces and windows.
- The IOS like rectangle navigation we had in the linear view only gave you an idea of the number of workspaces and the position. The thumbnails make it much easier to identify a workspace to switch to or drop a window/launcher to.
- The interface would work just as good horizontally, but it’s more common to scroll documents vertically and we already use the bottom of the screen for messages
Now while I think the workspace thumbnailing addresses the most useful part of the tiled view, we still rely on the user to do workspace “management”. So the next step is to make the Shell do the heavy lifting. Stay tuned.
November 22nd, 2010 at 5:39 pm
jimmac,
i love that even your “very crude” mockups have such a high level of polish. keep up the good work!
November 22nd, 2010 at 5:41 pm
the ‘plus’ button sliding down feels a bit odd, and a moving target in a UI that relies a lot on hot spots. dunno where to place it, though, without making it look odd.
November 22nd, 2010 at 5:44 pm
Why not place both +/- in the same place (on top)?
November 22nd, 2010 at 5:44 pm
@ebassi: While this is irrelevant due to the upcoming iteration, the button doesn’t really move. It shrinks. The whole “free” space is used for the add button (most likely action for the uber-sidebar when not already using workspaces).
November 22nd, 2010 at 5:46 pm
Still love this mockup! fmuellner, go for it!
November 22nd, 2010 at 6:16 pm
While the “add” button function is made intuitive by its placement, as it adds one space right where you click, on the bottom of the “list”, the same can’t be said for the “delete workspace” one.
Since it’s placed on top an unsuspecting user could equally infer that
a) it will delete the topmost space, just like the add will add one to the bottom (spacial placement similtude)
b) it will delete the bottom space, as the list works a bit like an inverted stack (functional similtude)
Now, being ambiguous about something the user is already scared of – deleting potentially means losing information – is probably not a good idea, as it leads to a discomfort threshold.
A delete/cross overlay in the corner of each space would probably be a lot less ambiguous.
November 22nd, 2010 at 7:02 pm
my main concern with new overview layout was the removal of bird eye view in favor of only linear view, with doesn’t allow anymore to switch easily using overview mode from one application in a workspace to another (even alt-tab doesn’t make that easy, if you want to move separate applications in separate workspaces).
Your new design improves things (you can see what is available in other workspaces) but I’m not sure it is enough. I was wondering on a “zoom out” view (obtained by mouse wheel) from current workspace, which would allow to see the various workspaces, to get back bird eye view (this was the way metisse was working).
November 22nd, 2010 at 7:18 pm
hmm, the ogg video claims that it’s only 4 seconds long, so it doesn’t play fully in WebKitGtk+. It does play fully in totem, but by the end of the video, it says that the video is at “0:16 / 0:04″. VLC behaves the same way as totem. I suspect something went wrong when encoding the video (?)
November 22nd, 2010 at 10:30 pm
Looks really slick.
I’m glad there will be some form of thumbnail workspace overview, the small rectangles/ symbolic icons shown in linear mode are a bit counter productive. Not too sure about the positioning of the remove/add workspace buttons, as previous posters have said. Despite the add workspace button’s dynamically expanding/shrinking size, the fact the plus icon moves upon every workspace added/removed looks rather odd- also I’m still of the opinion that having remove icons overlayed on each workspace would work better than the fixed position button shown in the mockup. Less confusing that way.
Excellent work though, seriously hope all this stuff lands in reality for Gnome 3.0.
Cheers.
November 22nd, 2010 at 10:57 pm
Workspace names are gone?
November 23rd, 2010 at 2:27 am
At risk of bikeshedding, I think these round corners are getting out of hand.
In there you have the round search field, the round corners of the panel, the open windows, the sidebar on the left AND the sidebar on the right. Every single corner there is rounded, and each one with a different radius.
I know it’s just a visual design thing that can be improved over time, but these elements are all repelling each other right now. That could paint you into a corner as the design tries to evolve.
November 23rd, 2010 at 2:35 am
From a UI design perspective, I like this idea a lot because it opens up the possibility of using two axises of movement in the Shell when in the overlay; up and down to switch between Activity spaces, and left/right to toggle between windows/applications views. However, from an aesthetic perspective, I much prefer the encircled window labels and black “x” used in the current implementation.[1] The aesthetic impression in the above mockup looks very much like a clunky Google-style ajax web app, whereas the older implementation was closer to a sleek Apple design.
I prefer the add/remove desktop plus/minus designs that were used in last August’s mockup. Now that you have the added space, perhaps you could add the text “Add new desktop” beside the plus sign, per the August 2009 design.
Also, I think the number of desktops should probably be limited to around 6-9 at the most, since that is the most that people will realistically ever use at a time.
[1] http://people.gnome.org/~mccann/screenshots/clips/20100106201448/shell-mockup-overview-test.png
[2] http://people.gnome.org/~mccann/shell/mockups/20090808/shell-black2.png
November 23rd, 2010 at 8:28 am
Regarding the shell itself taking care of workspace management, not long ago I sent a proposal for Ubuntu Unity that I think could be applied here:
http://www.webupd8.org/2010/10/interesting-unity-concept-for-managing.html
The idea is that you always have one (but not more) empty workspace. When you boot up your system you only have a workspace, since there are no open windows. But as soon as you open a window, a second empty workspace appears at the end of the workspace sidebar. You can open as many windows as you want on the first workspace and it won’t affect the number of workspaces, but as soon as you open a window on the second workspace, or move one to it, a third workspace would appear.
Likewise, closing the last window of a workspace or moving it to another workspace would make that workspace disappear, since it is empty now and there must always be only one empty workspace.
Would that be a good way for the Shell to manage workspaces automatically?
November 23rd, 2010 at 10:54 am
I think this type of workspace management is a mistake. A user SHOULD NOT be adding/removing workspaces!. Instead, there should ALWAYS be an empty workspace at the “end”. When a user starts running applications (adding windows) or moves windows to the workspace, a new empty one is added in the end.
Removing workspaces is a bit more tricky. Firstly, the main action of removing a workspace should not be “remove” per say, more like “merge all the windows from this workspace with that one”. This can be done by dragging the workspace onto another.
Additionally I would say that an empty workspace that the user slides out of automatically disappears. If the user needs it, he should just use the empty workspace in the end. (In the animation I would even show it as if the empty workspace ‘slid’ to the end to become the empty workspace at the end).
November 23rd, 2010 at 12:53 pm
@David Prieto, @dbdoskey: That is indeed the direction we’re going with this now.
November 23rd, 2010 at 2:03 pm
Wow, that’s terrific jimmac. Also, have you considered the other part of my proposal? That’s using a visual indication to group launchers depending on their workspace. Have you seen the mockups? Are they clear to you? Would you guys be interested in something along those lines?
November 23rd, 2010 at 7:15 pm
@David Prieto, dbdoskey
That’s a good point and shows how bad gnome designers actually are )
Instead of trying to make a really convenient desktop environment, they are playing with +/- workspaces. What fools!
November 24th, 2010 at 1:51 am
There was a thing which worked in the previous versions of gnome-shell but IMHO doesn’t work now. When I was in the overview (or now when I would have your workplace slider pulled out) I used to be able to kill non-active workspace (i.e., my active workspace was #1, but I saw in overview that #2 is empty). How can I kill it now without switching to it? In gnome-shell where empty workspaces had big minus sign on it, it was possible.
November 24th, 2010 at 1:42 pm
@mcepl: Indeed, but even better — you shouldn’t really worry about that. Thus the next iteration.
February 22nd, 2011 at 7:36 pm
These mock-ups look promising!
One thing I am puzzled about is how newbies should guess the difference between “Windows” and “Applications”. For my aunt/uncle (read: normal users) theses things are just the same. Probably this distinction only makes sense for the minority of programmers and computer literate people.
It seems that the “Windows”-view is all about “Organizing the Workspace” – which comprises organization of Windows(=Applications), virtual desktops and closing applications; while the “Applications”-view is all about “Starting (new) Applications”. Not sure if the “Windows” vs “Applications”-terminology does reflect this appropriately.
Keep up the good work.