In a perfect world with infinite resources, one can create a perfect product. It would be a thing of beauty, with oodles of functional excellence and be dirt cheap. Unfortunately that world does not exist but in the fevered imaginations of dreamers. The rest of us have to live with constraints the real world imposes. We think hard about which audience we create the product for, how will it help solve their problems, what price will they pay, and so on. I have learnt a lot from this post on constraints by Matt Gemmell. Some quotes from that post, which should be read and assimilated in its entirety by the way.
All technology imposes constraints.
There are many factors to consider. Performance and power consumption. Size and weight. Noise and heat. Beauty, durability, and portability. Connectivity and upgradeability. Compatibility and of course cost. At buying time, we presumably consider availability too. They’re all interrelated in various ways, forming a complex web of trade-offs.
What will you optimize for, given the constraints imposed. What is more important to you as a creator. What is important to users you wish to target. But the hard reality is this, Users don’t really get to make a complete choice. The hard choices are already made by the designer.
I remember Steve Jobs mentioning in one of his presentations that users employ product creators to make these decisions on their behalf. It is the job of the designer to choose between constraints judiciously. Not to randomly tack on features because it helps tick off one more check box in the minds of consumers who might not think deeply. Whether multi-tasking is a benefit when considering power management on a mobile device. Whether screen-size accounts for ergonomics of a human holding the device.
Superficial customization, extensibility options provide an illusion of control for the end user but come saddled with unacceptable tradeoffs for some users. For example extensible memory on my Galaxy S2 was seldom used. I preferred syncing over Wi-Fi or even a cable with my PC.
As a concrete example of how engineering decisions impact user experience, see this post by a Google engineer on why Android does not have a Fluid UI experience and might never have one. Here is the money quote:
It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.
That gentlemen is a classic example of a design decision taken on the Android platform. Deep in the bowels of the OS is a decision that ripples up to the UI. Of course am not sure if this was a decision to not optimize for fluid user interface. Or perhaps it was a legacy constraint that Android engineers could not work around.
The point is this, what are you optimizing for. Will you take the hard engineering decisions, that would not be seen or even understood by 99% of your users? Will you ask user’s to trust your judgement or will you take the lazy route and give everything the user asks for?
Apple chooses to optimize for user experience, for tactile responsiveness. Android chooses to optimize, or not, for broadest compatibility across a range of devices. Seen another way, the choices seem to be whether to work well on a single class of devices or work sub-optimally on a range of devices. What the designer chooses says a lot about their priorities. Which platform a customer chooses says a lot about what constraints they are willing to live with in exchange for what services.
Don’t miss reading Matt’s post, it opens up additional perspectives on how one should think when creating anything.
The post Android and iOS – Two Approaches to Managing Constraints appeared first on Mahesh CR.
