This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

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

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

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

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

window_grouping.png

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.

1.2.1. Window Selector

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

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

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

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

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

system_messages.png

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

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

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

2. Summary of Desired Changes

2.1. Launcher Context Menu

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

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

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

2.4. Window Preferences

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

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

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

3. Comments

2024-10-23 10:58