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.

Joshua Porter's post about whether good design can be replicated is fabulous. What I like is the idea that there isn't a solid set of methods that you can reuse in every case and think it might guarantee success or "good design". There's an interesting thought in there about process:

I wonder if the real issue is that most of the time designers simply don’t know if what they’re building is great, and they end up relying on process to get as far as they can. If they go through the right process, they think, then they’ll produce maybe not the best solution, but the best solution possible. This may be true…and it is comforting, in a way, because if you feel like you are doing it right then you can sleep soundly.

Couldn't we just say that all this activity that leads to design, whether it uses one methodology or another, just helps frame the problem and start the discussion about understanding what you're trying to solve before the eureka moments hits. We're not talking about sticking to rigor here, but maybe using tools and methods to get to some moment of clarity before carrying on to the design that can now be given focus.

The Michael Bierut passage is a great one, in that he suggests that he works at the problem in one way or another until the solution manifests almost magically. And Joshua suggests that perhaps it's just hard work, and I would say experience, that makes good design. I'd side with that opinion, if I had to side with anything.