UX Strategy Vs. UX Tactics
Juhani Lehtimäki, in his awesome Android UI Patterns blog, has a post up today entitled “Multi-platform Frameworks Destroy Android UX”. In it, he complains about the UX supplied by tools like PhoneGap.
To some extent, I agree with him, insofar as a stock PhoneGap app will not behave quite the same as a native Android app. Mr. Lehtimäki appears to believe that a PhoneGap app would land in the “uncanny valley” where a Web app would not, and I certainly disagree on that point (they’re both in the valley). However, it would be ridiculous of me to claim that the experience of using a PhoneGap app and the experience of using a native Android app are identical.
Tactically, if you are writing a native Android application, you owe it to your users to aim for maximum platform UX fidelity.
Strategically, a “UX über alles” mindset, decrying the use of tools lihe PhoneGap, is simplistic.
In the real world, budgets are not infinite. Talent is not universal. Time is not available on tap, to pour out whatever you need. While maximum platform UX fidelity is an admirable goal, so is accessibility, internationalization to all the world’s languages, a test suite rich enough to take years to run, etc. Choices like PhoneGap vs. a suite of native apps is a strategic choice, and such choices need to take into account all the constraints and all the goals. And at the end of the day, platform UX fidelity may not be deemed that important for a given app.
I suspect that Mr. Lehtimäki is focused on apps distributed via Google Play. In that situation, the strategic value of platform UX fidelity will be relatively high, and therefore may drive people away from PhoneGap. However, Google Play is but one channel. There are other audiences than the general public, and for some audiences and circumstances, platform UX fidelity may not be as critical.
From 2003 through 2009, in a mix of part-time and full-time work, I helped build out the IT capabilities of a friend’s civil engineering firm. My predecessor (a civil engineer by training and a “computer guy” by personal interest) took them from nothing to the Stone Age, relatively speaking. I brought them all the way up to, say, the Bronze Age, in terms of capability.
You might wonder why I didn’t get them all the way to flying cars.
The reason is that they are a civil engineering firm. They do not need flying-car-level IT capabilities, any more than they need gigawatt lasers for surveying. They do not have the budget to support flying cars.
As a result, UX tended to be highly variable. Some software, like AutoCAD and ArcGIS, clearly had some attention paid to UX, though often times it was lost in sea of complexity. On the far other end of the spectrum, they probably still, to this day, use a handful of MS-DOS applications, whose UX is atrocious by modern standards (and weren’t exactly top-notch back when MS-DOS was still relevant as an OS). They moved from an accounting system with lousy UX to a new accounting system with lousy UX. Some portions of their business were organized by means of some simple Excel spreadsheets (with limited UX). I tried to avoid writing much custom software for them, anticipating future maintenance issues, but what I did write did not have UX as top priority.
I imagine that Mr. Lehtimäki might brand me and this whole firm as a bunch of heretics.
Truth be told, all else being equal, they would have been better served with better UX. But that wasn’t among the top criteria — meeting functional requirements and budget constraints were. For example, QuickBooks has better UX than either their old or new accounting packages, but we could not figure out how to get QuickBooks to do what they needed to have done on the billing side, and therefore QuickBooks was not an option, UX notwithstanding.
If this firm were to someday get into custom-writing mobile apps for their field crews, PhoneGap might be a fine solution. Yes, platform UX fidelity would be lower, but platform UX fidelity would be somewhere around “does not increase the generation of belly button lint” in terms of their priorities. It might well be substantially easier for them to support a mixed bag of device platforms via PhoneGap than to develop and maintain 2-3 native apps, depending upon whether those apps were within PhoneGap’s capabilities.
Even firms that create off-the-shelf software for civil engineers might tend towards PhoneGap, if they can deliver the desired functionality for lower development costs and if they believe that they will be able to compete effectively despite the lower platform UX fidelity. Competition may be sufficient to drive them to native apps, just as competition on Google Play is what presumably drives Mr. Lehtimäki to rail against PhoneGap. But, again, this is a strategic decision, and there are many more factors in play than just platform UX fidelity.
In the fullness of time, the amount of development work for Google Play apps will be dwarfed — by an order of magnitude — by the amount of development work for more focused audiences, such as employees of a business. After all, that’s how software is outside of mobile, and it seems unlikely that the Android ecosystem will somehow fail to match it.
It is important for those deciding between PhoneGap, other cross-platform solutions, or a basket of native apps, to understand the platform UX fidelity issue. At the same time, it is simplistic to claim that “targeting multiple platforms with one app does not work”, merely when it is a sub-optimal choice for platform UX fidelity. Everybody — developers, managers, and those of us giving advice to them — needs to go into these decisions with eyes wide open.
In a perfect world, we could write cross-platform apps with perfect platform UX fidelity. As I have pointed out on many occasions, in a perfect world, I would have hair. As I am presently as balding as ever, I surmise that this is not a perfect world, and therefore platform UX fidelity has to slug it out with all the other admirable goals in software development.
