There’s more than one problem with this sign, like the change from an action/outcome pairing to a translation pairing, but the real problem is that the buttons on the sign really look like buttons, and the arrow points right to them.

The sign, taken as an interface, was actually a legend to a pair of discrete buttons located elsewhere.

I admit it was a little funny to watch, but it was also a reminder of how we can do so much for people using our products by thinking carefully about where we place controls in relation to where the outputs occur.

The Countdown Stoplight

Eko is a concept created by designer Damjan Stanković that adds a graphical countdown ring to the standard red stoplight to indicate the amount of time left for the light to change. Like a combination of the progress bar for finite durations and the venerable Spinner that shows an indefinite duration, this is a brilliant idea that draws from principles of emotional design and works to improve the everyday experience of driving.

Photo mockup of the Eko concept

The concept reminded me of countdown timers on pedestrian crossing lights that also indicate the amount of time before the light changes, but in seconds rather than graphic representation. I first saw these in San Francisco. While Eko is more of an experience-softening touch, the countdown timers on pedestrian crossings make a significant difference in decisions that pedestrians make.

I wondered if the countdown could also be applied to help drivers make judgements about the transitional amber light. Not so. Doing so would add a variable that must first be observed and then measured by its rate of change in order to aid the decision-making process. Amber light judgements need to be made too quickly and already involve quite a few variables, so I retreated quickly from that notion. But for red lights the Eko would be a great touch, where the driver has only time to sit and observe the countdown.

Scramble Crossings

Known by several names since the 1940s, [wikipop]Pedestrian Scrambles[/wikipop] are in use around the world, from Japan to the UK to the US, even here in Vancouver. The concept is to stop cars in all directions and open the intersection for diagonal and straight ahead street crossings. People walking around have all the skills they need to easily navigate through the crossing crowd without colliding, and have no need to watch for cars making turns at the same time.

Watching Sam Javanrouh’s time-lapse video of such a crossing’s first day of use at a busy Toronto intersection, we can see a distinctively safer and effective flow to alternating pedestrian and auto crossings: Watch Scramble by Sam Javanrough

The idea of people self-organizing with minimal direction by the intersection designers has a great deal in common with folksonomies, where people using social information software categorize content with an uncontrolled, emergent vocabulary. Folksonomies are typically realized in tag clouds, and like tag clouds Scramble Crossings can look somewhat chaotic but actually sort themselves out organically at the ground level. That ability of a crowd to self-organize without having meticulous guidelines in place reminds us that what’s optimal isn’t necessarily perfectly manicured, in content or traffic management.

I found that re-working navigation for an application as large as Ma.gnolia wasn’t quite as hard as starting from scratch, but it did present some real challenges. If I have one big take-away, it would be that global navigation can’t be refactored before most of the interaction it frames has been worked out. Kind of like arriving at a destination, then plotting out how you got there, instead of the other way around.

For the uninitiated, single-site browsers (SSBs) give a website its own window and dock icon (or place in the task bar for Windows), apart from the main browser. I made a quick (3.5 min) screencast to show how SSBs are created and how they present themselves in the desktop environment.

There’s an odd thrill in creating throwaway unique “applications” in seconds. When I first looked at SSBs though, I have to admit that they didn’t seem all that useful, more like a parlor trick. I’ve changed my thinking about that, however, and see an interesting path unfolding.

The biggest advantage I see in SSBs is their perceptual separation and independence from the browser. Having their own dock icon and a window, unaffected by any shenanigans in my much busier main browser, gives a frequently-used site a special focus and some protection.

The SSB You Already Know

This might all sound like just another toy in the geek-playground. Even if you’ve never heard of a single site browser, there’s a good chance that you’ve already used one: the iTunes Store. The iTunes Store is probably the most widely-used hybrid web/desktop application, where all the content is provided by a website, all HTML and CSS, but it’s wrapped in a dedicated application and allows web and local content to interact seamlessly.

Where iTunes is an application with a clear focus on media, Fluid and the general SSB concept are distinguished by their applicability to almost any website. As a general purpose tool, the capacity to support the specialized content that a given website delivers is limited by Fluid’s generic nature. But even that is changing, with recent updates adding specialized support for selected sites. Use Fluid to make a GMail, Facebook or Flickr SSB and you’ll see a badge showing the unread messages count, just like with Mail; sweet. In the screencast above, the thumbnails for outbound links enrich the information that’s delivered by the web application.

I’m unsure of how far Tod will be able to take support for widely-used functional patterns like messaging systems, when those patterns are implemented inconsistently and without consideration for what something like an SSB would want to know from them (like unread message counts). I do see two directions that Fluid can grow in that don’t require special support for only the most popular applications, and could take SSBs much further.

Persistence Across the Cloud

While the data I work with in Fluid apps is saved on the web, anything specific to my interaction with those apps remains local to a single machine. This is about more than just preferences and session persistence, as it can extend to any collateral on the desktop that the Fluid app helps me create. It’s only a half-formed thought, but Fluid seems to be interestingly positioned to provide a bridge between web and local data stores, even if that is on a site-by-site basis. Add Google Gears support and there might be some very interesting possibilities opening up.

Richer, Searchable History

Spotlight, the integrated system search tool in OS-X, became a much hungrier beast in 10.5 (Leopard), as it indexes the contents of each website I look at in Safari for the past month. This is very handy for re-finding sites that I know I visited recently, but didn’t bother to bookmark for recall. Fluid apps could be doing the same, and could be working hand-in-hand with Spotlight to make that history available both in the context of a Fluid app, or across the entire desktop. Or, combined with the preceding thought, across the web to cover any machine I work on. Finding a message or a fragment of a website, no matter which machine I saw it on as long as the machine knew it was me doing the seeing, would be a nice step towards making computing more ubiquitous.

It’s easy to dream, though, isn’t it? In the meantime, I’m happy for the way Fluid changes my working environment when I’m connected, and am looking forward to what surprises come out of this rapidly-developing idea.

Last week, changing words brought something I’d been mulling over into much clearer resolution. This week, conversations at Open Web moved it to the point where it might be good to share here.

Food for Thought

At SxSW, almost exactly a month ago, I watched the lively Building Portable Social Networks panel discussion (expertly moderated by Jeremy Keith, I’ll add. He shares some thoughts on moderation with reference to the same panel). Shortly after opening remarks summarizing the goal to make our identities and relationships portable across different social networks, Leslie Chicoine stressed the magnitude of the challenges such capabilities will present to product designers.

That obviously caught my attention, but it didn’t get much traction in the discussion, and my hope for the group to circle back didn’t pan out. I took away a lot from that panel, but the what left me wondering most was Leslie’s concern about complexity and usability.

I’ll try to summarize the issues: a way to think about the goal of portable networks is to imagine online identities that knowing more about us, like the avatars we like to use or our relationships with other people. In that world, we can enter and act in new social networks with a consistent identity (if we want that) and our network of people following us across different networks. Among the strongest arguments for doing this is that it eliminates the need for people to re-find friends and re-block the not-so-friendly each time they settle into a new service. Putting all that in control of non-expert web users, making it relevant to their lives, making it understandable and accessible, is critical to realizing the potential of growing identity and authorization technologies.

It’s a Tricky Thing

How hard can all that be? Fairly. Some of the challenges are partly answered already: how do we know that Todd S on Upcoming is the same Todd S on Ma.gnolia? If I’m using the same verified identity on both services, typically an OpenID, then it’s pretty easy. Others are more complex, by far: how do we recognize that what I share with friends is different from what I share with colleagues, or clients?

Work has been done to classify common types of relationships and encode them in microformats, but the list has grown quickly without nearly exhausting possible relationships, all of which can impact what we want different people to see of us online. Chris Messina proposes a simplified relationship list to spur some adoption of portable relationship recognition at a fundamental level, reducing the set of social identifiers to “me” and “contact”. In other words, you or someone you know. He’s also written about why relationship specification is complicated, and it’s worth reading if you’re doing any kind of work in apps where one identifiable person interacts with another.

Think about any stories you’ve heard about someone losing their job over a questionable photo or comments on Facebook, MySpace, what have you. I’d bet that the hapless protagonist or well-meaning friend assumed that what was posted was only visible to the ‘right’ people. It’s easy to write that off as people being naive, but naive understanding of the activity and content the system exposes is what we need to design for. As the software gets better at finding the people you already know on different networks, those using the networks are sure to expect that each relationship works the same in different places. We’re setting the bar high in striving for portable identities.

What If?

It’s worth a few moments to wonder: what if social apps were designed from the start to know when you’re at work or school, and when you’re in personal life mode. That one division of presence along real-world lines is a natural basis for a more context-appropriate experience. It wouldn’t fully eliminate mistakes, as people find ways to break anything, but it would keep actions and content contained in their professional and personal contexts, preventing by default the awkward collisions that happen now. Had social applications built this assumption in, the reaction by businesses and institutions when social networking started to appear inside their walls might have been very different. But, they didn’t, so back to the here and now.

Facebook has taken steps, like introducing Pages for companies/brands/causes, and adding more privacy controls (some 50 controls in 4 major categories). The controls are very numerous though well-organized, but apparently not changed by many people. They’re good efforts, but inevitably don’t line up with natural social boundaries between the personal and professional, and as such just don’t come together effectively.

Even achieving professional and personal contexts within the same network is only a first step. Within each context there are still more types of relationships. Many more: client, coworker, contractor, boss, friend, acquaintance, partner, biking buddy. And of course, a given relationship can have multiple valid labels. Now try to make all that work on many networks with different social experiences, keeping in mind the consequences should the wrong thing happen. Given that complexity, the scale of the challenges Leslie was clueing us into should be apparent: it’s big.

Privacy is Really Just Sharing Done Carefully

When you think about it, online social applications are bad places to put things that are meant to go unseen, and it makes the notion of privacy start to feel like the wrong idea. This brings us back to the words we choose, because I think we interact online not to keep stuff private, but to share it selectively. Setting up a privacy framework works as a force in opposition to the goal of sharing something. If instead we think about streaming shared actions (or gestures, if you like) and content to the right people and less about exception frameworks, things should work more smoothly and, I think, bring us closer to models that can cross networks without exploding.

Things fell into place a bit more in conversation with Ryan King at OpenWeb. I mentioned the polarity of keeping secrets and sharing selectively, and Ryan suggested that lining up relationships with facets of life might help organize things in terms that are addressable by non-experts and achievable in code. Thinking of the parts of an individual life, we can easily see relationships cross contexts without violating any rules, because the interaction is appropriate to the context. Just because your buddy from work can see the photos of you at a weekend kegger doesn’t mean that he should see them when you’re both at work. This is the kind of path we want to make natural with portable identities and networks.

I suspect that facets can act as non-exclusive groupings of contacts, and that those groupings are a good level of control for using as sharing channels and moving between services with those facets intact. And that’s how far I’ve made it with this line of thinking. The next step is to track down and mock-up some interfaces that work from a sharing orientation and through the network along lines that are organized like our actual social lives.

Any links to interfaces that sound like that, or feedback in comments or mail would be appreciated.

Ready to turn those paper sketches into usable wireframes, I turned to trusty OmniGraffle and started looking for a stencil of iPhone interface elements.

But no luck, as in no stencils to speak of that I could find. Moreover, the iPhone SDK beta doesn’t include the interface builder kit. I expect that future design work on iPhone and iPod Touch apps will also involve glossy mockups over standard wireframes, so I created a temporary stencil out of iPhone screenshots and a bit of custom shape creation. When the SDK is released with the interface builder, I’ll replace my hacked up elements with actual ones from the kit.

For now, though, I’m working with my homespun solution. Though it’s very much a draft with some rough edges and an incomplete inventory, it’s enough to get started. I thought there might be others out there thinking of designing an iPhone app and at a loss for how to mock up the interfaces, so I’m sharing the stencil here.

iPhone & iPod Touch UI Elements | Download Updated: March 23, 2008

I’d appreciate feedback on it, and will keep the stencil on this page with improvements posted here over time.