The Tyranny Of Big Displays And Perfect Networks "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 8 August 2013 True Device proliferation, Mobile, Ux, Mind the Product Mind the Product Ltd 874 Product Management 3.496

The Tyranny Of Big Displays And Perfect Networks


Device landscapeWe’ve all been there – swearing at our phones when our pithy Instagram pics won’t upload, cursing the data roaming charge as Dropbox decides to sync when we’re on holiday, cussing when the ‘next’ button is off the edge of the screen and we can’t get to it.

It seems more and more sites, mobile apps and even operating systems fail some of these most basic conditions. Users’ screens aren’t always 27″ behemoths (or retina beauties). Users aren’t always on WiFi or even a solid 4G connection. Sometimes GPRS (a measly 114 Kbps down and 20Kbps up) is as good as it gets and even then only at one lousy, intermittent, bar.

I really don’t need iCloud backups to run when I’m paying $24/MB

Recent personal frustrations include iOS which takes dozens of clicks to configure when traveling to ensure only the data I really want (those ever important check-ins, Instagram updates and Twitter statuses) is what gets used when I’m roaming. I really don’t need iCloud backups to run when I’m paying $24/MB thanks.

Even Instagram, which I normally laud for the way it’s designed for mobile (for example its starts uploading the photo while you’re entering the metadata so it seems like the photo uploader is really fast), gets this wrong. When you’re on a crappy connection failed uploads can crash the app and even if they don’t you have to restart the upload from scratch. Come on, even the most basic FTP program can resume an aborted upload these days. Don’t believe me? Next time you’re in the middle of an FTP upload yank out your ethernet cable (or turn off your WiFi) – your FTP program won’t even skip a beat once you reconnect and will calmly continue right where it left off.

Even on desktops this goes awry. Photoshop, for example, can’t handle small screens. On my 1366×768 MacBook Air 11″ the Save button on some dialogs is off the screen. And trust me, there is nothing more frustrating than not being able to save your work.

In the nineties we cared deeply about these things. We had colour calibrated monitors (a leftover from the print design days), but still knew that wasn’t the experience our users were getting. We used the web safe palette in the knowledge that it would be consistent on most browsers and computers. And we tested our websites on as many computers and monitors as possible before releasing anything.

Android Screen Sizes
Android Screen Sizes

What’s changed? Is it the proliferation of screens and devices? I know I use computers with resolutions varying from 1366×768 to 2560×1440, as well as two different iPhones, a handful of tablets and occasionally a computer hooked up to my TV.

And on mobile the story gets worse. There are around seven major mobile operating systems, with dozens and dozens of versions with varying capabilities to take into account. Screen sizes on mobile devices vary even more widely with hundreds of viewports ranging in size from 234 to 1080 pixels wide.

That’s no excuse though – it just makes our jobs harder. I know, I know, they’re hard enough already, but it’s about the users remember?

Test, test, test and then test some more.

Lessons for Product People:

  1. Test, test, test and then test some more. If you don’t have a plethora of devices yourself, your colleagues and friends do. And don’t just check the homepage – go through your key user flows to make sure everything works and is usable and as clear as it can be. And then test some more.
  2. Responsive design isn’t a silver bullet. In the right context it’s a great solution, but don’t just make something responsive and assume it will now work everywhere.
  3. You know that corner of your office where you can’t get any reception? Where you go to avoid calls from Mom? THAT’s where you test your mobile app. Make sure key interactions work, that updates don’t take forever or use up more data than necessary, and that uploads/downloads don’t fall over and crash the app.
  4. Take a trip abroad every once in a while. See what happens when you’re roaming and counting every KB used. Maybe background updates the user didn’t request aren’t so great anymore.
  5. Think about context. Do your users always want updates to run automatically in the background? Should your app act differently between WiFi and 3G/4G? Should it act differently when roaming?
  6. Understand your users. Yes we all hate IE6, but if the 0.5% of your users on IE6 are in fact 30% of your paying customers, you still have to support it. The same goes for devices, operating systems and screen sizes.
  7. Plan for the worst case scenario. How does your app behave when the data connection is spotty or non-existent? Fail gracefully, give the option to resume uploading when the connection improves or maybe even have a backup method that’s more stable and does that upload packet by packet to ensure it gets through. Consider a message bus or queue to mitigate an intermittent connection.

These are really high-level and hopefully just seem like common sense. How do you ensure your product works in every context? Share your lessons in the comments.

Comments 2

Nice article. Really great points.

On the topic of “responsive is a nice solution” I would like to add that it can be a great solution but it can also be bloody terrible! Unfortunately too many front enders and product managers see responsive as being just using the css tool ‘@media’ queries. On its own this can make things look right – but not actually deliver the user experience the product manager probably intended.

Because of the mis-use of the phrase responsive, I prefer either Responsive 2.0 or Adaptive. In an adaptive solution the common scenario of downloading graphics to the device and then hiding them is avoided, or downloading huge retinia size images and then resizing them to very small should be avoided.

Futhermore the Javascript techniques employed on desktop may expect more CPU and memory power than the a smartphone or tablet provides. The heavy use of Jquery is acceptable on desktop, specially when there is a plenty of memory for caching a typically a good web connection to download over. But on mobile I have seen live products reduce their download time by switching to a smaller library such as Zepto.js. In real world live examples cutting a 100k of download time can result in increased conversions equaling more money!

Sites that embrace Ajax need extra testing too – the Native Android browser runs less synchronous threads that Safari on iPhone. Fewer threads is actually better for a slow 3G connect, but less efficient on a good WiFi. Each round http trip has a significant impact so does multiple domains (eg different CDNs etc). Unlike a desktop the DNS is not typically cached between sessions, so the DNS is going to get resolved every session. Ideally make use of sprites and minimize JS and put all CSS in one file.

Google recommend a page load time of 1 second on mobile. The far too common standard ‘responsive with just @media’ will typically struggle to get anywhere near the 1 second target, for many of the above reasons. It takes a lot more effort to achieve high performance on mobile that just swapping CSS.

I can not agree more with test and test again – I would go further I would start that UX test from Google if possible! I would also consider what happens when connectivity is lost for periods of times, eg on a train. When connectivity returns is the user experience seamless? There are thousands of mobile devices so make sure to test on an old android (2.2), a new android (Jelly Bean) as well as iOS. Testing older versions of iOS is less critical on iPhone as updates are very quickly installed, but critical on android. Make sure to check out what happens on a retina display and standard resolution as well as large and small screens. And dont forget loads of people like landscape and loads of people like portrait! Then make sure to remember Safari and Chrome needs testing on iOS while on Android you need to test the native Android browser (default in 2.2, 2.3) and Chrome on v4+. (Default from Jelly Bean). Chrome is NOT available for Android 2.2/2.3 and at least 50% of the Android devices run these versions.

I spoke at a ProductTank event a while back, incase you missed it here are the slides.

Join the community

Sign up for free to share your thoughts