Difference between revisions of "User Experience/Command search"

Revision as of 23:35, 24 November 2008

This is a design of a new, simple way to interact with OpenOffice applications. 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, users spend a lot of time and concentration manually searching the menus, usually using the mouse, and feel frustrated and powerless for not being able 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 descriptions should contain synonyms for commands; e.g. "insert picture" = "insert image" = "add picture".

The search box can appear next to the menu bar, right-aligned. It should be labeled "Type what you want to do (F7)" or similar inside the box; the label text is faint and disappears when the box is focused. A tool tip should give a little more description: "Type here to invoke a command such as menu item to invoke".

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.0, Jim sees a new text input box labeled "Search" next to the traditional menu. He understands what it is for, thanks to the tool tip and his familiarity with URL bars. When he needs to add a formula inside Writer, he focuses the search box and types "formula". Three items appear below the box, saying "View -> toolbars -> formula", "Insert -> Object -> 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.

Placement

The consensus on the UX mailing list is to put the command (search) bar next to the menu bar, except perhaps for the MacOS version. There was discussion about putting it under the "Help" menu. It can also appear only when explicitly invoked, say under the Tools menu or by pressing F7; then it could replace the menu bar until it is dismissed by pressing Escape or a command is executed.

Putting the search box inside the Help menu would be more consistent with MacOS X's command search - see [1]. Consistency is important if everything else is equal, but here are some advantages to putting the command bar next to the menu bar.

1. In plain view it is definitely more discoverable than under any menu.
2. It is more inviting to use, so users are more likely to get the liberating benefits it provides.
3. 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 consciously 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 window location and the shortcut Alt+h) with the thought of getting help.

Users probably will not look under Help before making effort on their own. This often avoids 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.

Next to the menu bar it would look different than existing programs. But there is already a near precedent with the URL bar, which is perhaps more entrenched than MacOS's command bar in the Help menu. There are even tutorials on the Web about how to put their Firefox URL bar in the same row as their menu bar.

If the command bar is placed in the menu bar, it would be prominent, and so very accessible. It would also take up space that is free anyway. Resizing the window would resize the command bar, just like a URL bar in a web browser. If the window gets too small, the bar 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.

But in the end, a even command bar in the Help menu would be a great improvement over not having one at all.

Other details

Command descriptions can be created by hand, with using menu item tool tip text, 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 ranked by relevance.

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.

There may be an option to reveal a command's corresponding position in the menu, e.g. an icon ("reveal in menu"), positioned at the right edge of the results list.

Menu entries

User Experience/Command search/Commands

Related projects

• 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.
• 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
• Decide the exact text for the search box tool tip
• Create a mock-up of the unfocused search bar, showing the in-box label (grey) and a tool tip
• Compile a list of command names of menu items
• Add synonymous names
• File a feature request at QA.OpenOffice.org so that developers can weigh in on implementation options (arguments, use of Ubiquity code)