The Tyranny of the Minimum Viable User
In addressing shortcomings of a major web browser recently, I tossed out a neologism for a neogolistic age: Minimum viable user.
This describes the lowest-skilled user a product might feasibly accommodate, or if you're business-minded, profitably accommodate. The hazard being that such an MVU then drags down the experience for others, and in particular expert or experienced users. More to follow.
There are cases where reasonable accommodations should be considered, absolutely. Though how this ought be done is also critical. And arbitrary exclusions for nonfunctional reasons — the term for that is "discrimination", should you ask — are right out.
Accessibility accommodations, in physical space and informational systems, is a key concern. I don't generally require these myself, but know many people who do, and have come to appreciate their concerns. I've also come to see both the increased imposition, and benefits, this offers by way of accommodating the needs.
It's often underappreciated how increased accessibility helps many, often all, users of a product or space. A classic instance would be pavement (or sidewalk) kerb cuts — bringing the edge of a walkway to street level, rather than leaving a 10 cm ridge. This accommodates not just wheelchairs, but dollies, carts, wheeled luggage, and more. Benefits which materialised only after deployment, beyond the original intent.
Accessibility and Information Systems
For information systems — say, webpages — the accommodations which are most useful for perceptually-challenged users are also almost always beneficial to others: clear, high-contrast layouts. Lack of distracting screen elements. A highly semantic structure makes work easier for both screen-readers (text-to-speech) and automated parsing or classification of content. Clear typography doesn't fix all copy, but it makes bad copy all the more apparent. Again, positive externalities.
When we get to the point of process-oriented systems, the picture blurs. The fundamental problem is that an interface which doesn't match the complexity of the underlying task is always going to be unsatisfactory. Larry Wall has observed this with regard to the Perl programming language: complexity will out. In landscape design, the problem is evidenced by the term "desire path". A disagreement between use and design.
At its heart, a desire path is the failure for designer to correctly anticipate, or facilitate, the needs and desires of their users. Such paths reflect emergent practices or patterns, some constructive, some challenging the integrity of a system. Mastodon Tootstorms are an example of a positive creative accommodation. Mostly.
On other services, the lack of an ability to otherwise dismiss content frequently creates an overload of the spam or abuse reporting mechanism. G+ comes to mind. If a side-effect of reporting content is that it is removed from my view, and there is no other way to accomplish that goal, then the reporting feature becomes the "remove from visibility" function. I've … had that conversation with Google for a number of years. Or is that a monologue…
Software programming is in many ways a story of side-effects and desire paths, as is the art of crafting system exploits. PHP seems particularly prone to this, though I can't find the character-generating hack I've in mind.
There's the question of when a system should or shouldn't be particularly complex. Light switches and water taps are a case in point. The first has operated as a simple binary, the second as a variable-rate flow control, and the basic functionality has remained essentially unchanged for a century or more. Until the Internet of Broken Shit that Spies on you wizkids got ahold of them…. And modulo some simple management interfaces: timers or centralised large-building controls.
Simple tasks benefit from simple controls.
Complex tasks … also benefit from simple controls, but no simpler than the task at hand.
A good chef, for example, needs only a modicum of basic elements. A good knife. A reliable cooktop and oven. A sink. A cutting surface. Mixing bowls. Underappreciated: measuring equipment. Measuring spoons, cups, pitchers. A scale. Thermometer. Timers. The chef also may have call for some specific processing equipment: cutting, chopping, blending, grating, and mixing tools. Powering these increases throughput, but the essential controls remain simple. And some specialised tools, say, a frosting tube, but which generally share common characteristics: they're individually simple, do one thing, usually a basic transformation, and do it well.
The complexity of the process is in the chef, training, and practice.
The antithesis of this is "cooking gadgets" — tools or appliances which are complicated, fussy, achieve a single and non-general result, or which integrate (or attempt to do so) a full process. This is the stuff that clutters counter space and drawers: useless kitchen gadgets. A category so egregious it defies even simple listing, though you're welcome to dig through search results.
Appropriateness of Single-use Tools: Safety equipment
On single-use tools: if that single use is saving your life in conditions of readily forseeable peril, then it may well be worth having. Lifeboats. Seatbelts. First aid kit.
That gets down to a risk assessment and mitigation calculation problem though, which may be error-prone: over- and under-estimating risks, and/or the efficacy of mitigations. Pricing risk and risk-as-economic good is another long topic.
Lifts, Telephones, and Automobiles
There are times when you absolutely should be aiming for the minimum viable user. Anything that sees widespread shared public use, for example. I shouldn't have to read the user manual to figure out how to open the front door to your building. Automatic, sensored doors, would be an entirely MVU product.
I've mentioned lifts, automobiles, and telephones. Each is highly complex conceptually, two can maim or kill. All can be relatively safely used by most adults, even children. A large part of what makes lifts, automobiles, and telephones so generally usable is that the controls are very highly standardised. Mostly. The exceptions become newsworthy.
Telephones have deviated from this with expansion of mobile and even more complex landline devices. And the specific case of business-oriented office telephones has been for at least 30 years, a strong counterexample, worth considering.
Office Phone Systems
It takes me a year or more to figure out a new office phone system. If ever. A constant for 30 years. This wasn't the case as of the 1980s, when a standard POTS-based phone might have five buttons, and the smarts were in a PBX generally located within the building.
By the 1990s, though, "smart phones" were starting to appear. Rolm was one early vendor I recall. These had an increasing mix of features, not standardised either across or within vendor lines, but generally some mix of:
- Call forwarding
- Call conferencing
- Lots of other random shit to inflate marketing brochures
Feature #4 was a major problem, but the underlying one was, and remains, I think, the mismatch of comms channels and cognitive capacities a phone represents: audio, physical, textual, and short-term working memory.
The physical interface of most phones — and I'm referring to desk sets here — is highly constrained. There's a keypad, generally 12 buttons (not even enough for the impoverished Roman alphabet, let alone more robust ones), possibly an additional set of function buttons, and a handset, plus some base. Cords.
More advanced phonesets have perfected the technology of including a display for text which is simultaneously unreadable under any lighting conditions, viewing angles, or capable of providing useful information in any regard. This another engineering accomplishment with a decades-long record.
Phones are relatively good for talking, but they are miserable for communication. Reflected by millennials disdain for making phone calls Millennials prefer text-based apps to voice comms, as do numerous tech early-adopters. I suspect the reason is both the state-maintenance and fragility of phone-based communications.
I'm distinguishing talking — a longer and wandering conversation with a friend — and communicating — the attempt to convey or obtain some specific task-oriented or process-oriented information. The salient difference is that the latter is very strongly goal oriented, the former, not so much. That is, a "simple" phone conversation is a complex interaction and translation between visual, textual, audio, physical, and memory systems. It's also conducted without the visual cues of face-to-face communications (as are all remote comms), for further fun and games. This usually makes conversations with someone you know well (for whom you can impute those cues) generally far more straightforward than with a stranger, especially for complex discussions.
The upshot is that while a telephone is reasonably simple to use in the basic case — establish a voice connection with another device generally associated with a person or business — it actually fails fairly profoundly in the surrounding task context for numerous reasons. Many of which boil down to an interface which is simultaneously oversimplified and poorly suited to the task at hand.
Smartphones, and software-based telephony systems in general, followed the business phone lead.
Mobile comms generally have expanded on failures of business phone systems in poor usability as phones by significantly deteriorating audio quality and dynamics — constraints of packet-switching, compression, additional relay hops, and speed-of-light delays have boosted noise and lag to the level of interfering with the general flow of conversation. Which isn't particularly an interface failure as such (this is channel behaviour), but it encourages the shift to text of millennials.
I'll save the question of how to fix voice comms for discussion.
The point I'm making is that even an apparently straightforward device and task, with a long engineering history, can find itself ill-matched to new circumstances.
There's also much path-dependence here. Lauren Weinstein on G+ enjoys digging up old AT&T engineering and marketing and/or propaganda newsreels describing development of the phone system: direct-dial, switching, 7-digit, area-code, long-distance, touch-tone. There were real and legitimate design, engineering, and use considerations put into each of these. It's not as if the systems were haphazardly put together. This still doesn't avoid the net result being a bit of a hash.
An appreciation of why Mr. Chesterton built his fence , and whether or not that rationale remains valid, is useful to keep in mind. As are path-dependencies, 2nd-system effects, and late-adopter advantages. Those building out interdependent networks after initial trial often have a significant advantage.
It's also interesting to consider what the operating environment of earlier phones was — because it exceeded the device itself.
A business-use phone of, say, the 1970s, existed in a loosely-integrated environment comprising:
- The user
- The phone itself
- A Rolodex
- The local PBX — the business's dedicated internal phone switch.
- A secretary or switchboard operator, serving also as a message-taking (voice-to-text), screening, redirect, directory, interactive voice response, and/or calendaring service
- A desk calendar
- A phone book
- A diary or organiser
- Scratch paper
Critically: these components operated simultaneously and independently of the phone.
A modern business, software, or smartphone system may offer some, or even all, of these functions, but frequently:
- They aren't available whilst a call is in process
- They have vastly less capability or flexibility than the systems they replaced
The benefits are that they are generally cheaper, smaller, more portable, and create digital data which may be, if accessible to other tools, more flexible.
But enough of phones.
The Unix Philosophy
The Unix Philsophy reads: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
It offers a tremendous amount of mileage.
Exceptions to the Unix Philosophy: Complexity Hubs
I want to talk about the apparent exceptions to the Unix philosophy: shells, editors, email, init (and especially systemd), remote filesystems, udev, firewall rules, security generally, programming languages, GUIs.
Apparently, "exceptions to the Unix philosophy" is very nearly another neologism — I find a single result in Google, to an essay by Michael O. Church. He adds two more items: IDEs (integrated developer environments), arguably an outgrowth of editors, and databases. Both are solid calls, and both tie directly into the theme I had in mind in the preceding toot.
These are all complexity hubs — they are loci of either control or interfacing between and among other systems or complex domains:
Shells, editors, IDEs, and programming languages are all interfaces through which a skilled user interacts with a highly complex system. Whilst remaining in the context of text, this is a space in which new capabilities are themselves created or synthesised.
Databases … try to make sense of the world, under constraints of scale, consistency, performance, reliability, stability, integrity, and durability.
Email faces a vast array of complexities: standards, remote systems and operators, file formats, spam, security, identity, DNS, filtering. And that's just on the technical side.
Within the communications context there are composing standards, workflows, language, characterset, prioritisation, archival, deletion, and more.
Email is, in a word, a hairball. It wants an Alexander.
To a rough approximation, remote filesystems combine many of the technical complexities of both databases and email: sorting out who and what to access, via what standards, in a distributed context. None of the widely-used technologies is particularly satisfactory, and none of the satisfactory systems are widely used.
Linux's udev is at its essence the problem of remote filesystems made local — the idea that devices directly attached (or made to appear to be directly attached) to a system might go walkabout or show up unexpectedly for dinner.
It is "responsible for providing an abstract interface of the hardware", which tells us what we need to know: When "abstraction" appears in docs, it's a warning that Here Be Dragons.
Simplicity doesn't need abstraction.
Firewall rules and security generally are attempted as defences against the unexpected. Worse, they're very frequently contingent defences, which is to say, when you need a defence, you need it now. As in military contexts, your basic tools are limited: speed and agility, if you can get out of the way, shielding or armour, if you cannot, countermeasures, if possible. Given a comms context, rules of epidemiology also apply: guard your portals, or ports, with effective friend-or-foe.
Since attacks, particularly effective ones, are frequently unexpected, security is inherently a choatic space, and reflects it. It is highly resistant to attempts at organisation, though the focus on mechanisms, above, may help.
The GUI Mess
This leaves us with GUIs, or more generally, the concept of the domain of graphics.
The complexity here is that graphics are not text. Or at the very least, transcend text. It is possible to use text to describe graphics, and there are tools which do this: Turtle. Some CAD systems. Scalable vector graphics (SVG). But to get philosophical: the description is not the thing. The end result is visual, and whilst it might be rule-derived, it transcends the rule itself.
One argument is that when you leave the domain of text, you leave the Unix philosophy behind. I think I'm OK with that as a starting premise. This means that visual, audio, mechanical, and other sensory outputs are fundamentally different from text, and that we need to keep in mind that text, whilst powerful, has its limits.
It's also to keep in mind, though, what the characteristics and limits of GUIs themselves are.
Neal Stephenson, "In the Beginning was the Command Line", again, offers one such: Metaphor sheer. Most especially where a GUI is used to represent computer system elements themselves, it's crucial to realise that the representation is not the thing itself — map-territory confusion. In fact a GUI isn't so much a representation as a remapping of computer state.
Unix, the C programming language, and the bash shell all remain relatively close to machine state. In many cases, the basic Unix commands are wrappers around either C language structures (e.g.,
printf(3)), or report the content of basic data structures (e.g.,
stat(2)). Even where the concept is reshaped significantly, you can still generally find the underlying concept present. This may be more foreign for newbies, but as exposure to the system is gained, interface knowledge leverages to system knowledge.
GUIs lose this: represented state has little coherence.
Some argue that not being tied to the mechanism is an advantage — that this allows the interface designer a freedom to explore expressions independent of the underlying mechanism.
This is true.
But it gets to another set of limitations of GUIs:
- There is a limit to how much information can be represented graphically, imposed by display, resolution, dot pitch, scrolling, seeking, and time.
- Users hate change.
- GUI efficiency is intrinsically limited.
- GUI doesn't script. Not easily. And most definitely not within the metaphor of basic GUI use, which is how CLI scripts.
Scripting has the effect of constraining, for better or worse, changes to interfaces because scripts have to be updated as features change. The consequence is that tools either don't change arguments, change them with exceedingly long advance warning, or failing either of those, are rapidly discarded by those who use them due to gratuitous interface changes. The result is a strong, occasionally stifling, consistency over time.
The limits on information density and on scaling or scrolling are another factor. A good GUI might offer the ability to expand or compress a view by a few times, but it takes a very creative approach to convey the orders of magnitude scales which, say, a physical library does. Data visualisation is its own specialty, and some are good at it.
The result is that most GUI interfaces are good for a dozen, perhaps a few dozens, objects.
xkcd is on the money.
Change aversion and inherent limits to GUI productivity interact to create the final conflict for GUIs: the potential for interface efficiency is limited and change is disruptive, you lose for trying. Jamie "jwz" Zawinski notes this:
Look, in the case of all other software, I believe strongly in "release early, release often". Hell, I damned near invented it. But I think history has proven that UI is different than software.
What jwz doesn't do is explain why this is, and I'm not aware of others who have.
This also shows up in the case of Apple, a company which puts a premium on design and UI, but which is exceedingly conservative in changing UI. The original Mac desktop stuck with its initial motif from 1984 until 2001: 17 years. It successor has changed only incrementally from 2001 to 2017, very nearly as long. Even Apple realise: you don't fuck with the GUI.
This suggests an underlying failure of the Linux desktop effort isn't a failure to innovate, but rather far too much churn in the desktop.
My daily driver for 20 years has been Window Maker, itself a reimplementation of the 1989 NeXT desktop. Which is to say that a 30 year-old design works admirably. It's fast, stable, doesn't change unexpectedly with new releases or updates, and gets the fuck out of the way. It has a few customisations which tend to focus on function rather than form.
The Minimum Viable User GUI and Its Costs
Back to my starting premise: let's assume, with good reason, that the Minimum Viable User wants and needs a simple, largely pushbutton, heavily GUI, systems interface.
What does this cost us?
The answer is in the list of Unix Philosophy Violating Tasks:
- Dealing with scale
- Dealing with complexity
- Iteratively building out tools and systems
- Rapid response
- Adapting to changing circumstance
- Considered thought
- Scalability of understanding, comprehension, or control
- Integrating numerous other systems
- Especially nonuniform ones
Just Who is the Minimum Viable User?
A central question, and somewhat inexcusably buried here, is who is the Minimum Viable User? This could be the lowest level of system skills capable of using a device, which an OECD survey finds is abysmally bad. Over half the population, and over 2/3 in most surveyed industrialised countries, have poor, "below poor", or no computer skills at all.
I'm moving past this point quickly, but recommend very strongly reading Jacob Nielsen's commentary on this study, and the study itself: "Skills Matter: Further Results from the Survey of Adult Skills" (OECD, 2016). The state of typical user skills is exceedingly poor. If you're reading this essay, you're quite likely not among them, though if you are, the comment is simply meant as a statement of fact: from high to low, the range of user computer skills is enormous, with the low end of the range very highly represented in the general population. People who, largely, otherwise function quite well in society: they have jobs, responsibilities, families.
This has profound implications for futures premised on any sort of general technical literacy. As William Ophuls writes in Plato's Revenge, social systems based on the premise that all the children are above average are doomed to failure.
The main thrust of this essay though is a different concern. Global information systems which are premised on a minimal-or-worse level of sophistication by all users also bodes poorly, though for different reasons: it hampers the capabilities of that small fraction — 5-8% or less, and yes, quite probably far less — of the population who can make highly productive use of such tools, by producing hardware and software which fails to support advanced usage.
It does this by two general modes:
It simply lacks the necessary features. I could point to the entirely crippled commandline userland of a typical Android device.
It actively prevents advanced users from making full use of their devices by restricting access and enhancement. This might be seen as a patronsing or Big Brotherish move by vendors, and there's certainly concern over this. But it's also a realistic response to the security and threat landscape of mobile devices operate in, given typical user skill levels. A fact hammered home by the fact that skilled users frequently fail to manage their systems securely.
The dynamics are also driven by market and business considerations — where the money is, and how development, shipping, and maintaining devices relates to cash flows.
The Problem-Problem Problem
One business response is to extend the MVU definition to that of the Minimum Viable-Revenue User: services are targeted at those with the discretionary income, or lack of alternatives, to prove attractive to vendors.
There's been well-founded criticism of Silicon Valley startups which have lost track of what a meaningful problem in need of solution. It's a problem problem. Or: The problem-problem problem.
Solving Minor Irritations of Rich People, or better, inventing MIoRP, as a bootstrapping method, has some arguable utility. Telsa Motors created a fun, but Very ExpensiveTM, electrified Lotus on its way to creating a viable, practical, battery-powered, Everyman vehicle. Elon Musk is a man who has made me a liar multiple times, by doing what I unequivocally stated was impossible, and he impresses the hell out of me for it.
Amazon reinvented Sears, Roebuck, & Co. for the 21st^ century bootstrapped off a books-by-mail business.
I'm not saying there ain't a there there. But I'm extremely unconvinced that all the there there that's claimed to be there is really there.
Swapping out the phone or fax in a laundry, food-delivery, dog-walking, or house-cleaning business is not, in the larger scheme of things, particularly disruptive. It's often not even a particularly good business when catering to the Rich and Foolish. Not that parting same from their easily-won dollars isn't perhaps a laudable venture.
The other slant of the Minimum Viable User is the one who is pushed so far up against the wall, or fenced in and the competition fenced out, that they've no option but to use your service. Until such time as you decide to drag them off the plane. Captive-market vendor-customer relationship dynamics are typically poor.
For numerous reasons, the design considerations which go into such tools are also rarely generative. Oh: Advertising is one of those domains. Remember: Advertising breeds contempt.
Each of these MVU business cases argues against designing for the generative user. A rather common failing of market-based capitalism.
Robert Nozick explains criticism of same by creatives by the fact that "by and large, a capitalist society does not honor its intellectuals". A curious argument whose counterpoint is "capitalism is favoured by those whom it does unduly reward".
Pointing this out is useful on a number of counts. It provides a ready response to the Bullshit Argument that "the market decides". Because what becomes clear is that market forces alone are not going to do much to encourage generative-use designs. Particularly not in a world of zero-marginal-cost products. That is: products whose marginal costs are small (and hence: pricing leverage), but with high fixed costs. And that means that the market is going to deliver a bunch of shitty tools.
Getting from Zero to One for Generative Mobile Platforms
Which suggests one of a few possible avenues out of the dilemma: a large set of generative tools have been built through non-capitalistic organisation. The Free Software _ Open Source world would be a prime case in point, but it's hardly the first. Scientific research and collaboration, assembly of reference tools, dictionaries, encyclopedias. That's an option.
Though they need some sort of base around which to form and organise. And in the case of software they need hardware.
For all the evil Bill Gates unleashed upon the tech world (a fair bit of it related to the MVU and MFVU concepts themselves), he also unleashed a world of i386 chipset systems on which other software systems could be developed. Saw to it that he individually and specifically profited from every one sold, mind. But he wasn't able to restrict what ran on those boxes post-delivery.
GNU/Linux may well have needed Bill Gates. (And Gates may well have not been able to avoided creating Linux.)
There are more smartphones and Android devices today than there ever were PCs, but one area of technical advance over the decades has been in locking systems down. Hard. And, well, that's a problem.
I don't think it's the only one, though.
Commodity x86 hardware had a model for the operating system capable of utilising it which already existed: Unix. Linus Torvalds may have created Linux, but he didn't design it as such. That template had been cut already. It was a one-to-two problem, a question of scaling out. Which is to say it wasn't a Zero to One problem.
And yes, Peter Thiel is an evil asshat, which is why I'm pointing you specifically at where to steal his book. That's not to say he isn't an evil asshat without the occasional good idea.
I'm not sure that finding (and building) the Open Mobile Device Environment is a Zero to One problem — Google, well, Android Inc., leveraged Linux, after all. But the design constraints are significantly different.
A standalone PC workstation is much closer to a multi-user Unix server in most regards, and particularly regards UI/UX, than is a mobile device measuring 25, or 20, or 12, or 8 cm. Or without any keyboard. Or screen. And a certain set of tools and utilities must be created.
It's not as if attempts haven't been made, but they simply keep not getting anywhere. Maemo. FirefoxOS. Ubuntu Phone. Hell, the Psion and Palm devices weren't bad for what they did.
Pick one, guys & gals. Please.
The Mobile Applications Ecosystem is Broken
There's also the question of apps, and app space, itself. By one school of thought, a large count of available applications is a good thing. By another, it's a sign of failure of convergence. As of 2017, there are 2.5 million Google Play apps.
Is it even worth the search time? Is meaningful search of the space even possible?
The question occurs: is it really in Google's interest to proliferate applications which are separate, non-integrated, split development efforts, and often simply perform tasks poorly?
Why not find a way to focus that development effort to producing some truly, insanely, great apps?
The consequences are strongly reminiscent of the spyware and adware problem of desktop Windows in the early 2000s. For the same reason: competitive software development incentivises bad behaviour and poor functionality. It's the Barbarians at the Gate all over again. With so many independent development efforts, and such an inefficient communications channel to potential users, as well as poor revenue potential through kosher methods, the system is inherently incentivised to exceedingly user-hostil behaviour.
A valid counterargument would be to point to a set of readily-found, excellent, well-designed, well-behaved, user-centric tools fulfilling fundamental uses mentioned in my G+ post. But this isn't the case. Google's Play Store is an abject failure from a user perspective. And catering to the MVU carries a large share of the blame.
I'm not saying there should be only one of any given application either — some choice is of value. Most Linux distributions will in fact offer a number of options for given functionality, both as shell or programming tools (where modular design frequently makes these drop-in replacements, down to syntax), and as GUI tools.
Whilst "freedom to fork" is a touted advantage of free software, "capacity to merge" is even more salient. Different design paths may be taken, then rejoined.
There's another line of argument about web-based interfaces. I'll skip much of that noting that the issues parallel much of the current discussion. And that the ability to use alternate app interfaces or browser site extensions is critical. Reddit and Reddit User Suite, by Andy Tuba, are prime exemplars of excellence in this regard.
Yes, this is a lot of words to describe the concept generally cast as "the lowest common denominator". I'm not claiming conceptual originality, but terminological originality. Additionally:
- "Lowest common denominator" is technically inaccurate. It's greatest common denominator, but that creates a confusion as to whether what's being discussed is a high goal to be attained or a low limit which is imposed. (The LCD of any two integers is 1.)
- "Minimum viable user" plays off "minimum viable product", popular extant Silicon Valley terminology. And is technically accurate.
This post was adapted from an earlier Mastodon Tootstorm.
- Reddit fans of the concept might care to visit /r/DesirePaths.