Vincent Vuntz wrote in October of musings from the User Experience Hackfest primarily (if I may be so bold) to plug an alternative desktop organizational paradigm called activities. From Vuntz' description they seem to be little other than prearranged virtual desktops (virtual desktops are also known as workspaces):
If you look at the current usage of workspaces, you can find out that most people use them to make it easy to switch between various mental contexts. And actually, nearly everybody using a computer has to switch between mental contexts, like read mail, browse the web, do my work, etc.
I too have happened upon a similar and similarly named idea; it is quite an intuitive one to power users, however the similarities between Vuntz activities and the idea I've had are only skin deep. I'd like to focus on a comment written by one "mangler" which articulates my opinion of Vuntz activities quite well:
Activities are not browse web and answer emails.[An activity is] work on a project which includes e.g. using the terminal, browsing around and answering mail, switching hamster applet on and off, chatting with project members in an IRC channel.What I want to know about activities:- How long have I worked on them- What files have I produced- What messages have I exchanged with others (be it mail or irc)
Mangler's comments out the naïve two-dimensional Vuntz activity as a simplistic fantasy of how users use desktops, and suggested some productivity-driven features to boot. I like Mangler's contributions to the notion of activity, but what I'm really hoping is that they suggest more to you than mere productivity-related features,, because maybe you aren't as concerned with productivity as you are with something else.
To this end, activities really ought to be offered as a more generalized framework which other applications and modules can plug into to provide their own facets and functions in the same way that a window manager defines the behavior of windows and decorates them with whatever window mangement controls the user sees fit to have.
To explore what kinds of features you might want to add to your desktop's notion of activities I think we should explore their very nature a little further.
An activity seems to be a more or less informal spatial organization of application windows with the prescribed intent of associating windows relevant to a specific activity.
One difference might be that while most things called virtual desktops can only accommodate windows which appear on one or all virtual desktops in a single session, perhaps something called activities can do away with that limiting spatial metaphor. That is to say: with virtual desktops a window is either tied to your screen or it is tied to one of the rigid partitions in a large expanse of virtual space you call a virtual desktop; perhaps individual activities can be more like a plan describing window visibility and position.
Ok, that may seem a rather shallow difference at first, but it gets messier. Let's consider two very different approaches toward similar (though not identical) user interface-related goals.
First UI approach: custom shells. By which I mean software packages which offer to dump you into a command shell with a modified PATH (for the uninitiated, PATH is a variable that determines which commands are immediately available to the user.) I've encountered packages ranging from compiler toolchains to revision control systems which offered a custom shell as the default mode of interaction with the software. The goals accomplished by the custom shell might be three-fold; the first two involve name collisions: if you desire commands that share names with other known packages (or names which would be impolite to assume domain over) then modifying the PATH environ is an easy route to success. The other goal is convenience, and that's closely related to the second approach to user interfaces I want to discuss.
Second UI approach: graphical user interfaces. Why on Earth would someone trade in the near-limitless power of the command shell for a slower, more limited graphical interface? You can type many more commands than you can fit buttons on your screen, and using menus and moving the mouse around is laborious and unnecessarily slow! The first reason is obvious: it's easier on your primitive human memory. Buttons and menus are like a clickable cheat-sheet of commands you can enter (of course most GUIs even offer hints to help users forgo using that slow mouse, but that is neither here nor there.)
What custom shells and GUIs have in common with one another is activity-centric organization!
The user interface design approach used in every typical graphical application is the same approach we're craving when we follow our noses into the corner of the memesphere where activities live, yet somehow when we all stumble into this intuitive user interface idea, we tend to miss the clear connection between activities and the advent of GUIs.
Let's be clear about one technological reality: most GUI toolkits are application-centric; that is to say that most system processes represented by GUIs have their own windows which are not shared by other system processes represented by GUIs. It's as if we couldn't let the greenbeans touch the mashed potatoes! There are exceptions, of course: Gnome panel applets, Growl alerts, GTK+ plugs and sockets, the near-ubiquitous "tray icons" and NextStep dock applets -- just to name a few; and there are plenty of ways of writing pluggable software which isn't represented by a system process, and can be dynamically loaded by other program code, shared libraries and scripting languages chief among them.
Just examine the anatomy of any graphical user interface to see what I'm getting at with my comparison of GUI and activity. The X-Chat IRC client has different tabs or pages for switching your focus between different IRC channels. It has a text-entry widget for entering messages and commands. It has a list of users in the active channel. It has a box containing the channel topic. The only thing barring us from seeing graphical applications in the same way that we see activities is because of the monolithic application-centric design pattern. How about launchers? In a very legitimate way, the act of starting an application is as much a part of that application as it is a part of the application you used to start it. So a launcher can be seen as a field of limited cooperation between different applications, tied together due to a mere technical limitation into a launcher. Lots of applications are like database interfaces mated with various other tasks: media players, news readers, mail clients. Your web browser is a database of bookmarks, cookies, and browsing history combined with a network transaction layer (GUI representation = "location bar") and an application sandbox environment we call "the web." If you think about it, the underlying databases containing your history and bookmarks never needed to be specific to individual browser programs, and neither did the user interfaces that correspond to them. Apple's Spotlight might just as easily draw up your documents as it might draw up your browser history on any one of your browsers, and my bookmarks are stored on del.icio.us
Activities may be a good idea, but what I'm trying to get across in this article is that we're already using activities: we should focus more on tearing down the barriers between applications than on trying to arrange their windows.
Dylan McCall wrote:
This would benefit particularly if we beefed up file handling to be more sensible, for example remembering what programs were used to work on certain files and providing options for particular "actions" that can be performed on files in a way much like "Open with" but a bit more understandable. In addition, it would help if the shell was more consistent with applications it launches so that "files" in the file manager sense stopped being files and started being documents, graphics and whatnot as they are in their more specialized tools.
Pre-X, Mac OS had this same behavior, and let me just say that it was extremely annoying to me personally, and implementing it is fraught with pitfalls: metadata does not carefully follow files as they get moved around. Every time you move or copy a file it would forget which application you "preferred" (quotes deliberate) to open it with in the same way that it forgets what its thumbnail looks like, except that thumbnails can be recalculated from the contents of the file, whereas your "preferred" viewer/editor application cannot.
I would however like to point out the similarities between a graphical shell that remembers which applications you prefer for individual files, and the custom command shells I mentioned earlier. Perhaps it would be useful to associate file handlers with different activity screens. Immediately what comes to mind is that if you have The GIMP or Photoshop associated with an activity, double-clicking file icons in that activity would prefer to open the file with The GIMP or Photoshop. The same could be said for opening video clips: a regular media player by default, your favorite video editing software from within your video editing activity. The only downside to this seems to be that drag-and-drop has served this purpose perfectly well in the past.
If I may, I'd like to bring this article to an end with a few crazy ideas I've had in the past for desktop organizational paradigms and tools that are quite different
Windows/Portals
Every now and then I remember the realization I had that the popular notion of windows might have been called boxes if desktop environments allowed you to choose an arbitrary rectangle from a GUI and tear it off and display it elsewhere on your screen. Many GUI toolkits allow for widgets to be explicitly set to "tearable" (GTK+ has years on Microsoft in implementing this feature) but those widgets are discrete and really only meant for reorganizing toolbars and menus. Ultimately I think the idea is a bit impractical, but it meets with a certain programmer's sense of efficiency to implement tearable toolbars as a subset of the ability to tear arbitrary rectangles out of GUIs and reorganize them as you see fit!
Infinite Desktop
The Infinite Desktop idea is not much different from the existing virtual desktop/workspace approach. Virtual desktops are a lot like one giant desktop which you can only page in edge-of-screen sized increments. What if you could page in much smaller increments? (Or no increments: smooth scrolling?) What if the dimensions of this virtual desktop had no practical limitation and scrolling vertically was as easy as scrolling horizontally?
Controlling such a large desktop with such small increments seems unwieldy with controls that are conventional for existing virtual desktops, but I think I have a solution to that problem. If you've ever used Mac OS X's zoom feature (made easy by the fact that they had one of the first hardware-accelerated window compositing layers in a popular windowing environment) I hope you noticed the default movement option is much more satisfying than the other option. When you zoom in, your notional desktop is now visually larger than your display is, and you must pan your screen (let's call it a viewport) around to see it all. The obvious user interface for this is to move the mouse cursor beyond the edge of the viewport, intuitively nudging it in that direction, exposing the parts of the desktop you want to access.
The better user interface -- and the default with Mac OS X's zoom feature -- is for the viewport to be positioned within the expanse of the desktop relative to how the mouse cursor is positioned within the expanse of the display.
What that means is that if your cursor is in the corner of your display, then the viewport is showing that corner of the desktop. As you move your cursor in any direction, the viewport gradually pans in that direction, too.
Simple alternatives include holding a key/button combination and dragging the viewport/desktop position relative to the desktop/viewport position. There is zoom control to consider too, but I'll leave that up to you, but not before suggesting that maybe windows can be scaled arbitrarily! Maybe important windows are larger ones, positioned around the periphery of your primary window galaxy. Perhaps notionally-related workspaces / activities are organized into scaled-down collections which you have to zoom in on to use, and which look like the thumbnails of virtual desktop pagers when you aren't zoomed in on them. Perhaps you can also instantiate formal rectangular organizations which can be clicked on to zoom in and lock in so that you are free to mouse without moving the viewport, if that sort of thing bothers you (for many activities, I imagine it might; but there are plenty of ways you can imagine to lock the screen in place, I'm sure.)
Exposé, Dashboard, and the Desktop
The desktop serves, as far as I can see, two functions, be they or be they not usurped by other features which can fulfill the same purposes. First, it's the first thing you see when you login! Perhaps the desktop has never been embraced as the go-to interface for starting new tasks/applications/whathaveyou because beside being the first thing you see, it's also the first thing to become obscured. On the other hand, Microsoft Windows' and the Gnome desktop environment have both had a show desktop feature for over a decade, Mac OS X has had Exposé for many years now. Is the Desktop really any more keystrokes/mouseclicks away from your Start Menu, applications menu, Dock, Gnome Do, run command dialog, Spotlight, or any other interface you use for running programs or opening files?
The primary thing holding back the desktop has been that navigating them is kludgy, they are often unorganized (or if they are organized, they're too organized to serve other legitimate uses) and more often than not they're just a file-folder abstraction for some directory within your HOME directory (with the notable exceptions of icons representing filesystems, removable media, and make-believe places like My Computer.)
Sure, you can add icons for your favorite documents, applications, and URLs on the web, but as I mentioned before, the Desktop has been too kludgy for even most novices to fool themselves into thinking that's a convenient place for them to go. The desktop for most people tends to be a neglected place, at best a rest stop for recent downloads, and the place to access removable media.
I also like Apple's Dashboard (at least in concept -- in implementation it's a ludicrous hog of memory) as an alternative home for applets which are too big or otherwise ill-fit for your Gnome panels / Windows Taskbar / Dock.
Are they a match?
I think they are! As a software developer I appreciate the ease of access of the contents of my desktop (an ordinary directory populated by ordinary files? Can it get any simpler?) but I think the Desktop can be much, much more.
While it may not be the best idea for Apple's target demographic, I think most Linux users would feel right at home with this idea: What if you merged Apple's Desktop Exposé function and Apple's Dashboard reveal function? What if your most commonly use applications, application/Start menu, and a generic run dialog, recent documents/downloads all had a home within an organizational paradigm sitting somewhere between the idea of a Desktop and the idea of Apple's Dashboard?
The Desktop has remained unchanged for a long time in part (I think) because the friendly cluttered meat-world desktop analogy is charming and unintimidating, and is always easy to access for developers. But I propose that it's time to move the Desktop forward. I want to press one key or key combination and have all those things at my disposal. Perhaps this is even where your virtual desktop / workspace pager, or notification backlog belongs. Of course it doesn't really matter what I think belongs there, as long as there's a good applet / plug+socket / docklet framework for it.
Labels: desktop environment, user experience, user interface
