Developing an Extension

Update: The labeled spaces extension can be found here.

As I work to have my idea enter the pipeline for inclusion into mainline, I’ve decided to implement my labeled workspaces idea as an extension. To make the customizations necessary, I’ll need to have a pretty good understanding of the system I’m modifying. Unfortunately, due the current lack of documentation for the Javascript files, I’m going to have to go through the source code and try to understand it myself. It also doesn’t help that I’m not accustomed to the technologies the shell is made out of – Clutter, St, Shell, GI, and Gjs, but I think it should be a fun learning experience. Firstly, I plan to learn and understand Clutter with:

• Clutter Documentation
• Clutter Tutorial

After learning Clutter, St, and Shell should easier to pick up since they are either fully or partially based on Clutter. After understanding the drawing libraries, I’ll head on to understanding GI. Actually, it turns out Clutter and GObject are closely related, so I’ll have to do those two together. Finally, I’ll look over Gjs and the Javascript files concurrently and attempt to understand how the UI works. After all this, I should be able to understand what components to modify as I make my extension.

Have any tips, comments or pointers?

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.

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.

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

Ctrl+Alt+Down

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.

Conclusion

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.

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

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

Glawn Project Status

Glawn is my personal software project. The Georgia Tech LAWN login client, shown in the screenshot below, has come pretty far from its inception.

Glawn 1.0, pronounced guh-lon

Believe it or not, it started as an unnamed shell script that I created during my Freshman year at Georgia Tech. It was pretty shoddy work, but it worked. During my sophomore year, after taking a class in C (1372), I decided to rewrite the shell script in C, using the getline function to accept the user’s username and password.

Then summer arrived.

With plenty of time (although, I did have my first internship during this time) and an itch to learn some open source technologies (GTK+ specifically), I was able to release a graphical version of my script, Glawn 0.9. Though an appreciable milestone release, it was still kinda hacked together. In fact, I didn’t want to touch the codebase at all the following semester.

Glawn 0.9, beta quality

During this time, I also was able to revamp my Prism Webpage using recently learned web technologies (XHTML, CSS, Javascript). I wanted to have a decent looking site as this would hold the Glawn Project Page. But I digress.

Fast-forward to Spring 2011, Georgia Tech-Lorraine, Metz, France. I worked on Glawn a good amount to bring it to it’s 1.0 release. By the way, multi-threaded processes are a pain. Anyway, to sum things up, Glawn now works on Windows, in GT-L, and has been downloaded at least 5 times (once for a 4007 project).

Hey, it’s a start…

What’s in store for the future? The user-visible feature roadmap can be seen on Glawn’s FAQ page. On the technical side, I plan to use GSettings for data storage and to rewrite the GUI with GtkBuilder. I am on the fence as to whether or not I should put this project on Launchpad.. Suggestions?

Glawn is my personal software project and my lens into open source development.

Hello world!

Hello everyone,

My name is Nanley, and I’m a student of computer engineering at Georgia Tech.

I hope to chronicle here some of my life experiences as well some thoughts on my interests. These include: Health, Linux, and Art.

Well, that’s me. And once again, Hello World!

Kirby, by nano