![](\"https:\/\/i0.wp.com\/mattfife.net\/special\/elevator\/IMG_0185.jpg\")
<\/a>\u00a0\u00a0\u00a0\u00a0 ![](\"https:\/\/i0.wp.com\/mattfife.net\/special\/elevator\/IMG_0184.jpg\")
<\/a><\/p>\nThe display was locked-up mid-boot and never did recover during my short trip from the 4th to 1st floor.\u00a0 Everything went well, but wow.<\/p>\n
This brought up the importance of how it is often it’s the *subtle* clues software needs to be giving off that show that things are working ok and the software is built with enough quality to handle many eventualities to the level we feel confident enough for our important data (or in the case of this elevator – our very lives).\u00a0 Interfaces that lock up after you hit a button, spinning disks that don’t give you any clue how long they’ll take to come back, or dialogs that have confusing wording are all things that make you start to feel un-trusting of the software and start thinking it is glitchy or low-quality.<\/p>\n
Brings me to a pretty decent book on UI design I read recently “UI Design for Programmers” by Joel Spolsky.\u00a0 Here were some of the notes I took while reading his book:<\/p>\n
- \n
- People feel good about software\/something’s usability when they get a “chain of victories” – when a tiny chain of perfectly timed events\/accomplishments go off right.\u00a0 That’s what makes people enjoy <\/strong>using your software and perceive it has value and was well designed.<\/li>\n
- Know the point of usability testing:<\/u> You only need about 2-5 people to test your usability.\u00a0 More people than that, and you’ll see same stuff again and again. \u00a0You don’t<\/em> want numbers\/stats like ‘27.5% of the people found the save dialog box’.\u00a0 You want to know what users think <\/strong><\/em>should happen – so the thing you’re looking for are things like “Most of the users kept opening the file menu to find the save feature – but it wasn’t there”.\u00a0 The point is to teach you <\/em>how people *think* the interface should work.\u00a0 If you just outsource this and get a stack of numbers back, it’s like paying someone to go to college for you.\u00a0 You are not learning how the average person approaches the visual clues on a computer.<\/li>\n
- Use ‘affordances’ to help users see\/learn what to do:<\/u>
\nAffordances are visual clues.\u00a0 Use negative space to show where hand or finger goes like they do on camera bodies, put ridges on window edges to show it can be sized\/slid. \u00a0Make tabs act like real file folders so they click and show new panes, etc.<\/li>\n- Don’t break real world metaphors:<\/u>
\nWindows briefcase was totally confusing since didn’t work like real briefcase.\u00a0 Do I put things in it then copy that to my pen drive to take it home?\u00a0\u00a0 Also, always obey the laws of physics – windows tabs dragging things should behave as on a real desk.\u00a0 Don’t rely on the user knowing about strange ‘hidden’ panes or the like when switching between things (early versions of Mac Office did this).\u00a0 Don’t break people’s expectations of how something works if you use a visual metaphor.\u00a0 If you’re using it, it should be because it’s a GOOD metaphor.<\/li>\n- Consistency<\/u>
\nCertain hot-key combos and other UI behaviors had better be the same as other apps or people will get frustrated. Even if you hate the way Microsoft\/Apple did it – different or ‘clever’ new UI or key shortcuts for cut\/paste and other common features will just anger 99.999% of the people (yes – this means you Linux).\u00a0 If you’re going to do it differently, you better understand exactly why and that most people will probably TRY to do it the old way; so be ready for that.<\/li>\n- Designing for extremes often produces better designs for everyone<\/u>
\nIf you design your product for difficult\/extreme cases – it should become even easier for normal use.\u00a0 Design for people who are colorblind, for low light, shaky hands, wearigng gloves, etc.\u00a0 RFID cards for hotels were designed for folks that had poor vision\/arthritis, but turned out way easier than standard house keys for buildings and are used all the time.\u00a0 People now just put coat pockets up to the the sensor when their hands are full – much easier.\u00a0 Designers started designing large handled kitchen tools for people with arthritis; and then it turned out everyone actually preferred them – now almost all modern utensils have large handholds with nice grips and large knobs.\u00a0 Your UI should never rely on color for functionality.\u00a0 A good number of people are partly colorblind – so if you design in B\/W, it will help you create affordances that will likely help everyone – i.e. pie charts that have labels that float over each slice instead of just in a color key to the side with many different colors that are very close in shade.
\nFor computers – design for people that can’t: read, use mouse well, or have memory so bad that can’t remember own name if it wasn’t on a card.\u00a0 This is the right <\/em>way to design for usability that turns out good for everyone – and not condescending like the ‘clippy’ assistant was.<\/li>\n- Mice are hard to control<\/u>
\nAssume everyone is using your app with a crappy laptop trackpad or clip-on trackball attached to their laptop.
\nListboxes should expand to whole physical page or max elements – don’t make them scroll if at all possible. \u00a0Dropdowns should happen if you click ANYWHERE in dropdowns box – not just the down arrow.\u00a0 Always autoscroll down when near bottom of page.\u00a0 Use bold, fat fonts so characters are wide & selectable like Macs that use Chicago font. \u00a0No characters should be 1 pix wide like if you use Arial.<\/li>\n- Not all happenings are equally likely<\/u>
\nCoders think that if you allow something between the range of values, that any value in that range is equally likely.\u00a0 This is usually wrong and leads to inefficiency.\u00a0 i.e. If the range of 0 to 100 is allowed, 50 is probably more likely than someone choosing 47.\u00a0 If you allow window repositioning, odds are most of time folks will want windows in certain spots – like right against edge, not exactly 2px from edge. \u00a0Or if a window is inside another window – should you really allow sub windows to go past edge? \u00a0Snap too or have elements go to the most *likely* values\/positions.\u00a0 Photoshop has a snap to edge\/nearest ‘edge’-like feature of the picture ability.<\/li>\n- Don’t force remembering – give hints along the way<\/u>
\nMenus give lists of commands so you don’t have to remember individual commands like the old Emacs days.\u00a0 Always try to allow folks to chose from lists of things instead of having to remember.\u00a0 Give other context hints: thumbnails show what the contents of a file is, autocomplete helps finish words. \u00a0All little helps are good – but don’t go overboard – allow easy outs or pass arounds for your ‘helping’ or folks will get frustrated.\u00a0 If you fail to guess right 2-3 times, auto-disable the feature.\u00a0 Photoshop’s snap-to feature is easily disabled in the menu bar, or just hold down ALT to get rid of it for that operation.<\/li>\n- How to design a product<\/u>
\nDon’t design by listing features <\/em>you want – start with list of activities <\/em>you want to accomplish. \u00a0What activities do you want to complete with your software?\u00a0 This is especially true for version 2.0 of your app. See what people ACTUALLY use it for and optimize for those activities.\u00a0 Turns out many people use Excel to make simple lists – which killed competitors when they optimized for other activities.<\/li>\n- Don’t fall prey to “design time warp” effects<\/u>
\nYou take weeks to design the dialog boxes and flow – thinking long and hard about it – but the user sees it and needs to make a choice in 5 seconds.\u00a0 They see so many options – they don’t know what to do.\u00a0 i.e. a complex print dialog box that has so many options and parameters nobody knows WHAT to do with all the buttons\/options.\u00a0 Solution is to take a printout of the dialog to conference room and ask 3 people what they would do if they saw it.
\nOver the course of the 6mo to 2 years you develop things, you come up with more and more ideas.<\/em> While you learned them over months and years, your user will experience them in just a minute or two. The best designs are the simplest – like a toaster.\u00a0 If a software design team built a toaster, it’d end up costing $1200, make toast, BLT’s, have lcd displays, and boot up and ask if you want to register for AOL before you could make a single slice of toast – and it probably wouldn’t even do that right the first go.\u00a0 VCR designers kept adding more features until they realized what people really needed was if you put a tape in, it should automatically switch to the VCR mode of the TV\/VCR setting, and actually start playing right away, then auto rewind when it hit the end of the tape.
\nSeconds feel like hours<\/em> when you get no immediate response back.\u00a0 After about 2.7 sec, people get bored\/give up.\u00a0 So when you click on something – always do SOMETHING, never just sit there blankly while you work.\u00a0 Turn cursor to hourglass, progress bar immediately appears, etc. try to break up long operations when it makes sense.\u00a0 Instead of waiting for VB to compile all at once when you hit F7, do the parsing after each enter for a half-second, so compiling was fast.
\nWhen that fails, bunch all long operations TOGETHER so you ask all the questions up front, then tell them to go get a coffee and when they return – it will be done.\u00a0 NEVER pop up a dialog half-way through that pauses the long action so they’re stuck at the machine for the whole time.
\nBasic takeaway: Over the time you design a package, you should be removing <\/em>complications, not adding them.<\/li>\n- Don’t confuse usability <\/em>with <\/u>learnability<\/u> <\/em>– Figure out if you need learnability or usability in your app.\u00a0 If the user is going to use it once or twice (like a map kiosk) they need high learnability.\u00a0 If it’s something they use every day – it needs to be very usable.\u00a0 Hopefully a usable program is learnable so that the user can figure things out on their own.\u00a0 This means it might not necessarily be that it’s easiest on the first go – but should act <\/em>the way the expect the first time.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Went to visit a good friend that just had their first child at a local hospital.\u00a0 On the way out from the joyful visit, I was greeted by this wonderful elevator: \u00a0\u00a0\u00a0\u00a0 The display was locked-up mid-boot and never did recover during my short trip from the 4th to 1st floor.\u00a0 Everything went well, but wow. This brought up the importance of how it is often it’s the *subtle* clues software needs to be giving off that show that things…<\/p>\n
- Know the point of usability testing:<\/u> You only need about 2-5 people to test your usability.\u00a0 More people than that, and you’ll see same stuff again and again. \u00a0You don’t<\/em> want numbers\/stats like ‘27.5% of the people found the save dialog box’.\u00a0 You want to know what users think <\/strong><\/em>should happen – so the thing you’re looking for are things like “Most of the users kept opening the file menu to find the save feature – but it wasn’t there”.\u00a0 The point is to teach you <\/em>how people *think* the interface should work.\u00a0 If you just outsource this and get a stack of numbers back, it’s like paying someone to go to college for you.\u00a0 You are not learning how the average person approaches the visual clues on a computer.<\/li>\n