My proposal for scaling open source: don’t
sicpers.info
sicpers.info
It seems more likely to me in general that 'making technology more accessible increases the number of people who will be able to access that technology' than 'simpler interfaces make people dumber'.
The thing that I find bothersome is the expectation of simplified interfaces and feature sets outside of professional domains. It is an approach that works well if the software does exactly what you want of it, yet fails miserably the moment a user's expectations deviates from the developer's expectations. There is little room for creative thought or problem solving since the software tries to do everything for the user rather than providing a set of tools to them.
Bunz's conclusion: "The difference between empowering the user and manipulating her or him is minimal, but decisive: it makes a difference whether the interface is empowering you, or patronizing you while hiding it in bright, friendly colours and the technique of infantilization. In a conversation about this contemporary problem of interface designs, Robert Ochshorn (2014) pointed out that there is, indeed, a fine line between ‘designing to empower a skilled user’ and ‘designing to prevent a user from feeling stupid’. This means that the difference between the interface assuming you are intelligent and teaching you to outgrow it, and patronizing the user by eliminating the possibility of making mistakes while effectively controlling her or him, is difficult to spot. Following Wendy Chun, who addresses the new media of today as a habit, one can say that habits ‘are both inflexible and creative’ (Chun 10.1057/9781137437204 - Postdigital Aesthetics, Edited by David M. Berry and Michael Dieter200 Infantilization in Digital Environments forthcoming 2015; Chun 2015, this volume), while Tiziana Terranova (2004, 83) has pointed out that online spaces cannot be conceived as ‘purely functional’. As I have pointed out elsewhere (Bunz 2014, 50), this is a tendency we find often when looking at the being of technology: technology is haunted by an ambivalence – in this case, its potential to manipulate and its potential to empower people. Despite infantilization looking friendly and innocent, it might follow other interests, and, at a time in which computers are becoming ubiquitous, we need to be aware of this. Soon, infantilization might leave our screens to be found on the things around us – Google has recently launched a car with a smiling face. Being addressed as a child is ambivalent, and this ambivalence is typical of our time: technology companies want people to feel comfortable and play with their technology. At the same time, people also need to take technology into their own hands, as learning how to use it not only empowers them, but also shapes what technology becomes: school will never end."
[Edit: Seems obvious companies try their best to make products that get people consuming more instead of producing more. Removing complexity from digital interfaces is a recurrent theme.]
About TFA, I believe everything has its place - open source shouldn't try to "win" and just do its thing. At the same time megacorporations devote greater and greater resources to bigger projects like the linux kernel.
This is not an indictement though... software is getting more complex and i.e. it's unthinkable now for anything but a very large company to make their own browser.
I don't know where we go from here.
This was prescient (article is from 2015) of the media kindergarten of the past 5 years
software is getting more complex and i.e. it's unthinkable now for anything but a very large company to make their own browser.
isnt the answer then to reduce the incidental complexity?provide alternatives that have "onramps" to greater capability instead of being stuck in "dumb ui land".
even a browser could be re-imagined as just a vm that runs "html" as a shared lib for one type of content, greatly simplifying the model for broswer makers
there are lots of potentialities i think
AI's are now in the early stages of being used to write code and that's only going to increase.
I think enough during my workday. And when explaining things to my daughter or reading a book.
You probably never read the book, because the author never tells you to "dumb things down" but to make them so intuitive you don't have to think about them.
Same way you don't have to think how to open a tab or a door.
Have you ever been in front of a door and wondered if you had to push, pull, approach, slide? That's bad design.
This is exactly what I (and some colleagues) observe in academia, we now have first semesters that have grown up with smartphones and tablets but have never used "a computer" before.
That leads to some awkward conversations:
- "can you send me your file?" student: "but I only have that in word?" - "yes ... can you send it to me?" ... " student: "but I only have that in word!" - "... ?"
My prediction / fear is that this will only get worse over time as we have not hit the first generations that have been born after widespread touchscreen adoption yet.
Speaking of school, I'm in the age group you mention, and I'm baffled how those people have managed to get to University without knowing the concept of a file. Almost every paper I've written since the beginning of high school has been turned in as a PDF in Turnitin or Google Classroom.
My main point is that the people who have trouble with the complexities of a tool will have a more likely chance of abandoning the tool or switching to a different tool than learning. The people who can navigate the interface probably aren’t getting dumber for using the simpler interface either.
Specifically regarding this, I think what the poster is implying is that all of the options within a piece of software have been removed. The interface has been dumbed down until you can only do the exact couple tasks the team has designed it to do to, and nothing more. The options that allow us to fine tune the software operation to our needs, to flexibly use the tool have been removed to the point where all you get is a button to do the task, and if it fails you get a cute cartoon that says "omg, sorry!".
When using technology that hasn't been dumbed down, the development team can often be surprised at what users are doing with it, because they are doing all kinds of things we never thought of. Once the software has been dumbed down enough thats not possible, because the software wont let you do anything the development team didn't think of.
Most often this will be you and people similar to you.
Less often you build it for a friend and people like them, or an organization you care about and organizations like them.
Here is an historic example: the GIMP. AFAIK the original purpose the software was intended to serve was to create merchandise, I think post cards, from fotos to sell at a stand.
Compare that to Photoshop whose original intend was to make images ready for print production, you see two very different set of users.
Photoshop filters got their name from studio lightning filters, a technical term completely logical to it's intended audience. Everybody who did movies/fotos in the pre-digital era new what a filter was. This naming made the Photoshop menu and concept intuitive, thus raising it's usability.
The replies that suggest just yourself, people like you, friends etc don't provide satisfaction to those people who gain the most satisfaction from building things large numbers of other people want to use and ideally enjoy using.
I'm happy to write/build little things for myself, friends and other small groups up to a point. But the motivation is limited. I don't see myself putting in 1000 hours polishing something like that, as it feels like a waste of limited lifespan. It's just not fun.
Whereas I'll happily put in 5000 hours to a project that I feel is, or could be, making a noticable, useful and liked difference to the lives of millions of people. It some level of psychology that's satisfying, a kind of deeper fun.
Don't ask me why it makes a difference how many people are affected. I don't have a good answer.
I know there are many people who don't feel this way, because they say so. But it seems to be how some people are wired.
But there's that pesky scaling problem.
So which people and which projects to focus on?
I think it's a dilemma that a lot of people struggle with in times of creative freedom who are wired that way, and I have yet to recognise any really good articles or guidance on resolving it.
I find this much better than convincing open source gatekeepers, who already have their brains overloaded, to accept pull requests.
this is the whole premise of open-source originally. If the "fork" is good, either the up-stream takes the changes, or the fork becomes the official one. This will be determined by the users of the program.
I know that Free software is about freedom first and foremost not whether we take advantage of these freedoms, and that it has many ancillary effects on our privacy right and keeping old hardware running and all...
I've seen the drama (from a distance) in some large FOSS projects, but there is a sea of small one-person or small group projects which are usually a pleasure to contribute to - they usually entail nice simple, small scale, person-to-person interactions, not massive discussions and red taping - it's fun :)
If everyone you know is using zoom and WhatsApp, they will not use signal and jitsi just for you, so you will be forced to use the proprietary tools.
Think about remote school and trainings for example ,here you have zero choice.
And in the past, we saw the case with Linux where it was very hard to have support for hardware as manufacturer did not care at all about Linux.
For such a case, scaling is an important factor to be able to use your open source software. Sadly.
You don't have to "growth hack" and beat $1T companies, but don't use that as an excuse for ignoring usability. In OSS "simple" more often means "works for the maintainer" rather than something that's actually intuitive and usable for the majority of people. If you only have a handful of hardcore users, because everyone else failed to run the software, and was told to read the (barely existing) manual, that's a problem with the software's design, not scale.
Choosing to do so doesn't create any requirement to make it useful to anyone else. This is the root of a chunk of angst today: consumer X finds open source project Y, discovers it doesn't do Z, and throws a twitter/issue hissy fit.
There's *zero* requirement on the author to fix the perceived deficiency, nor should there be any expectation.
If X wants it addressed, then - as noted elsewhere in this topic - a founding principle of open source is that X is free to fork and fix.
Now, of course, some authors create open source and actively solicit use by others. In that case, they do need to consider feedback from their users. But again, there's no divine right conferred on users that the author will address their every whim. Fork and fix should be the first option - with no expectation it'll be upstreamed.
> Let your customers outgrow you [...] When you let customers outgrow you, you'll most likely wind up with a product that's basic--and that's fine. Small, simple, basic needs are constant. There's an endless supply of customers who need exactly that.
This has been tried for the last 30 years; with some success, but very limited, and probably not really primarily attributable to "Software Freedom" either.
Essentially this article is "keep doing what we've been doing for the last 30 years", which doesn't strike me as a very good strategy.
I do think we should not just "copy" whatever others are doing. Actually, I call this the "new coke fallacy":
1. Project X is more popular than us.
2. Project X does Y.
3. Therefore, we must do Y.
There are all sorts of problems with this: you may misidentify Y, X probably does a good job solving Y already (not always though!), and exactly because it's not X and does Z instead of Y is why you have (part of) your user/customer base in the first place.
It didn't work out very well for Coca Cola, and unless you're really sure what you're doing it's probably also not going to work for you (but if you can do Y substantially better, it might be a good idea).