Difference between revisions of "User Experience/Command search"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Related projects)
(Other details)
Line 51: Line 51:
 
The result list should not obscure too much of the document.  So, the size of the results box should be constrained (but not too small), and a scrollbar should appear if needed.
 
The result list should not obscure too much of the document.  So, the size of the results box should be constrained (but not too small), and a scrollbar should appear if needed.
  
The result list can be ranked by alphabetical order, by frecency, or by date of addition.
+
The result list can be ordered alphabetically, by frecency, by relevance, or by date of addition.
  
 
There may be an option to bring up the Help on what you're trying to do (like maybe have a divider and underneath the matching command, saying something like "View help for X command").
 
There may be an option to bring up the Help on what you're trying to do (like maybe have a divider and underneath the matching command, saying something like "View help for X command").

Revision as of 06:51, 4 December 2008

This document is a design of a way to interact with OpenOffice applications using commands. It is being discussed at the UX mailing list, here

A major difficulty in using large applications like OpenOffice is that users do not know where to find the menu item or button they need, because there are so many menu items and buttons. Despite designer's efforts to organize the menus and tool bars, users spend a lot of time and effort searching through the menus, usually using the mouse. They feel frustrated and powerless to achieve what they need.

It is more efficient for the computer to search for the menu items, based on query text entered by the user. The user types what she wants to do, and sees matching commands appear in a drop-down box under the query box. The list of matches shrinks as the user types. The user can hit Enter to activate the first entry, or use the arrow keys to select another entry then press Enter.

The query matches substrings of command descriptions. If a query contains multiple words, they are matched as a conjunction (not as a string) of non-overlapping words.

The command box should appear next to the menu bar, right-aligned. It should contain the label "Type what you want to do (F7)" in faint color. The label disappears when the box is focused. A tool tip appears on mouse over, saying "Type in the box to invoke a command, e.g. 'insert table'".

Command box mock-up; please create a better one

Use case

Jim uses Writer a lot, but inserts formulas rarely enough to forget how to do that. So every time he needs to insert a formula, he has to look through the menus. He guesses it may be under Tools, clicks on the Tools menu, but does not find anything related to formulas. Then he opens the nearest candidate menu, Format, but again does not find anything. Next, he opens Insert, which sounds promising, but he still does not see anything about formulas. He closes the menu and visually scans the menu names again, then decides to look in Insert more carefully. He consciously reads every menu in order until he reaches Object, which sounds promising. Finally, Jim finds Formula near the bottom of the Object menu, and selects it, feeling frustrated and stupid.

After installing OOo 3.2, Jim sees a new text input box labeled "type what you want to do" to the right of the top menus. Curious, he points the mouse pointer at it, and sees the tool tip "Type in the box to invoke a command, e.g. 'insert table'". Jim starts typing "insert table" and sees a list of commands, appear. Thus he understands what the box is for. When he needs to add a formula inside Writer, he focuses the command box and types "formula". Three items appear below the box, saying "View Formula tool bar", "Insert formula" and "Table formula". Jim presses DownArrow, then Enter. Feeling satisfied and powerful, he enters his formula.

Other uses

The same mechanism and the same box can be used for more uses:

  1. Searching Help without invoking the help window first. Thus the user's thought stays with the issue that needs help, rather than being interrupted by invoking the help app first, seeing the help interface and going to the right tab to search for the issue.
  2. Setting options. When you activate a command matching an option, the options window would open with the right tab and the option in focus. That would avoid searching through the huge maze of options.
  3. Inserting special characters: type "insert x" where x is the name of the character, such as "inf" for infinity.
  4. Opening files. When you start typing a file path, the result list shows names of directories that complete it. If type a directory path and a substring of a file name, the result list would show files in the directory, whose names contain the substring. Eventually, OOo may be able to rely on file indexes provided by the OS, such as Tracker and Beagle, so you don't have to type the file path, just the file name.
  5. Switching windows. If the query matches the name of a file that is already open, you can switch to the window showing the file.

Command box placement

Several places for putting the command (search) box were discussed on the UX mailing list:

  1. Next to the window's menu bar
  2. As an entry in the "Help" menu, as in some Mac OS X applications (illustration)
  3. In place of the menu bar, when explicitly invoked (say under the Tools menu or by pressing F7). It would disappear when user presses Escape or executes a command.
  4. Next to the cursor or selected object, when explicitly invoked.

The consensus is to put the command box next to the menu bar, except perhaps for the MacOS version. Consistency with Mac OS X and other programs is important if everything else is equal, but users are already familiar with a URL bar, which is somewhat similar. And next to the menu bar it would have some advantages:

  1. It is more discoverable than under a menu. Users rarely look under Help because before trying on their own may avoid the detour through the Help system, which interrupts the user's task; it is a different mode of thought. By contrast, the command feature should be natural and seamless and the usual way to interact with the program.
  2. It is more inviting to use, so users are more likely to take advantage of it
  3. It is not associated with getting help. If it's under Help, users may think that it is only for getting help, while if it's next to the menu, that suggests it applies to other things.
  4. Even knowing that there is a command feature under Help, in order to develop a habit of using it, users would have to break their association of the Help menu (including the menu location and the shortcut Alt+h) with the thought of getting help.

Next to the menu bar, space is free. Resizing the window would resize the command box, just like a URL bar in a web browser. If the window gets too small, the box may eventually become hidden like other tool bars and even with the menu bar; or it could just break into a new line under the menu bar.

Other details

Apart from their canonical name (e.g. "insert picture") commands may have synonym names ("add picture"). Synonyms can be created by hand, using the text in the Help, and a thesaurus. The synonyms can be extensible by for the user, and even easily shareable.

The history of executed commands should appear in reverse order if the user clicks on or presses the Down arrow key in an empty, focused query box.

The result list should not obscure too much of the document. So, the size of the results box should be constrained (but not too small), and a scrollbar should appear if needed.

The result list can be ordered alphabetically, by frecency, by relevance, or by date of addition.

There may be an option to bring up the Help on what you're trying to do (like maybe have a divider and underneath the matching command, saying something like "View help for X command").

Mockup for providing an icon to reveal the command's position in the application menu structure.

It may be useful to reveal the menu item for the selected command's (if there is a menu item), as in MacOS. But that would be too slow, distracting and would not encourage the user to use the command. Instead, we can highlight the enclosing menu in the menu bar (and the rest of the path path to the item) without; the user can open the menus if she is interested. Alternatively, each result that corresponds to a menu item can have an icon at the right edge, that when clicked opens the menu to reveal the item.

This command facility will not be included in the MacOSX version of OOo, at least initially, until it is better than the system search for menu items under the Help menu.

List of menu entries and buttons

User Experience/Command search/Commands

Related projects

  • MacOS X applications have a command box in the Help menu.
  • All desktop command-search tools, such as Gnome Deskbar, Gnome Do, Apple Spotlight
  • Archy and Enso, libre partial implementations of Jef Raskin's book "The Humane Interface". Archy is a content-based system completely driven by commands which act on ordered selections as arguments. For example, to calculate 1+2, type "1+2", select it and execute the command Calculate. The result replaces the expression. Enso is a similar, though limited, tool for the desktop.
  • Mozilla Ubiquity, a command tool for the Firefox Web browser, where commands have arguments. No menu entries exist as commands so far, but the code may be useful for implementing this current proposal.
  • The text editor Acme, plus all its clones. They do not search for commands - you have to know the right command name and arguments.

To do

  • Create a nicer mock-up with larger font and right-aligned box
  • Create a mock-up of the unfocused command box, showing the in-box label (grey) and a tool tip
  • Compile a list of menu items and buttons
  • Create a command name for each menu item and button
  • Add synonymous names where required
  • Convert this document into a specification
  • File a feature request at QA.OpenOffice.org so that developers can weigh in on implementation options (arguments, use of Ubiquity code)
Personal tools