Difference between revisions of "User Experience/Command search"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
m
 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This is a design of a new, simple way to interact with OpenOffice applications. It is being discussed at the UX mailing list, [http://ux.openoffice.org/servlets/BrowseList?list=discuss&by=thread&from=2124105 here]
+
This document is a design of a way to interact with OpenOffice applications using commands. It is being discussed at the UX mailing list, [http://ux.openoffice.org/servlets/BrowseList?list=discuss&by=thread&from=2124105 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.
+
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.
+
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 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 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".
+
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'".
  
[[Image:OO_command_bar_proposal.png|600px|Command bar mock-up; please create a better one]]
+
[[Image:OO_command_bar_proposal.png|600px|Command box mock-up; please create a better one]]
  
 
== Use case ==
 
== 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
+
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.
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 menuHe 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
+
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 menusCurious, 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.
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 ==
 
== Other uses ==
Line 29: Line 26:
 
# Switching windows. If the query matches the name of a file that is already open, you can switch to the window showing the file.
 
# 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 ==
+
== Command box 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.
+
Several places for putting the command (search) box were discussed on the UX mailing list:
 +
# Next to the window's menu bar
 +
# As an entry in the "Help" menu, as in all Mac OS X 10.5 applications ([http://picasaweb.google.com/photosofstuff/InsertTitleHere?authkey=lUpePSqMnis#5250481191941369218 illustration])
 +
# 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.
 +
# Next to the cursor or selected object, when explicitly invoked.
  
Putting the search box inside the Help menu would be more consistent with MacOS X's command search - see [http://picasaweb.google.com/photosofstuff/InsertTitleHere?authkey=lUpePSqMnis#5250481191941369218].  Consistency is important if everything else is equal, but here are some advantages to putting the command bar next to the menu bar.
+
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:
  
# In plain view it is definitely more discoverable than under any menu.
+
# 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.
# It is more inviting to use, so users are more likely to get the liberating benefits it provides.
+
# It is more inviting to use, so users are more likely to take advantage of it
# 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.
+
# 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.
# 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.
+
Comment: Actually, it is. If you can't find a feature, you should turn to help.--[[User:Mirek2|Mirek2]] 04:07, 10 April 2009 (UTC)
 +
# 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.
  
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, 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.
 
+
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 ==
 
== Other details ==
  
Command descriptions can be created by hand, with using menu item tool tip text, the text in the Help, and a thesaurus.
+
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 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 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.
Line 58: Line 52:
 
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 relevance.
+
The result list can be ordered alphabetically, by frequency, 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").
  
 
[[Image:Command_search_revealinmenu.png|thumb|Mockup for providing an icon to reveal the command's position in the application menu structure.]]
 
[[Image:Command_search_revealinmenu.png|thumb|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.
+
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.
  
== Menu entries ==
+
== List of menu entries and buttons ==
 
[[User Experience/Command search/Commands]]
 
[[User Experience/Command search/Commands]]
  
 
== Related projects ==
 
== Related projects ==
 +
* Mac OS X 10.5 applications have a command box in the Help menu.
 
* All desktop command-search tools, such as Gnome Deskbar, Gnome Do, Apple Spotlight
 
* All desktop command-search tools, such as Gnome Deskbar, Gnome Do, Apple Spotlight
 
* [http://rchi.raskincenter.org/index.php?title=Archy_in_the_Future Archy] and [http://www.humanized.com/enso 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.
 
* [http://rchi.raskincenter.org/index.php?title=Archy_in_the_Future Archy] and [http://www.humanized.com/enso 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.
* [http://labs.mozilla.com/projects/ubiquity Mozilla Ubiquity], a command tool for the Firefox Web browser, where commands have arguments. No menu entries exist as commands so far.
+
* [http://labs.mozilla.com/projects/ubiquity 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 [http://en.wikipedia.org/wiki/Acme_(text_editor) text editor Acme], plus all its clones. They do not search for commands - you have to know the right command name and arguments.
 
* The [http://en.wikipedia.org/wiki/Acme_(text_editor) 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 ==
 
== To do ==
* Create a nicer mock-up with larger font
+
* Create a nicer mock-up with larger font and right-aligned box
* Decide the exact text for the search box tool tip
+
* Create a mock-up of the unfocused command box, showing the in-box label (grey) and a tool tip
* Create a mock-up of the unfocused search bar, showing the in-box label (grey) and a tool tip
+
* <strike>Compile a list of menu items and buttons</strike>
* Compile a list of command names of menu items
+
* Create a command name for each menu item and button
* Add synonymous names
+
* Add synonymous names where required
 +
* Convert this document into a specification
 
* File a feature request at [http://qa.openoffice.org QA.OpenOffice.org] so that developers can weigh in on implementation options (arguments, use of Ubiquity code)
 
* File a feature request at [http://qa.openoffice.org QA.OpenOffice.org] so that developers can weigh in on implementation options (arguments, use of Ubiquity code)
  
 
[[Category:User_Experience|UI Ideas]]
 
[[Category:User_Experience|UI Ideas]]
 
[[Category:To-Do|User Experience\UI]]
 
[[Category:To-Do|User Experience\UI]]
 +
[[Category:UX Idea]]

Latest revision as of 04:08, 10 April 2009

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 all Mac OS X 10.5 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.

Comment: Actually, it is. If you can't find a feature, you should turn to help.--Mirek2 04:07, 10 April 2009 (UTC)

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

  • Mac OS X 10.5 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