Recent Blog Posts

strategery all day

July 30, 2009 by Steven

Brian The Intern and a client (more in the background) doing a post-it exercise

Fun day today, though long. The whole company spent the whole day in the office (but for lunch and a field trip) with a client. Here we’re doing the Post-It® exercise (read more on these in my book), which we’ll finish with a whole other group of the same client, tomorrow.

I, especially, have been slogging through paper and words for weeks, so actually doing really conceptual work – and drawing – is a nice change.

Tags: Design, Permalink | Comments (0)

how big is your image?

July 22, 2009 by Barbara

Have you ever noticed that iPhone emulators on the desktop are huge? What's the deal?

The "deal" is that your computer probably has 70-90 pixels per inch (ppi), and the iPhone has 149 ppi. So the same graphic looks twice as big in each direction, for four times the area. And this is not the worst of the problems.

What's worse is I've found pixel sizes ranging from 110 ppi to 310. Yes, nearly a factor of three.

Until recently, we could make a cheap guess as to what the pixel size would be, because phones tend to have screens that comfortably fit in the hand. So "small" screens (defined by Admob and MMA as around 128 pixels wide) have 110-120 ppi. "Large" screens are likely to be around 150 ppi, plus or minus 15.

We're not the only folks to worry about this. Bryan Rieger of Yiibu writes eloquently on the topic. Even better, he provides methods for handling this beyond simple image resizing. Go now and implement his suggestions. We do.

Like I said, until recently we could handle this with some simple heuristics. That 310 ppi phone is very uncommon, to the point of ignoring it, and of course it doesn't look like a mobile phone in terms of screen size (in pixels) anyhow.

But now we have devices like the Palm Pre. It's got a beautiful screen, and it's at 186 ppi with the same pixel dimensions as the iPhone. That's nearly 25% smaller pixels in terms of height and width. Or, the same image will have 56% the area on the Pre.

And these are both advanced Webkit browsers. So people will be sending the same content to them.

What to do?

  1. Continue to work with organizations like Device Atlas and WURFL to get physical screen size in the database. And help populate the data! They need your help.
  2. Be sure to send images that will be appropriately visible. You may need a larger image on the Pre in some cases, especially for enterprise (i.e., heavy bifocal) customers.
  3. Don't skimp on your font size. Palm recommends 15 pt fonts. Our review suggests this is good, and smaller fonts start being more difficult.
  4. Get serious about managing your content and structural images. Do as Bryan does.

And this blog entry doesn't get an image because we're going on vacation. See you next week.

Tags: Design Tips, Permalink | Comments (2)

desktop-mobile consistency

July 10, 2009 by Barbara
Little Lebanon (in Dallas) McDonalds with southwest US styling and English and Arabic signage

ماكدونالدز - arabic mcdonalds in Dallas by austinevan

I'm the first person to rail against a slavish consistency between experiences. I want to see the right experience in the right context on the right device, not a foolish consistency. The same experience with a brand in different situations is bad for your brand and bad for your customers.

You can read a bit more about bad consistency in my recent how many webs essay. But this entry is about necessary consistency. And key players don't have it.

The wrong inconsistencies cause user problems

Different labels, different methods of organizing information, conflicting default values, and conflicting underlying metaphors will cause problems. Let's look at examples.

iPhone 3.0 broke consistency for playlists

The latest software release from Apple is the first iPod software that changed the sort order of playlists. A playlist titled "1 party" or "_Podcasts" is at the top of the list in iTunes, and was on my iPod Touch until last week. People who name their playlists this way do it to quickly find certain content. Apple changed the sort order, and those lists are now at the bottom.

Worse, the sort order has been changed for podcasts within the playlist as well. I tend to like my podcasts to play from oldest to newest, or in random order.

Finally, and this may be a bug, the smart playlists are not updating correctly. My _Podcasts smart playlist (in iTunes) explicitly excludes some artists and unchecked items. But on my iPod Touch, they are back. I'm going to have to re-build my smart playlist to get it to work in both places.

This experience has left me unable to consume my content, to the point that I have to pull over in the car, scroll down somewhere in the list to where I have fewer spurious entries, and launch the playlist from there. Bad inconsistency.

OmniFocus for the iPhone with a default due time of midnight

OmniFocus mobile is inconsistent for due times

OmniFocus is actually the reason I wanted an iPhone or iPod Touch. It's been so helpful in balancing "hugely long task list" with "actually getting stuff done." It's not for everybody, but I continue to use it. (Gmail tasks? Outlook tasks? iCal tasks? All toys.)

The desktop version of the application has a default time a task is due, for all tasks with a due date. I think by default it was 5pm: a nice, sane date. And changeable in the options.

Unfortunately, the mobile version also has a default task-due time. Midnight. And it is not changeable in the options. So every time I specify a due date, I have to also specify a due time. Of course I forget. After all, the point is quick capture of tasks; adding four extra actions isn't quick.

The problem comes when I'm deciding what to do next. I have tasks due today, and tasks due tomorrow. Generally, I do the former before the latter. And I tend to do overdue tasks before that. Unfortunately, mobile-generated tasks are late for the entire day that they are due. In red. Causing flags to go up. Because they are due at midnight.

The right consistency

So while a slavish consistency is bad, structural inconsistencies — especially with my personal data — are also bad.

Don't design mobile in a vacuum

When building your mobile experience, it should be consistent with the vision and intent of the rest of your brand's experiences. You need to have a person or group responsible for maintaining overall design vision and brand identity, as well as overall design vision for whatever product suite you are working on.

The mobile experience must be part of a coherent whole, not independent.

Tags: Business,  Design,  Design Tips,  Mobile applications,  Mobile web,  Strategy, Permalink | Comments (2)

carnival #181

July 6, 2009 by Steven

Carnival!

The Carnival of the Mobilists is hosted this week by Andrew Grill at London Calling. The Carnival is a weekly collection of the Web’s best writing on mobile and wireless, hosted and collected by a different site each week. If you are already reading our blog, you should add this collection to your subscription list as well.

Especially be sure to check out Barbara’s entry How Many Webs?. As Andrew summarizes it:

Barbara Ballard submitted a really interesting piece [and my post of the week] that promoted her thinking after she saw a Razorfish presentation on the differences between the internet and the mobile web. As Barbara’s post suggests “the mobile experience should be appropriate to the mobile context. It might have fewer, more, or the same features. Let’s just make sure they are the right features whether they are on the desktop or not“. I for one fully agree.
As you can see, it must be worth it since it made post of the week!

Tags: Design, Permalink | Comments (0)

over-apping

July 1, 2009 by Steven

This has been bugging me for a while, but I wasn't sure until today whether it was me: There are too many mobile apps.

I don't mean in raw numbers, cause those are great. And I'm not complaining about pointless apps, and games or gimmicks no one uses after the first day. I mean by choice between a mobile (or mobile-compliant) site and an app, there are too damned many apps. And, again percentage wise, way too damned many iPhone apps.


We've discussed this in some detail, and while I cannot seem to find a place to link to it, we've said it a lot in presentations and training we offer. There are a series of choices when going mobile, and a key one is whether you can live with a website or have to live with an app. Neither is inherently better than the other, and your choice (even if it's "both") will always have a downside.


Today, within the last hour in fact, I saw a TV ad for a new iPhone app from Nationwide Insurance.

It's not a general insurance company app (unlike the USAA mobile site Barbara brings up a lot) but seems to be entirely focused on post-accident activities. (I don't have their insurance, so cannot be sure, but Googling presents only this app). So... who will download this? This strikes me as the perfect thing to make mobile, but also the perfect thing to make a mobile website. Why?

Now, this doesn't mean a one-size fits all solution. A Barbara has dicussed here and elsewhere, you can offer multiple variations of that website. Hell, like I said above you can offer both an app and a site. But don't fall into any one trap to keep up with the Joneses, or because your new toy is really cool, so damn everyone else's.

In this case, it might well need a multi-faceted approach. Me? I'd be likely to add an option to the IVR when you call them that says we can let you do this through your phone, just press 7 and we'll send an SMS to the current number. Push message, click and launch a site without typing. Or, if you insist, install an app (unless you are on Verizon, et. al.). Sure, sure. Websites can't take photos generally, but I am sure if that's needed we can find a way for MMS to work.

Any way, think about your customers, or hire someone else to take a good, long, scientific and fact-based look at your customers, and decide on the right solution for them.

Tags: Design,  Design Tips,  Mobile applications,  Mobile web, Permalink | Comments (2)