With a not-uncommon sense of despair, I recently read an article on a hack for jailbroken iPads, allowing desktop-like layered window management.
The hack is called Quasar, and was created by Pedro Franceschi. It’s unquestionably an impressive technical achievement, and on those grounds he’s to be congratulated.
Quasar looks like this:
Self-evidently, it brings desktop-style, manual layered window management to (jailbroken versions of) iOS. Hopefully just as self-evidently, that’s a terrible idea.
On simultaneous multi-tasking
The comments on the linked article are positive overall, indicating that (amongst the tech-savvy, early adopter sort of audience that The Verge attracts), there’s a desire for some form of simultaneous multi-tasking support on iOS (that is, to have more than one app visible at the same time, in some form).
So far, fair enough. Many of us have felt some friction at iOS’ resolutely “one at a time” app interaction model. When writing, for example, we’ll commonly want to refer to another document or to the web. Some writing tools embed reference facilities or mini-browsers for that purpose, but such functionality also acknowledges that there’s an unfulfilled need – at least for some percentage of users.
Quasar, in common with many hacks and engineer-generated solutions to user problems, addresses the deficiency in precisely the wrong way.
An alternate, considered solution to the issue is Windows Snap, also available with the Metro interface on upcoming Windows 8 RT tablet devices. Snap allows a second app to be shown in a narrow (320 pixels wide) bar on one side of the screen.
This isn’t an arbitrary, forced construct. Snapped status is a defined, discrete application state on Windows, with notifications when the app enters or exits that state, and relevant UX guidelines to suit the situation.
Snap is only one possible implementation, but it’s a judicious, sensible, pragmatic solution.
Experiences should be designed
The core problem with the Quasar model is that it’s not designed for the needs of the device or its users. It’s the desktop windowing model, designed (or perhaps more truthfully, evolved for better or worse) for lean-forward, stationary, pointer-driven, large-screened and comparatively high-performance devices. Everything that, relatively speaking, a tablet is not.
Unconsidered design (or lack of design) tends to simply gravitate towards the familiar, which is a natural instinct when we’re lost in some way. The desktop windowing metaphor is familiar from older computing devices… and that’s all. Its suitability to the iPad’s form factor, usage scenarios, and current app interaction models was not considered. It introduces additional frames of interaction and cognitive load, and disregards the interaction heritage and environment of the platform.
Quasar was not designed, but rather only implemented. It’s the classic outcome of closed, engineer-based thinking.
Experiences should be designed. If your interface will be used by humans, you need to design it for humans. Familiarity may well be a factor to consider in that design, but it’s by no means the only one – and it’s almost always trumped by context.
With touch-screen mobile devices particularly, context is key. Not just the physical context (Am I moving? Sitting down? Do I have only one hand free because I’m holding the device?), but also the interaction context (Am I in a hurry? Am I likely to be at leisure to browse or read? What’s my goal?) and the user’s mental model of what’s going on.
Falling back on what’s familiar from some unrelated context, regardless of its suitability to the current situation, is user-hostile and antisocial. It’s a demo or an academically curious proof-of-concept (which I readily acknowledge that Quasar is), rather than anything we’d call a solution.
“Because I can” isn’t a design, and nor is “it’s familiar”. Assessment of context and suitability is always required.
Design for humans
Quasar is a clever demo, and its unsuitability for the iPad can’t do much practical damage because it’s only for jailbroken devices – a tiny niche of tech-savvy tinkerers that will be forever unknown to the vast majority of people.
But knee-jerk design decisions are worryingly commonplace, and pose substantially more risk to software users. Familiarity is only one factor, and it’s often a deceptive one. Consider the entire scenario and context, and take the time to truly design your user’s experience.