There /are/ cases where reasonable accomodations 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 accomodations, 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.

2/

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 10cm ridge. This accomodates not just wheelchairs, but dollies, carts, wheeled luggage, and more. Benefits materialising after use.

3/

For information systems -- say, webpages -- the accomodations 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.

4/

When we get to the point of process-oriented systems, the picture becomes more blured. 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.

https://en.m.wikipedia.org/wiki/Desire_path

5/

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 accomodation. 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.

6/

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 that feature becomes the "remove from visibility" function. I've ... had that conversation with Google for a number of years. Or 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.

7/

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.

8/

Simple tasks benefit from simple controls.

Complex tasks ... /still/ 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.

(At this point I'm overlapping to the Ontology of Technological Mechanisms, noted.)

9/

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 other tools I'm omitting here, 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.

10/

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.

If you can only use it on one recipe, it's bad mkay?

https://duckduckgo.com/?q=useless+kitchen+gadgets

11/

There are times when you absolutely should be aiming for the minimum viable user. Pretty much anything that sees widespread 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 elevators, automobiles, and telephones. Each is highly complex conceptually, two can maim or kill. All can be relatively safely used by most adults, even children.

12/

A large part of what /makes/ elevators, automobiles, and telephones so generally usable is that the controls are very highly standardised.

Mostly.

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.

It takes me a year or more to figure out a new office phone system. If ever. A constant for 30 years.

13/

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:

* Voicemail
* Call forwarding
* Call conferencing
* Other random shit to inflate marketing brochures

14/

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), and a handset, plus some base. Cords.

15/

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.

https://www.inc.com/john-brandon/why-millennials-dont-like-to-make-phone-calls.html

16/

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.

17/

When you're using a phone in a goal-oriented process, you are jumping between a number of different informational contexts. You need access to:

* The other party's identity and contact info
* Information you want to express
* Operating instructions for the device itself
* Information captured during the call
* Access to /other/ contacts, during the call
* How to transfer/include others
* Your or the other party's state loss due to interruption
* Resolution or next steps

18/

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.

19/

The upshot is that while a telephone is reasonably simple to use in the basic case -- establish a voice connection with another device genarally 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.

20/

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.

21/

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 / propaganda newsreels describing development of the phone system: direct-dial, switching, 7-digit, area-code, long-distance, touch-tone.

22/

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.

https://www.chesterton.org/taking-a-fence-down/

23/

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
* A secretary or switchboard, 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.

24/

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.

25/

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.

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.

http://www.faqs.org/docs/artu/ch01s06.html

26/

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 preceeding toot.

http://sasamat.xen.prgmr.com/michaelochurch/wp/index.php/2013/01/09/ide-culture-vs-unix-philosophy/

27/

Exceptions to the Unix Philosophy are all complexity hubs.

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.

28/

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.

https://en.m.wikipedia.org/wiki/Gordian_Knot

29/

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.

It's a CRUDdy situation.

https://en.m.wikipedia.org/wiki/Create,_read,_update_and_delete

30/

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.

https://en.m.wikipedia.org/wiki/Udev

31/

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.

32/

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.

33/

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.

34/

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.

35/

Neal Stephenson, "In the Beginning was the Command Line", again, offers one such: Metaphore 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/. 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.

http://www.cryptonomicon.com/beginning.html

36/

In many cases, the basic Unix commands are wrappers around either C language structures (e.g., printf(1) and printf(3)), or report the content of basic data structures (e.g., stat(1) and 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.

37/

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

38/

Scripting has the effect of constraining, for better or worse, changes to interfaces /because scripts have to be updated/. 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.

39/

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.

https://www.xkcd.com/980/

40/

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.

jwz 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."

https://www.jwz.org/blog/2012/04/why-i-use-safari-instead-of-firefox/

41/

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.

42/

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 Windowmaker, 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 focus on /function/ rather than /form/.

43/

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 complexity
* Rapid response
* Adapting to changing circumstance
* Considered thought
* Scalability of understanding, comprehension, or control
* Inegrating numerous other systems
* Especially nonuniform ones

/44

Another question 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_.

This has profound implications for futures premised on any sort of general technical literacy.

https://www.nngroup.com/articles/computer-skill-levels/

/45

As William Ophuls writes, social systems based on the premise that all the children are above average are doomed to failure.

I'll venture that 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 -- of the population who can make highly productive use of tools.

https://mitpress.mit.edu/books/platos-revenge

46/

Another possibility is that the definition is of the Minimum Viable-Revenue User: services are targetted 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.

https://medium.com/the-mission/silicon-valley-has-a-problem-problem-b34437a57e99

47/

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 Expensive, 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, 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.

48/

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.

49/

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.

For numerous reasons, the design considerations which go into such tools are rarely highly generative.

Oh: Advertising is one of those domains.

Remember: Advertising breeds contempt.

https://[email protected]/581469

50/

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".

That's solipsistic.

https://www.libertarianism.org/publications/essays/why-do-intellectuals-oppose-capitalism

51/

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.

https://[email protected]/578689

52/

Which suggests one of a few possible avenues out of the dilemma: a large set of generative tools have been built through noncapitalistic 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/.

53/

An aside: when I said "occurs" above, I want to make clear that that's a thought that comes to me in writing this, which is amongst the reasons I'm finding the tootstorm form itself so useful. It's an online analogue to my index-card note-taking and drafting methods.

https://[email protected]/629086

54/

Back to 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 unleased 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.

55/

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 1-2 problem.

56/

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.

http://bookzz.org/book/2692814/227fe9

57/

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.

58/

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?

https://plus.google.com/104092656004159577193/posts/HvFhwViLobb
https://www.statista.com/statistics/266210/number-of-available-applications-in-the-google-play-store/

59/

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?

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.

http://www.nytimes.com/2004/09/19/business/yourmoney/barbarians-at-the-digital-gate.html

60/

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.

61/

@dredmorbius When you're done with this thread, please let me know if you publish it to a blog or something. I'd love to share this post alone with someone not on Mastodon, and to more readily read all the posts.

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.

62/

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 interfaces or browser extensions. Reddit and Reddit User Suite, by Andy Tuba, would be amongst the prime exemplars of excellence in this regard. Though the thought of how to maintain user-state locally (with syncing capabilities) is one ... that shall be unfinished here.

63/

And, at 64 cards, I'll wrap this.

The original Minimum Viable User post is here:
https://[email protected]/580128

On my Chrome on Android tootstorm:
https://[email protected]/573500

64/end/

@dredmorbius The issue that you're describing with an MVU is similar to the issues of designing a thing for the lowest common denominator. You might be able to find more related info by looking into that.

For those who prefer their long-form reading in long-form-amenable formats, I've adapted the tootstorm I'm replying to here to an essay:
https://redd.it/69wk8y