Coupled vs. Decoupled

Sidestepping the constant bickering about Maps, iOS and the iPhone 5, there has been little said about a larger, ever more looming question that Steve Jobs himself alluded to during the now infamous interview a few short years ago in which he joined long-time rival Bill Gates on stage. As this mobile era grows into its maturity, we should be asking larger, more conceptual questions about the path the industry is taking. Five years ago, Steve Jobs was torturing himself with these same questions.

The big question was, and still is, whether or not a coupled approach of tight hardware and software integration will be successful in the mobile marketplace or if a decoupled approach, the Microsoft approach if you will, of software and hardware being created separately would be the clear winner. Jobs himself was unsure, as the only successful example Apple had is the iPod, and the integrated Macintosh suffered defeat to a successful decoupled approach taken by Microsoft. However, mobile is a whole new (bigger) ballgame.

When Jobs unveiled the iPhone in 2007, he brought up an issue that the PC industry solved decades ago: how do you navigate a bit-mapped graphical user interface? You do it with a mouse.

What the mouse allowed that other input methods didn’t allow was a degree of flexibility in the interface. In a sense, the mouse was the old “multi-touch”. Windows could be resized, icons could be dragged long distances, handles and scroll bars could be placed in almost arbitrary ways and any user trained with using the mouse and the all-flexible cursor could easily control on-screen elements like never before. The beauty of the mouse and cursor was the scalability without a loss of precision thanks to a neat innovation called acceleration. This meant that the interface could shrink down to a 9″ screen or scale up to a 30″ display without the user feeling any pain or loss of precision, and the same app written for the 9″ screen should work just fine on the 30″.

This is where Jobs probably spent a lot of time worrying. Here was Android, an open platform with potentially many vendors making various devices with varying screen sizes. Would the scalability of the mouse-enabled desktop interface carry over to the mobile world? I find it hard to believe it ever will without always being second-rate.

For one thing, fingers and finger gestures are a fixed variable, they’re a much more crude input device . We can only slide our fingers so fast and so far before losing a tremendous amount of precision and gaining a large amount of fatigue in repeated cycles. Also, fingers cover up the exact points of contact we’re dealing with and usually in the exact area where we must see to get the most precision.

Another area of trouble is app quality. Unlike designing software for desktop computers where the dimensions of the devices don’t matter because windows and on-screen elements can scale freely without needing to accommodate the exacting precision of the cursor, touch screen interfaces aren’t so  lucky in this regard. With the finger being as inaccurate as it is and screen real estate being at a premium, great care and control must be used to make sure elements on a mobile device remain usable. What you end up getting are two extremes of design failure in this regard: on larger devices, poorly written apps can waste the available real estate by scaling upwards, and on smaller devices the same apps can become frustratingly unusable because of down-scaling.

There isn’t an algorithm out there that can automatically handle these problems Android devices face. This is a fundamental design concept issue and what you end up getting is a fragmentation of experience, a loss of consistency across various Android devices. Most people in their right minds can’t be bothered to hand-test their app on the dozens of screen sizes let alone hundreds of Android variants in the wild. So you have developers making the sane compromise by creating apps targeted at the mean screen size. With the current screen-size race, this means the newest flagship Android devices never get to show their true capabilities with some apps till they’ve already been replaced twice-over. Furthermore, file size becomes an even bigger issue as  installers of Android apps bloat with various scaled elements to accommodate the various screen sizes and performance brackets.

The coupled or decoupled argument eventually went in favour for Microsoft and its decoupled approach due to the mouse and cursor and the vastly superior flexibility it offered. Add to that the rapid explosion of computing power in the mid 90s to iron out the software wrinkles and you have the  state of traditional desktop computing today.

Regardless, the decoupled approach never made for a better product back then, just a better selling one. And as we expound on these original concepts by squeezing them into smaller form factors, we start to see the stress cracks on a fragmented Android ship.