Recent Blog Posts

Little Springs Design, a mobile user experience design firm, is growing. We have an immediate need for an interaction designer for full time work. This position can be either senior or regular, and pay will be based on experience. Work is located in Lawrence, Kansas; no relocation benefits are available at this time.

Specific responsibilities:

• participate in user research and modeling
• create wireframes and mockups for mobile web sites, applications, and services
• translate wireframes into detailed design specifications
• monitor academic research

A Senior Interaction Designer would also:

• lead client engagements
• mentor other staff
• monitor mobile industry trends
• develop industry expertise

We understand that excellent interaction design does not necessarily match up with a specific set of experience. You may have come from human factors, information architecture, graphic design, human-computer interaction, or a number of other disciplines, and this will be reflected in how you see the world.

Minimum experience and skill:

• 2+ years in interaction design
• ability to write detailed design specifications for developers' use
• experience designing for at least two platforms (such as web, Java, desktop, Mac, PC, mobile web, mobile applications, embedded)
• education in design, HCI, anthropology, library science, or human factors (bachelors' degree or equivalent experience)
• flexibility in use of computer programs and operating systems

Preferred:

• experience designing for mobile applications
• experience researching and creating personas
• ability to design & communicate using Flash and/or OmniGraffle

Please send a resume (PDF or HTML preferred) and a description of past work to: sales@littlespringsdesign.com.

Little Springs Design works on a variety of user experience projects for every type of company in the mobile industry, including device manufacturers, carriers, software companies, platform companies, and industry associations. We believe in integrity, mutual respect, and keeping our word. We also believe in ensuring we all have time for a satisfying personal life.

Meta data is the set of data describing a piece of content. The content can be a video, image, blog post, you, your mobile, or really anything. The meta data can include location (IP or physical), date created, date modified, keywords, tags, genre, author, and so forth.

Meta data has been present and used for years. You probably use Microsoft Word or Open Office, and you can edit a document's meta data via the File menu. Operating systems use date, name, and other information intensely.

While meta data is very useful, it requires constant vigilance to retain its usefulness. Perhaps the most immediate example of this is the recent major push for desktop search, such as Apple's Spotlight, that looks at the content of files and not just their name and meta data. Web search engines tend to look at content more than meta data in the page's header, since it's so easy to stuff irrelevant data there.

This post was triggered by my use of iTunes. I like to subscribe to podcasts and sometimes download audiobooks. iTunes treats podcasts, music, and audiobooks separately . . . but only if the meta data is correct.

Keep in mind that people consume these three types of content differently. Apple's iPod designers appear to know this, but the desktop designers don't. An iPod, for example, will not play podcasts in shuffle mode, nor will it automatically populate the device from podcasts. It will happily do these things for music, because they make sense for music.

The current state of iTunes:

• many audiobooks, including every free one I've ever seen, are categorized as podcasts
• iTunes U content has the genre as the school name, creating new playlists but NOT listing in podcasts; they are categorized as music
• university lectures through other mechanisms are usually podcasts but sometimes music
• if the user changes the genre, the application doesn't care. It leaves the content in the unwanted location.

To fix this on my own machine, I have created a fairly complex smart playlist to put everything I consider to be "podcast content in my inbox" into one place. This is pretty ridiculous and also requires ongoing tweaking on my part.

When a system does not have control over its meta data, things get more complex still. Groups who want to share pictures on Flickr really have to pre-agree on a tag. "momolondon" gets you Mobile Monday London shots. "daveandpip" gets you pictures for a specific couple. What if a potential contributor doesn't know the secret code?

Flickr is at least a single repository. I use a set of pretty bizarre tags on del.icio.us, based on what I want to do with the bookmarked page. "to_n800" is stuff I've found somewhere and want to use from my N800. "modbook" is stuff I think will be useful when I finally get my new ModBook. Does this make any sense to anybody else? Hardly. I also generally find other folks' tags not particularly helpful, because they are built on a different context.

Perhaps most immediately relevant to me is the tags on this site. Every last post is related to mobile and user experience. The entire site needs these two tags; it certainly doesn't help somebody navigate this site for me to add these tags to every last bit of content. Yet for your feed reader or for Technorati, mobile is a key descriptor. Only when you use the keywords in the meta tag on the page as well as the tags I add to the posts do you get a complete description.

You may wonder what this has to do with mobile. Mobile applications tend to use meta data more intensely than desktop applications, due to the increased importance of context and the smaller screen. User agent strings are a form of meta data, and quite important to many developers, but notoriously unreliable.

If we want these applications to be reliable and useful, we'll need to do the following:

• build flexibility into any application that relies on meta data. This is a place where explicitly limiting mobile access to a subset can be a problem. Maybe the content is indeed a video, but it is a slideshow and can easily be shown on a mobile. That's unlikely to be caught in content-type meta data
• build content search into the listings, perhaps by providing an initial list that are simple meta data matches and then a link or list of content matches as well.
• build robustness into context detection. A user might not update status or might have skipped the meeting on the calendar
• incorporate meta data quality management into processes
• avoid requiring extremely accurate meta data in applications; give the user the opportunity to fix the problem; use alternate spellings

You folks are smart ... what strategies do you use to make use of meta data but not be killed by its negative aspects?

Hey, this is a desktop post!

Not really; it’s yet another iPhone post. If iPod requires iTunes on Windows, then iPhone requires Safari on Windows. Sharing bookmarks, maybe sharing history? I was just talking about integrated experiences.

Other niceties: help all those developers create web sites that will work on the iPhone by giving a Windows Safari. In theory, what works on one will work on the other. Maybe this will encourage Nokia to use the same version of WebKit?

Have fun, but be careful with the processor and data demands. The charge has to last all day.

Do you live in a silo? Probably yes. Can you get out of it? Probably not, unless you are willing to change your life.

The iPod is not just a music player. It is an entire ecosystem surrounding the acquisition and consumption of music. Microsoft Zune tries to expand this into sharing content as well.

The iPhone expands on the iPod music integration, but takes on a new challenge: the carrier. That video voicemail? A cross-company effort between Apple, their manufacturer, and AT&T. Not easy, especially with companies who are utterly certain that the other one doesn’t know what they are talking about.

You don’t actually have to be Steve Jobs to do this. Arlene Harris started Jitterbug and faced many of the same problems iPhone has: the network services had to be integrated with the phone user interface. In Jitterbug’s case, it’s Samsung who is doing a lot more than just providing a device. Jitterbug needed voicemail that integrated with the Yes/No user interface. Amusingly enough, SonyEricsson had a Yes/No UI for a few years, but didn’t get this one figured out.

These companies are addressing the exact issue that Michael Mace complained about the Sprint experience. I find myself wondering if the decreasing margins in the device industry are encouraging Samsung to do this.

One thing to note about an integrated user experience: you are going to have a walled gardens. Walled gardens are not bad; they are just limited. AOL did very well for years on this model. What would be bad is making this the only available model.

The Jitterbug and iPhone are each targeted at niche markets … but perhaps the niches are large enough. The iPhone may get some people who were going to get an iPod video. The Jitterbug is targeted at the older crowd, but could be useful for the folks who just want a voice phone regardless of age.

EDIT: just after I wrote this, Safari for Windows was announced. Perhaps this is a planned integrated user experience?

OK folks, we can get all excited about mobile Ajax. After all, there is a mobile Ajax FAQ now, right? That means it must be real.

Get real. For now, the only way to develop for Ajax is to develop for specific device types, possibly running on specific operators. We don't even have good cookies. Session states are not well stored. We've got major rendering issues, compatibility issues ... and don't just take my work for it. Mike Rowehl has a bit more development experience than I do.

I'd love to have all of the fancy features that Ajax enables. Of course, we'll have to overcome some limitations inherent to mobile:

• high latency connections (compared to landline) will introduce delays in interaction flow, so pre-fetching will be important where possible
• the single-window paradigm of most mobile devices means that delays in interaction are extremely noticable
• short battery life & processor speeds means that scripting should be used only where necessary
• different DOMs and BOMs mean that sites will have to be designed for specific browsers
• you have to get carrier buy-in for fancy stuff; they could block your IP address if users are having major problems with your site
• the application needs to somehow detect device state, and (typically) avoid fetching content when the screen is off but the browser is running. Exceptions of course exist.

In the meantime, I've been waiting for cookies and basic session tracking to work since 1998. They still don't. This is a higher priority problem.

Tucked into the same conference where Microsoft Surface (decidedly NOT mobile) was announced was Livescribe. Founder Jim Marggraff refers to the product as “paper-based computing”, and it has some nice features; check out their sneak peek.

Livescribe uses the same pen technology as (among others) the Nokia Digital Pen, though with a voice recorder and built-in computer (for a lower price).

Both devices require special “digital” paper printed with faint lines, which allows the pen to orient itself and save the strokes as digital as well as physical ink. At the simplest level, a pad of digital paper allows saving notes. Nokia goes one step further, and a special pad of paper tells the pen to send the drawing as an MMS (Bluetooth Nokia phone required).

Livescribe appears to use a different pad/type of paper for different applications. A travel notebook has a “translate this” icon on the bottom of the page. A blogging notebook lets the user record voice while making notes, enter an address, and double-tap the “post to” icon.

Particularly interesting to me is the classroom scenario … which works just as well for meetings of many types. Open up your notepad, double-tap “record”, and take notes normally. Each keystroke and word has a timestamp for when they were written or drawn; this timing mechanism allows the lecture recording to be searched. You get to hear what was said when you jotted a specific note. Great stuff, though I’ll have to wait and see how good a recording it will get sitting in the 8th row while scraping across paper.

Think of Livescribe as a voice + pen input, speech output computer. There are lots of different potential applications, and of course it talks to your computer (probably a Java application, given that they are hiring Java programmers).

Of course, I have a Modbook on order, and I’m anxious to get it. This is a tablet Mac with a Wacom digitizer. As soon as I get it, I’ll be trying out the inkBook notetaking software. That means that I am two minor enhancements away from getting the same functionality with my computer.

All of these solutions (Nokia Digital Pen, Livescribe, Modbook + inkWell) are inherently mobile, though all can be used while stationary. All use input sources beyond the standard keyboard+mouse of computers. This is one of the ways in which mobile has more capability than the desktop.