Nate Cull is a user on You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
Nate Cull @natecull


"Design" as practiced today by computer people tends to be heavily based on the idea of negative space: that good design is what's NOT in a system, and by extension, what is NOT ALLOWED TO BE ADDED to the system by a user.

A "design-heavy" system, then, is inevitably highly restrictive about user actions, lest they "ruin the cool design" by adding their own desired features that "make it messy".

But users WANT control over their own space.

Is there a "design" that empowers users?

· Web · 4 · 6

@pnathan Sadly the CLI concept didn't extend even as far as the X Windowing System.

There may be a reason for that.

@natecull I've built a few tools for users.

when you need reliability of tool, you wind up tending to limit the choices. and most prefer that sort of thing. reliability and choice are intrinsically linked.

When you kick off the shackles, you basically wind up accepting radical unreliability and the cost of fixing it yourself. Knowledge has a price basically.

Genuine wizard UIs are things like the CLI, emacs, autodesk, and a few others. They are unpopular.

@natecull now I want to be uber-clear. I prefer being a wizard, and having wizard tools, knowing enough to recover when I summon the bugs. There aren't a lot of tools like that because they aren't popular, and I recognize that preference, even though I think it's fundamentally problematic in a technological society.

@natecull Oh yes. The UI paradigm I am fascinating by but havn't explored in enough depth is the dwarf fortress paradigm. it's implemetned badly, but I think - I think! - it points to a possibility of interface that is substantially more powerful and profound than is currently in the WIMP paradigm, while retaining graphical power.

@pnathan ooh, can you unpack that a bit? I've only booted up DF once; can you explain what's interesting about its UI paradigm?

@natecull @pnathan

well, I can't explain what pnathan thinks is interesting

but I can tell you what *I* think is interesting!

in things like the overmap view, four keys match to up/down/left/right, and the chording involves another key

IIRC (I have to look this stuff up EVERY time I start playing DF again), lowercase moves around in the current zoom-in on a section of the overmap, uppercase for moves to adjacent sectors of the overmap

it's allllll keyboard, all of it. all.

@pnathan @natecull

and I will be honest, I don't play it often lately, but sometimes I get these stretches

there's a section of the basic interface that shows what options you have at this level of menu/submenu/etc., because DF KNOWS it's not rote learnable, really. way too complex for it. but after a while you don't need to 'see' the guide of what the commonly used keys do at this menu level, because muscle memory.

in a way, it's like Elite: Dangerous, but easier to get started with! ^_^

@sydneyfalk @natecull yes, the chorded and keyboard sequenced ways of moving through screens is fascinating. some of the key sequencing should be redone, but paradigmatically it's a very powerful system. a lot of it I have as muscle memory now.

@pnathan @natecull


vi ain't got shit on DF for complexity/confusingness

yet I can actually PLAY DF

vi is just repellent to me

(although I CAN use it, it just -- ugh, I just wanna enter my friggin' code)

@natecull @pnathan What of stuff like Applescript?

(NB: I'm aware it exists. I've not used it myself and don't know its capabilities. A point which might factor into any possible response.)

@dredmorbius @natecull @pnathan
AppleScript has the ability to automate user interaction with a GUI, but from what I understand it can't create new widgets. Also, apps aren't really designed to be composable.

@dredmorbius @natecull I would say the ergonomics of applescript are such that it's not full of use.

I didn't dink much with it because it didn't relate to the GUI paradigm that I worked in too well and I could already write bash etc by the time I encountered it.

@pnathan @natecull @dredmorbius hypercard was one of my early inroads to building software, so i used hypertalk some - similar vibes, i think?

hypercard was an amazing thing and i still miss aspects of it, but language-wise hypertalk suffered a lot from mistaken ideas about english-like ergonomics, i think.

@dredmorbius @natecull @pnathan
re: X, many (most?) of the linux desktop users i know use it to multiplex a bunch of terminals, and people tend to script things within the environment, so i'm not sure it's accurate that the cli didn't carry over.

@brennen @pnathan @dredmorbius

right, but that's not using X *as X* or to interact *with* CLI. It's using X just as a set of terminals for CLI that's completely unaware of X.

X, the system (as I understand it), does not use CLI. It sends and receives messages of its own devising and format but doesn't expose these to the user or use the CLI or pipe system to do it (except for some command options for programs which are mostly now ignored)

Tcl/tk, though, I think does use Unix pipes?

@natecull @dredmorbius @pnathan i mean, X is a windowing environment, so i dunno how using it to contain a bunch of windows isn't using it as that.

and yeah, X is a giant weird beast and i've never actually written code against it in any meaningful way, but i use stuff like xclip, wmctrl, dmenu, rofi, etc., to control facets of it pretty routinely, so it's at least situated in a cli & scripting-driven environment that i use to control my own space.

@pnathan @dredmorbius @natecull to go back to your original point, i think unix is a design that empowers users.

surely not one without substantial design flaws and a gnarly learning curve, but i refuse to accept systems that lack many of its properties, especially the ones that let me add and re-shape features.

@brennen @pnathan @dredmorbius

Well, because X is about *graphical components* of which 'windows' are just one tiny, tiny subset

Like you might want your program to accept input from and send data to buttons? Grids? Charts? Images? Textboxes?


None of that is even really possible with the 'a simulated VT-100 running just inside a window' use case of X.

So CLI is not interfacing with X 'as X', just X 'as a VT-100'.

@dredmorbius @pnathan @brennen all of that though is probably possible with Tcl/tk and maybe with some of the oldschool CLI tools you mention? (which really, really don't get much press at all even among hardcore Linux fans)

like to properly represent the state of X as CLI I think you'd need at least an object model? cos things on the screen ARE objects, they have persistence and state

Maybe all I want is a modern Tcl/tk that works with all the shiny GUI toolkits and OOP systems?

@pnathan @natecull @brennen @dredmorbius Smalltalk doesn't work with all the shiny GUI toolkits. You generally get 90s MVC, some variant of Morphic, or Pharo's newer incomplete thing.

@pnathan @natecull @brennen Really, really, really good suggestion.

I don't know, though it would seem to be close.

@natecull @pnathan @brennen NB: I'm massively hampered in all this discussion principally by /never having really grokked GUI application design in the first place/. My sense of "application" has always been "something that works on a stream of inputs or polls regularly for state", but not "and presents this with a bow and cherry on top".

I could use pointers on some good books on GUI UI/UX. Don Norman seems to be one source. Brett Victor another.

@dredmorbius @natecull @pnathan modulo a handful of toy projects and tiny utilities, every "GUI" i've ever built has lived inside a web browser, so i s'pose i'm in much the same boat.

@brennen @natecull @pnathan I ... have markedly better CSS chops than I care to discuss in polite, or impolite, society. No JS though. Yet.

@pnathan @natecull @brennen Virtually all of that picked up out of necessity trying to salvage my sanity and/or vision from the present state of HTML maldesign.

@dredmorbius @pnathan @brennen

It seems quite hard to think of how to encapsulate the IO flow and state of a GUI component.

ie the input stream could be a stream of events (mouse/keyboard or underlying widgets, data model) and a similar output stream... but it all seems a bit confused and intertwined compared to a simple script that reads a stream of records and writes a stream of updated records.

Could *maybe* separate the IO flow into 'channels' like 'standard output' and 'standard error'

@brennen @pnathan @dredmorbius

and maybe MVC could be pictured at toplevel as:

(stream of view-modification requests + stream of model updates) --> UI component --> (stream of view-updates + stream of model updates)

but it still seems not right. It's a whole nonlinear *data* flow. And that nonlinearity is what makes it hard to modularise. Too many wires snaking out in all directions, all needing precisely matching sockets.

@natecull @dredmorbius @pnathan @brennen don't try to map unix pipe concepts on a UI, the only place that works is Android intents et al

I only skimmed replies, but AppleScript was going in the right direction. I wonder what smalltalk did for representing object passing?

@calvin @natecull @pnathan @brennen If you look at my "Tyranny of the Minimum Viable User" #dreddit piece, you'll see I discuss that specifically.

There is also the distinction between "nodal" utilities and "complexity hubs". The latter do stdin/stdout poorly, if at all (though some do in fact do it). Most complexity hubs have *multiple* inputs and outputs.

@natecull @pnathan @brennen Interesting case in point: I've always found awk scripts far more intuitive than Excel spreadsheets. Even for simple stuff.

For sufficiently simple stuff, I write utilities that I'd otherwise use a spreadsheet for. E.g., summing a sequence, or generating univariate moments.

@dredmorbius @natecull @pnathan @brennen see, people are REALLY underestimating excel here

excel is a funcprog environment that

1., normal people use, and normal people use to great effect to get things done

2. actually offers a non-linear way to do programming; instead of a linear program, you operate on cells of a 2D space containing either data or formulae, and operating on ranges is easy

adding VBA was a terrible mistake that added complexity and inelegance

@calvin @dredmorbius @pnathan @brennen right, Excel and its ancestors (Visicalc) are a great example (I think) of what's now being called 'functional reactive programming'.

What if the whole GUI was like an Excel spreadsheet, and widgets were cells? They have a value, the value can be changed, it doesn't care how the value changes but if it does, that change propagates to all observers.

@natecull @dredmorbius @pnathan @brennen Mathematica has elements of this, but it's aiming more towards REPL-document hybrid

@brennen @pnathan @dredmorbius @calvin

the trick is how to remove irrelevant detail ('the user moved the mouse') as soon as possible, and pass on the relevant detail ('African_swallow.airspeed is now 42').

@calvin @natecull @pnathan @brennen I'm not contesting that Excel /isn't/ a functional programming environment.

I'm contesting that it's a /good/ FPE.

It is *VASTLY* too error-prone and difficult to debug. Not to mention awkward. OTOH, *it is often the only tool available since "real" programming tools are denied to front-office workers.*

(Including awk.)

Ray Panko, Univ. Hawaii, has studied Excel errors since the 1990s:

@dredmorbius @natecull @pnathan @brennen I don't think it means the idea is unsound though; on the contrary. There's a lot of ideas to take the spreadsheet and make it a far more useful tool than awk's programming equivalent of a face for radio

@calvin @natecull @pnathan @brennen Awk offers a line-of-code development model.

Excel offers a *grid of code* model. That's hard to see, visualise, debug, QC, validate, etc.

It's *possible* to write Very Robust Excel. It's not *easy* to do so.

I'll also note that I'm talking of my own personal use: I'm not saying that *everyone* who has an Excel-like task should use Excel. I'm saying that when I've got a simple "accumulate a store of values, compute something, kick out report", I prefer awk.

@dredmorbius @calvin @pnathan @brennen

I suspect this is because spreadsheets don't offer *grouping* constructs, which are pretty important for humans to organise information.

A 2D grid gets you a long way, but not really far enough.

If you had a sort of web of nodes which you could expand or shrink, and had a natural mapping TO a 2D grid if you wanted it...

@natecull @pnathan @calvin @dredmorbius a spreadsheet is a shittier-than-average database with what is a better-than-average representation layer for a whole bunch of people to be able to grasp it.

the achilles heel is how bound the physical structure of the data is to the representation & interface, but maybe that's what makes it approachable. there has to be some way for a serious db to be as approachable as excel is, but i don't know what it'd be.

@brennen @natecull @pnathan @calvin And yes, the notion that Excel integrates data storage, data manipulation, and data output, is pretty key.

MS Access took that a slight level higher, though it also had a remarkable propensity to suddenly detonate and destroy entire city blocks, without warning.

@natecull @dredmorbius @pnathan @brennen well, there are "sheets" but it's a bit clumsy

I think perhaps copying ideas from SQL for structure and drilldown would be interesting (another funcprog environment with good ideas, but clumsy tooling; SQL feels like funcprog if it were implemented by programmers who only used COBOL, and half the functions are missing - i'm convinced SQL is also why people swear of RDBMSes to the point of using Mongo et al)

@calvin @natecull @dredmorbius @pnathan put me in the camp of "syntax irregularity and the friction of defining new structures aside, sql is basically pretty good".

those caveats do matter, though. my hunch is that mostly people get lured into garbageware like mongo because sql rdbms systems make manipulating schema a difficult, largely out-of-band sort of task relative to most of their interface.

@brennen @natecull @dredmorbius @pnathan see, I always think talking about "schemaless" is a red herring when it comes to NoSQL - it's really about SQL as a query language & about making the DB just plain ol' serialization of Plain Ol' Objects - this is easy for a programmer, and it's a *schema*, typed language or not

SQL is only lovable if you're a 70s DBA. I'd want a modern RDBMS protocol of sorts, that makes queries and serialization easy - with strict schemas, since the other end has those

@brennen @pnathan @dredmorbius @calvin yeah, a database where defining a schema is an out-of-band operation seems a little like a functional programming language where you can't pass functions to functions.

One of the defining characteristics of data is that it exhibits recursive structure: things inside other things.

RDMBSes in the SQL model, however, are built assuming that there are certain Things (databases, tables) which May Not Ever Be Put Inside Other Things.

@natecull @brennen @pnathan @dredmorbius well, hierarchial DBMSes exist (a lot of NoSQL can be considered as such) but then you lose the advantages of RDBMSes. the problem is that mappings in SQL between tables are clumsy. what if RDBMSes had typed pointers between objects that made it easier to related between objects between tables?

@natecull @brennen @pnathan @calvin Having learnt RDBMS and various mainframe hierarchical data formats more-or-less simultaneously, I've been aware that There Is More Than One Way to Fuck Things Up.

Relational 2D data is convenient. It does /not/ fit all sets of circumstances. Normalising hierarchical data may or may not be possible. And often you're dealing with a cross of "what is present state" and "what is most recently-added transaction" (or "what is the full transaction history"?)

@calvin @pnathan @brennen @natecull There's also the realisation that many mainframe hierarchical formats appear to have been lifted straight off the underlying *paper* forms in use at the time.

At which point you realise that it was easier for the programmers *then* to simply duplicate the paper record in electronic form than to rationalise it.

@calvin @dredmorbius @pnathan @brennen and a sea of objects, or even dumb objectlike key-value data like JSON, doesn't have this restriction!

so it's naturally a lot simpler to work with 'an object full of objects full of objects'


'a database, which I gotta get my RDMBS administrator to spec a server and provision for me and define a schema which if I ever then change I gotta file a helpdesk request to do it and butwhooops the user just put a new data type in and crap...'

@natecull @calvin @pnathan @brennen Is JSON really a persistent data /store/?

Or is it a way of shuttling data between systems?

@dredmorbius @natecull @calvin @pnathan anything is a persistent data store if exists in the vicinity of enough half-educated programmers.

ANYWAY, this thread is a lot of fun but now i'm going to go fuck around with a pile of music gear i don't understand, which is probably also a good place to think dark thoughts about the state of interfaces and modularity.

@brennen @dredmorbius @natecull @pnathan for parting thoughts on spreadsheets, simmer on stuff like Quantrix, "3D" structured spreadsheets

@dredmorbius @calvin @pnathan @brennen

yes and yes.

I keep thinking that JSON is the new '80-column IBM card'.

It's terrible, but it's at least a defined 'plug shape and pinout'

so data stores are gonna assume it as the 'shape' of the data they store, just like 80-column screens and text files stayed the standard well into the disk and VDU era

@natecull @dredmorbius @pnathan @brennen I mean, JSON column types exist in everything from MySQL to DB2/400 (which is by far the weirdest SQL server I can think of)

@natecull @calvin @dredmorbius @pnathan @brennen To me, many of the problems of SQL arise because of how we use it: 1. Very restrictive with permissions. How much easier to solve problems if you can creat a ton of temporary tables. How much easier the queries. 2. Embedding it in apps. It’s like embedding vi in an app. Useless! But using it directly is cool. Like having awk and creating new files is cool. But better.

@kensanata i have probably linked this bit of rambling here before, but i've harbored related thoughts for a while:

@brennen The only point I’d like to add to that is that single user single file SQLite would answer many of the concerns, I think.

@kensanata yeah, perhaps. i do use (and like) sqlite for some stuff, but the limitations are real. i really haven't followed up on these thoughts by incorporating a relational db into much of my personal stuff, so i'm not honestly sure how much i'd feel those constraints if i just used sqlite for more things.

@kensanata @natecull @calvin @dredmorbius @pnathan @brennen I don’t understand your point 2. Why don’t you want programs to use SQL?

@wrenpile @kensanata (Retrying this message)

I think the argument is that SQL is a tool for working with and analyzing data like vi(m) is a tool for working with text files. So embedding SQL into a program artificially solves the problem by shoehorning in a tool's "interface" (magic strings) and at the same time introduces tons of second order concerns (sanitization, etc) as well as domain-specific middleware.

@cj @wrenpile @kensanata But applications have been built around RDBMS (and other) data stores ... since pretty much forever. If SQL *isn't* a general data language, than what is?

@dredmorbius @wrenpile @kensanata I think your statements/questions are orthogonal. SQL and RDBMS aren't coupled. No one is arguing against "SQL is a general data language". But is embedding SQL into binaries a good thing? Does that answer depend on ORM support for the language? Or sanitization libraries? Or sharding libs? I'd argue SQL-RDBMS coupling and SQL-as-a-general-data-language are orthogonal to these concerns.

@wrenpile I don’t mind embedding SQL in apps given that I don’t want two different ways to access data in a database. Being able to copy and paste SQL statements from source code and trying them in a general REPL is great for debugging. For people who come from a strict programming background (Java only for example) the embedded SQL (strings, no type safety, no compilation) is abhorrent. That’s why we have Java based QL now and it makes debugging hard. 😒

@kensanata Thanks for clarifying.

When you have a complex query with multiple joins and subqueries, having a REPL is vital not just for debugging, but also for prototyping.

As for Javaworld snobbery toward SQL, hey, SQL SELECTs are functional programming, and Java is … ?

@wrenpile Haha. Well, what can I say. At the office they are all gung-ho about getting rid of SQL statements and replacing them with a QL that generates the statements and thus guarantees type safety (database tables generated from interfaces and bind variables generated from the same interfaces). I tell them that this catches the kinds of errors I don't make and makes my life more difficult regarding the errors I do make, but it's not helping.

@kensanata Let me guess: in place of one big sql query yielding the answer you want, you end up with a bunch of small queries stitched together with many many imperative statements.

@wrenpile I haven't seen much of that, to be honest. We just translate big SQL statements into big nested Java function calls.

@natecull @calvin @dredmorbius @pnathan meh. i'm not really pining for more hierarchy in my datastores, though it has its place (hierarchical filesystems are certainly useful). my gripe is more that there's a bunch of friction to making new tables.

@brennen @calvin @natecull @dredmorbius @pnathan postgresql does a surprisingly good job at not being terrible, for a rdbms

@natecull @calvin @pnathan @brennen There are macros, worksheets, regions, etc. Though the groupings are predominantly on that 2D grid.

So it's not /all/ that bad.

And there are any number of CLI / scripting languages that promote Very Bad Habits. PHP is notorious for this. Perl can definitely get you there. I've even heard C occasionally causes problems.

@brennen @natecull @pnathan There's the whole Xt intrinsics toolkit. Go look up O'Reilly's early X11 documentation.

And, for that matter, contrast "X Power Tools" to "Unix Power Tools" The latter was indispensable, and even today remains highly useful despite being first published in 1993 (there have been 3 editions, through 2007). The former was ... dispensable, and seems only to have seen 1 edition.

@brennen @natecull @pnathan As jwz notes having learned working for Netscape / Mozilla: changes in GUI only get you so much, and *cost* you so very, very, very much.

Since you're dealing with what a person can *see* and *manipulate*, both *directly*, there's only so much bandwidth for information or control.

CLI has a vastly larger interface surface, if you will. The options are far vaster.

I have 1,000s of commands available to me from the OSX or Linux bash prompt.

My OpenWRT router: 660.

@pnathan @natecull @brennen How many command options are there from the Chrome or Firefox menus? From MS Office or LibreOffice menus?

@dredmorbius @pnathan @brennen One reason for this is probably that GUI actions tend not to be joinable or linkable; there's no fundamental GUI 'grammar' for anything like the concept of 'two symbols separated by a space' in CLI.

other than 'drag icon1 onto icon2' for a kind of primitive 'apply icon2 as argument to icon1 as function', but it executes immediately, it doesn't give you a third object which is the result of combining the two.

@natecull @pnathan @brennen GUI primitives seem to mostly be mouse and keyboard events.

Ironically: if you /start/ with CLI and toss a GUI wrapper around the elements, you can address some of this. I'd argue that a problem (and, more to come, quite probably advantage) is that one GUI tool cannot /easily/ "become a keyboard or mouse" to provide inputs.

First: think of the malware possibilties.

(X11 already had this problem: grabbing mouse/keyboard inputs.)

This is also usually test/QA stuff.

@brennen @pnathan @natecull That is, tools that /can/ automate GUI bits are generally used for testing and/or QA. I've used a few briefly a long time ago -- can't even remember names. OK, Selenium was one I recall.

The other problem is sorting out /what element you want to talk to / hear from/. You've got a bunch of crap on screen, there's no sense of pipelining or stdin/stdout/stderr.

Named sockets /might/ work.

@dredmorbius @pnathan @natecull yeah, it's funny - we could sure ask for more flexibility and composability in GUIs, but it seems like in a lot of ways the heavily OO-inflected desktops of the late 90s / early 2000s were the high water mark for any mainstream idea that we'd get that.

@brennen @pnathan @natecull And which were those?

I remember hearing that Amiga, and OS/2, and maybe NeXT offered much of this, but I've never really seen any particularly convincing demonstrations.

(OS/2 seemed to have a sense of "workspaces", though they seemed underwhelming to me.)

There's also the problem of preserving user state *within* GUI apps. *Even if I can fire up all the shit that I had open now, on reboot, I'd lose massive amounts of state.* Which fucking sucks.

@natecull @pnathan @brennen (I've been putting off some updates and a restart for this very exact reason.)

(There's also the month+ old problem of a nuked Chrome Browser extension's user state that's been on my to-do list for that month+, though I have to dig into the fucking headspace of Chrome and the extension to see how that happens. The developer of the extension himself *does not know and isn't interested in finding out.* Fucking sigh.)

@brennen @dredmorbius @natecull I never used hypercard. I've heard very very good things about it.

I should probably find an emulator or something and use it for a bit.

@pnathan @natecull @dredmorbius you can run hypercard stacks in-browser from's collection. i can't really tell how it'd feel to a new user at this late date, but i think it's worth the attempt.

@brennen @pnathan @natecull @dredmorbius Hypercard lives on in a more modern iteration through LiveCode ( Not used it myself, but some former colleagues swore by it.

@natecull @pnathan Is there /no/ X scripting language?

If I think of that, the first thing I tend to gravitate toward is Tcl/Tk.

@dredmorbius @natecull Not as far as I know? all my reads of xfree86 and xorg man pages have not ticked the "scripting language" bit in my head.

I think for Linux work, often the idea is to build a client lib with a ffi around the C binary and use perl etc for the scripting.

@natecull I'd argue restricted designs are more about supporting system growth/evolution and testability, validating options can be supported without weird edge cases, & that users won't suddenly lose favorite features, than it is about "coolness"

various web protocols have approached being as useful as bash CLI, but interoperability standards (like XMPP, RSS/ATOM) have tended to lose popularity just as soon as they've achieved mass penetration for inexplicable reasons

@kcsaff @natecull > interoperability standards (like XMPP, RSS/ATOM) have tended to lose popularity just as soon as they've achieved mass penetration for inexplicable reasons

I'd love to understand why RSS is fading away. it's soooo nice.

@natecull Unix? :P Seriously though, language-based design has always fascinated me, because humans invent words, subvert them, and expand them. We've tried to "design" them--e.g. grammar school, and on a whole 'nother level, esperanto--but always fail. It seems like when computers catch up to us, there will be something here for us to work with.

Basically any programming language is a user-control-oriented design. I only very rarely see graphical ones, because of artificial user/programmer divisions.

(There are a few I've used, coming out of Xanadu. Like, take a look at gzz. ZigZag is, from a user perspective, an overgrown note-taking system with too much flexibility, but the UX is very much for power users looking for a whole lot of control.)

@natecull My view of great design may well be described as a compromise between what you describe.

I'll practice the "restrictive" view for each individual component, in large part to avoid duplication of features. But the overall system should allow components to be freely combined.

Then again that design vision is very much what underlies the Unix shell, and it's "do one thing and do it well" mentality.


well, to be fair

> But users WANT control over their own space.

while true, think back to every designer/programmer complaining about clients who "want" things

a lot of time people "want" things they don't ACTUALLY want under any circumstances

I think it's why the "simple/advanced" settings paradigm has become so entrenched -- there's going to be people who wanna tweak everything, here you go

but for most people, going into settings is to switch one thing off or on, nothing else


and I'm not critical of the simple/advanced paradigm, either. I think it's a good idea. everything should have an easy mode, in a perfect world -- just as everything should be customizable if someone really wants to get in there and fiddle around.

it's just that, well: if most people tried to do car maintenance, it would be a catastrophe

same deal

@sydneyfalk @natecull
while true { think back to every designer/programmer complaining about clients who "want" things }

a lot of time people "want" things... <- **unreachable sentence**

[Yes, I am sorry.]

@natecull I'm going to *STRONGLY* challenge your premise, though I /personally/ agree that /I/ want control over my systems.

*MOST USERS DO NOT.* The level of user sophistication is *exceedingly low*, and *well over half the population has effectively abysmally bad or no computer literacy at all.* Says research:

Hence: the tyranny of the minimum viable user:

@natecull So, this gets to a few related concepts:

1. *Interfaces* are the human end of a tool. (The other end is the working end.)

2. *Ideas* themselves are interfaces.

3. There are cognitive complexity limits that extend through a population.

4. Protocols and conventions themselves are a sort of language, and the ubiquity of these is a component of a system as a whole. There's a whole class of tools which are described as horrible ... other than the fact that everybody uses them.


@dredmorbius #2, 'Ideas are interfaces', is something that resonates strongly with me.

Turning that around (inside out) is a reasonably good explanation for what I would like to see in software:

* software interfaces which map cleanly to ideas *

I want a system that's an 'idea processor'.

An idea:

* is something created by the user
* should not be a priori restricted or distorted by the system
* is composed of smaller ideas joined in a regular manner
* can be communicated to others

@dredmorbius This particular use case is where the 'big design up front' problem really grates.

A 'heavily designed system':

* does not let the user create arbitrary ideas but only ones approved and understood by the designer

* very much restricts and distorts ideas to fit the design, and sees this as a benefit

* prefers a small set of monolith preapproved components and often disallows linking and joining

* very often prevents communication for commercial reasons

@natecull There are "heavily designed" (though not necessarily "big design up front") systems that _do_ offer a great deal of flexibility. But they have to be designed to accommodate just that.

A key comes from one of my most underappreciated uni courses: linear programming. *The system's components and interactions must /lift/ rather than /add/ constraints.*

Any system of *increased* dependencies <coff>systemd</coff> will *increase* constraints and *decrease* options.

With one key exception.

@natecull A *useful* and *powerful* system of *protocols* and *standards* /does/ increase constraints, but does so *in the interests of interoperability*.

In doing so, it *lifts* the constraint *of inter-component compabibility*. That is, you don't have to go through a massive decisionmaking process *for each and every motherfucking element* trying to sort out if it will work with others.

"It just works."[tm]

(Debian Project unofficial motto.)

@natecull "In the Beginning Was the Command Line" -- Neal Stephenson.

See also: Hypercard. Which, it turns out, was very much an inspiration for early Web development. The Viola browser / system most particularly.

@natecull Well, /the fact of their near-universal ubiquity is itself a major element of their value/. It's one of several socialised / network effects (and means that rent can be extracted as a consequence, @garbados ping).

So, yeah: Microsoft Windows, MS Word, Visual Basic, PHP, Javascript, English, SMTP, etc., there are reasons for their persistence that have ... at least *very little* to do with their fundamental suitedness or capabilities.

Ubiquity itself has value.


@natecull Then you get the dynamics of GUI vs. CLI systems that I mention in my Tyranny piece, that play into this.

CLIs have persistence largely because of their scriptable nature, and the facts that 1) scripts will break and 2) sysadmins REALLY FUCKING HATE THIS. So you Don't Break Scripts.

GUI doesn't have that constraint (though retraining costs are Very Large -- but also highly externalised).

So that's one angle on all of this.


@natecull Designs that empower users are generally modular, extensible, and show what Steve McConnell notes as strong cohesion and weak coupling ("Code Complete").

Look to architecture, housing, and mechanical systems.

Houses (and offices, at least in theory) are designs which empower users: they provide a basic /framework/ within which multiple tasks and activities can be supported. They don't generally restrict or limit what can be used within or placed within them.


@natecull They're highly customisable.

If you look at, say, specifically a kitchen, the types of things you can obtain that are very high utility tend to be very modular. Start with a heat source (cooker and range), water taps and sinks, a refrigerator, and storage for food, cutlery, crockery, and cooking tools themselves.

A chefs basics are knives, bowls, whisks, spoons, measures, scales, graters. The more general the better. *Avoid single-purpose gadgets unless the purpose is essential.*


@natecull The result is a highly capable, generally uncluttered, space.

Automobiles are complicated but to a fairly large degree rely on interchangeable components: tyres, spark plugs, oil filters, various light bulbs, batteries, etc., are bog standard and are highly interchangeable. You don't rely on the auto manufacturer for them.

Even manufacturers often come up with a standard powerplant, transmission, etc., and build multiple models around these. The "differences" are mostly cosmetic.


@natecull A huge problem with the software / systems space is that the manufacturer alignments are strongly *against* standardisation. If you're an ISV of some major piece of software, *you want its use to grow to consume all available user tasks.* The problem isn't in the software engineering, it's in the software *market* economics.

So look to that for the source of your problems.