Desiging for Mobility

I recently acquired a Black­berry Pearl.

It’s a nice lit­tle device that doesn’t absolutely scream cor­po­rate whore but lets me carry around a lot of the essen­tials of my life in my (over­loaded) purse. It also has per­haps the small­est screen in pro­duc­tion on a device capa­ble of truly access­ing the web.

While I love hav­ing access to all the minu­tia of my life in an instant. (Third old­est niece’s mid­dle name? Com­ing right up.) Using it to find stuff on the web dri­ves me half nutty. A sim­ple look-up of store hours or a phone num­ber is a mess for any­thing I don’t already have book-marked. Google’s pre­sen­ta­tion of paid and then “yel­low pages” gen­er­ated search results ahead of the store’s actual site is beyond annoy­ing. (It’s also very dif­fi­cult to dis­tin­guish between the paid and not paid results — at least in the stan­dard black­berry web browser.)

I’ve been think­ing that it’s about the tiny size of the screen.

Even in my plan­ning for the weather infor­ma­tion of our web­site I’ve been focused on the get­ting it all to work in the tiny bit of screen that the Pearl affords. But I had some hints that there was more to the mat­ter than just the form fac­tor. I decided that the left hand list­ing col­umn of sin­gle data points should be moved up in the HTML file so that they would appear first when you get to the main weather page because exactly how warm/cold it is and how much rain has fallen are the two bits of infor­ma­tion I most need when I’m not at home.

This morn­ing Peter Mer­holz at Adap­tive path writes about design­ing for mobil­ity and hits it in one.

His key state­ments are:

“The thing that’s inter­est­ing about design­ing for mobile isn’t the form of the device. It’s that the device comes with you.”

…and…

“We don’t want to explore cyber­space when we’re out-and-about. We want to quickly get a key piece of infor­ma­tion, or make a key con­nec­tion. We want key func­tion­al­ity at our fingertips.”

The dif­fer­ences in the envi­ron­ment in which we are using the device/web dic­tate dif­fer­ences in how we want the web to behave. It’s not about the device. It’s about the task appro­pri­ate for the context.

Even a lap­top with a mon­ster screen used in the Avis park­ing lot of the air­port should dis­play the basic infor­ma­tion such as the “store locater” or “map” nav­i­ga­tion but­tons at the top of the page. Because we don’t want to browse the selec­tion of books at Bor­ders we want to find the near­est Bor­ders store.

It’s clar­i­fies what has been both­er­ing me about using the web via Black­berry and why it is that I am try­ing to do with our own weather pages isn’t quite work­ing out. I have a sneak­ing feel­ing that I’m about to dis­cover that sim­ply rear­rang­ing the HTML (to sort out the load order) and mak­ing a sec­ond CSS file (to address the con­straints of the mobile device form fac­tor) is not going to be enough. Mobile implies a dif­fer­ent set of tasks and infor­ma­tion needs that can’t be addressed by rear­rang­ing the boxes on the page.