"Designing the Obvious" at WordCamp
Upcoming SlideShare
Loading in...5
×
 

"Designing the Obvious" at WordCamp

on

  • 6,701 views

This is the presentation I had originally planned to give at WordCamp. Several people have asked for it, so I posted it here.

This is the presentation I had originally planned to give at WordCamp. Several people have asked for it, so I posted it here.

Statistics

Views

Total Views
6,701
Views on SlideShare
6,074
Embed Views
627

Actions

Likes
6
Downloads
79
Comments
0

8 Embeds 627

http://wordpress.tv 606
http://www.damage.n.nu 9
http://www.slideshare.net 4
url_unknown 3
http://translate.googleusercontent.com 2
http://wordcamp.info 1
http://74.125.93.132 1
http://207.46.192.232 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    "Designing the Obvious" at WordCamp "Designing the Obvious" at WordCamp Presentation Transcript

    • I’m RHJR, and I’m a WP blogger. Designing the Obvious, however, is a book about web application design principles. And I didn’t talk about blogs in it at all. But you guys are all here to talk about blogs, so I’ve adapted things a bit, just for you WordPress geeks. Today, I’ll follow each topic with an example of how to apply the concept to a blog. We’ll talk about: 1) Building only what’s absolutely necessary (and how to do it) 2) Getting users up to speed quickly so they can start liking your app 3) Surface the important elements on a page 4) Handle errors
    • build only what’s absolutely necessary. First, let’s talk about building only what’s absolutely necessary.
    • Early on, we need figure out what really needs to be built. Seems obvious, right? Well, it is, unless you want to build something really good. It’s easy to build everything that comes to mind. It’s easier to do that than it is to cut things out and build only what’s absolutely necessary. But that’s what needs to be done, because a more focused app is easier to learn and use, and easier apps lead to repeat business. So take your wireframes (like this one) and strip things out of it until the essence of the app shines through. What’s the core purpose of the app? What’s it do? Focus on this. Let’s see how to do that by stripping some things out of this “fictitious” webmail app. In the book, this is called “Interface Surgery” and there are several examples.
    • Strip out the ability to search the web. - All browsers have this. It’s redundant to include it.
    • Strip out the Saved Search feature. - Takes longer to save and re-run the search than it does to just type it in - This means we can get rid of the two tabs as well. Cleaner design.
    • Move the Storage Used info to another screen. It doesn’t need to be in the main UI 100% of the time. This is a webmail app, right? So send an email when the inbox starts to get full. OK, see the INBOX label? It’s big and bold to tell you which mailbox you’re looking at ...
    • So get rid of the TITLE BAR for the FOLDER box. You already know from the sidebar what folder you’re looking at. Get rid of Apply Action dropdown. Move these actions somewhere else. (We’ll talk about those in a moment). Clean up the mess. Again, a simpler design.
    • Surface the command links (reply, forward, etc.) Apply some logic to the links so they’re disabled when they can’t be used. (Heck, you’re building fewer features now, so spend some more quality time on what’s left and make it great.) Clean up the mess again.
    • Reminder: This was the original.
    • This is the new version. Much cleaner. Much more focused. Not a huge dierence to us, but MASSIVE to a typical user. Let’s talk about how this applies to a blog. Usually, blogs contain several elements: a post, a link to another post (or two), a link to the archives ... things like that.
    • [example of this applied to a blog] This is Sam Stephenson’s blog (and no, I have no idea who Sam Stephenson is). He stripped out almost everything. He left out the blogroll, the category links, the list of recent posts ... heck, he left out the post footer! There’s no way to digg this, StumbleUpon this, trackback it, comment on it, or anything. Each page contains exactly one post. I love this design. Sadly, Sam has only ever written two posts. Bloggers are a creative bunch, and I certainly am not saying everyone should do this. This is sort of extreme. What I’m saying is to figure out what’s actually important to YOUR blog, and kill everything else. If you don’t need links to previous and next posts, get rid of them. If a blogroll doesn’t really help you, ditch it. If you and your readers won’t benefit from a list of links to categories, don’t include one.
    • Sometimes a blog doesn’t even need standard blog elements. A “tumblelog” is a form of a blog that has no titles, no footers, no categories, no trackbacks, no search, no archives ... nothing. It’s just a long series of very stream-of-consciousness posts that are either quotes, links, images, videos, or ideas. Of course, the trick is to avoid removing too much. Your page still needs a page title to provide some sort of context. Tumbelogs often lack the most basic and standard elements of a web page. So be careful if you do this.
    • turn beginner’s into intermediates, immediately. Now that you’ve stripped down the app so only the important stu is in it, it’s time to focus on turning beginners into intermediates.
    • Alan Cooper - “perpetual Intermediates” Most users are not beginners. People learn as much as they need to learn very quickly, thereby becoming intermediates. They rarely advance to expert level. Design for the intermediates, but MAKE SURE PEOPLE CAN BECOME INTERMEDIATES IN THE FIRST PLACE. How? Instructive design. Almost EVERYONE fails in the area of instructive design. They never tell users how to use the app, and they never figure it out on their own. If you hired me tomorrow to fix your app’s design, this is the first thing I’d look at. That said, I did find a few examples of good instructive design work. Some of them are discussed in the book.
    • Surface the Help info. Inline tips from Squidoo (from Seth Godin) - Show up on rollover - Short, concise tips
    • Take care of the “blank slates” Basecamp screencasts Fill up the blank slates with useful information - Big red link - Screencast
    • No milestones exist. This is what it looks like with no instructive elements. Not very helpful, eh?
    • My Yahoo!’s blank slate is filled with a preview of what your page could look like. No, Michael Jackson isn’t on it all the time.
    • Welcome screens: - Call out what can be done on the page - Show it to new users - Set it to disappear automatically after the 5th login or something - As people get more familiar with the app, you don’t want them to keep bumping into newbie stu. BONUS: - You can use this again when you have a new feature to announce, so it’s dual-purpose.
    • [example of this applied to a blog] This is a rather well-known blog that breaks the same rule that most other blogs break. It doesn’t make it obvious that headings are links. Almost all of the links on this page black and underlined. But the links to the permanent post page are green and have no underline. Oh, and the link directly to post comments is ... um, purple. You know, so it doesn’t match anything else on the page. Four dierent link styles on the same page. So how does someone new to this page get to become an intermediate user of this blog? Yup. He has to guess.
    • [example of this applied to a blog] And in the tooting my own horn category, this is my blog. Notice that every link on the page is orange. The only exception is the notification area at the top, but I underlined that one to make it clear that it’s a link, so it’s OK. ;)
    • surface important elements. To further help users understand how to use your app, and so they continue enjoying your app ... surface the important elements on each screen.
    • Seth Godin’s banana principle: - Put up clear signposts on a site and people will follow them, just like a monkey follows a trail of bananas.
    • What’s this page about? - There is a point to it, but who can tell what it is?
    • Add some links. Color makes things stand out. But not enough. We want to turn these 3 links into giant, clear bananas.
    • Surface the main points of this page - the three hot spots.
    • Get rid of the instructions at the end of the text, and you’re done! Much clearer. Now the monkeys can follow the bananas.
    • [example of this applied to a blog] What’s the major call-to-action on this page? What is it that the folks at WordPress want me to do when I land on this page for the first time? Hint: Download WordPress! Where’s the link? In the header, of course! (Kidding.) What pops out the most on this page? The word “Welcome” and the screenshot on the right. Neither of these things are clickable. And the word “Welcome” doesn’t mean anything to a user. It doesn’t help them, doesn’t get them started, doesn’t provide context, doesn’t do, well, anything.
    • [example of this applied to a blog] Any idea what’s on Apple’s mind today? There are over 30 links on the Apple.com homepage. Which one do you think they want you to click? OK, so these aren’t blogs, but you get the idea. If you write a blog post promoting something on another area of your site, for example, include a link, and make it big and obvious.
    • prevent errors with poka-yoke. (POH-kah YOH-keh) Once they start using the app, make sure they can use it without feeling like idiots by making mistakes all the time. This one of the best ways to improve your app. If people never make mistakes in your app, they’re going to feel really smart. That’s a good thing, and it’s something most companies never achieve. From Lean manufacturing processes, this is Japanese for “error-proofing” The best way to handle an error is to prevent it from happening in the first place. Two types: Prevention and detection Some examples ...
    • Popcorn button = prevention device.
    • “Did you mean?” Great idea. Helps users fix their typos and helps them correct words they don’t know how to spell. This is a detection device.
    • Google Suggest Blurs the line between prevention and detection by helping you choose a good search term. - Doesn’t work well for people who stare at their keyboards while typing, though. - Also, people tend to rely on the suggestions rather than their own search terms, which may have been better. - If using this, use it for lookup actions (like looking up someone’s phone number), not for searches
    • Undo systems = fantastic. - Get rid of JS alerts/confirmations (because they suck and no one reads them) - Clear visual notification that you can Undo This should be in every web app where you can delete or seriously aect data. (Right now, it’s not even in every Google app, so we’ve got a ways to go.) This introduces “forgiveness” into your app. People can play around without being terrified of breaking things.
    • Anyone signed up for ODEO? This shot doesn’t do it justice, but these fields are HUGE. And it doesn’t really help anything. They didn’t do anything to make the form more usable, they just filled up the page. Imagine this at 800x600 (for people with bad vision). Four fields, and two of them would be below the fold.
    • RememberTheMilk Inline validation = prevention AND detection. - Detects errors immediately and notifies you - Prevents users from hitting Submit before the form is correct. - Should still be able to hit Submit (accessibility reasons, disabled JS), but this alleviates most of the issues people have with forms. And they really appreciate it. This one is good, but not quite perfect. Tells you there’s an error as soon as you hit the field, before you have a chance to enter anything.
    • OurProperty.co.uk Much better. Also includes inline tips. Let’s take a closer look at the decisions for your form design.
    • Typical form. Thinking back over what we’ve talked about so far, what can we do to make it better? (Take suggestions.)
    • - Add instructive text - Display checkmarks when fields are correct. - Show errors inline. - Show them next to the field. - Show them AFTER the field loses focus - Disable the I’m Done button You can make these really big - it helps. Here’s an example:
    • Eventful.com - large errors = easy to see MOST users can complete this form correctly before hitting SUBMIT - Good for users - Can translate to less bandwidth for you, because you’ll only get ONE server call
    • Completed form = I’m Done button lights up and you’re good to go. Sadly, I couldn’t find an example of good error-handling on a blog. Typically, the only place this would apply is when a user is adding a comment to a post, and when I went through all the blogs I read normally, I didn’t find any that used inline error messaging like this. Obviously, the moral of the story is that you should do add this to your blog. And since WP is open source, you can hack around it and make that work. And since I’ll be spending Monday with the dev team, I may just try to talk them into building this functionality into WordPress. :)
    • Questions?
    • Check out the blog at www.rhjr.net for continuous reality checks on application design. I’ll be around, so feel free to come talk to me about your apps and ask questions and such. Enjoy the rest of WordCamp!