Oh, menus and controls.
I can honestly say that, before these chapters, I didn’t think of ‘controls’ in such a descriptive manner-I just called them controls, and thus, while watching my emails disappear into the abyss, would punch my screen, and say ‘These controls suck.’ That’s enough of my unproffesional ranting. For now.
The first chapter breaks controls down in the following fashion; imperative (things used to initiate a function), selection (tools used to select options or data), entry (tools used to input data), and display (things used to manipulate the program visually) controls. With these descriptions, it also brings to mind much for granted we have taken controls. As I listed the above, I thought a lot about interfaces and design layouts, but again, I have never thought thought to actually call them controls.
Imperative controls covers buttons, butcons (a moment of unprofessionalism-butcon? really? I mean, I get it, but…seriously?), and hyperlinks. These are your standard links to information, buttons for saving, or butcons with an image of a disk to denote saving. Imperative controls are simple enough.
Selection Controls very simple select additional options or items that the user wants/needs. This is done with check boxes, flip-flop buttons (which, while used should be avoided), radio buttons, combutcons (drop down radio menus), list controls, earmarking, combo boxes, and tree controls. This section also goes into some rules of thumb about what not to do when designing, such as scrolling horizontal text.
Entry controls allow entry of new information. This is obtained through bounded controls, such as spinners, dials, sliders, and thumbwheels-most popularly seen in media centers. Unbounded entries are entries that can be changed later, such as text entry, validation, clue boxes, units and measurements, or overtype.
Display controls are just that-controls for the display. I don’t know how many times it has driven me insane to scroll text horizontally. What? Why? What makes you think I want to scroll left and right as I’m reading? This is irritating-it should be noted that once the user sees a supposed ‘end point’ on a horizontal scale, we expect it to STAY THERE. Common display controls are scrollbars, splitters, drawers and levers.
Chapter 22 goes into menus. The first third of the chapter (roughly) covers some history of menus, and how menus are a very distinct driving force of most designs-without menus, you have no setup or starting point for order. Site maps can be considered menus, or miniature walkthroughs, of a site. Menus are credited back to command line interfaces, where a list of options were presented and the user would typically input a number or keyphrase to execute a command. This is actually still used in C++, the main programming language used to write many computer GUIs, and in some cases, games.
Sequential hierarchical menus typically start as a menu, the user inputs an option, and is lead to a different menu as a result. Again, this is a very common menu setup. Some simplified computer games still operate using this form of menu, where your decisions will lead down different roads or paths, and the user in some cases can backtrack or proceed as needed. However, the game version I described here is actually considered a visual hierarchical menu. A criticism of VHMs (I’m not going to attempt to keep spelling hierarchical and butchering-I’ll be editing all night) is that, while it was a good way to make certain that all the options were present, there was just too much information.
Drop down/pop-up menus are self-explanatory: it’s a menu that encompasses many choices all within one window. I have mixed feelings on drop-downs/pop-ups…while I understand it’s effectiveness, there just reaches a point where you have to define what to use based on the information. I’ve always hated drop downs that have hundreds of countries in them, or the fated drop down that has all 50 states in it. Seriously? Couldn’t you just…use a text box input? Likewise, I have no issue with gender being defined through radio buttons or drop downs-both are relatively effective in it’s use. Again, more things for a designer to think about.
The last thing this chapter touches on is the pedagogic vector. This basically explains creating a menu that allows the user to learn what they’re doing without fear of being scolded-easily obtained with simple steps, such as including an Undo or Cancel button. This vector allows for users to try and learn the programming without fear of commitment or having to endure something they were unprepared for. from there, it describes the more popular/common menus seen: File, Edit, Windows, and Help. These are considered primaries, with optionals being View, Insert, Settings, Format, and Tools. I’m not talking about ribbons. I hate them. I hate them a lot. It finishes out discussing standards that should be upheld with menus-disabling things that can’t be applied at a time, checkmarking things that are active, defining shortcuts (or accelerators), and access keys.
In my opinion, this chapter WAS a repeat of things that I knew, however it did define terminology that I didn’t know existed. I still find that again, in terms of design it is ultimately a case of defining what the user goal is and trying to find a simple, straightforward way to get them there. I still hate ribbons-I’ve hated them since they were introduced. Why are you fixing things that aren’t broken? I think they should have touched on the concept of ‘over-working’-the process in which you are doing TOO MUCH. I know that we’ve covered it as a design principle, but there needs to be a section dedicated to just it-because ribbons, in my opinion, are just that: over-working. Menus + toolbars were working fine…