i started working on an app and when you right click on a grid, you get about 14 menu items. i thought it was cleaner to start to nest some of the menus as there were clean "grouping" of menu items but it caused a bit of debate.
is there some guideline or best UI practice on context menus?
I would say maximum one level of nesting. And nesting only for rarely used actions, its a major hassle to use, especially for inexperienced users (i.e. your grandma).
A submenu requires extra clicks or mouse movement and should be your last resort. And the mouse movement required really is tricky; you have to move the mouse over that narrow strip of one menu item to the right, to get to the submenu.
Also, a submenu hides the item that the user may have been looking for, whereas normally it would have been in plain sight.
14 items isn't that much; for reference, my Firefox context menu contains 14 elements and I can find what I want real quickly. It is much better to group the items sensibly, with some separators in between, and maybe add clarifying icons.
Related
Hoping you can help me as I have searched a lot of forums and did not find the same question, never mind the answer I need :)
I have a power point pack which I have put together. It is built to be a template for my team to use repeatedly and is set up using slide masters to control the layout. Each layout slide in the slide master includes two checkboxes to identify either a pass or a fail. My problem is that when you insert a new slide (by either duplicating an existing slide or adding a slide from the slide master layout), and change the checkbox value it also changes on the other slide. Is there a way either using some quick VBA or otherwise to stop this from happening and break the link between the two slides.
Any help would be really appreciated.
In a weird way, this is reasonable behavior from PowerPoint, though it certainly does seem bizarre.
Shapes on a master layout appear on any slide based on that layout. Though they appear on the slide, they're not editable on the slide; it's as though the slide were a clear layer above the layout, one that you can add more stuff to but that you can't "penetrate" to get at the stuff on the layout below.
Placeholders are a special case and so, apparently, are ActiveX controls like your checkboxes, which DO allow editing. So what's happening is that when you change a text box, you're changing the text box on the layout, not on the slide itself (the checkbox doesn't even exist on the slide ... you can't select and move it in normal view, for example, unless you go to the layout in Master view).
When you change the checkbox, you're changing the one on the layout, and since the checkboxes appear on any slide based on the layout, when you change the checkbox, you're changing the one on the layout, ALL of the slides based on that layout get the changed checkboxes.
Some mildly tricky VBA could look at each slide and if it's based on the layout that contains the checkboxes, COPY them to the current slide from the layout and finally make the checkboxes on the layout invisible.
The simpler solution might be to supply a sample slide with the checkboxes ON the slide and let the users copy/paste it into their presentations.
[later]
I've reported this to MS as not so much a bug as a design oversight; the behavior may make sense, but it's not useful and can mislead users (as you well know).
I'd suggest that you visit https://powerpoint.uservoice.com and suggest that ActiveX objects on masters/layouts behave more like placeholders ... spawn new instances of themselves when a new slide based on the layout is added rather than letting the user THINK that's what's happened.
I'm using AngularJS 1 with angular-material and ui-router.
Does anyone know what the best practice is for providing a UI for some "new foobar" type thing? In other words, let’s say I have a ui.route putting me at /app/#/foobars/ which shows a list of all the foobars. At the bottom right is a FAB with a big plus sign, which will bring up a new UI something to allow the user to specify how they want their foobar. What is the best practices for this "UI something" that comes up, using Angular?
Should I use an angular-material dialog? (That’s my first inclination, but it seems old-fashioned.)
Do I create a route to /app/#/new-foobar/ and just bring up another UI? (This seems heavy-handed; I don’t want to change the URI, plus I probably want to get back to where I came from after creating the foobar.)
I think that ui-router allows nested states; is this something I would use? But I don't want the new view/component to be embedded in the current view --- I would expect a card or something to somehow "overlay" whatever view is showing.
I wouldn't use nested states for this, as they are intended for things such a master/detail navigation.
The answer to your question is "it depends", as many situations in programming there're always some tradeoffs you must consider. Depending if you're targeting a desktop or a mobile app you'll have more or less space to put these options on the screen. If there're a lot of configuration options you should define a completly different state on wich you layout them and apply this configuration when you come back to the list. If there are not too much of them or you want to keep them visible at the same time as the list, you can go with a SideNav panel that can be locked open depending on the resolution. An alternative I've used sometimes is using a subheader to show some controls, as you can make it "stick" below the header or let it go if you scroll the list. As I told you before is a matter of choices and tradeoffs, and some sense of usability and simplicity towards the final user. There's no silver bullet nor best practice, just follow your intuition. Good luck!
I'm developing a Winforms application which has been running for years with an explorer view (TreeView left, screen right). I means that:
All the screens have an hierarchy organization
All the nodes on TreeView have one and only one screen related.
A screen gets activated when a node on treeview gets selected.
One of the advantages is that the user has an ordered stucture and one of the inconveniencies is that with hundreds of screens the user gets confused.
I see other options: use classical menus, use tabs or a mix of everything.
Any advice for a good way to show a lot of screens to user in a user-friendly way?
Update: I'm changed "hundreds screens" by "a lot of screens". The most important thing is not show all at time but that the user can find what they need easily.
Update2: In this proposal, the user only see one screen at time.
Update3: I'm talking about handling multiple screens not showing multiple screens. No MDI, only one ontime.
I have used other applications similar to this is the past, and the major problem is trying to find the exact screen you want. There are two common solutions to this problem, shortcut codes and favorites menu.
With the shortcut codes, allocate a short code (5 or 6 characters) to each screen. The user then inputs this shortcut code into a text box which will then jump to the correct screen. Users will create their own list of often used codes.
For the favorites menu, allow users the ability to be able to create their own menu list in the structure they want. They will find things easier, if they organize it themselves.
Why do you need to show so many seprate screens at once? Why not just show the screen for the currnetly selected node, why are all needed at once?
If it is all tabular data is is probably too much to be consumed all at once, if it is graphical data, could it not be combined?
There may be a valid reason to show all the data at once or there may not, hard to tell from what is provided in your question. With that said, better to keep it simple than overload the user. MDI apps are never easy to use.
Tabs may work for a small set of items but still is not a good UI for hundreds of items.
If you are only showing one element at a time, out of hundreds possible on the tree nodes, then that is fine. The one screen showing at a time would be contextual to the item selected as the user moves through the nodes. Think of the Outlook approach where what is selected in the left pane is displayed in the right pane in whatever form fits the data being displayed.
Have you considered the Office Ribbon?
The Ribbon gives you a lot of flexibility on how to show and
organize functions and it's highly visual.
Here is a good link about the Ribbon and also here
To use the Ribbon you have to license it from Microsoft. You can do that online.
Providing the user with ketboard shotcuts is usually a good thing too.
I also like to provide the user with an "autocomplete" field on the menu
so that they can can find the function by name (or part of it) and be
able to navigate directly to where they want to go.
I general I find trees to be a bad idea, especially if your "hierarchy" is of a small fixed depth.
If you have a small fixed depth, consider replacing the tree with a list. At the top of the list can be drop-downs for filtering based on the node-level properties. It will use up less screen real-estate because it is vertical-only, with no horizontal component.
Clicking on an item can display it in the view (like currently), but it may be a good idea to allow a user to double-click on more than one item which could launch more windows, or tile with the existing displayed items. (I am assuming that currently, the user only sees a single detailed view at once in any given window.)
Actually, it’s hard to beat a hierarchy for organizing large numbers of items. I wouldn’t favor a classical pulldown menu for vast numbers of windows because it would be even harder to keep track of where you are than in a tree (e.g., a tree lets you look in multiple branches at once). But here’s a few alternatives:
I’m not clear how you ended up with so many windows, but maybe it comes from combinations of classes, views, content, and detail, or maybe it comes from using a task-centered UI structure for something far too complex (I’ve more on that at http://www.zuschlogin.com/?p=3). For complex apps, you want a different primary window for each significant class of data object (e.g., invoices, employees). These are listed on one menu, and typically there’s few enough (15 or less) that it can be single non-cascading pulldown menu. The content of each window is set by a separate menu, perhaps by a menu item that opens a dialog that may include a list box (like an Open dialog) or other controls for querying/searching. The “view” of each window (how the data objects are shown, e.g., table versus form) is set by menu items in the View menu. Details for any given object in a window can be shown in a separate pane within the window in a master-detail relation, essentially turning you data objects into a menu for details. A single window can have multiple detail panes for the user to open and close to select the specific detail to show. Tabs may also be used within a single pane to fit subdivisions of content.
You say it’s not important to show all window options at once, but often showing all options at once makes it easiest for users to find what they need. Maybe you need a “home” window that lists all the other windows in organized, labeled, and separated categories. This is will be easier to use than the tree if your users select a window then stick with it for most of the session. Your tree is better if there's frequently selection of windows throughout the session, owing to the overhead of getting to the home window. If all windows/options don’t fit on a single home window, then show only selected common windows for each category on the home window and provide a button or link to show an exhaustive list.
If you’re talking 100’s of windows, maybe you should have Search, perhaps in addition to a menu-based browse approach to getting to a window.
In any case, providing easy access to the few most commonly used windows is a good idea. Such windows can be explicitly selected by the designer, based on user research, or selected by the the user (favorites), but it also typically works well to make it automatic with an algorithm that uses some combination of frequency and recency of use.
Is there a simple way to tell what triggered Click event of a Button apart from setting multiple flags in Mouse/Key Up/Down event handlers? I'm currently only interested in distinguishing mouse from everything else, but it would be nice to handle Stylus and other input types if possible. Do I have to create my own button control to achieve this?
Edit: To clarify why I care: in this particular case I'm trying to implement "next" and "previous" buttons for a sort of picture viewer. Pictures in question may be of different size and buttons' positions will change (so they are always centered below picture). It's quite annoying to follow such buttons with mouse if you need to scroll through several pictures, so I want to keep mouse position constant relative to clicked button, but only if it was clicked by mouse, not keyboard.
Edit2: It does not matter whether the buttons are on top or down at the bottom, since the center can change anyway. "Picture viewer" here is just an abstraction and in this particular case it's important for me that top left corner of the picture retains it's position, but it's out of the scope of the question to go in details. Scaling the picture is not so trivial in this sort of application as well, so I do want to know the answer to the question I asked not going into UI implementation discussion.
if (InputManager.Current.MostRecentInputDevice is KeyboardDevice)
You should instead handle specifically the MouseXXX, StylusXXx, and KeyboardXXX events.
Could you elaborate on why you would care?
Having written many custom controls myself over the years, I cannot recall one instance where I cared how a click event was triggered. (Except for that pre VB6 control lifecycle glitch that fired the got focus-click-lost focus in a different order depending on whether you clicked a button, used an accelerator key, or pressed ENTER as the default).
Personally I find it annoying when people place buttons at the bottom of Windows forms and web pages. Read some of the literature on UI and you will find that most people don't even get that far if they don't find something interesting on the page/form. I like to be able to click next as soon as I know the content is of no interest to me, so keep the nav buttons prominent at the top.
I would put the prev/next at the top of the picture where you can control their position. Dancing those buttons around goes against most opinions on UI consistency. Further creating a different experience for a mouse user versus a keyboard user also goes against most current wisdom on good UI design.
The alternative is to choose a constant max size a picture can obtain on the UI and if it exceeds that scale to fit, otherwise allow it to change freely within a frame. This keeps your buttons at the same place if you absolutely must have them on the bottom.
You could create an enumeration with the different devices, have a global property that you set every time the mouse/keyboard/etc. is initiated, and just refer to this when needed.
What do you think is the best way to present a hierarchical list of functionality to users within your traditional WinForms application? (A menu system - Assume functionality can be split into a small number of modules and sub-modules but with no fixed depth in terms of those sub-modules).
Do you like the traditional drop down menu system, ribbons, docked toolbars, a treeview approach or any other innovative ideas?
An important thing to consider in your design is Usability vs Discoverability.
The best solution depends strongly on who you users are. The UI requirements for a kiosk application for tourists in a city centre are very different to those for a control screen at a power station...
I often have a toolstrip docked on top for those functions that is most used. And all other as drop down menues with hotkeys set.
If I have a list that can contain different types of items I use a bottom docked toolstrip that change its content depending on the selected item in the list. That way I only have buttons/icons that is relevant for the task and not a bunch of disabled buttons irritating the view.
I also add a context menu for the items that automagically fills with the same choises as the bottom toolstrip. That way I give a faster way to get to the "action" without having to move the mouse down to the bottom of the screen.
I really hate the ribbon-thing (as a user) so I dont use it as a programmer in my projects.
In my opinion the best way is to make sure everything can be done in several ways.
Menus
Keyboard shortcuts
Toolboxes ...
So the user can choose it's way around.
What I really like to see in more application is that a menu or option is directly attached to the selected item (control) a user is looking at. And of course the menu is in context with the given content.
I have implemented this in my open source project Monex and I really like using it myself. Just look at this screenshot.
You could always opt for the increasingly ribbon control. Microsoft/Office interfaces have a habit of becoming the user's expectation of norm (eventually).
Menubars, toolbars, and Ribbons are used for commands, where the user selection of an item acts on a data object displayed in the window or the application as a whole. Which one you use depends primarily on the number of commands in your app.
Toolbar alone: About 20 or fewer commands. Provide both icons and text labels for each command button. Represent the hierarchy by separators. Have no more than two levels –flatten your hierarchy accordingly.
Menubar with toolbar: Over about 20 but less than about 1000 commands. Up to twenty menu items on a single menu (using separators) is generally better than cascade menus –flatten your hierarchy accordingly. Common commands should have accelerators. Generally limit your toolbar to no more than 30 of the most commonly used commands, primarily commands otherwise only accessible from within a dialog box. Consider not having toolbar controls for menu items that have accelerators –one good means of expert access is often sufficient.
Ribbon: Over 1000 commands. A Ribbon is little more than putting different menubars-and-toolbars on separate tabs. To work well, the tasks associated with each tab (the top of your function hierarchy) should be non-integrated –users relatively rarely switch from one to the other. The Ribbon is also tends to be more effective for promoting discovery of advanced features at the price of discoverability and efficiency of basic features.
Check if items in your function hierarchy may be better represented as attributes rather than commands. Commands carry out a process, such as Open, Find, and Copy, while attributes change specific characteristics of something, such as Font, Size, and angle of view. Attributes are set by field controls within your window (e.g., text boxes, check boxes, and dropdown lists) rather than menu items, toolbar controls, or Ribbon controls.
A window-full of such field controls (or other representations of data objects) is a content block. Tree controls may be used to control what content block is shown. Like tab controls, they are preferred over multiple windows when the user frequently switches among the content blocks and does not compare content blocks. Trees are preferred over tab controls when the amount of content will not fit in a single row of tabs.
Do not have any empty nodes in your tree. Anything the user clicks on should display a full pane of content –flatten your hierarchy accordingly, even going to the extreme of using a list box rather than a tree.
If users tend to select one content block, complete a task there, then leave your app, then consider a “home” page displaying a full-page menu of all the content blocks, possibly spatially arrange according to your hierarchy, each accessible with a single click.
In my opinion there is no definite answer to your question. It always depends on the menu you are presenting to the user and the users that are expected to use the application
A menu with standard/common functionalities is probably best presented Office style meaning drop down menus or the new Ribbon style.
A menu with custom functionality and, as you state multiple modules and submodules with different depths, is often best presented as a TreeView-like menu.
Looking from the point of the user, a typical user will do just fine with a standard menu whereas a more advanced user won't mind more advanced features like keyboard navigation or possibility to hide/show the menu or dock it to the other side of the window.