My web development background is more in the unsexy database and backend server logic, rather than what you actually see on your cellphone or in your web browser. That needs to change for a couple of projects I have on deck. Now, the web is full of "Getting Started" tutorials for various technologies--and thank goodness for that. But what I call "war stories" are somewhat rarer. War stories bring you back to the real world when you're feeling that chest-thumping "Stand back, good people--I'm a programmer!" sense of invincibility after hacking together a proof-of-concept.
So when I was pointed to Luke Wroblewski's slim (78 page) book, Mobile & Multi-Device Design: Lessons Learned, I snagged it. I was aware that Mr. Wroblewski had already written Mobile First, so I kind of knew what to expect. Even so, some things were not only eye-opening, but almost eye-popping. (The user interface overhaul required to support a user upgrading from iOS6 to iOS7 springs to mind.) If you're not a software designer or developer and you want to understand why mobile app. development is so expensive--your answer's in this book.
And that answer is multi-dimensional, not unlike the real world where such applications have to work.
The first two dimensions that factor into mobile applications (and I include web pages that could be used on a mobile phone in the definition of "mobile applications") are the height and width of the screen. Optimising for a screen the size of a credit card means that your website or app. looks chunky on a tablet...not to mention absolutely ridiculous on a large TV screen. And, unsurprisingly, optimising for a full-size screen leads to something completely useless on a small smartphone. We've all been there, right?
The third dimension has to do with getting input from the user of your mobile app. or web application, regardless of screen size (a.k.a "responsive websites"). And here there be dragons. Unfortunately for programmers (and the people who pay them), there's no reliable way for software to infer all capabilities of the device on which it's installed. Screen size is typically used to make educated guesses, but there are limits. The line between Lilliputian tablets and Brobingnagian cellphones narrows by the nanosecond--or so it seems. And even if the device in question is unquestionably a tablet, it might have a keyboard plugged in (e.g. Microsoft Surface) or it might not. If there is a physical keyboard present, then displaying the on-screen touch keyboard whenever the user taps a data entry field wastes half the screen real estate...and annoys the user.
There's much more to it than just the examples above, of course. But you get the idea.
Last Thursday night, I realised that there might be one more dimension to the question of responsive design. That dimension is the context of time. Last Thursday evening was significant in that my football team, the Green Bay Packers, played their divisional rivals the Minnesota Vikings. Just now I can't justify the expense of the internet-syndicated broadcasts, so I follow the play-by-play on the packers.com website, typically while working on other things.
Here in the Atlantic Time Zone, night games (such as last Thursday's) start at around 9:30pm. Dennis is an early riser, so keeping him awake with the tippity-tapping of my keyboard while bathing the room in the glow of the monitor would have been superlatively rude. Technology to the rescue! A tiny Nexus 7's touchscreen and the fact I can dim it and angle the glow away from Dennis eliminate that problem. (That, plus insomnia, are the reason most of my reading & research are done after bedtime.)
Problem was, whomever the Green Bay Packers hired to redesign their website to adapt to different screen sizes eliminated the widget that shows the score, who has the ball, the down, time remaining in the quarter, etc. when the site is viewed on my little tablet. So I switched over to the NFL's webpage for some of that info. (This being the only game on at the time, it was only slightly less annoying to periodically refresh the screen for updates during the third and fourth quarters.)
That the game status widget would not be front-and-center during game-time really surprised me. Because the statistical likelihood of the user visiting the website during those critical three and a half hours for something other than checking the score is practically nil.
Yes, I realise that there may well be a business decision here, and it does not want to cannibalise revenues from TV or internet streaming. Also, there is a Green Bay Packers app. available for Android. (No, I won't install it--it asked for waaaay too many permissions. You're my football team forever, boys, but you really don't need to know all of those things to show me a score or sell me a cheese-hat, kthxbi.) That being said, the Packers are arguably the most fan-oriented team in the NFL, so even the cynic in me is still surprised.
But for those of us creating applications to be used on small screens, the ruthless priortisation necessary might still have to account for the fact that what brings the user to the site/app. may not be a constant.
Which is most definitely food for thought as I make the mind-shifts necessary to work in four dimensions. Though painting my office door to look like the Tardis would probably be overkill, yes?
