<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[maxdepth]"] (see also the log)>>

Desktop Interface

It is time to do more than just copy the Xerox/Mac/Windows crowd. The desktop really needs to advance beyond Windows Vista and Mac OS X.

The Launcher Context Menu

The context menu for the application launcher as it now exists offers only very rudimentary functionality. The following submenus could be added for many applications:

1. Recent documents
2. Favorite documents

Admittedly, this would require a certain amount of integration with various applications (D-Bus?), but it would allow for a quick and consistent means of accessing documents. In the context of video or music players, tracks could be considered as documents. Yet this concept doesn't need to be limited to documents. For chat clients (such as GAIM) it could be a list of Buddies.

Window Grouping

Window grouping has always been more grief than it's worth. Microsoft Windows 98/2000/XP has an option to group windows whenever the taskbar gets too full. It groups windows belonging to the same application (usually Internet Explorer) and provides a popup/pulldown menu to select windows from the group. There are three usability problems that this creates:

1. The windows in the group are not always visible.
2. You now have to click twice to access any window in the group.
3. Just because the windows are related by application, doesn't mean their content is related.

Many users inherently feel a need to group related windows together and, if an accessible grouping/ungrouping method were available, they would no doubt use it. Currently GNOME already has a grouping method of sorts, it's called "workspaces," and although it's functional, it's also rather clumsy. Below is a portion of my proposed desktop interface design.

As you may be aware, GNOME already has applets which perform the basic functionality shown here (Fast user switch applet, Workspace switcher, and Window list). What I propose is that these existing applets be modified to make the desktop experience more unified and enjoyable. Since the Window selector is the most used, it should be our first focus, the Workspace selector next.

Window Selector

• It should be possible to rearrange the buttons however the user decides. This allows the user to do some grouping, just by sticking related windows next to or nearby each other. It is obvious to me that this is something most users want. Many tabbed applications (notably Firefox) allow the user to move the tabs around at will. I recently read on a message board responses to a application which gave Windows this functionality. The excitement over the freedom that this seemingly simple functionality offers is unbelievable.
• Currently the button widths are all equal, being the width of the widest window title. This is a waste of valuable space and it causes a lot of unnecessary button movement. Each button should be the width of its title or less (at least a determined minimum width). The priority should be to show as much of the selected button's title as possible. In the diagram above, the Firefox window is selected and thus its entire title is shown. This would generally allow more buttons to be shown and so reduce the need for grouping.

Update 2006-11-11: A fixed width based on a "Maximum columns" setting would be more usable. Scrolling arrows (like those on a scrollbar) should be ever present to handle the event that more buttons are opened than this setting (as used in Firefox 2.0).

Workspace Selector

Currently the "workspace switcher" is a graphical pager, displaying rectangles representing each workspace. Each workspace rectangle contains smaller rectangles representing windows in that workspace. A user can move a window from one workspace to another by identifying the window's icon in the pager and dragging it from one workspace to the next. This is often overly tedious because you're squinting and grabbing at very small icons. My prefered way to do this is just right click on the window's title or taskbar button and from the context menu select "Move to Another Workspace >" and then select the desired workspace name.

It is obvious that the designers of the workspace concept thought users would generally set up a small number of workspaces which would change infrequently. They didn't plan on the dynamic creation and destruction of workspaces as is common in a project oriented environment.

• If you plan on creating and using more than just a few workspaces, working with them by name is by far a better method than working with unnamed workspaces on a pager using index location for identification. Since switching workspaces is generally done much less frequently than switching windows, it doesn't make sense to use valuable screen real estate by making all of the workspace names visible at once (the "Show workspace names in switcher" setting). Generally all the user really cares about is, "What workspace am I in right now?" Additionally, if they need to switch workspaces, two clicks isn't too much work for the frequency of the task. Therefore, using a pulldown menu to do the workspace switching seems sensible.

• The current method for adding additional workspaces is to right click on the pager, select "Preferences," and increment the number of workspaces in the popup dialog and maybe optionally rename the workspace to something more fitting. This requires three, four, and maybe more steps! By setting a textbox at the top of the workspace switcher's pulldown menu, it would only require two steps to create a new workspace and switch to it. An identical textbox should also be set on the top of the "Move to Another Workspace >" menu.

• Deleting a workspace should be made possible by right clicking on the workspace's name in the workspace selector. This would bring up a context menu which would contain a "Delete" action. Only empty workspaces would be allowed to be deleted without an additional prompt for permission.

The Titlebar

In my quest to reduce clutter and free up more screen space, I've questioned whether the titlebar is really needed. Here are the titlebar's functions:

1. Display title
2. Indicate focus
3. Provide access to Minimize, Maximize, and Close buttons
4. Provide access to a context menu (via right-click)
5. Provide access to Move and Resize actions via dragging

That might seem like a lot of functionality, none of which anyone would want to be without. You'd think it was indispensable and maybe to some it is, but to me personally I'd like to have the option for hiding it. Why? Because I can do without it. Well, I could if I were given an option to set border thickness. The window title and context menu are already available to me from the window's button in the tasklist, as are the abilities to Minimize/Maximize/Close the window. With the option of making the border all around the window thicker, the border could be highlighted to indicate focus. A thicker border would also make resizing the window easier (especially when considering the new touch screen laptops). Lastly, I don't need the titlebar to move the window, because I use the X11 Alt+drag standard, which is more versatile anyhow. You might say that I won't be able to close or maximize the window as quickly as if I used the buttons on the upper right corner. Sure I could, that's what keyboard shortcuts are for. Actually, by using keyboard shortcuts, I can nearly eliminate accidental window closing by making the Close shortcut difficult to hit on accident (Alt+F4).

Update 2006-12-24: I've recently discovered that border thickness and the presence of the titlebar are dependent on the selected Metacity theme. Thus in order to make a change to either of these preferences, the user must manually modify the theme they are using. I experimented with modifying some values in some of the XML theme configuration files and found that border width is generally hard-coded and setting the has_title property to false generally isn't handled well. This makes these basic preferences difficult to work with. I propose that these two properties be user configurable from the theme editor. For "Border thickness", the user should be able to choose "Use default" or input an integer value for the thickness. The "Show titlebar" preference is boolean value that should also have a "Use default" option. The default options would be theme dependent.

Update 2006-12-25: Here is a very lean theme I hacked together: Borders. It removes the titlebar and has thick borders when the window is resizable, but thin borders otherwise.

The Toolbar and the Menu

Toolbars allow for quick access to frequently used commands. They usually only contain a small subset of the commands to be found in the menu. Conversely, the purpose of a menu is to provide an organized and exhaustive list of commands. Menus generally are used infrequently to run commands, because of all the extra navigation they require. Therefore, they really shouldn't take up a whole bar or even half of one. The "Main menu" applet (akin to the Window's "Start" button) is a good example of what I mean. Displaying the File/Edit menu in this compact way should at least be an option. As a note, Firefox has an add-on which hides the application menu entirely, but I wouldn't suggest going to this extreme as it severely limits usability.

Update 2006-12-24: Recent releases of GNOME allow users to compile in Mac style menus and attach the menu to a panel via an applet. I have no doubt this will be made into a user configurable option once this project stabilizes some and is supported by larger projects like Firefox and Open Office.

The Dialog

You have probably experienced at one time or another the annoyance of working on a document and then having your work interrupted by a "low battery" or similar system message dialog which pops up and steals focus from your work. Some applications also behave in this manner. For instance when Gaim loses connection to a chat server, it will pop up a dialog asking if you wish to try to reconnect. I propose creating a system message applet which applications could register messages with (via D-Bus?). When needed, this applet would display action buttons to allow for reactions to its messages. A history would also be available for accessing past messages. Additionally, messages could be colored to indicate urgency (grey, yellow, red). This would obviously require a lot more work than just designing an applet, but the usability (and coolness) factor give it merit.

Update 2006-12-24: This project looks promising:

http://www.mono-project.com/GtkSharpNotificationIcon

Locking the Panel

It is a good practice to lock down your launchers and applets so that you don't accidentally move any of them during everyday use. The current design requires launchers and applets to be locked or unlocked individually. This is often quite tedious. Consider the case where you would like to insert a new launcher in the middle of some 20+ other launchers. This would require unlocking about 10 launchers, moving your new launcher into place, and then re-locking all those launchers. This is painful, which is not what we want our desktop experience to be. The good news is that this situation can be easily fixed by just making the panel itself lockable/unlockable via its context menu.

There is one slight caveat to this, often the panel can become so filled with launchers and/or applets that there is no available place to right-click for the context menu. This is good cause for placing an ever-present handle on one or both sides of the panel (let the user decide). Those who believe in strict adherence to Fitts' Law may throw a fit at this suggestion (sorry, I couldn't resist a good pun), but that is why this would be optional. The usability that handles provide more than justifies their taking up a corner or two of the screen.

One side benefit to having a panel edit mode, is that the context menu for the icons can change when the panel isn't being edited (which is most often the case). This would prune a lot of options that you don't regularly use ("Lock To Panel", "Move", "Remove From Panel") and make them only available when you actually need them.

Update 2006-12-04: From a suggestion made by JustinPealing below, I have abandoned my idea that we need to add handles to the panel. Justin suggested a superior idea which will not break Fitts' Law, but will be just as effective in solving the problem I mentioned above. It also looks to be easier to implement than handles. This idea involves adding a "Lock Panel" checkbox to the right-click context menu, which would control when the panel is in edit mode. The panel editing options would only appear in the right-click context menu when in edit mode.

Summary of Desired Changes

Launcher Context Menu

1. Submenus of quick launch lists such as Recent Documents, Favorite Documents, Tracks, Buddies.

Window Selector

1. Make it possible for the user to rearrange the buttons via drag-n-drop (See bug #302398 COMPLETED).

2. Create a "Minimum columns" setting for the user to allocate a default number of spaces for buttons to fill. (See bug #310809 COMPLETED).

3. Create a "Maximum columns" setting which would limit the number of buttons that could be squeezed into the space available.
4. Implement either a pager (arrows on left and right of buttons) or a pulldown menu for accessing hidden buttons.

Workspace Selector

1. Add an option to display workspace selector as a pulldown menu, rather than a graphical pager.
2. Include an "Add new" textbox at the top of the workspace switcher's pulldown menu.

3. Add an identical textbox at the top of the "Move to Another Workspace >" menu.

4. Create a context menu for the workspace pulldown menu and add a "Delete" action to it.

Window Preferences

1. Add a "Border thickness" option.
2. Add a "Show titlebar" option.
3. Add a "Compact menu" option.

System Messages

1. Create an applet which collects system messages and allows easy access to them (action buttons and a history).
2. Modify applications to use system message applet when available.

Panel

1. Change "Lock To Panel" option in right-click context menu to "Lock Panel," which when unselected will put the panel in edit mode, making edit options available in the same context menu.
2. Make this option available in all right-click context menus anywhere on the panel.

Comments

• JoachimNoreiko: I've always considered workspaces to be awkward and too technical for the average user, however OS X's decision to include them may prove me wrong... Grouping windows could be useful, but I wonder whether the real benefit might be to allow grouping of windows while visible too -- basically, *external* tabs instead of internal ones.

  • JohnPeterson: Workspaces are currently quite awkward even for experienced users, but they still serve a valuable purpose. I wouldn't expect new users to know how to use them, nor would I force anything upon them. For beginners, the UI can be set up to behave exactly the same as a non-workspace environment, simply by using one workspace and hiding the selector to create/go to others. Please clarify what you mean by "external tabs."

    • JoachimNoreiko: Tabs on the outside of windows. Consider: tabs are useful, but they add an awkward extra layer of window management, *within* the application. Also, why only group gedit documents together, or web pages? At the same time, there is a need to group windows as you illustrate at the taskbar level. Take tabs out of the app window.

      • JohnPeterson: Right. It is one of my fundamental beliefs that automatic grouping by application is overly restrictive.

• JoachimNoreiko: I have to say that I think removing the title bar is a terrible idea. Sure, its functions are available elsewhere, but not in any discoverable way. I should also tell you that interface proprosals round here tend to go nowhere unless you can find someone who's going to code them.

  • JohnPeterson: I would by no means recommend removing the titlebar by default. That is a power user option.

  • JohnPeterson: I believe my interface ideas can generally be implemented in parts and so I plan on breaking this document up into more digestable pieces to reflect that. Right now I'm just trying to get my ideas on paper. I do hope to find time to help in the coding up my propositions, at least some of them. Thanks for the advice.

• MarkusDeMartini: (Just a random thought and I know it probably wouldn't be that efficient) Expanding on the idea of a user selector, Gnome could open straight into a "guest" desktop with a default configuration (or desktop of choice) instead of gdm. Then you could select your user on the pulldown menu and have a popup where you would enter the password. I know that this would be less secure, so there would be an option to boot to gdm instead.

  • JohnPeterson: This is a great idea and it doesn't have to be insecure. The default user would just have to be a somewhat limited guest user account, but that way anyone could get to work right away and if they needed personal stuff, it would only be a few clicks away.

• JustinPealing: My comments on locking the panel - when someone right-clicks on a launcher, they are technically clicking on the panel as well. Why do panel options not appear somewhere in that context menu alongside the launcher options? (for example, under a "panel" sub menu) That would remove the need for any handle.

  • JohnPeterson: This idea is superior to my handle proposition, as it removes the need to break Fitts' Law, which I am always hesitant to do. I also figure that this would be easier to implement than handles. As you suggest, we could just place a "Lock Panel" checkbox in the right-click context menu and only when the panel is unlocked would it show the options for editing the panel. Great feedback!

• CostinChirvasuta: I love your Borders theme! Just that I changed all borders to be 5 pixels wide. I use Alt-space a lot (including to close windows) so it's better for me.

  • It is quite minimalistic, which I think some users can appreciate. Yeah, I did make the borders extra thick because I like being able to grab them easily for resizing.