Update: Please make sure to check out another take on this idea – automatic labeling.
While the current shell is doing a great job being simple and easy to use, there are a number of difficulties the interface creates. One of these difficulties is reminding the user what he or she is working on in a workspace, when there are multiple workspaces in one session. The following is my analysis on the current situation and a proposal for how we can improve workspace management in GNOME Shell.
The Activities Overview
So this is how the Activities overview currently looks. We currently do an excellent job of dynamically adding and removing workspaces – there’s always an extra one if needed and a workspace gets removed if there are no running apps within it. But notice the one glaring issue with this setup. To switch to a different activity, a user must inspect the small workspace boxes and hope for there to be a noticeable visual cue that tells them, “Ah, yes, this is the (Planning) workspace where I check my email, and use my calendar.” This setup may be okay if you have noticeably different apps in each workspace, but it falls apart when you have say two Chrome instances on their “New Tab” pages running fullscreen in different workspaces. You’d have to click the workspaces to see what other apps are there for context clues or inspect the tabs of each Chrome instance. That was a highly specific case, but it’s meant to show a general issue that could be experienced among many apps. This is a less than ideal solution. To fix the problem of reminding the user of their workspace activity is relatively simple: labeled workspaces. 
Note: The mockup above is meant to portray the concept and is not a requirement on how it MUST look. The implementation details can vary and is ultimately in the hands of the GNOME design team. Some variations may include: having a rounded input field, having an icon that expands to a text field upon click, or even having direct label entry into the mini-workspaces on the right.
With labeled workspaces, the user can immediately recognize the purpose of each workspace they set up. In addition to the name, labeled workspaces also behave differently from dynamic workspaces. Upon labeleling, a dynamic workspace would “float up” until it rests beneath another labeled workspace or hits the top of the stack (if there are no other labeled workspaces above it). It would also gain the following properties:
- User-Controlled Lifetime – if all the apps close within the workspace, the workspace will survive, even across reboots. This means that developers don’t have to save the apps/states of individual workspaces, and users won’t have to recreate/label the same activity they do each session. To make a labeled workspace dynamic again, a user would simply select the workspace in the overview, enter the label field, and delete (backspace) the previously typed in label. If the workspace is empty, it will be automatically deleted. 
- User-Controlled Positioning – labeled workspaces can be moved around relative to each other. This is a feature that I think many would like to have. 
With labeled workspaces, the problem (as it currently exists) of reminding the user of their activity per workspace is solved. I believe the manner in which I have presented the concept does not complicate the UX for the simple “one workspace” user, an provides functionality for the “multiple workspace” user in a manner that improves their workflow without being disruptive (to both demographics).
With labeled workspaces, other GNOME shell aspects – working with apps in different workspaces and working with workspaces themselves – improve as well. I will cover these improvements in a later post, so stay tuned!
Not surprisingly, the realization of these deficiencies isn’t something unique to only me. The following bug reports are either sources of inspiration or related discussions I found after the fact:
- Bug 648855 – Use tags and named workspaces
- Bug 663984 – Give users the choice between dynamic and static workspaces
- Bug 646409 – Allow dragging of workspaces to reorganize them
“I used to be a gnome developer, then I took a keyboard to the knee.”