Desiging for Mobility

I recent­ly acquired a Blackberry Pearl. 

It’s a nice lit­tle device that does­n’t absolute­ly scream cor­po­rate whore but lets me car­ry 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 tru­ly 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? Coming right up.) Using it to find stuff on the web dri­ves me half nut­ty. 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­at­ed search results ahead of the store’s actu­al 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­ber­ry web browser.)

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

Even in my plan­ning for the weath­er 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 decid­ed 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 weath­er page because exact­ly how warm/cold it is and how much rain has fall­en are the two bits of infor­ma­tion I most need when I’m not at home.

This morn­ing Peter Merholz at Adaptive path writes about design­ing for mobil­i­ty 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 quick­ly get a key piece of infor­ma­tion, or make a key con­nec­tion. We want key func­tion­al­i­ty 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 Borders we want to find the near­est Borders store.

It’s clar­i­fies what has been both­er­ing me about using the web via Blackberry and why it is that I am try­ing to do with our own weath­er pages isn’t quite work­ing out. I have a sneak­ing feel­ing that I’m about to dis­cov­er 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 box­es on the page.