On choices vs simplicity/automation

[smichel17]

In #3377 (comment), @mnalis wrote,

As a resident give user a choice proponent

It's not that I hate automation, I love it, but I go crazy when it does something "wrong" and I can't override it. Imagine if you could not override methods when you inherit a class in Kotlin (or whatever terminology is used these days) - it would be horrible for programmer, even if the original classes were superbly done and did a vast majority of things right.

I'm giving a talk this Saturday at SeaGL (the Seattle GNU/Linux conference) which is closely related to this topic.

https://osem.seagl.org/conferences/seagl2021/program/proposals/822

This is kind of a placeholder until then; afterwards, I'll edit this post with a written version of my argument.

You can watch the talk here:
https://archive.org/details/SeaGL2021-Stephen_Michel-Technically_Biased_Taking_Free_Softwares_Niche_Appeal_Mainstream

In summary:

• Let's face it: software freedom actually does benefit tech-literate folks more than tech-illiterate.
• I prefer those terms over "non-technical", which implies they'll never become technical.
  • Instead, we should strive to educate, the same way we (society) have decided it's worth teaching everyone literacy skills.
• People aren't tech-illiterate because they're dumb. It's because they don't care / they don't see why it's worth their time.
• Designing crippled software in order to make it less intimidating reinforces this effect, because it removes any reason for them to want to learn.
  • We must reject this design paradigm; it is an existential threat to Software Freedom.
• Designing software that serves people who don't want to learn (yet) is still/especially important. And hard.
• Scriptable interfaces are a great way to simplify UI (replace many options with one script) and simultaneously give people a reason to be interested in learning.

[smichel17]

Updated. (@mnalis)

[mnalis]

Yeah, I agree very much with all you've said in talk and here. In my opinion, the main issue is what you notice also - making software easy yet extendable (without horrific learning curve for advanced features) is hard.

Sure, simple but scriptable UI is easy way out for original programmer (let's make simple program, and allow users to extend it infinitely via built-in script interpreter - which I'm personally all out for), but it is far from perfect, because now there is gap between "simple user happy with basic simple interface" and "expert AKA programmer willing to learn yet another embedded scripting language and it's API") - and that gap leaves out majority of what are considered "power users" in classical software paradigm.

Details

Still I'd like such scriptable UI (e.g. if each quest was copy/pastable script embedded in SC, instead of Kotlin code which needs to be compiled etc), as it allows third-parties to program "plug-in macros" (which non-tech-literates could simply download and use) and also avoid situations which otherwise occur (like me having to fork SC just in order to add one dialog and modify few quest to trigger little more often, or add a few test quests; and having to re-investigate to keep it working when major upgrades break my changes). With scriptable I could just copy/paste few quests someone else have written, and modify few I need - making changes and testing them would be much faster, especially since I don't develop for android, so I rely on github to compile things for me, then download on phone etc, making something that could be 20 seconds with scriptable UI take 20 minutes - which does not look huge until one considers that I usually needs multiple tries to make simple things work (again).

It also sounds like a gaping security hole if too powerful (e.g. more than just a quest limit and which tags to add; like opening custom windows etc), and something users could easily break unless protected from accidental changes and easy "undo" & "reset quest to defaults" options.

So, yeah, the hardness of simple initially but easily extendable with easy learning curve (as not to skip from novice directly to expert) is big part why we don't see it often, I think.

I think other big issue why the free software is mostly oriented to tech-literate is the lack of time and lack of programmers. Sure, you could possibly design and implement such easy yet extendable interface - but for 1 such feature, you could've implemented at least 5 harder to use (eg. tech-literacy required) features. And given that programmers firstly want to scratch their own itch (as the saying goes), it is not hard to see why the software is in such state.

Oh, and there is an issue with people equating "freedom" with "gratis", thus it seems harder to make money for selling free software. Which becomes issue, if programmer has no incentive to write something they don't care about:

And for programming in free time for no compensations, programmers usually like to program something they find useful/interesting (which is often not what tech-illiterate users find interesting). Thus, for a long time, nobody wanted to write open source Office package -- as it is boring, and not really useful to programmers. So it only happened because closed source company decided to throw in the towel and open source their office suite, when the effort to contribute became manageable for free software programmers (sure, I can fix that bug or add that simple feature if I or someone I care about needs it, but there was not way in hell I was going to waste many years of my life to write open source office suite from scratch -- no matter how highly I believe in free software ideals)

[lynxdingo]

At that point it might just be better for the "expert" to fork the branch and add their own features in their edition.

[Lee-Carre]

better for the "expert" to fork the branch and add their own features in their edition.

Expertise with OSM editing doesn't inherently imply expertise with software development.

[Lee-Carre]

• Complexity is Good, Simplicity Overrated
• Eric Raymond expounds on related concepts at length in The Art of Unix Programming & The Art of Unix Usability