In "The language we use," David Malouf discusses how ideas about user interaction can become so ingrained in what we are familiar with, that our language begins to reflect that familiarity. That can lead to a natural tendency to explain away interaction without thought to what it means to the design of a thing. In this case a student describes the change of context in a sketch presentation by using the word "click" (as in clicks to go to the next screen). The absent minded use of the word "click" brings with it the connotations of a mouse click, and limits the possible set of interactions.

David makes two great observations here. First, that the way we talk about interaction design is as important as the visual elements of the design solutions we produce. The language we use, and in particular the selection of meaningful words that convey behaviors, and the intellectual content and analysis of our design is a closely bound component of what we're providing when we do design work. It is productive, therefore, to write about interactions (e.g. in your spec) and deconstruct what you write.

The second great observation David makes is that there is danger in the use of loaded language when it comes to describing interaction. Words like "click" explicitly point to the use of one type of input behavior, whether it's a mouse input or finger touch, that carry with it the limitations or constraints of that behavior. The same might be true of using certain conventions or design patterns. The use of a specific, familiar interface element, like a tab for instance, might lead to known but perhaps limiting behavior for a given application, that would hold the designer back from considering better alternatives for the interaction.

This discussion also reminds me of the thread started by Josh Kamler on "Designing by Writing." It is extremely valuable to engage in writing and discussion about design through deconstruction. Even in the absence of a studio environment, we can learn to analyze what we design by paying particular attention to how we describe what we've designed when we write specs and re-reading and deconstructing what we've written, and actively engaging in regular critique of our work.

Sketches are often better tools for communicating designs than high fidelity illustrations or schematics. The purpose of the sketch style wireframe is to prevent the intended audience from thinking about visual design and focus on the functionality and behavior you are proposing.

I'm happy to announce the release of this set of sketch stencils for OmniGraffle, based on the Wireframe Stencil. This set of user interface sketch stencils is designed for OmniGraffle 5.x. OG4 users are able to use the stencils by changing the .gstencil extensions to .graffle. The sketch kit contains all of the UI elements you'll find in the free Wireframe Stencils we provide at Konigi, plus additional shapes and elements to make it easier for you to adjust to this style of wireframing.

As usual, I'm sticking to the goal of keeping the tools on this site inexpensive or free. Your $10 purchase of this stencil set entitles you to free upgrades forever.

John Gruber laments the illogical, yet human, tendency to avoid saving new documents, which occasionally leads users to the loss of data when an "Untitled Document" is left in limbo and a crash leaves them scrambling to figure out what happened to it. The point is that users often can't be bothered with things like figuring out where to put this thing on a file system because we're too busy with the task at hand, e.g. writing the thing that we might not have a name or place for yet.

Good software would save users from their non-saving, human selves. Software needs to offer a way to protect us from our laziness (and I say that as someone who is very lazy about certain things) by providing systematic methods for frictionless data protection and recovery. We're talking about the realm of usability principles that Jef Raskin wrote about, e.g. providing undos rather than dialogs for destructive actions.

Gruber also talks about the "i" apps' implicit handling of things like file system paths in iTunes and iPhoto, which take care of file organization for you, so you can just focus on things that makes sense to you, like albums and playlists, and let the system just do the file management for you in a logical manner. Gruber also writes of the autosave intelligence in apps like Stickies and BBEdit, which auto-save in the background unbeknownst to the user, and upon return from an abandoned session, data is back where she left it, in whatever state they left it in.

These are frictionless applications--those that lets users get to the main task that brought them to the app in the first place, e.g. writing, uploading photos and music, without having to think of things like the file system. This is design for use, and not for micro-managing control. It's getting directly to the point of using the application, and avoiding obstacles like thinking about how to use the application.

I think this is the vision most of us, concerned with ease of use, espouse and want for our apps. I speak out of both sides of my mouth sometimes, opting for micro-managing some things, e.g. I've used a photo management app based on my camera/year/ file organization rather than using iPhoto's file management, but I let iTunes manage all my music and video data. But the point is, most people probably don't want to micromanage that organization.

In BusinessWeek, Bill Buxton discusses how to keep innovating, with the main idea being that you can continue to cultivate creativity and innovation by finding new things that you have a passion for. He suggests that when you get good enough at a thing, you should find something else to be passionate about, and commit and throw yourself into learning how to do it. You'll be bad at it at first, but the experience of learning something new, no matter how bad you are at it at first, may affect your creativity in positive ways that you won't realize until you experience it. In some cases, they may inform what you are already expert at, and in others lead you in entirely new and surprising directions.

The discussion reminds me of Paula Scher's talk focussing on serious versus solemn design at TED. Scher spoke about the different times in her career where she was able to be most innovative in her craft, and the thing that was common in each case was that she was doing something new--something she didn't know much about when she started that particular project. The fact that one has no reference point or bearing can lead to innovative thinking.

This is the same argument Buxton is making. I think Buxton is saying that the continued pursuit of new endeavors itself, is what can help cultivate one's creativity and create the pre-conditions for innovation. I'm sure a lot of people who take up new hobbies and have the continuing need to learn see the obvious in this. This is one of the reasons I feel at home in a city where it is easy for me to start investigating and learning something new all the time. Being in a city isn't necessary, per se, but being able to get inspired and start doing something new is a hell of a lot easier for me here. This coupled with the fact that my wife and I homeschool our 8 year old son, which has lead me to dive deep on countless topics and project that I would never have held my interest in the past. If you read my personal blog, you know about my forays into toy making, game design, character creation and storytelling.

In any case, the story is not new, but is a reminder for me that being well-rounded and having many interests is a good thing. In fact it's one of the top criteria I've used when participating in the hiring of people.

Think Vitamin's Clive Howard says "Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones." In this article, Howard goes through the wireframing process, discussing who should be involved, which tools to use, and offers sound tips to enable you to make better wireframes.

Among my favorite points are those about ownership and involvement. This is to do with ensuring that someone is driving the process and iterations, and making sure that the interaction design process doesn't happen in a vacuum, but is reviewed, validated, and informed by key team members, e.g. engineers, as you're creating them.

I also like the points about fidelity, and avoiding doing too much design. That said, if you're also the visual designer, or can base the visual language of the wireframe to the visual language of agreed upon visual design specs, then I don't see a problem doing that.

What I don't agree with, is that you want to avoid designing behaviors such as Flash or AJAX. Wireframes, storyboards, and sketches are the precisely place to explore how websites and applications should behave. You needn't be as specific as specifying types of transitions, just generalized behaviors and relationship to system logic. If you don't specify behaviors, decisions will get made without your input. If that's fine with you, leave them out. But you're supposed to be the expert on your users, how they've modeled the site or app, and what they expect to do there.

Lastly, one point that is missing for me is know how to pitch/present the wireframes. These aren't just documents to be chucked over the wall. While they should be able to stand on their own when it comes time to design or develop what you've specified, your job is not done when you've shipped the doc. You have to present and justify, explain details, and answer to questions that will undoubtedly arise about how things behave. For this reason, I rely very heavily on annotating wireframes and storyboarding behaviors. Those questions will need to get answered eventually. If you don't think you deserve to be in that conversation, leave them out, because someone else will make those decisions without you. But if you intend to be involved in the user experience, why not be involved in every aspect of design, and make sure your wireframing process allows others to be inform what you produce.

There's quite a bit of good stuff in Howard's points, so be sure to read the article to find out what each of the bullet points above refer to.

The JQuery'd Breadcrumb is an odd breadcrumb interface that collapses all nodes in the branch upon page load, and then expands to show each node the user mouses over. Their explanation:

This collapsible breadcrumb was developed to deal with deeply nested, verbosely named pages. Rather than limit the amount of elements shown on the sever side, we decided to go with a client side solution for usability and SEO reasons.

I don't see how this is a usability improvement over an exposed breadcrumb. If they needed/wanted to use breadcrumbs for whatever reason, it would seem more usable to show a larger truncated portion of each string with an elipsis, and expose the string on hover, rather than just show these strange portions of the string. I don't even see the whole first character, so it just looks kind of broken in a way.

I like the attempt to do something about minimizing breadcrumbs in deep paths. But it might even be more useful to use something like the path control we're accustomed to in the Finder and Windows Explorer. You'd have to do a lot to make it look less like a form control to make it unobtrusive, but provide some context. Do it with ULs and CSS, and I think you'd still be ok with regard to SEO, although someone might correct me if I'm wrong. I don't know why you'd allow horrendously long titles as in their example, but clearly you don't need to have the current node in the branch visible if the point is to minimize the weight of this UI element.

The New York Times' Article Skimmer prototype provides a nice gallery view of top articles, and utilizes a categories sidebar to filter articles. Keyboard shortcuts are also provided to navigate prev/next category, or to jump to a specific category. Very nice way to view articles. The dense tabloid style of the regular site can be overwhelming sometimes.

Via SwissMiss

If you've been following this blog, you may know how I've wanted to do sketch/jitter line styles in OmniGraffle to produce sketchy diagrams and wireframes. After David's demo of his method for doing sketch shapes on the Design Commission blog got me started figuring out how to get the effect natively in OG, I've started to finally create sketch versions of the Wireframe Stencils. Above is a screenshot of the forms set. I expect this will take me a few days, but hope to release these in a few weeks.

The New York Public Library Labs has begun testing a light usability testing system to supplement their formal tests, inspired by the Five Second Test method which was devised by Jared Spool and turned into a service by the guys at mayhem(method). The service, nicknamed Infomaki (info roll?), combines the type of service 5 second test provides, as well as allowing single question surveys for checking on things like simple labeling issues, which you might have tested using card sorting.

The test lets you answer only 1 question, or continue answering as you like, which makes the task feel very game like, and reminds me of crowdsourcing apps like Amazon's Mechanical Turk. I love that the types of questions you can ask require simple twitch-like responses, so you can get through a lot very quickly. Here's a bit more from the NYPL Labs site about the project:

It has become apparent that we needed a tool in our kit that would allow us to get simple usability questions in front of users with a minimum of fuss.

[O]ften, what is needed is just a sanity check– a reassurance to our team that we are on the right track.

Our design sessions frequently result in debate about which of two words is more compelling or accurate for our users, or whether a particular button is noticeable in a particular location. When we can, we test designs on real people using paper or digital prototypes, but it is impractical to test every day; sitting down with real people is not always as simple as you’d expect, what with the schedules of busy New Yorkers.

We’ve used SurveyMonkey in the past for full-fledged traditional surveys, and we’ve also evaluated OptimalSort for online card sorting, and been inspired by the Five Second Test. But none of them were a perfect fit, for reasons including complicated interfaces, inflexible setup, privacy policy hassles, and/or lack of a way to embed a link back to our site when the test is completed.

So, we set out to create our own rapid-testing usability laboratory from scratch, and last Tuesday we launched it, in rough beta form.

Having worked on information systems in research libraries, I'm always excited to see libraries that are ahead of the curve in terms of technology, and the NYPL never fails to impress. The NYPL Labs is testing the system with a small number of usability questions related to NYPL sites now, so you might get some repeat questions, as I did. It would be great if the system could cookie sessions to ensure that questions aren't repeated. This is a terrific start though. The NYPL Labs plan to release Infomaki as an open source application, which is great news for us.

Requested Reading Recommendations from the School of Visual Arts, MFA in Interaction Design program.

Upon the request of readers, we asked faculty to recommend books for an interaction design reading list. These could be landmark texts, underdogs, or critical reads, or stepping stones to other fields. The following is what resulted from our request, comprising in part: a sneak preview of what will be assigned in courses; what some consider to be cornerstone interaction design texts; and what some consider important connections to other fields.