Summit 7 Team Blogs

Mobile version = mobile app? Appsolutely not

Or, rather, to paraphrase the 42nd President of the United States, the answer is it depends on what your definition of “app” is.

Across the board, the number of users accessing the KCTCS sites via mobile devices has more than doubled year-on-year. In several cases the increase has been even more dramatic. More than a third of these visitors are using an iPhone or iPad; a little under a third are using an Android device; and the rest use Windows phones, Blackberries, and any number of more-or-less weird or wonderful alternatives. Far from coalescing around a single platform, we are seeing diversification, albeit with Apple/Android dominance. Vastly outnumbered last year, Android visitors have increased ten-fold to near parity with Apple, while Windows phones moved from the realm of statistical non-existence to a “look at me! Look at me!” babble of statistical noise.

So how many apps do we need? One for iPhone, surely. One for Android too. And one for Windows. Three. But what about Blackberry? Oh, and the Kindle Fire mom would like that. Five? Ten? Not all Androids are Apple-killing supermachines. What about something for the two-year-old vintage models? Last week, one person visited our highest traffic site using something called a Sunburst. He/she stayed for six minutes and viewed 10 pages. Man, a Sunburst app would have made life so much easier…

When you dig into your Google Analytics you might find something entirely different. Perhaps the vast majority of your visitors are using just a couple of specific operating systems. In these circumstances, why not create beautiful, optimized apps for those users?

But we’re going with no apps, and here’s why.

Part of the answer is our diverse, multi-platform visitor base. But the other reason is that an app is conceptually the wrong approach, I would argue, to displaying web content.

I understand an app – mobile or otherwise – to be a piece of software that performs or allows the user to perform specific tasks. The Internets agree! The “perform specific tasks” part is important.

If the task we want to perform is the virtual inflation of a balloon using the microphone as an air valve, a custom mobile app is a great option.

If the task we want to perform is the carpet bombing of pigs by suicidal birds using a multi-touch input, a custom mobile app is also appropriate.

But if our goal is to display web content and provide an interface to server-based functionality (such as search), there is already an app for that. It’s called a web browser.

Now, there are strong arguments for creating mobile apps, even if the content you are serving is essentially web content. All things being equal, device-specific apps have the potential to be far more beautiful things, designed with the specific capabilities (and limitations) of the platform in mind. Native iPhone apps necessarily have a level of user interface integration lacking in generic “mobile” designs.

Unfortunately, it would take from now until the end of time to create pixel-perfect, device-specific applications. There are obviously ways to create more fluid designs that scale and degrade appropriately for each of the hundreds of different screen resolutions we detected last month. (Screen resolution is not the only variable, of course, and as we get into the design phase of this project I’ll discuss some of the challenges in more detail.) But we can expand this principle of cross-device adaptability, and look instead for cross-platform compatibility.

Our iPhone app will be our Android App will be our Blackberry app. Our mobile view will be our mobile app. The principle is that we will manage content in one place – Sitecore CMS – and, through the magic of CSS, and a little Jason code, we (Amy, Jason, and I) will serve up an optimized mobile browsing experience without fanfare, without app downloads, and without a vast app development infrastructure. Stay tuned to see how we do.