It's 2013, I have an iPhone. I check my mail or Twitter feed, see something interesting, click -- and something like this happens:
EMBED: Server_Attention_Span.jpg - click to redirect to http://xkcd.com/869/
I'd say this occurs about a third of the time: The site redirects me to the smartphone version of the site, I lose the link, and I can't get back.
Getting through login credentials is even worse, even on desktop computers with a regular old web browser interface, I think.
What do customers expect our sites to do?
They want them to work. From desktop to mobile and back again, with interoperability -- they just want the sites to work. With the example above, they don't.
And if you are anything like me, that means a lot of phone calls end up at your desk, and either an unfunded, no-time-allotted "bug process fixing" party begins, or else a customer conversion rate fails to meet expectations.
A second example
"Electronic Scrabble Flash" is a game where five real-world tiles light up with random letters. Players rush to assemble words. It's fast, fun, and open to anyone who can read. Maker Hasbro even has an online version where you can try before you buy.
It's fantastic, and would be great to play on an iPad.
Only it doesn't work on the iPad.
The game uses Adobe Flash as a core technology, which is not supported by iOs devices.
Once more, our customers expect the software to just work, and it doesn't.
Fixing the mess
There are a few possible ways to fix this mess.
The first is to develop operating-system level native applications. To do this, the team needs to hire either a developer that can code in iOs, Android, and HTML, or, more likely, several experts.
This will drive up costs, not just for the features themselves, but because it creates three different release pipelines to manage. And if your team is moving toward continuous deployment, the native route introduces an entirely new "quality gate" -- the vendor store -- that may need to investigate and test each new version of your software.
With native versions of the software, we still have the initial problem. Links go to a desktop page, which pops up a window asking if you want the native application, which, most likely, goes to the home page of the native app -- not the content you want.
My preferred fix is to develop a mobile site in HTML5. HTML5 works on iOs, Android, and BlackBerry, and could embed the old link in the referrer, creating a seamless experience.
The challenge is actually doing it. HTML5 developers are few and far between, and the director of application development is likely to argue that the company already paid for a big mobile project -- What? We should do it again?
My advice? It might be wise to start by spending a couple of lunch hours testing these specific interactions to see if the problem exists -- and if it matters. If it does matter, encourage a few staffers to learn the technology at night. Put it on their goal sheets, even if you have no specific project in mind. Look at the technology roadmap for the team and plan future projects to be in HTML5.
That's my suggestion, at least. I'm curious about you.
Have you experienced this problem at your shop? If yes, what are you doing about it?
— Matt Heusser is principal consultant of Excelon Development.
Related posts:
Email This
