User Experience/UI ideas
For a pretty long time, we've been discussing a possible new UI. We've had several suggestions and mock-ups, like the one of user JaronBaron or the FLUX UI, and discussed those lightly, but that's as far as we have gotten. Rather than trying to summarize all of a single user's suggestions into one and critiquing it separately, it seems more logical to create a list of UI ideas from which a new UI can arise. (We should also keep in mind the UI elements of competing software.) Please discuss these elements under the "Discussion" tab.
Direct Manipulation Snippets
See here for a detailed description
Styles button
As suggested by Leonard Mada: "Instead of fonts, I would probably add a "Styles"-button: [in the left-most corner of the toolbar]
- less space occupied than the list-box
- when pressed (or hovered), it should open a small window, stacked to the left-margin, which contains:
- frequently used styles, grouped by: heading, body-text, other
- list of styles used in the document
- the font-list (a more advanced one)
- further formatting options
Users will have a more useful touch to styles, and would be able to change the styles attributes where they need it: within styles!
And it would add consistency to their documents / increase the use of styles / increase awareness of styles / move toward automatic styling."
Menu and help item search
A searchbox that would search through menu and help items, much like that in Mac OS X Leopard (under the help menu).
Chrome-like title bar
I recently tried Google Chrome and once its Mac counterpart is released, it will become my default browser. The UI innovations in Chrome are commendable and should definitely stand as an example. So here's my Chrome-based idea: a tabbed title bar with tabs that can be dragged out. There would be slight differences: I'd suggest a save button next to the title when the document is unsaved (instead of a "*" like some other apps have) and "open" and "new" buttons on the right (open would be a split button, with the down arrow showing recent documents OR a button opening a new tab which would stand as an open dialog). The document icon next to the title in the tab bar could open a menu with "Save as...", "Print", and other document-related commands, now that we're looking into ways of getting rid of the menu bar.
History sidebar
The idea is a sidebar showing action history, much like the history sidebar in Firefox, only with actions (or the history panel in design applications, only made into a sidebar). The unique idea here is that there could have several columns (the sidebar would be resizable horizontally) for those times when one undoes a few things, then changes something, but then wants to come back to what he had before he undid anything.
Inline command search
This is a design of a new and simple way to interact with OpenOffice applications.
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:
- 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.
- 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.
- Inserting special characters: type "insert x" where x is the name of the character, such as "inf" for infinity.
- 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.
- 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 make the shortcut obvious (Alt+H) and it would be more consistent with MacOS X's command search (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.
- In plain view it is definitely more discoverable than under any menu.
- It is more inviting to use, so users are more likely to get the liberating benefits it provides.
- 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.
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 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").
