Thats why it bugs me to see e.g. linux desktop inanely adopting mainstream interfaces instead of focusing on steeper learning curves that come with high rewards. Dumbing down technology also leads to dumbed down users , and now we have already a generation that is struggling to use any tool that is not a touchscreen. Thankfully some technologists are starting to wake up to the fact that dumber isnt better (or maybe they ve milked the dumbdown cow to the end) and that we need more capable tools even if they re hard to use (e.g. this interview of Palmer luckey https://www.youtube.com/watch?v=epy8UVZilmA&t=990s)
I don’t see any logical sense in this. I think what you’re implying by “dumbed down” technology is technology that is made easy to use. It doesn’t matter how smart you are, more complex than needed interfaces is always dumb design. If a majority of the users use a tool for a couple use cases, the tool should be designed to make doing those tasks as simple as possible. More obscure tasks will be found by the people who need them when necessary, even if their is a steeper learning curve for doing so. I’d never want my hammer to be harder to use than necessary nor would I want a textbook to teach inefficiently because someone thinks the complexity of presentation will make me learn better (while those 2 things may have a spurious correlation, it is possible to get a better outcome while not making the material more complex).
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.
> I think what you’re implying by “dumbed down” technology is technology that is made easy to use.
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.
> a generation that is struggling to use any tool that is not a touchscreen
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.
You can already see this in younger kids who haven't touched a proper computer but use a tablet or phone every day. Though, I think most will be fine as they grow older, with PC gaming and school at least.
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.
> Dumbing down technology also leads to dumbed down users
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'.
OTOH i think dumbing down is an active process that leaves end users untrained to complex interfaces. I can compare young students who struggle with a complex interface like blender , yet i remember my uncle (a lawyer) who had learned sql just to use DbaseIV in the '80s
Your uncle was special, even for the 1980's. While many people did take the time to learn how to use those more complex interfaces, many people avoided computers altogether. Contrast that to today. People are expected to use various forms of computers, even if there is no compelling reason to do so.
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.
The difference being that SQL is a standard that's used across many products, has a very flat learning curve, and will be familiar to anyone who uses databases. Whereas Blenders UI is unlike anything else and has a very steep learning curve even for people familiar with other 3D modelling tools.
I don't want to think when I want to call my wife, play a movie, get information, or 99% of the things I do on my life.
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.
I don’t want to waste mental capacity on someone’s dumpster-fire interface. I reserve that mental capacity for the task that I’m trying to accomplish with the tool.
Why shouldn't mainstream Linux desktops adopt mainstream interfaces and then people who want a steeper learning curve can use a less mainstream desktop?
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.
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
This complexity supports increasing functionality (i.e, the browser becomes an operating system within the operating system) and also legacy technology (i.e. Microsoft Windows), both of which have come to be expected by the customer/user.
The complexity itself is made possible by constant gains in hardware processing capability such that optimization is often a secondary concern.
AI's are now in the early stages of being used to write code and that's only going to increase.
I consider this whenever I see someone saying that “such and such” text editor needs to “be more like vscode”. Trying to out do Microsoft’s paid development team is a losing game. You will always be a second place player. And no one wants a crappy vscode clone. But as the article says, you don’t have to focus on the lowest common denominator, but can instead build an incredible experience for the small set of people who want it.
I dont contribute to open source these days cause of the amount of drama. But what I do is fork and add stuff that I find useful or want. Eventually someone or the other finds it and if they care enough pulls it in.
I find this much better than convincing open source gatekeepers, who already have their brains overloaded, to accept pull requests.
> I dont contribute to open source these days cause of the amount of drama.
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 :)
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 feel free and open source software's promises is still yet unrealized since I don't do these sort of things, and probably neither do most programmers.
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...
Some intersection of "The users that gave the most interesting or thoughtful feedback" and "The users who are closest to the original intent of the tool."
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.
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.
To me a lot of OSS already has a disdain for the "lowest common denominator" type of users, and this article has this vibe.
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.
Guardedly agree, though there's also entitlement risk here. If an author scratches their own itch, and it does what they wanted, and they decide to open source it, then good on them.
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.
The same concept was advocated by 37signals/Fried, in Rework:
> 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.
> We already have various tools for enabling growth: the freedom to use the software for any purpose being one of the most powerful.
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).
I think this is telling us to drop X windows / Wayland, it's time to acknowledge that's a failed experiment. We should go back to just terminals and load firefox in framebuffer when we need that. ;)
