Iterate Me: Brian Klaas: Blog - UI

On App Inventor: Speaking the Language of Novices

Mon, 12 Jul 2010 09:08:00-0400

Google's App Inventor is a great idea. Empowering consumers to create is always a good thing. Visual Basic was the key to Microsoft's long-time success. Map making tools are the reason why Warcraft III and Starcraft still sell on retail shelves, more than a decade after their release. iMovie, Windows Movie Maker and its counterparts have helped make YouTube the site for almost every Web meme of the last five years. Visually-oriented IDEs are a great way to develop software quickly. Visual Basic and Delphi are two classic examples of this, and their tradition of partial WYSIWYG views carries on to Visual Studio and Flex Builder today. (I've also made the argument that if Adobe wants CFBuilder extensions to really take off, they need a visual UI to create them.) They've even evolved to have a similar visual language: panels spread out on the screen which allow for inter-panel communication and interaction, playing off visual and interaction patterns common to many IDEs. When you fire up Eclipse or Visual Studio, you, as a programmer, can say "Oh, I know the basics of how this IDE works because it looks like other IDEs I've worked with." All of those tools, however, expect that the user has some kind of fundamental understanding of the basics of programming: simple data structures, simple logic controllers, and so on. You simply can't get by without them. Now let me say that I've had minimal direct experience with Google's App Inventor. I don't think that's a problem here because I want to talk about first impressions, as those mean a lot to the average, non-technical user at whom Google is targeting the product. Take a look at this screenshot from the product's home page: The focus of the UI is on the simulated phone screen in the middle of the window, as it should be. Take a look at the list of controls under "Palette," on the left. There you'll see titles for controls such as "Canvas," "ListPicker," and "TinyDB." Although there is a question mark next to each which, when clicked, tells the user what the control is, that text (and other text on the screen) is very much the language of the programmer and not the user. A non-technical, non-programmer, average, everyday Android phone user (who is the target user of App Inventor) would probably look at that and say "What the heck is a ListPicker?" I've worked with a lot of "non-technical, non-programmer users," and know pretty well that when any "programmer-ese" comes in to play in the UI, users tend to be taken aback and almost immediately take a combative approach to this UI written in a language other than their own. This programmer-centric language works its way in to other elements in very subtle ways. Look at the properties you can manipulate in the "Components" and "Properties" panels. The text which describes the properties you can manipulate, while clear, is written in camel case — a programmer's, not average user's, convention. "CheckBox1" could just as easily have been displayed as "Check Box 1." The same goes for "BackgroundColor" and "BackgroundImage." I know this sounds trivial, but it's clearly the work of programmers who expect that users will get or, at least, grow accustomed to the way software is written by programmers, not "average end users." I also have to wonder if the basic assumption of the standard IDE UI as the default UI is an appropriate one. In my experience, users are task-focused. They want to be able to make a movie from video on their camera and upload it to YouTube. They want to write a letter to their congressman about an issue that is important to them. They want to set up a quiz for the students in their class to take. As users are task-focused (and not document focused), an application should start with smart defaults and help a user accomplish basic tasks quickly. Instead of showing the standard IDE UI at startup, App Inventor may be better served with a "Start Screen" which could ask:

What kind of application would you like to build?

One that uses data from my Twitter account.

One that uses maps to display places that are important to me.

One that lets me chat with my friends.

None of the above.

The options presented here, when selected, would then pull together some of the basics for the application, saving the "average user" quite a bit of time and lay out most of hte plumbing required to get their desired application off the ground. This "Start Screen" could be turned off in the application's preferences for user who don't want to be bothered with this kind of getting started page. The blocks tool that the team has devised to map out the internal logic of the application is really smart. It makes visualizing the logic clear and it's easy to drag and drop components in to the right order. No-code development environments like this are key to getting "average users" to use the tool to create applications that do what they want. I've used "average users" in quotation marks throughout this entry. That's because I don't think the real audience is "average users" — meaning someone who owns a smartphone but hasn't developed software before. The tool was developed by university-level faculty and targeted towards students at various levels (elementary, middle, high and university) but in the context of teaching software development. As such, I believe the tool makes the fundamental assumption that you have to have some knowledge of the art of programming. That assumption informs the design of the UI and how users interact with it. It makes it vastly simpler for individuals to develop applications (even me!), but it's not a tool that can be used by just anyone with experience with smartphones. App Inventor was created by a lot of people much smarter than I. It's also still in beta and something I know that the team will improve upon over time. I just have to point out that if they really want to create something which allows the average user of a cell phone to build their own applications, they need to create a UI that, from start to end, reads in the way that an average, non-programmer user would understand.

Making Your Web Apps More Human

Tue, 28 Apr 2009 09:08:00-0400

I was reading a post on Luke Wroblewski's blog recapping a presentation on "Designing Humanity in to Your Products" at the Web App Summit 2009 and it got me thinking about the tensions I often find in creating the text for the Web applications I build. We have an interdisciplinary team responsible for all the educational and training content developed at my place of work. They're very smart, talented people who know a lot about their specific area of expertise. Over time, we've settled on a writing style that's, well, a bit formal. We're an academic institution, after all, and the Chicago Manual of Style is pretty clear on how words should be crafted for the page. The problem with sticking to a standard like Chicago is twofold:

We're on the Web, not the page. The Web really is different from the printed page.
Web 2.0 experiences are fast becoming (if not already) the standard. Users expect to be referred to in the first or second person. Users expect to take center stage in all the activities available in a Web app. They expect the casual, conversational style of Facebook to be how all Web apps should work.

I'm not trying to single out the technical writers and editors that we have on our team. They're great and really know what they're doing. I'm also not abdicating the basic rules of academic writing to Facebook or IM style. (I teach an online course at a graduate institution, after all, and I see how lazy students can be when it comes to writing.) What I am trying to point out is that often when we generate the text for our Web applications, we're bound by a sense of obligation to "proper style" or "business tone" that's so formal it only reinforces the stereotype that computers (and by extension, the Web applications that run on computers) are so devoid of anything resembling personality or idiosyncratic style that we can't, fundamentally, connect with them. Part of the success of Facebook or Twitter or any number of Web 2.0 sites is the way in which they approach the user: a friendly, conversational tone with human-readable (and understandable) messages. As pointed out in the blog post, we need to take a conversational rather than formal tone, especially when it comes to error messages or other "system guidance" to users. This may result in a site with a less authoritative (as in totalitarian) voice, but the benefit is that users feel assisted, not punished, when they need to ask a question or something goes wrong. As I've been implementing newer apps, and those using my Contextual Guidance API, I've made a conscious effort to keep the tone less formal and more conversational. This has resulted in a few discussions about what's appropriate (contractions seem to be a sticking point), but I think the upshot are apps that are more approachable and, by extension, more human. People have such limited time to get anything that they don't see as non-essential done, it's important to make them feel that they're dealing with an app made by humans, for humans.

30 Essential Controls for Web Interfaces

Wed, 04 Feb 2009 09:31:00-0400

I realize that I've been posting a lot on user interface design for Web applications, but it seems that there are more and more excellent resources becoming freely available on this front every day. What's even better is that many of these resources provide simple, clear examples for best practices. Thanks to the good folks at Ajaxian, I came across 30 Essential Controls, a page which lists frequently used Web UI controls (ie; multi-select box, rich text editor, autosuggest, etc.) and which RIA frameworks use them. So if you're prototyping a particular UI and want to know if the framework you're considering (because you are using frameworks and not trying to reinvent the wheel, right?) supports that type of control. There are handy links to many specific control implementations inline, so it's pretty easy to find some of these controls while others you'll have to go searching for. The parent site for this page, which is for the book "Designing Web Interfaces: Principles and Patterns for Rich Interactions" has quite a few good resources itself, including a blog from the authors. If you haven't seen Bill Scott's presentation on Designing Web Interfaces on Slideshare, it's definitely worth checking out and making it through the 300+ slides. He just did a webcast on O'Reilly and should be posting the audio from the session soon. Take a look at the "Explore the Book" page as well, as it summarizes most of the content of the book into an easily usable page. It looks like I'll be picking up their book shortly.

10 Useful Web Application Interface Techniques

Tue, 13 Jan 2009 09:10:00-0400

I'm rarely disappointed when the smart folks who put together Smashing Magazine come out with a new article on Web application design and information architecture. Their style is straightforward and remarkably jargon-free, especially when compared to other UI design-focused sites. 10 Useful Web Application Interface Techniques is their latest posting on the subject (see that article for even more, related articles on effective UI design techniques). While I do get a lot out of reading these articles, and the tips and strategies are usually dead-on (and make good common sense), one of the things I love about what they do is that they provide visual examples for nearly every tip and technique. It's a great way to quickly survey what other sites are doing, and how they're working to innovate in UI design.

Neuro Web Design

Fri, 09 Jan 2009 10:10:00-0400

A less buzzwordy title for this book would be "The Neurosociology of Effective eCommerce Design," but I suppose that's not as pithy as "Neuro Web Design." This brief, clearly written and surprisingly obvious book by Susan M. Weinschenk examines the neuroscience behind effective Web marketing and design, focusing in particular on eCommerce. Quite a bit of the book covers how the "old, mid and new" parts of the brain affect our decisions to buy and act in the ways that we do. (I'd argue that you could interchange those three terms with "id, ego and superego," but there are physical parts of the brain which map to these concepts.) Weinschenk focuses quite a bit on socialization and how we need to be a part of a group, especially when we make decisions about buying. She focuses on the effectiveness of public reviews, reciprocity, immediacy, and threat in designing your Web commerce and marketing strategy. It was interesting to read that psychologists are now demonstrating, though data, the effectiveness of "chunking" content — a practice that my work has put to use for over a decade now in long-form online educational content. Learners provided much anecdotal data about preferring chunked content, but Weinschenk points to studies that back this up with numbers. A lot of what she says makes great common sense and is, honestly, pretty obvious when you think about it. She presents things in a very easy-to-read and understand style. I did find, though, that the overall book is a bit thin as the core concepts are repeated in a number of different ways over 132 pages (padded with elegant spacing, pictures, and reminder boxes throughout). It also ends rather abruptly, providing very little wrap-up, but this isn't fiction.

Web App Design Anti-Patterns

Thu, 04 Dec 2008 22:37:00-0400

Slideshare is a great learning resource. There are presentations from top-level presenters in a number of fields (particularly Web design and development) posted there, although you sometimes have to wade through the litany of "Hot Brazillian Girls" slideshows that never quite seem to go away. You can subscribe to their very convenient RSS feed of latest presentations submitted to the site, or the most viewed presentations within a given day or week or month, and so on. I usually review one or two presentations a day on the site. Bill Scott, the Director of UI Engineering for Netflix, posted a great and detailed presentation on "Designing Web Interfaces: Principles and Patterns for Rich Interaction." What's really useful about this presentation is not just the depth of examples but also his pointing out anti-patterns in Web application interface design. Anti-patterns aren't well discussed in this area, and I think he makes some great points about common approaches to interaction which may be less helpful than we expect them to be. The presentation is below, but you should definitely head on over to Slideshare if you haven't already, as there's a wealth of useful presentations there.

Designing Web Interfaces

View SlideShare presentation or Upload your own. (tags: ajax rich)

Protoshare: Sweet Collaborative Wireframing

Thu, 09 Oct 2008 08:44:00-0400

Protoshare is a full Web application that enables Web application teams to collaborate with clients and customers on prototyping Web sites. I'm a big proponent of prototype-based development, but one of the drawbacks to this methodology is that there aren't a number of really good tools to facilitate the process. Those that do exist are desktop-only and somewhat expensive. Protoshare enables you and your team and your clients to build out protoypes completely online in a surprisingly rich, drag-and-drop environment with smartly integrated commenting and discussion. Where Protoshare really shines is in the wireframing layout process. They've done some very impressive work with JavaScript on the browser, and the very rich UI is fluid and responsive. Even more impressive, you can make your wireframes fairly interactive, utilizing RSS for dynamic data display, or menu drop-downs or flyouts that really let you and your clients see the workflow, rather than just talk about it. You can certainly build HTML prototypes that do the same thing (and we do!), but Protoshare helps to automate that process. I've been looking at it as a way to enable our team and our clients to work remotely and still collaborate effectively, and I think it meets that requirement. However, as most of my team and our clients are all within a short walk of each other, I'm not sure that the fees (which are not steep) and the lock in to the product are worth the investment. We can also generate richer prototypes on our own, but certainly not as fast. If our designer/developer team and clients were more geographically dispersed, Protoshare might be a great tool for us to use. I think the product is really excellent for smaller design shops or independent designers who want to collaborate with their clients without driving around (or flying to) a lot of meetings. I don't know if you'd use Protoshare to protoype a fairly large corporate intranet, but I think that aside from not being able to handle the full scope of AJAX-based interactivity (though you can address that by building Flash movies and inserting those in to the Protoshare wireframe), it's a very capable tool. (Though I would like to see real-time audio communication built in to the tool. It's very, very useful to talk through the workflow with collaborators, rather than just post comments asynchronously.) Interestingly, Protoshare requires that you use Firefox 3. While IE is almost fully supported, Firefox is what you need to be using to fully engage with the application. It's unusual for almost any Web-based application to require Firefox over IE, but that's what they've done. I'm not sure that this isn't a problem, as home business or corporate clients may not want or be able to install Firefox just to collaborate with you. They may just ask that you meet with them in person instead.

Designing the Obvious Moment

Fri, 12 Sep 2008 09:37:00-0400

Robert Hoekman Jr. has written two quite excellent books on user interface and interaction design. I read these books earlier this year, but thought I'd finally get to blogging about them as part of my ongoing book reviews. Designing the Obvious was the first of the two books and, for me, the more successful of the two. It's rich with UI design aphorisms that simply make good common sense. Written in a simple, conversational style that draws heavily from actual Web application development experience, this book, and its counterpart just make sense. The book deserves to be read by anyone who actually builds any kind of Web application user interface, no matter how simple or complex. One of the things I really liked about his approach was the whole concept of turning beginning users into intermediate users quickly. That was the inspiration for my whole series of posts on the Contextual Guidance API. His outright demand that you make it simple, eliminate anything unnecessary in the app and in the design, and focusing on how you accomplish a task at every moment within the application is great advice. My team has taken that advice to heart and has begun designing our new applications around much of Hoekman's advice in this book. The result has been applications that visually make more sense to our clients, and clients that are really happy with what we're developing. Designing the Moment is focused on very common, very specific moments of interaction with a Web application and how they can be made better. It's less cohesive as the previous book, which took more of a big-picture view to the art and process of designing user interfaces. In this book, the examples are very specific, somewhat less generalizable, but many of the same principles from Designing the Obvious come in to play. My sincere feeling is that a number of the solutions presented in this book will become outdated over the next couple of years (ie; blog and social networking site design) but, again, the basic principles of clarity, task-orientation and removing all but the essential are more than sound. Designing the Obvious should be mandatory reading for all Web application developers, even those who rarely work on the UI. At the end of the day, the interface is the application, no matter what application you're using. Knowing how to create great interfaces is key to building great applications.

Getting Back to the Original Pointing Device

Mon, 18 Aug 2008 09:11:00-0400

Smashing Magazine is a great site that frequently provides inspiration and illumination about all things design (and technology design in particular). I stumbled across the site a couple years ago and I'm always impressed with the quality of inspiration they provide. They recently put together "10 Futuristic User Interfaces," a look at where user interfaces might go in the not-too-distant future. Interestingly, a lot of the interfaces point (no pun intended) to heavy use of the original pointing device: the finger. Of particular note are the interfaces for Futuristic Glass, Motorola Sparrow, Composition of the table, and Ringo. All of these interfaces rely primarily on hand-based motor skills to grab and manipulate information in a meaningful way. Pointing as the primary means of communication isn't exactly new, or futuristic. We can see lots of implementations of "touch" devices in use today. Microsoft has Surface and its various, manufactured-real-soon now incarnations. There's the Wii. There's a number of new multi-touch computers, including the well-advertised one from HP. And there's the iPhone. A combination of devices are making touch-based interaction (computing) a reality. My question, though, is this: will people forgo a century or more of developed typing skills for a touch-based interface. Touch-based interfaces are largely serial input devices. You can't type more than one letter at a time on the iPhone. Multiple touches signifies a single, special action in multi-touch interfaces. I suppose you could make the argument, however, that keyboards work the same way: a machine only accepts one key as input at at time. However, keyboards are fast. You can use all 10 pointing devices on your hands at an incredibly rapid rate to generate input. Touch devices expect that you'll be using a single input . Given the range of motion required for or the limited space available in touch interfaces, it's nearly impossible, at this point, to provide input at the same rate as a keyboard. A common complaint that Blackberry device users have about the iPhone is that it's much slower to create responses/entries on the iPhone than it is on the Blackberry because of the keyboard and because you're able to provide input at a much faster rate. This is a problem that time and ingenuity will probably solve. However, the miniaturization of technology prevents a major barrier to rapid input via touch. The average finger size of our species isn't going to get smaller any time soon. Another major obstacle to input interfaces like Ringo (which is pretty dang cool) is the need for small, inexpensive and completely proliferated holographic projectors. That day is probably coming too, with the march toward technology miniaturization. So touch input, glass-as-the-computer, and the proliferation of holographic projectors. Maybe Minority Report had it right all along.

Getting Users Up to Speed, But Not Getting in Their Way

Fri, 09 May 2008 09:31:00-0400

I've mentioned Robert Hoekman, Jr.'s excellent book "Designing the Obvious" a number of times in previous posts. Hoekman devotes an entire chapter ("Turn Beginners Into Intermediates, Immediately") to the subject of getting users up to speed with applications as quickly and unobtrusively as possible. He argues that most of the users who stick around long enogh to use your application don't ever get beyond being "intermediate"-level users, and that:

We need to implement some tools that stick around long enough to help users learn what they need to know, but then disappear once their purpose has been served.

So how do we do this? How do we know someone is a real beginner, an intermediate user, or an expert user (for those rare people who really want to take the time to learn all the nooks and crannies of the application)? How do we then track they they are gaining experience with the application so we no longer treat them as beginners but as intermediate users (or advanced users, as appropriate)?

I'm working on a simple API to help provide the appropriate level of contextual guidance to users of an application. The focus here is really on the backend tracking and determination of a user's experience level with an application. The contextual guidance API would be called before a page-view is rendered and the view itself would determine what to display based on the "experience level" of the user that has been passed along to it. With this system, we can hopefully begin to provide users instructive text (aka help) in a way that's useful and appropriate to their experience with the application, and that adapts over time to get out of their way or change to show them new tools at their disposal.

The core function would look something like this:


function getExperienceLevel(userID, applicationName [, applicationSection]):string {}

The arguments would be:

userID (numeric): The PKEY userID of the user.
applicationName (string): The string name of the application, so that multiple applications could be tracked within the same table, if appropriate. This could also be an applicationID value, if you have an applications table to work with which defined each application and gave it an ID.
Optional: applicationSection (string): The string value of the section of the application in which the user is working. This is useful in larger applications, where a user may spend most of their time in sections A and B but not in C. The user would need more help in section C of the application, and less in A and B. You need a way to be able to discern this, and this is the proposed way.

The function would return a string containing one of three values:

beginner
intermediate
expert

You could return a numeric value that somehow translated in to a range (eg; 1-10 = super noob, 10-20 = inexperienced, 20-30 = lower intermediate, and so on), but that level of granularity is probably more trouble than its worth — especially in the view where you'd have to write a whole lot of conditional logic to handle the appropriate display for each of those value ranges.

So those are the basics of the method. In the next post on this topic, I'll talk about internal logic and the fact that we can't reduce experience to simple numbers. We have to take in to account the fallibility of memory in our business logic.

If you have any questions or comments, I'd love to hear them!

If You Need to Explain, You've Got a Design Problem

Thu, 01 May 2008 09:49:00-0400

The title of this post is a wee bit binary, but it's a topic worth discussing. I was just reading a post by Rob Adams, who is working on Adobe's Thermo project, about the value he finds in paper prototypes, and some of the problems.

I'm in the middle of developing a new application with my super-great team, and we're moving from paper prototypes to a clickable, HTML prototype. There's a lot of discussion with the client during this time, and they've now seen four versions of the application on paper. At one point in his post, Adams makes the following salient point:

Correct any mistaken assumptions that are an artifact of the low-fidelity paper, but make sure you record points where you have to help them or explain something - these are design problems you need to fix.

It's very, very easy when settling in to a routine of back-and-forth and discussion with a client to easily explain away a question they have about the interface (and therefore the workflow) without realizing that this, in all likelihood, is a design problem that needs to be solved. If they're asking you "How will this work?" or "What is this for?" or "Will it do [x]?" when that task is represented on the prototype (or is supposed to be represented or implied in the prototype), then you've got a design issue that you need to handle. If they're asking about how data is stored or background workflows not covered by the prototype at hand, then that's not necessarily a design issue that needs to be addressed.

Sometimes you're so focused on just getting through the key aspects of the prototype in the hour that the client allows you to meet with them that it's easy to quickly explain something they don't understand in regards to how the application will work. Have a second set of hands with you to note all the questions (something else that Adams recommends) so that you can go back later and say "They didn't understand this, and it's supposed to be self-evident. Let's take a look at how we can improve the design."

If someone in the prototyping process has a question about how the app is supposed to work, then you can be sure that there will be lots of people who use the app who have the same question. By listening to the workflow or application operation questions being asked and not quickly explaining them away, you'll find the design flaws and be able to fix them before they become a headache in production.

Good Defaults = Good Instructive Design

Thu, 21 Feb 2008 09:38:00-0400

Many user interface and interaction design experts will tell you that you should not ask users to make choices when they don't have to. Unnecessary choices presented to the user are the sign of laziness on the part of the development team and ultimately work to the detriment of a user's experience in your application. As a result, it's also extremely important to choose good default values for any choices you do ask users to make. This applies to not only things like "Create New..." tasks, but also to things like search. Let me give you two examples from my own development projects.

First up is a wiki tool we built for our online course system. Everyone's used wikis, right? Wrong. A Pew report from 2007 indicated that less than 15% of all surveyed users (and their survey size is around 2000 people, from which they extrapolate the activities of most US citizens) had a blog, or created a Web page, or posted to a blog. I know that a blog is not a wiki, but the reality is that blog usage is generally considered higher than wiki usage from a content contribution perspective. (The percentage of US citizens who have used Wikipedia is probably a whole lot higher than 15%).

Anyway, the point is this: most of our users weren't familiar with what a wiki was or what they could do with the tool. We provided a simple editing interface, thorough help documentation, and even Flash-based demonstrations of how to use the tool — all accessible from within the wiki interface. That wasn't enough. Users still didn't know what to do with the page by just looking at it. Here's what it looked like to them:

A big white space isn't the most inviting of interfaces to get users started creating content. Robert Hokeman, Jr., makes a strong case for this in his excellent book "Designing the Obvious:"

For users just getting to know a Web application, a blank slate can be a barrier in the learning process. Instead of knowing what to do first, users can become stalled when faced with the empty canvas.

By providing a sample of content or automatically selecting a "getting started" template, users can see what they might be able to build with the tool, or can start clicking and editing what's provided. They don't have to do a lot of figuring out how the tool might be used — you're doing that for them, saving them time and confusion in the process. (Of course, you're also proscribing how the tool can/should be used to them, which can be a detriment to creativity. Creative users, however, will find a way to bend the tool to their own ends. They always do.)

So we went back to the wiki tool and addressed the number one question users had: "I'm not sure what I can do with this thing." By displaying a default preview of what a wiki page could look like, rather than presenting them with a blank screen (or a screen with a tiny bit of text that says "Insert text here" on it), we give the users ideas on how to get started and what, specifically, the tool is designed to do. The updated default view of a wiki page now looks like this:

That's a heck of a lot clearer.

The second example starts to cross in to the realm of instructive design: that is, providing tips and context and the right kind of default values so that the user knows what they are supposed to do with the application, registration form, etc.

Everyone's had the very annoying experience of filling out a form and entering something like a phone number, only to have the system come back to you once you've clicked the "Submit" button and say "Phone numbers must be in the (xxx) xxx-xxxx format." or something equally annoying. A well-designed form that wants to be instructive and help the user enter information in the expected way from the start would pre-populate that phone number field with (xxx) xxx-xxxx so that you could click on it, and start typing in the right format.

In building a survey tool, we decided that a Likert scale question (or matrix question) would be one of the supported question types. The tricky part with supporting that question is getting users to enter in the appropriate setup information for the question. A Likert scale question can be represented by a series of columns (which are the evaluative scale, such as "Excellent, Good, Fair, Poor") and a series of rows (which are the items to be evaluated, such as "Checkout time, Cashier friendliness" and so on).

This was our original design:

Most users could figure out how we wanted the information required using this form. However, we'd still get users who would put all choices on a single line, or separate them using commas or tabs. How to make it clearer? Here's a recent revision:

This is better, as it tells the user exactly what to enter and where to enter it. The design is being instructive. We've provided "defaults" which tell the user what they need to know, and save them from guessing, or confusion about what to put in each of the fields.

We could go farther, however, and create a dynamic preview of the question as the user entered both rows and columns to make up the matrix/Likert question. That's something we're looking into. (There's debate on the value of that, as once a user makes a couple of matrix questions, they pretty much get how to do it and don't need to see a whole lot of other stuff cluttering up the interface.)

So the point here is this: choose good defaults, and make them instructive. The more unobtrusive guidance you can give to your users, the faster they'll get up to speed with your application, and the less (wrong) decisions they'll make in the process.

More on Magic Ink: Or, Has 20 Years of the GUI Ruined Us?

Mon, 11 Feb 2008 11:16:00-0400

As I mentioned in my last post on Bret Victor's excellent paper, Magic Ink, there was so much food for thought for software and UI developers in his article that I took the rare step of making my staff read the article and discuss it in a group setting. One point which arose during that discussion bears further elaboration here.

Victor spends a good bit of time talking about developer/machine representations of a data model versus how real, actual human beings are able to represent data, and, more specifically to my point, choices. In particular, he takes to task the standard "Preferences" (or, in Microsoft parlance) "Options" screen found in pretty much every desktop application. What we are frequently presented with is something like this:

But this is a machine's (or, better yet, a developer's) representation of a series of choices. It's all binary and fairly decontextualized. Now, the trend in UI design to categorize preferences or choices into a larger context such as "Security" or "Bookmarks" is helpful, but a lot of these preferences are still represented in the machine model, not the cognitive model the user has. Victor points us to a better way:

For presenting abstract, non-comparative information such as this, an excellent graphical element is simply a concise sentence.

Victor's BART schedule widget, which he uses as a case study for many of the ideas in the article, uses just this approach when setting user preferences. For example, here is a preference setting which lets a user decide if they want to announce upcoming trains, and when those announcements should go off:

This is very succinct and tells the user, in plain English, what's going to happen.

But would this pass the Mom test? (AKA "Could your less-than-technology-savvy mother figure it out without any help?")

I'm not sure.

Look at the example. What are the visual indicators that you can actually interact with this? How do I know that I can change the text in this sentence?

Granted, most users, when presented with a new piece of software or a Web application that they can't immediately figure out, just start clicking until something happens. Someone clicking that preference sentence would see, in short order, that you can change quite a few things, as evidenced in additional shots from the BART widget:

But the question, for me, remains: would a user be able to figure this out? Would they get stymied by this and not really know what to do next and instead click on things elsewhere that they had already figured out. I'm inclined to believe that is exactly what most users would do.

Users have become so inured to the checkbox/radio button preferences dialog box that I'm not sure they'd intuit how to manipulate preferences in any other way. Users have been working with that kind of preferences model for over 20 years, and I don't know that it's a "design pattern" that can be broken without a heck of a lot of effort. (Then again, clicking around on the screen until something happens isn't a lot of effort.) What I suspect would happen is that a user would see this and then say "Well what do I do now?" and call the help desk (or a tech-savvy family member or friend). Users who feel they don't have the time to figure things out (and who does?) often just stop their task when the path to accomplishment isn't immediately available. Worse yet, if they've been burned in the past by randomly clicking around on the screen (resulting in an application or system crash), they won't be able to move forward with manipulating the application for fear of wrecking everything.

I know that Victor's article is forward-thinking, and it's great that it is, but in considering how users interact with interfaces right now and the years of "standard" experience that they have, the preference as a sentence to manipulate concept is slightly problematic.

Perhaps stronger default visual indicators, like hyperlink-style underlines under items than can be changed, would alleviate this problem and quickly teach users that those items were changeable. It's a nitpicky point, but important, because without those extra visual indicators, a heck of a lot of people would be calling the help desk.

The Virtues of the Simple Home Page

Tue, 14 Aug 2007 09:15:00-0400

The good folks over at Vitamin have written another useful and insightful article about Web application design, this one talking about the nightmare that can become the home page.

A couple of key points:

Less is more. I cannot stress this enough. Their example of the Apple home page is good, but Google is an even better example. Part of the reason Google attained such dominance in the search industry is because their home page is simple: a search box with a minimum of fuss. People like simple. Believe you me, I do understand how clients will want to cram as much information on to the home page as possible (if you ever saw some of my earlier site designs, you'd know I was a perpetrator of this crime). But less is always more — you point out what's truly important by not dumping everything you think is important on to the home page.
I really like the idea of designing the "interior" pages first. This makes a lot of sense in that it gets the client to think about the application (or site) as a whole, and not spend all their energy on the home page and then not have any time to spend where it really counts: focusing on how people use the internals of the app.
If you don't believe people enter Web sites via pages other than the home page, I guess you haven't heard of bookmarks.

Data Visualizations Galore

Wed, 08 Aug 2007 09:30:00-0400

I just came across this great resource from Smashing Magazine exploring many modern approaches to data visualization. I really liked the work my Munterbund and the Shape of Song projects, but some of the examples simply contained too much information to make the resultant display understandable. Maybe I prefer to see smaller sets of data, but layers on layers of data make it difficult to discern patterns to all but the most expertly trained of eyes.