Tag Archives: gnome shell

Labeled Workspaces Revisited – Tags

With multiple workspaces in use, labeled workspaces have the advantage of quickly reminding the user what activity they’re working on in each workspace. My previous proposal was to have workspaces manually entered by the user. It brought along with it an additional text-entry interface element into the overview. In this proposal however, we revisit the topic of labeled workspaces with another option that offers the benefit of automation but sacrifices some specificity. This proposal is not to implement labeled workspaces through direct label entry, but rather, through indirect, automatic tagging. Compared to the previous proposal, these are the main benefits:

  • No addition to the overview’s interface for label entry
  • The user is relieved the burden of having to manage their workspaces (controlling the UX is one of our design principles)

So how would tagged workspaces work? Well take a look at the windows tab in GNOME Shell’s looking glass. Notice that we have data – data on the titles of each open window (and theoretically data on previously opened windows or tabs if we stored this). Using this data, we can use any tag-cloud generation algorithm to find words that relate to what the user is doing in each workspace. These tags can be displayed whatever way is deemed best for the user experience. It could be a tag-cloud overlay on each mini-workspace, or it could be a comma-separated one-liner of relevant words.

wordle test (open data session, first 8 pages transcribed)

Because tagging is automatic, the user no longer has to control the lifetime of each workspace. That feature’s purpose was to prevent the user from retyping the label each session. Thus, there no longer needs to be a distinction between static (user-controlled) and dynamic workspaces. Nonetheless, allowing a user to rearrange his or her workspaces would be a good feature to have.

Tagged , ,

Labeled Workspace Improvements

Labeled workspaces help improve the experience of “Finding & Reminding,” in multiple parts of GNOME Shell, as I mentioned in my earlier post. Let’s take a look at two parts of GNOME Shell that could be improved with this concept.

Keyboard-Based Workspace Switching


With labels

When switching workspaces via the keyboard, the user is faced with the task of finding what activity is on each workspace, before they reach their target destination. An improvement to this situation will not decrease the amount of workspace traversals the user must make, but it will get rid of the time the user spends examining each workspace traversed, behind the dialog.

With the configuration on the right, the user simply sees their target label and moves until they reach it. No need to examine each workspace in between each move.

Alt + Tabbing Among Multiple Workspaces

Alt + Tabbing

With labels

The current alt+tab dialog’s organization with respect to workspaces is simple once you grasp it. It puts your current apps on the left of a line, and all other apps on other workspaces on the right side. If there are apps w/ instances across different workspaces, this line-based separation is found under a nested list. This application-centric view effective as it is now, but I believe that the use of labeling, like in the figure on the right, would make it easier to find “which” instance of a certain app a user wants.


Due to the nature of workspaces being activity-focused, I believe it would be a great improvement to include labels while switching among them via keyboard. For alt+tabbing however, because the purpose is mainly for the user to switch among apps (not activities-specifically), the current interface is probably suitable. With multiple instances, and when spread across different workspaces, however, labels should make application switching easier.

Tagged , ,

Improving Workspaces in GNOME Shell

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

Current Overview, Multiple workspaces

Current Overview, Multiple workspaces

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. [1]

Overview with Multiple, 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. [2]
  • 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. [3]

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:

  1. Bug 648855 – Use tags and named workspaces
  2. Bug 663984 – Give users the choice between dynamic and static workspaces
  3. Bug 646409 – Allow dragging of workspaces to reorganize them

“I used to be a gnome developer, then I took a keyboard to the knee.”

Tagged , ,