We don’t often write about products that we didn’t work on, but I came across Path last night and felt it was worth talking about. Path has been around since November of last year. I only vaguely remember looking at it when it first launched, and I don’t even recall what it did – obviously a problem.

The new version, Path 2, is about capturing and sharing moments – they refer to it as a smart journal. It’s not Twitter, Foursquare, Instagram or Facebook (though it does feel like the timeline). It’s a bit more like Evernote in terms of what it does, but is more about what’s going on in your life. What struck me about this app though, and made me want to write about it, was the interaction design.

Native vs Custom

Until recently, I’ve felt most apps fall into one of two camps. They either use core elements of an OS or they’re comprised primarily of custom UI. Neither one of these approaches is wrong, though some argue that breaking conventions is a no-no. I typically argue that it’s okay to diverge from conventions so long as the experience is intuitive and polished. If it improves things, even better. Experiences that start with an overlay teaching people how to use the interface obviously miss the mark. Thankfully, we’re beginning to see UI designers start to find some balance in between these approaches – Path is an excellent example. It feels familiar, but they’ve made some smart decisions that break away from the norm without wandering off into obtuse interactions or under/over-designed visuals. The decisions they’ve made not only make things better, they add personalty and delight – something that is crucial, and often overlooked when designing something functional. There are a number of things I love about the work the team at Path have done but I want to point out a few on iOS.

First impressions matter: first-run & on-boarding

Signing up for a service is typically a painful, or at least, mundane experience. It’s a few fields, some buttons and some useless directional copy. It works though. With the exception of a system error, no one struggles with these experiences. As designers, our tendency is to focus in on the meaty parts of a project and innovate. Something as trivial as a signup flow is considered a commodity and typically little to no effort goes into them. Path chose to improve it. The first-run simply lets you understand the value by looking at a canned ‘Path’. From there, you either create an account or use an existing one. No fields, no useless directional copy, just a few intuitive interactions. I love that form elements and actions are suppressed until I’ve chosen what I want to start with. This non-linear approach is refreshing. Once registered, the app also does a good job of connecting you with other people on Path (albeit without Twitter integration, though I’m told it’s coming soon). The number of screens below make make this appear like a long, drawn out process, but in reality you never notice it.

Best part about this: I don’t have to type in my email or phone number, just pick the appropriate info that’s pulled from my address book.

Navigation: Learned and explicit

There are two things that are noteworthy here. One is how you access the menu. There is an explicit button that slides the current view to the right revealing the menu below (the Facebook app does this too). Additionally, Friends are accessed through a button on the right. What’s nice about this is that there’s what I call UI hinting going here. By animating the panels left and right I’m given a hint that I can likely swipe them to execute the same action. Relying solely on swipe isn’t quite learnable enough, and obviously we don’t want a UI instruction sheet. But only using buttons isn’t the right choice either since a gesture requires far less accuracy and is therefor a more efficient means of performing the same action.

Best part about this: This isn’t a simple swipe then animate action. It’s a pan gesture. There is an enormous difference between these two methods. The former, makes things feel sluggish and disconnected, while the latter feels physical and natural.

Prioritization: Information when needed

One of the things that I love about small screen mobile design is that the physical size constraints force us to make hard decisions. What matters most in a given context is something that I’d love to see designers ask themselves more when working with larger displays. Striking a balance between what navigation and content I need to see at any given moment is what Path does right. The ‘post new’ button suppresses the options into a delightful radial fly-out menu – I’m not inundated with options by default. The best example though, is how they’ve prioritized the content. Because a Path is timeline-based, the common tendency for most designers would be to have a time stamp in some elegant, faint grey text – just visible enough, but not to loud as to cause a distraction. What Path decided to do, and I agree, is to focus on the content of the post and de-prioritize the timestamp by making it appear when you begin scrolling the timeline. This removes clutter from the screen but allows you to see the information when needed.

Best part about this: That Path realized the timestamp isn’t all that important by default. It is after all, a timeline, so you already understand some element of time without the stamp – i.e. the stuff at the top is recent.

Congratulations to the team at Path for re-inventing themselves. It’s an incredibly thoughtful interface and very interesting product – you should try it if you haven’t already.

Most of you likely know that Color is also reinventing themselves. I hope they read this and recognize that they too need a transformation like this. This is the level of care and polish that will become the standard for everyone – startups and established businesses.

You can follow me on on Twitter @gt and us @teehanlax.

Enjoy the awesome collection of works by illustrator/designer/type aficionado, Alex Trochut. I am getting kinda sick of the whole “blog style” portfolios… can somebody please do something new?

I tend to lean away from most of the random design crap, but there’s something about Nelson Balaban’s work that’s not quite as cliche… or maybe it is and it’s just that I’m in love with the work he did for the “Computer Arts Project”.

Some of the most compelling new online destinations are driven by a participatory model that invites users to create, manipulate, share, curate and distribute digital content. This model creates opportunities for all sorts of network effects, allows for more compelling content to emerge from a diverse population, and engenders a more proprietary feel (a sense of ownership and responsibility), not to mention community involvement.

All very interesting, but how do designers plan for and build online destinations that succeed in this model? Well, there’s clearly no formulaic way to guarantee results, and it would seem that success depends on a lot of intangibles and unknowns like market vagaries, priming, timeliness, confluent fads, etc.

At the same time, we can see that sites that have developed robust and productive communities boil down to an essentially intrinsic value proposition. In other words, they don’t depend on community at the outset. Sites like “flickr”:http://www.flickr.com and “del.icio.us”:http://del.icio.us make it possible to easily access your stuff anywhere there’s a web connection; the community stuff is great once you get involved, but there’s a sort of prima facie reason for using these sites that helps get you started.

That’s all really high-level, pretty obvious stuff, but here’s something more tangible—I’ve noticed a few best practices in terms of mechanics for enabling user-contributed content:
# Got to start somewhere: make the button really easy to find
# Bookmarklets + screen-scraping is the easiest way to let users to bring external web assets into the fold
# In terms of user input (data, meta-data, etc.) make it clear what’s necessary and what’s optional
# Leverage known data (time and place, any screen-scraped data, data derived from stuff the user just entered, data derived from stuff other people have entered for similar items, etc.) to enable “smart defaults” 
# Use active assistance (e.g. field auto-completion) if possible
# Allow users to preview their contribution
# Keep things really simple and straight-forward. Framing things up in self-evident structures (1,2,3; what, where when, etc.) can help
# Two options when users are finished: (1) take them back to where they started from or (2) take them to their newly uploaded content. Which alternative is best depends on the context, or you could give them the choice.

Any others?

Just to refresh, design patterns are general repeatable solutions to commonly occurring problems. There’s a putative measure of objectivity or optimality attributed to design patterns, distinguishing them (in theory at least) from what are often called “best practices,” which tend to be derived through convention.

To sort things out in my own head, I came up with this visual scheme for slotting patterns into the interaction designer’s toolbox. Obviously, this is not the only way to slice things up:

I had a bit of trouble deciding what should go in the top-right box. By quality attribute, I mean desirable traits like learnability, modularity, explorability–the “ilities” of design, which I think are both fairly abstract and context-dependent or subjective. These are sometimes called soft goals or “non-functional requirements”:http://en.wikipedia.org/wiki/Non-Functional_Requirements in systems design.

Back to design patterns. We’ve commented here before that we tend to be cautious about methodologies that are borrowed from other disciplines; we need to constantly ask ourselves, how will this help us improve our work?

Design patterns in software engineering are meant to be used in a deductive, rationalistic fashion. So you have this general problem or requirement, X, design pattern Y solves X, therefore use Y. Now, when I reflect on my own process—and I’ve got “reason to believe”:http://www.kottke.org/06/09/how-design-works that I’m not alone here—I find that it’s more organic than that, more inductive than deductive, more bottom-up than top-down.

Obviously, there’s a balance to be achieved. When a project is in the initial bootstrap phase and I’m trying to make the jump from abstract requirements to a concrete design solution, I’ll often perform a sort of “breadth-first search”:http://en.wikipedia.org/wiki/Breadth-first_search in my head/on foolscap. During this phase, I’ve found design patterns to be helpful, allowing me to quickly frame up the design problem in concrete terms.

I think that pattern-based design has the potential to move interaction design forward, but we need to sort out how this will jive with established methodology that works in the other direction (e.g. scenario-based or iterative design), and also how to balance the value of standards and conventions with improvisation and innovation.

Learn more about UI design patterns:

* “obligatory wikipedia entry”:http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
* “repository of website design patterns”:http://iawiki.net/WebsitePatterns
* “compendium of HCI design patterns”:http://www.mit.edu/~jtidwell/interaction_patterns.html (not just for websites)