What's the best way to present menus in your application?

What do you think is the best way to present a hierarchical list of functions to users in your traditional WinForms application? (Menu system. Suppose the functionality can be divided into a small number of modules and submodules, but without a fixed depth in relation to these submodules).

Do you like the traditional dropdown menu system, ribbons, docking toolbars, tree structure approach, or any other innovative ideas?

+1


source to share


6 answers


An important thing in your design is Usability versus Openness .



The best decision depends on who you are. The UI requirements for a tourist kiosk app in a city center are very different from those for a control screen in a power plant ...

+2


source


I often have a toolbar docked at the top for those features that are most used. And all the others are like dropdown menus with hotkeys.

If I have a list that can contain different types of items, I use a bottom dock that changes its contents based on the selected item in the list. This way I only have buttons / icons that are relevant to the task, not a bunch of disabled buttons that annoy the view.



I also add context menus for items that are automatically populated with the same options as the bottom toolbar. Thus, I give a faster way to get to the "action" without moving the mouse to the bottom of the screen.

I really hate the ribbon thing (as a user), so I don't use it as a programmer in my projects.

+1


source


In my opinion, the best way is to make sure everything can be done in multiple ways.

  • Menu
  • Hotkeys
  • Toolbars ...

Thus, the user can choose the method.

What I really like about other apps is that the menu or option is directly bound to the selected item (control) that the user is looking for. And, of course, the menu is in context with this content.

I have implemented this in my open source Monex project and I really enjoy using it. Just take a look at the screenshot .

+1


source


You can always select the ribbon control. Microsoft / Office interfaces have a habit of becoming the user expectation of the norm (eventually).

0


source


In my opinion, there is no definite answer to your question. It always depends on the menu you present to the user and the users who should be using the application

Menus with standard / general functionality are probably best represented in the Office style, meaning dropdowns or the new ribbon style. Menus with custom functionality and, since you specify multiple modules and submodules with different depths, are often best presented as a menu like a TreeView.

From a user perspective, a typical user will be fine with a standard menu, whereas a more advanced user will not mind more advanced features like keyboard navigation or the ability to hide / show a menu or dock it to the other side of the window.

0


source


Menus, toolbars, and ribbons are used for commands where a custom item selection acts on a data object displayed in a window or in the application as a whole. Which one you use depends primarily on the number of commands in your application.

  • Toolbar only: about 20 or fewer commands. Provide both icons and text labels for each command button. We represent the hierarchy as delimiters. Have no more than two levels - place your hierarchy accordingly.

  • Menu with toolbar: about 20, but less than 1000 commands. Up to 20 menu items on a single menu (using separators) is generally better than cascading menus - place your hierarchy accordingly. General commands must have accelerators. As a rule of thumb, limit your toolbar to no more than 30 of the most commonly used commands, most notably those available only from a dialog box. Consider that there are no panel controls for menu items that have accelerators - good enough for expert access.

  • Feed: more than 1000 teams. The Ribbon is nothing more than creating different menu bars and panels on separate tabs. To work well, the tasks associated with each tab (at the top of the feature hierarchy) must be non-integrated — users relatively rarely switch from one to the other. The Ribbon also tends to be more efficient at promoting new features for the price of detection and efficiency of core functions.

Check if the members of your function hierarchy can be better displayed as attributes rather than commands. Commands perform a process such as Open, Find, and Copy while attributes change specific characteristics of something, such as Font, Size, and Viewing Angle. Attributes are set using the field controls in your window (such as text boxes, check boxes, and dropdowns), not menu items, toolbar items, or ribbon controls.

A window populated with such field controls (or other representations of data objects) is a block of content. Tree controls can be used to control which block of content is displayed. Like tab controls, they are preferred over multiple windows when the user is frequently switching among blocks of content and does not compare blocks of content. Trees are preferred over tab controls when the amount of content will not fit into one row of tabs.

You have no empty nodes in your tree. Everything the user clicks should display the full content pane - raise your hierarchy accordingly, even as a last resort use a list box rather than a tree.

If users tend to select one block of content, complete the assignment there, then leave your app, and then consider a "home" page that displays a full page menu of all blocks of content, possibly spatially arranged according to your hierarchy, each accessible with a single click ...

0


source







All Articles