161–170 of 641 posts
I feel like the author wants everything to be Apple simplified. That all users should dumb down to on off go and stop. Ask chat got for anything else. I disagree for so many obvious reasons it's pointless to iterate them. We as a society need to get MORE capable, more critical, and improve our cognitive abilities; not the opposite.
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one. Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I j…
Good points, but to add to the sources of instability ... a first time user of a piece of software may be very appreciative of its simplicity and "intuitiveness". However, if it is a tool that they spend a lot of time with and is connected to a potentially complex workflow, it won't be long before even they are asking for "this little extra thing". It is hard to overestimate the difference between creating tools for…
I see people using DAWs, even "pro" ones made by companies presumably interested in their bottom lines. In all cases I have no idea how to use it.
Do I complain about intuitiveness etc? Of course not. I don't know how to do something. That's my problem. Not theirs.
A lot of this type of stuff boils down to what you're used to. My wife is not particularly tech savvy. She is a Linux user, however. When we started a new business, we needed certain applications that only run on Windows and since she would be at the brick and mortar location full time, I figured we could multi-purpose a new laptop for her and have her switch to Windows. She hated it and begged for us to get a dedica…
Familiarity is massively undersold in the Linux desktop adoption discussion. Having desktop environments that are near 1:1 clones of the commercial platforms (preferably paired with a distribution that's designed to be bulletproof and practically never requires its user to fire up a terminal window) would go so far for making Linux viable for users sitting in the middle of the bell curve of technical capability. It's…
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one. Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I j…
The contributors of free software tend to be power users who want to ensure their use case works. I don't think they're investing a lot of thought into the 80/20 use case for normal/majority or users or would risk hurting their workflow to make it easier for others
If handbrake scares them, don’t you dare to demonstrate how to use ffmpeg. I remember when I used handbrake for the first time and thought “wow, it’s much more convenient than struggling with ffmpeg”.
I actually think ffmpeg’s UI is simpler than Handbrake for those at all acquainted with the command line (i.e., for those who understand the concept of text-is-everything-everything-is-text). Handbrake shows you everything you can possibly fiddle with whether or not you plan on fiddling with it. Meanwhile ffmpeg hides everything, period, and you ask for specific features by typing them out. It's not great for discove…
Someone who only wants to convert from one format to another, and isn't accustomed to CLIs, is far better served by "drag the file here -> type an output filename and extension in the text box".
The problem (and the reason both FFMpeg and Handbrake exist) is that tons of people "only" want to do two or three specific tasks, all in the same general wheelhouse, but with terrible overlap.
Earlier quoted context omitted.
This is a weird thread for me to read, as someone who a) works primarily with developer tooling (and not even GUI tooling, I write cryptography stuff usually!), b) is very active in a vibrant community of artists that care about nerd software projects. I don't, as a rule, ever ask artists to contribute for free, but I still occasionally get gifted art from kind folks. (I'm more than happy to commission them for one-o…
Why should they work for pay on free software? Nobody expects to be paid to work on the software itself. Yet artists expect to be treated differently. If it is your job, then go do it as a job. But we all have jobs. Free software is what we do in our free time. Artists don't seem to have this distinction. They expect to be paid to do a hobby.
Earlier quoted context omitted.
Overall, the development world does not intuitively understand the difficulty of creating good interfaces (for people that aren’t developers.) In dev work, the complexity is obvious, and that makes it easy for outsiders to understand— they look at the code we’re writing and say “wow you can read that?!” I think that can give developers a mistaken impression that other peoples work is far less complex than it is. With…
> I think that can give developers a mistaken impression that other peoples work is far less complex than it is. Not at all. Talented human artists still impress me as doing the same level of deep "wizardry" that programmers are stereotyped with.
Other engineering disciplines are simpler because you can only have complexity in three dimensions. While in software complexitiy would be everywhere.
Crazy to believe that
Makes a good point, but the headline bothers me. It isn't the free that is the problem, it is the complexity.
Earlier quoted context omitted.
The contributors of free software tend to be power users who want to ensure their use case works. I don't think they're investing a lot of thought into the 80/20 use case for normal/majority or users or would risk hurting their workflow to make it easier for others
And this is precisely why desktop Linux has not knocked off Windows or MacOS.
You don't need two different versions of the software, one that is easy and one that is powerful. You can have one version that is both easy and powerful. Key concepts here are (1) progressive disclosure and (2) constraints. See Don Norman's Design of Everyday things. https://www.nngroup.com/articles/progressive-disclosure/ https://www.nngroup.com/videos/positive-constraints-in-ux-wo...
It's easy to make the powerful version It's a little harder to make an easy version Making the progressive version is very difficult. Where you can please one audience with the powerful and easy versions, you can often disappoint both with the progressive version despite it taking much more effort. In my personal experience, you're lucky if free software has the budget (time or money) to get to easy. There's very lit…
So yes, it is hard to make the simple version. You have to have a very good understanding of what the user wants out of your product. Until you have this clarity, every feature seems important. Once you have this clarity you understand what the important features are. You make those features more prominent by giving them prime real estate, then tuck away the less important features in a less visible place. Simple things should be simple. Complex things only need to be possible.