Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Yikes...It Looks Like That?! - UI Worst Practices

1,140 views

Published on

A presentation given by Chris Blatnick and Bruce Elgort at Lotusphere 2008.

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

Yikes...It Looks Like That?! - UI Worst Practices

  1. 1. BP 214 Yikes…It Looks Like That?! - UI Worst Practices Chris Blatnick Bruce Elgort ®
  2. 2. Your Hosts for Today's Session…
  3. 3. Your Hosts for Today's Session… Chris Blatnick Senior Technical Specialist - IBM OpenNTF Project Contributor UI Geek Blog: www.interfacematters.com Yep...rounded corners! :-)
  4. 4. Your Hosts for Today's Session…
  5. 5. Your Hosts for Today's Session… Bruce Elgort OpenNTF Co-Founder Taking Notes Podcast Idea Jam Show-N-Tell-Thursdays Mad Drummer Blog: www.bruceelgort.com Contributing Editor: vowe.net
  6. 6. “Learn from the mistakes of others”
  7. 7. “Those who do not learn from history are doomed to repeat it”
  8. 8. “Whatchu talkin' 'bout Willis?”
  9. 9. These are important adages we hear often...
  10. 10. ...but let's take a minute to reflect on them and what they mean
  11. 11. Sometimes, the most powerful way to learn how to do something right, is to examine how someone did it WRONG
  12. 12. Thus, the thrust of our show... User Interface Worst Practices
  13. 13. Subtitle: Learn from the mistakes of others so you won't be doomed to hear “Whatchu talkin' 'bout Willis?” from your users!
  14. 14. A good user experience is not just nice to have...it is a MUST HAVE Just look at how the internet has changed our perception as to how we look at Notes applications and how we design them – well maybe
  15. 15. Users are savvy, sophisticated and have little patience for applications that waste their time
  16. 16. The aesthetic qualities of design are very much a part of the modern application interface Web 2.0 - they have to look nice and clean and simple
  17. 17. Thus, it's your job as a developer to not only write good code, but to create a... Compelling User Experience
  18. 18. Here's how NOT to do it...
  19. 19. Validating User Input ®
  20. 20. We've all had to do this, whether it's formatting the phone number in the expected way, making sure they enter the customer account correctly, or validating a social security number.
  21. 21. How to tell your users you hate them and don't trust them to enter some numbers... Take a look and let that sink in. Think the users liked this app?
  22. 22. How do we fix this?  When data needs to be stored in a certain format, make sure you handle it from a programmatic standpoint.  Don't put the effort on the user...that's why you get paid the big bucks!
  23. 23. Unclear Error Messages ®
  24. 24. Error messages need to actually say something. They need a reason for being there
  25. 25. 23
  26. 26. How do we fix this?
  27. 27. How do we fix this? Clearly (in non-tech speak) state the error and direct the user on what to do next. Give enough detail so that support can actually help them
  28. 28. Another Great Example
  29. 29. Another Great Example Remember: Error messages should be informative and actionable
  30. 30. And One More Since They’re so Important
  31. 31. And One More Since They’re so Important No one said they have to be grey and boring!
  32. 32. Uncommon Use of UI Elements ®
  33. 33. Doh! Can you say Radio Buttons? There was all kinds of code behind this control to prevent the user selecting more than one choice! The question is “WHY?”
  34. 34. How do we fix this?
  35. 35. How do we fix this?  Avoid going against established conventions.  If users expect an element to work one way and it works another, you will quickly lose their trust.
  36. 36. Reusable/Generic Components ®
  37. 37. We all agree...code reuse is good. Except when there's little thought behind it...
  38. 38. What happens when we click 'Next'? Do we get “more than finished”? Check out that text alignment too...What do you think the problem is?
  39. 39. How do we fix this?
  40. 40. How do we fix this?  When reusing any element, make sure that it fits the context of what the user is doing.  Make the appropriate modifications to add functionality or  remove unnecessary items to keep from confusing the user.
  41. 41. Poor Use of Color ®
  42. 42. Explosion at the Skittle’s Factory!
  43. 43. Explosion at the Skittle’s Factory!
  44. 44. There are just so many things wrong with this one…
  45. 45. There are just so many things wrong with this one… 1. I got a sunburn from the color 2. Too many choices for radio buttons 3. Why did I need a dialog box for this?
  46. 46. Ah….Pink and Brown
  47. 47. Ah….Pink and Brown A great color combo (in fashion or home decor)...not in an application
  48. 48. How do we fix this?
  49. 49. How do we fix this? Color choices in an application should generally be subtle. It's absolutely necessary to utilize complementary colors from the same palette. If you're not sure what a color palette is...go learn it right after this session
  50. 50. Looking at things from our point of “View” ®
  51. 51. Twist(ie) and shout…
  52. 52. Twist(ie) and shout… Don't let the Domino server design the UI for you!
  53. 53. How do we fix this?
  54. 54. How do we fix this? CSS it up a bit! Tables can be your friends too
  55. 55. Tabs Gone Wild! ®
  56. 56. Wow!
  57. 57. Wow! At least the designer was nice enough to use color to let us know where we are...
  58. 58. Tabs are Everywhere!
  59. 59. Tabs are Everywhere! They're even escaping outside the dialog box!!!
  60. 60. Notes is not exempt…
  61. 61. Notes is not exempt… If you see the “twidgie”, there's too many tabs!
  62. 62. Even Amazon got it wrong once…
  63. 63. Even Amazon got it wrong once… Listen to Mr. Nielsen: “Multiple rows create jumping UI elements, which destroy spatial memory and thus make it impossible for users to remember which tabs they’ve already visited. Also, of course, multiple rows are a sure symptom of excessive complexity: If you need more tabs than will fit in a single row, you need to simplify your design.”
  64. 64. Chris and Bruce Shake Their Heads…
  65. 65. Chris and Bruce Shake Their Heads…
  66. 66. How do we fix this?
  67. 67. How do we fix this? Tabs are an excellent way to divide content into logical sections, but like everything else, you can have too much of a good thing. Consider limiting tabs to a small set (6-8 is ideal)
  68. 68. If I Can't Do It...Don't Show It ®
  69. 69. For example...
  70. 70. For example...  Edit button when I don't have rights  Next/Previous links when I'm at the beginning or end of a list
  71. 71. How do we fix this?
  72. 72. How do we fix this?  Either hide the function from the user completely or create a “disabled” state, where the function (button, link, etc.) is still physically in the same place but doesn't do anything.  Based on the context, consider if you should give the user some clues about this (via an error message or text label).
  73. 73. The Screen and Paper Are Not The Same ®
  74. 74. Complex form designs don't print well
  75. 75. Complex form designs don't print well What looks great on your monitor...
  76. 76. May not translate to paper….
  77. 77. May not translate to paper….
  78. 78. How do we fix this?
  79. 79. How do we fix this? Unless you have a simple design that maps nicely for printing, create a separate “printer-friendly” version of pages and forms Remove unnecessary elements: • Action bars • Navigation • Radio buttons and check boxes • Any other UI element that is not meant for print consumption
  80. 80. The Shifty Eyed Avatar
  81. 81. The Shifty Eyed Avatar How YOU doin'? 'nuff said...
  82. 82. The Shifty Eyed Avatar
  83. 83. Composite Applications/Mashups ®
  84. 84. There are just no words for this one…
  85. 85. There are just no words for this one…
  86. 86. How do we fix this?
  87. 87. How do we fix this?  Take great care when integrating disparate programs in a composite application. If the UIs are not complementary, you risk disorienting the user and making their work harder than using the apps separately.  Creating a good UI in a composite app environment will be a challenge and we're just really starting to explore this area. Keep an eye on the Notes community blogs to see what people are doing.
  88. 88. The Notes Skeleton ®
  89. 89. How many Notes apps look like this…
  90. 90. How many Notes apps look like this… When we see such applications, are we really surprised when people say they don't like Lotus Notes?
  91. 91. How do we fix this?
  92. 92. How do we fix this?  User facing apps should be polished...No Exceptions!  Don't expose the plumbing to the users...they expect more.
  93. 93. Importing Data ®
  94. 94. How do we fix this?
  95. 95. How do we fix this? You're the developer...eliminate the barriers by writing the code to perform these steps.
  96. 96. It Doesn't All Have To Look Like Mail ®
  97. 97. From this…
  98. 98. From this…
  99. 99. To this…
  100. 100. To this…
  101. 101. To this…
  102. 102. To this…
  103. 103. From this…
  104. 104. From this…
  105. 105. To this…
  106. 106. To this…
  107. 107. How do we fix this?
  108. 108. How do we fix this?  Get out of the mindset that all Lotus Notes applications should look the same and utilize a 2 or 3-pane UI  The application user interface should be designed to facilitate the work that the user does.  Start your design by focusing on the interface first and let the UI be driven by user needs
  109. 109. “Magic” Functionality ®
  110. 110. What Happened Next
  111. 111. What Happened Next  I called customer service (expensive for me in terms of time...expensive for them in terms of support costs)  Told that the field expected 7 characters (put a zero in front)!  Told to replace the first alpha character with a zero!
  112. 112. How do we fix this?
  113. 113. How do we fix this?  Avoid the need to use voodoo rituals in the first place by coding your application appropriately.  If you can't avoid the situation, provide clear, detailed, simple instructions on what is required  Your user's time is their most precious asset. Don't abuse it!
  114. 114. Admin Driven Application Choices ®
  115. 115. How do we fix this?
  116. 116. How do we fix this? Get rid of the Admins!? Administrators DO NOT have the final say in application functionality! Repeat this mantra: BUSINESS drives APPS, APPS drive Infrastructure If you are doing it any other way, it's time to make a change...
  117. 117. How do we fix this? Get rid of the Admins!? Administrators DO NOT have the final say in application functionality! Repeat this mantra: BUSINESS drives APPS, APPS drive Infrastructure If you are doing it any other way, it's time to make a change...
  118. 118. Layout and backgrounds ®
  119. 119. A very common mistake...
  120. 120. A very common mistake... Wasting precious screen real estate with graphics that don't add to the functionality of the application And watch out for those background too!
  121. 121. How do we fix this?
  122. 122. How do we fix this?  Make sure features have a definite purpose for being on the screen.  A little decoration is often a good thing to add but not when it hinders usability.  Also be aware of readability. Your app should be easy on the eyes, especially for older users.  Tip: Learn about the proper use of whitespace
  123. 123. Make a good first impression ®
  124. 124. Please don't let this be your introduction to the world
  125. 125. How do we fix this?
  126. 126. How do we fix this? If you use an About document and want it to appear when users are new, invest the time to make it as attractive and useful as the rest of your application.
  127. 127. Don't be afraid to spice it up...
  128. 128. Don't be afraid to spice it up...
  129. 129. Don't assume... We won’t even say it ®
  130. 130. Don't assume that functionality is clear to your users unless it's “knock you over the head obvious”
  131. 131. Don't assume that functionality is clear to your users unless it's “knock you over the head obvious”
  132. 132. How do we fix this?
  133. 133. How do we fix this?  If you use features that do not offer any affordances (obvious clues that let you know what something does), you need to provide users with clear and direct instructions.  If possible, don't include ambiguous functionality at all. Make features simple and easy to use.  Here's a good litmus test... “Is this easy enough that my grandma could do it?”
  134. 134. Let's wrap things up... ®
  135. 135. What Can You Take Away?
  136. 136. What Can You Take Away?  All of the things we talked about today were UI constructs that violated some established practices around the user experience.  These practices are the fundamental principles of UI design
  137. 137. Keep the fundamentals in mind
  138. 138. Keep the fundamentals in mind In their book “Software for Use”, Larry Constantine and Lucy Lockwood introduce the six fundamental principles of UI design: 1. The structure principle 2. The simplicity principle 3. The visibility principle 4. The feedback principle 5. The tolerance principle 6. The reuse principle
  139. 139. The Structure Principle  The user interface design and layout should have a logical structure  Organize related information and keep unrelated information separated  This principle deals with the overall architecture... Is it clear, concise and cohesive?
  140. 140. The Simplicity Principle  The UI should be simple and easy to use. Your users should be able to figure out common tasks without help  Focus on simple language...avoid tech talk  Long procedures should be broken into shorter tasks and have good shortcuts Simplicity
  141. 141. The Visibility Principle  Keep your UI uncluttered and show the user what they need when they need it...no more!  Don't overwhelm the user with unneeded features or too many choices
  142. 142. The Feedback Principle  Let your users know what is going on...keep them informed of changes in state, relevant errors, etc.
  143. 143. The Tolerance Principle  Your application should be forgiving of user errors and flexible enough to mitigate problems (allowing undo, rollback, etc.).  Your application should prevent errors as much as possible in the first place by being tolerant of user input This is the polar opposite of tolerance!
  144. 144. The Reuse Principle  Your application should reuse components and behaviors when possible and be consistent with user expectations, reducing the need for users to relearn or remember.
  145. 145. Questions and Answers ®

×