This is a work-in-progress! Help/advice/comments/suggestions are most welcome!
Contents
The following is an idea for a new main menu. It is influenced by the Slab and Affinity Search Menu, and also a little bit by KDE 4's Kickoff and Vista's Start Menu. It also takes ideas from Gnome-Do.
Key design elements
- Integration of live search
- Combines searching and categorical navigation - so you can search within a category, for instance
- Able to access a range of different object types
- Can be fully operated from the keyboard in a GNOME-Do kind of way
- Good ergonomy and intuitive to use (I hope!)
- Dynamic adjustment to user behaviour - hence heavy reliance on 'Recent' and 'Favourites'
Mockup: Default appearance
Mockup: Expanded all category
Mockup: Expanded applications category
Design description
Sort modes
- The top of the menu is occupied by three sort modes. each represented by a clickable button. Only one sort mode can be active at any one time.
- Favourites is automatically populated with the most used items.
- The sort mode reverts to 'name' when 'recent' or 'favourite' mode is active and a user action (selection of a group, for example) results in the search results list being empty.
- The default sort mode is a property of the filters found in the left hand column. When a filter is selected, the current sort mode changes to that set by the filter. After this, it can be manually changed using the search mode buttons.
Right-hand column
- Contains the search box and search results.
- The alignment of the search box with the space which contains search results communicates the connection between these two items.
- Search is live: results are automatically updated as the user enters search text and selects categories from the left-hand column.
- The search results box contains space for 10 items. When more than items 10 are returned, a more button is displayed, indicating that it is possible to page through the results.
- Paging to the right, a back button is displayed with an arrow pointing to the left.
- Note: In a previous incarnation of this design, the search results box would expand downwards to include the extra entries. Discussion of this issue can be found at the bottom of this page, as well as in previous versions of this page.
Left-hand column
- Each entry is a filter.
- Filters are arranged in a hierarchical tree.
- Searches entered into the search text box operate on the results of the filters.
- The default sort mode is a property of the filter.
- A possibility for future development - make entries in the left-hand column user editable/expandable (including the default sort mode).
Use and navigation
Menu activation
- The menu can be activated by clicking the menu button or by pressing the menu short cut (something nice like GNOME-Do's Super+Space).
- By default, when the menu is started, focus is on the top-most item in the search results list - this is highlighted.
Right hand column - search results
- The right hand column contains the results of the left hand filters and the search text.
- Pressing return or clicking on an item in the results list activates it.
- Up and down arrow keys navigate through the search results list. Pressing return activates the selected item.
- The right arrow button pages to the right.
- Left arrow key pages to the left. When there aren't any pages to the left, pressing left switches focus to the top item in the left-hand column.
Left-hand column - 'groups'
- Clicking or pressing return on an item in the left-hand column applies that entry to the search results.
- Child items are revealed by clicking on the little arrow thingy next to parent items.
- Up and down arrow keys can be used to navigate the list.
- The right arrow key moves the focus to the top item of the right-hand column.
Search box
- Typing while the menu is open shifts the keyboard focus to the search text box, this results in text automatically being entered in the text box.
- Search is live - as the user types, the search results list is automatically updated.
- Down arrow button switches keyboard focus to the top search result.
- Right arrow button when at the end of a line pages through search results in the right-hand direction.
- Left arrow button when the text cursor is at the far left of the search text box moves keyboard focus to the top item of the left hand column.
Categorical menu tree
/MenuCategories contains details of the hierarchical arrangement of items in the left-hand column.
Questions and thoughts
- Is it appropriate to have system settings in the main menu, or would it be better to have a link to a control centre, as is currently found in the Slab?
- An idea: when the user selects a directory in the search results pane, the contents of that directory are then displayed in the search results pane.
- Another idea: a status bar to the bottom of the menu, which would display context dependent help and reports. For example: 'Press return to start the Firefox Web Browser', or 'Search complete'.
- I'm pretty unhappy with the handling of large numbers of search results. This will be especially problematic when results are ordered by name. Does anyone have any suggestions?!
AndersFeder: Just a thought, but would paged results be better? Instead of a long scrollable list show only the first x items and then at the click of a button in, say, the lower corner of the menu, show the next x items.
AllanDay: I have thought about using some kind of paging in the past. I guess my opinion on the matter has been that this isn't a web-page, so let's not start imitating them. You might be right though, Anders. Paging would have the advantage of meaning that the search box/menu wouldn't have to expand to accommodate results. There would be a negative side though. Paging would mean that you would have to make an extra action to see the full contents of lists of results with between 11 and 19 results - which includes many current menu operations. An example: I currently have 12 items in my Accessories menu. If I select Applications > Accessories, I want to see all my accessories straight away. I don't want to have to do an extra action to see the last couple of items, which I may or may not be interested in.
AllanDay: I've taken up the paging thing for the time being. It certainly looks neater. I still wonder how painful this will be to use in certain situations, however.
Could the left-hand panel use an accordion menu (suggested by Andrew Stormont, who also wrote the prototype).
Could it use a simple query language, like that found in Affinity, or Banshee?
Comments
AndersFeder: Again an interesting read, Allan. I think innovating the main menu is a great idea - ideally the main menu could be the final, unifying destination for the many desktop navigation tools we see popping up these days (Beagle, Tracker, deskbar, Gnome-Do, Gimme, Affinity etc.). I haven't tried the Slab, but I think they're on the right track. Personally, I would strive not to limit myself to a few narrow sorts and hierarchies, but rather create a pluggable structure. For instance, a "songs matching my current mood" sort for music files or "people related to this document I'm currently working on" sort. Actually, many of the ideas for the abandoned Dashboard project could be recycled for this project - only instead of rendering items of predicted interest in a huge list in one side of the screen, the items would be rendered in a neat menu structure when requested with a mouse click by the user.
AllanDay: Thanks Anders! The design's still evolving! Your idea for a pluggable structure, as you call it, is an exciting one. The way I'm imagining it, each menu item (in the left-hand column) would become a query. You could then have a graphical tool which would enable users to modify and rearrange existing queries, as well as add new ones. (Is this, roughly, what you had in mind?!) I can already imagine some ways in which the design can be modified to fit with this idea.
AndersFeder: Yes, basically. The menu plugins could be made available as standard packages such that the user may install them through the distro package manager or, as you suggested, through a specialized GUI for the menu (implemented with e.g. PackageKit). The exact query interface and the manner in which query results are rendered would be an implementation issue, but one could imagine the plugins having more degrees of freedom than just producing a horizontal list of text items. For instance, a submenu for navigating LAN workgroups may feature an area showing network status information. A menu for navigating your e-mail may feature a few handy buttons for actions such as composing new mail or retrieving incoming mail. You're probably right that a proper balance need to be struck between main menu features and specialized browsers - the latter are better suited for highly complex queries.
AllanDay: It's useful to hear that you're in favour of using the main menu as a central location for desktop navigation. I have been wondering about whether this is the right direction for a main menu. Here, the Slab is instructive - it uses a model where the menu provides a short list of items and provides a link to a more substantial browser application. This can be at times frustrating, but it also represents quite a neat division of labour. Going down the road of trying to provide a generic search interface runs the risk of overlap with other interfaces, whether they be specifically search orientated (like the Tracker and Beagle front ends), or more specialised browsers, such as Banshee/Rhythmbox, F-Spot, Soylent, PaperBox, and Nautilus.
