UI ideas for when toolbars fail

Answer 1

You're well out of the comfort zone, through the discomfort zone, and halfway through the having-a-hot-poker-shoved-up-your-backside zone :-)

You should really be thinking of the toolbar as a speed-bar, somewhere where the user can go to do common operations with minimal actions. Other than the Gimp with its infamous UI, I can't fathom any application that would need anywhere near 1,000 common operations worthy of use in a speed-bar.

Perhaps you need to rethink what you're providing.

Some of the Microsoft applications do it reasonably well, they divide their toolbars into sections (e.g., drawing, statistics, formatting) and let the user decide which sections are shown. That way the user decides if they want a minimal workspace or whether they want the whole top half of their workspace taken up by toolbars.

The non-common operations should always be available by menus anyway, whether common is fixed by you (hard-coded), chosen by the user (configuring those sections) or "intelligently" shown by the program (based on previous use).

Here's what I would consider a good approach.

1. Have all operations accessible from the menus by dividing them into sections (operations within a section should be at least vaguely related). Let's assume for now you can have 30 sections of 30 operations each (unlikely, I know, but simple for this discussion).

2. Have a special section for adaptive operations. By that, I mean a section the program will populate with operations based on how often the user uses them. To do that, you need to keep a record of how many times an operation is used by the user (each user has their own count, of course, since their usage profile will be different).

3. Allow the user to configure which sections are displayed in toolbars, including the adaptive one. This gives them control over it.

4. The adaptive section should be populated by the most commonly used operation provided they don't already appear in another toolbar already. That way, the user can get at the most commonly used operations which aren't already on one of their chosen toolbars.

That seems to me the most flexible solution, giving the user total control over the use of their screen real-estate.

Answer 2

I'd think the biggest question here is "what kind of interaction flow are your typical users looking for?" Take a look at how your users actually interact with your program as it stands - are there certain patterns in how they access the various items you have on toolbars?

For instance, are some of your toolbar items extremely frequently used, while others are rarely accessed and when they are, typically accessed along with other similar functions? Perhaps the former items belong on the toolbar, while the latter items would be better suited to some kind of set of palettes that could be opened in a sidebar.

Is there any way that you can make some of the toolbars more context sensitive? It seems rather unlikely that all 1000+ of your toolbar items would actually be relevant to any particular state of the application. Instead of displaying every possible action, just display those for which the prerequisites are met: if you have an option to make a line through two points, don't display it until 2 points are actually selected.

The key thing to remember is that user interfaces should be driven by what the user needs to do and see at any given point in time.

Answer 3

Can you describe what you're doing a bit more? From the sounds of things it's a CAD tool.

In this case, I may do something a bit different but also common.

I would firstly suggest make everything as context-sensitive as possible, and then, do this:

1. Place very very common and general functions at the top
2. Create a entirely new window for managing the rest of the buttons

The new window will sit off on the second monitor of the user. It can be large and extravagent, and contain searching and large icons for getting around inside it. Specifically, however, I may also add an ability for it to be navigated very fast, using the numpad.

You may detect, in the main window, when the numpad has focus and is being used, and take that as input to searching for specific commands in the offset window. Perhaps you can group them all so 100 functions exist per group, and for functions of type X, you start with a "9". I don't know your user base, and this would be only appropriate if people start to become experts in the software, but I think it's not a bad model in-general (a window off to the side to manage all these actions).

Answer 4

Adobe Photoshop approaches (I can't say "solves") this issue through pallets of controls. The individual pallets can float on the screen, be docked to the window, and can have tabs inside them with additional pallets. Also, most pallets can have a context menu with access to meta-settings for the pallet itself.

It also has a number of key items in a traditional toolbar, some of which change dynamically as the context changes. For instance, when you begin to stretch a layer, a box appears where you can type an exact dimension. When you change tools, the toolbar changes to include controls that relate only to that tool. And so forth.

One good thing about this approach is that many heavy users have multiple monitors and it is often practical and useful to float many pallets onto a second monitor.

I think it works partly because the controls are sensibly collected into the pallets so that related controls are together.

I'm certain it has an upper bound for number of total controls, however.

Answer 5

You might consider looking at techniques from websites, since websites with hundreds of pages are more common than apps with hundreds of buttons.

A very web-like solution is to add a "search command" box. It does require the user to use the keyboard, but if you index the commands well they won't have to memorize the names of all commands, just what they do.

One possibility is to make your tab-toolbar hierarchical. e.g. in the screenshot you showed, Analysis, Freeform, Primitive, and Util would be tabs underneath Surface.

To figure out how to categorize things, you could try grabbing some typical users and doing card sorting tests. It might get a bit hairy with 1,000 cards, but you'll find out how your users want to group the buttons.

Dav's suggestions of a context-sensitive toolbar sounds good to me too.

Answer 6

One alternative I've seen, in GIS programs, is to abandon putting this at the top of the window altogether. For example, ArcGIS puts the (very few) quite common "commands" in the menu/toolbars, but then has an entire docked window in their UI (which can be turned on and off) that provides a tree view of all of the available commands (they call this ArcToolbox - not too creative of a name on their part, but it makes sense to their users).

There are quite a few advantages to this - The main one is that you can have a hierarchical, categorized structure of commands that's fairly fast to navigate. In addition, plugability becomes quite easy, as plugins can just add commands to the tree or create new tree nodes.

It's not as elegant, in some ways, but it seems to be fairly easy for most people to handle.

Answer 7

The user has two hands. One usually on the keyboard, for modifier keys and such, and the other on the mouse. A CAD user probably has a very nice mouse with 5 or 6 buttons.

I believe that I might like an interface designed to pop up around the current mouse position. Not just a right-click context menu, but surround the mouse with a text menu, an icon toolbar or three. Maybe two context menus. This doesn't have to be radial although radial looks nice. I like exploded radial, with a big hole in the center so the area around the mouse stays visible. But the interface could be rectangular and work fine.

Then I would use the left hand fingers on the keyboard. Assign 12345 to functions in one toolbox/menu. Assign qwert for another toolbox/menu and asdfg and zxcvb. Give the spacebar a big important function and of course Ctrl, Alt, Shift, even Caps Lock.

Then use sequences of these easy to hit left hand keys to select functions. asdf and qwer should get the most important stuff. For the newer user, each keystroke should update the menu display so that they can see what is happening. For the experienced user, the display should never slow down the command input.

Oh, and have a fast way to repeat the last command and maybe the 2nd-5th last command. Maybe have a visible last command stack and use the numbers 1-5 to move a different command to the top of the stack and another easy to hit key like back-tick to run the top command on the stack.

For example, the user should be able to hit Space to pop the menus and qqrwe to select the function and have it execute right then.

Of course the mouse can still be used to navigate and select commands. But I think the keyboard method would give the best speed, much like vi as a text editor does. I think that having to hold Ctrl Alt and Shift and hit keys, all with the left hand leads to finger cramps.

Answer 8

David,

This post is pretty old but I thought I'd respond anyway as I'm an avid user of your software, Grasshopper, as well as Stack Overflow. When using components in your software I typically find my self in two separate modes: looking for components I'm already aware of, or figuring out what other components are available that might be able to perform what I'm trying to achieve.

When using components that I'm already aware of 99% of the time I end up using the feature where you can double click on the canvas and type all or part of the component name. Even when I'm looking for new components I tend to use that feature more then the toolbar. Say I know I want to divide a line, but I don't know where the Icon is. I'll just enter the name "Divide" to search for all the commands with "Divide" in their name.

While the toolbar is useful for seeing an overall view of what's available. I end up spending a lot of time dragging components out just to see what inputs they accept. Thus I think it would be useful to make the toolbar more dynamic and context sensitive. For example if the user selects a component that can output points, then I'd like to see a separate toolbar pop up that only shows components that can take points as an input. Autodesk Revit has functionality like this where, for example, if a user selects a wall they will be presented with all the tools related to modifying walls.

With your software this would be easy as you could simply cross reference the output of the currently selected component with the inputs of all available components to generate the dynamic tab. Ultimately this would allow users to quickly answer the question "where can I go from here" by selecting individual components in their current definition.

Answer 9

A few labels and tooltips (and logical grouping!) can go a long way: take a look at the UI in Office 2007/2010; It's actually really good (people complain because it's different than it was before).

Now imagine that same UI without the labels on the buttons...

Simply add labels to your buttons and group them into drop-downs, and your UI will be great!

Answer 10

these buttons are for commands such as "Line between 2 Points", "Circle through 3 points" etc. etc. Many modern CAD apps have hundreds if not thousands of tools to manipulate geometry

This sticks out, to me, as the big failing. Maybe that's why I've always found CAD programs so incredibly difficult and frustrating to use.

Here's how I look at it. Before CAD, what did we do? Pencil and paper, with ruler, compass, triangles, t-squares, french curves, and so on. So the transition to computer was done by making each tool a "tool". Then to add more features, you add more "tools".

But that's backwards. I didn't use a compass because it had a great user interface -- it's actually a bit clumsy -- but because it provided a perfect circle. If I could draw a perfect circle with my pencil freehand, I wouldn't ever reach for the compass!

Well, my computer can draw a perfect circle, and the very concept of "tools" are irrelevant to it. Go look at some old videos of human-computer interaction, before we knew what "toolbars" were. On RAND's GRAIL, if you wanted to delete something, you'd scribble it out. If you want to draw a box with the corner chopped off, you draw a box and then chop the corner off. On Ivan Sutherland's Sketchpad, if I want to draw a line between two points, I draw a line between two points, and the computer understands the constraint that the line should be between those two points. These aren't that hard for a computer to figure out.

I don't know what 1000 things your CAD program does, but I think they probably fall into a relatively small number of categories:

• draw new things
• stretch/deform things
• move things (often with one point/axis/side/etc fixed)
• delete things
• ...

So why do I need more than a handful of tools? If I draw a squiggly circle, chances are really good that I want a real circle. Let me draw and figure out what I want. Don't make me use any toolbars.