Oh boy, we're redesigning VLC interface those days, and does this article is spot on on numerous part we've seen.
0. A lot of things are not-intuitive, and we've had to do basic UX and looking at our users to understand what the needs where (we don't use telemetry/spying). And it took a lot of time...
1. And yes, this requires to rethink some of the basics stuff for VLC usage.
2. And the nerd-porn part is very true: we solved it with 3 layers of access. Simple usage should be direct, Advanced usage for normal users should be within 2 clicks, and Geek/Pro options can be further away.
And we will have options for different usage of VLC that will impact a bit the UI (but we're making that as simple as possible, to not make the codebase too complex -> more time)
3. Finally, a lot of things had to be decided without consensus, and that requires leadership that is not the usual way we work.
I can share some of the work, if some people care...
As a daily user of VLC, I just want to say: I only use about 10% of what it can do but I can pretty much guarantee that _my_ 10% of feature coverage doesn't match anyone else's.
This is the biggest issue we have. People use VLC for various different things, from DVD playback to audio media library to audiobooks or professional QA. Not everyone has the same needs.
The unspoken "problem" you have is that your existing users are doing just fine with VLC.
If all you see is "growing" the userbase by nuking and reworking the user interface what happens to us your existing users?
As a direct example -
I use VLC primarily as a music player for my jazz album collection. It handles many formats I throw at it. It has a simple playlist (I play albums from start to finish and do not value a lot of spazzy track selection features).
I have a nice useable interface that works well. I ignore the stuff I don't need, I know WHERE the stuff I do need is.
I use VLC because it doesn't change much year to year unlike the vast majority of flash in the pan music players that go in and out of fashion.
If you privilege growth of new users you don't care that I know where things are and how to make them work. You just reorganize things according to some "designer" that is entirely growth oriented and doesn't care about me.
(I really don't understand this comment, nor the tone that I perceive as quite aggressive, but I may just misunderstand it. So answering anyway)
> The unspoken "problem" you have is that your existing users are doing just fine with VLC.
Some of them yes, some are complaining. Quite many, in fact.
> If all you see is "growing" the userbase by nuking and reworking the user interface what happens to us your existing users?
We're just working so that it still works for our existing users, that's exactly the point of my previous comment. It will require, at some places, to have some options, for contradictory use-cases; but mostly, we will try to support everything that we did, just simplify some cases (changes of subtitles or audio for example, chromecast or access to video effect), and provide a media library to people who listen to a lot of audio.
> I use VLC primarily as a music player for my jazz album collection. It handles many formats I throw at it. It has a simple playlist (I play albums from start to finish and do not value a lot of spazzy track selection features).
It should absolutely still work. If it does not work as before, just tell us why and we will fix. I can even send you some early designs, if you are scared.
We are in no hurry, so we'll do well. It just requires more time, which is what we have :)
> If you privilege growth of new users you don't care
Who talked about growth? We're talking about VLC! We don't make any money by having more users, on the contrary.
> (I really don't understand this comment, nor the tone that I perceive as quite aggressive, but I may just misunderstand it. So answering anyway)
I think it was a bit aggressive, though i sort of understand it: one of the most common (if not the most common) complains after a UX change in any semi-popular program is that the change was negative for some people's experience and i think everyone who has used computers for a while has experienced at least once what they perceived as unnecessary UX degradation of one of their favorite programs.
So whenever the topic of some program changing their UI (regardless of reasons) comes up, a kneejerk reaction that goes fully towards the negative side of possibilities is expected. The more time people invest in a program, the more painful it becomes when they feel that their investment becomes worthless.
(EDIT: FWIW personally i do not make any weird use of VLC, so as long as it keeps having the common minimal slider, play, pause, etc UI i doubt i'll have any problems with it :-P)
Oh sure. But we're not doing a reddit-thingie: we're doing some reskinning of the player and adding an optional media library. And improving the audio usage quite a bit.
And we're using 21st century tech to overlay controls on the player.
We're not removing features from VLC, not removing codecs, not removing options.
I didn't feel aggressive when I wrote it to you, I'm a very happy VLC user, thanks very much for working on it.
I love the fact that VLC seems to be able to play and use most any media I throw at it.
I love that I can edit the play/toolbar stuff. Awesome.
I like the fact that VLC still has menus instead of trying to mash everything into a single menu "hamburger" ie like the browsers and some others have done. I'm skilled with a mouse and even I find "hamburgers" onerous to use.
I love the fact that VLCs icons are very simple, clean and clear what they do. I really like that they haven't changed much over time.
Most things seem to be where they should be.
I don't really see anything I wish was gone.
If someone that watches a lot of anime (or whatever) or something needs a special button or context menu added somewhere so they can enjoy VLC more, I'm totally fine with that and I'll likely infer the sense of it if it appears.
> I love the fact that VLC seems to be able to play and use most any media I throw at it.
Kept
> I love that I can edit the play/toolbar stuff. Awesome.
We kept that, and we will keep that.
> I like the fact that VLC still has menus instead of trying to mash everything into a single menu "hamburger" ie like the browsers and some others have done. I'm skilled with a mouse and even I find "hamburgers" onerous to use.
No hamburger menu, and we're even removing hamburger menu from Android.
On Desktop, the menu bar is hidden by default, but can be made visible always with a simple option. So if you want it, you have it.
Not just that, but the code of the menu has not changed. So all is at the same place.
> I love the fact that VLCs icons are very simple, clean and clear what they do. I really like that they haven't changed much over time.
We don't have many icons, so there won't be any change on that. But I can give you screenshots if you want.
> Most things seem to be where they should be.
We don't change much of the player UX
> I don't really see anything I wish was gone.
We do not remove feature, again.
So again, you should mail me and I'll give you designs and you'll tell me what is missing for you.
> The unspoken "problem" you have is that your existing users are doing just fine with VLC.
Depending on usecase, it's quite possible that current users are successfully using it but could have a much easier time of things with some UI tweaks. It's dangerous, yes, but it can be favorable overall.
> to understand what the needs where (we don't use telemetry/spying) And it took a lot of time...
Don’t worry, good design work takes time by very definition. Telemetry/spying does not magically fix that, and instead tends to lead to worse designs because people miss the forest for the trees.
Agreed, telemetry is a classic case of "more data is not better data".
With a smaller number of organized sessions, you can still collect telemetry (without spying), and you can also collect all sorts of information that telemetry just won't give you.
I suspect that a hands-on approach can be cheaper, too. It's just not any fun because it doesn't give you an excuse to play with your company's Snowflake warehouse.
I think there are certain things that are hard to achieve without telemetry. Like answering the question of "how many users will finally remove (hopefully) deprecated feature X affect?" or "Does anyone actually use this on platform Y?"
One thing that bites me from time to time: if I run VLC from the command line with a media file as the argument, but I screw up and don't enter a valid filename (easy to do with tab-completion, with multiple files matching and then accidentally hitting Enter before completing the name), then VLC starts up and goes bonkers. I have to switch back to my terminal window and Ctrl-C to shut it down.
If you take that to the extreme it becomes disrespectful and you'll lose those users to competitors who don't treat them as second (or third) class users.
A concrete example is controlling the player over a unix socket. A "geek/pro" feature to be sure, which VLC and mpv both have support for. mpv provides clear documentation of this feature while VLC provides next to zero documentation of this feature's existence, let alone how it actually works. As a "geek/pro" user, the choice between vlc and mpv couldn't be more clear. The former seems to pay lip service to UX while the later, despite promising little in the way of UX polish, actually delivers a more polished experience for anybody who might want to use these sort of features.
I disagree, these unix sockets are user interfaces, albeit not graphical user interfaces. I am a user who's trying to interface with these players, what could these be other than user interfaces?
And unfortunately 'lack of documentation' is putting it lightly. VLC's barebones manpage directs users to https://www.videolan.org/doc/, which in turn says the documentation doesn't exist and gives the user another link to a wiki. If you dig around on the wiki you can eventually find this brief acknowledgement of the interface in question: https://wiki.videolan.org/Documentation:Alternative_Interfac...
Documentation is part of the user experience (who is documentation for, if not for the users?), and in this regard VLC is very poor. I think this relates to VLC treating technically inclined users like second or third class users.
> But we will do our best so that the people who just use the basic player don’t have much changes for them.
Ok, thanks, I hope so ;-) I was asking because for me the UI is fine and
usually when software gets "redesigned" for no apparent reason it means
features get removed because "simplicity".
> I was asking because for me the UI is fine and usually when software gets "redesigned" for no apparent reason it means features get removed because "simplicity".
We are not removing features. If a feature is removed, it is a bug, and it will be fixed.
> If at all possible, please make it possible to continue using the current UI and keyboard shortcuts as an alternative.
Current UI is impossible for numerous technical reasons and for maintenance. However, there will be options so that it comes quite close to the current version.
I had another request question if you don't mind. Is there a possibility of adding a feature of pausing a video when clicking once on the video? This is pretty much the only feature which keeps me on MPC-HC.
I've never found it very usable, which I find sad because the functionality is so good. It's always been my last resort when nothing else would work, but never my first resort.
As for why they want to one obvious reason might be that the saw potential to improve it.
Kind of a weird comment, but honestly I think these are the best reasons for why a volunteer driven open source project should do anything to their ux.
yes... but thats often very subjective. In fact history has shown (for
me) that what others praise as an improvement of usability and user
experience is very often just a degradation of those.
See reddit, gnome, Windows 10, ... there is a long list of redesign-fails.
Are you looking at how you preserve the preferences too? I neither love nor hate the UI, which probably means it does a good job of getting out the way, but my one bug bear is things like when I turn off sub-titles they get re-added on the next video.
I think this might make fantastic fodder for discussion -- both the actual design, and the process of going about the redesign in an organization like the VLC project.
From a non-power user: I'd love to see the handling of subtitles becoming a bit more intuitive, specifically as to syncing them with the movie. Ideally, I'd match a sentence in the movie to the same sentence in the subtitles instead of having to iteratively mess with the delay so that the subtitles fit.
At least on Android, VLC UX is quite professional-ish. I never had a problem with finding something. Maybe because I am power user. But my non-poweruser friends are also happy with VLC.
Telemetry can perfectly be done in a privacy-conscious way. Getting real user feedback is paramount, but telemetry is super important as well because it has a scale that you can't achieve just by asking users.
What would you hope to learn from telemetry on a video player? Stats on the use of specific features? Formats? Codecs? Errors? I'm wondering if it's worth the hassle. Each of these is nontrivial if you really want to be privacy-conscious. Data can easily identify porn watchers, pirates, possibly journalists in conflict zones... and police only has to say cheese pizza to get all the logs.
Most non-open source players and codecs do that, btw. It is insane.
In the case of VLC, telemetry would help to know which options are used the most and which ones are not. It could help knowing which menus are never accessed.
> I prefer serving the average user who doesn't have time to dive into the settings and tweak everything before he is finally able to use the product. Striving for ease of use removes the need for most settings.
Serving average users by providing sensible defaults is a good idea but why does so many think that removing settings is a natural next step?
I've joked[0] about making a slide deck and start selling training to every modern software company :
> Have your cake and eat it too!
> How to please all your customers at once - Combining sensible defaults with the forgotten art of making your software configurable.
Multiple configurations are a maintenance burden. So, all else being equal, it's better not to have them. That said, not all else is equal, and configurability can indeed increase the user experience. But if your defaults are so good that very few people take advantage of the settings, you're better off dropping them.
At what point does user experience trump the ability to use the software at all in the first place?
UX designers are often seduced by reductionism because it makes their lives easier and combined with various hand-wavy aesthetical rationalizations, proceed to ignore several immutable aspects of reality:
Developers of an open source project usually have little insight into how their project is actually being used out in the real world. They only know about their use cases and (if they're lucky) that of their co-maintainers and bug reporters.
If at some point in time, an option was added to make some piece of the project do "x" instead of "y", it is overwhelmingly likely that the option _was put there for a very good reason_. Just because you don't know the reason doesn't mean one doesn't exist.
If the project has more than a few dozen users worldwide, then it is extremely likely that for every UI widget, command-line option, or configuration setting, there is a non-trivial subset of users who rely on that thing being there for their workflow. Remove it, and at best you lose those users. But more often you make them angry as well.
When looking at others' code and designs, it is a very human trait to assume that the person who created it didn't know what they were doing and that the way _you_ would do it is better. I get this and I fall into this trap more often than I would like to admit. _But it is almost always wrong_. We often look at the code in a vacuum and don't see the context under which is was written and why it is still there.
I've watched this happen time and time again with various open source projects: Person (or team) creates a successful project, maintenance of the project shifts to a new person or group who decide that the old project was "unmaintainable" and decides to a ground-up rewrite into what they _think_ is going to be a better version of the same thing. When in reality, all they have done is written a new, far less useful version of a somewhat similar thing.
Making things configurable is difficult, because it just explodes the testing space. Maybe that's okay for no-liability, here-be-dragons, use at your own risk open-source software, but for proprietary software that you have to support, it's a clusterfuck to give too many options, because people will inevitably hit on the combinations of them that don't work and then you have to deal with it.
> Adding features and settings is fun and often done without much second thought. In the end, it results in a bloated beast that causes a lot of confusion and frustration, especially among the type of users most open-source projects are missing, the average user who just wants to get things done.
A few large open source projects have tried to improve usability by removing features and options. Look at the history of Gnome 1 through 3. Professional UI experts were paid to produce usability advice for Gnome[1], and the Gnome developers responded with the wholesale removal of configuration options across dozens of major programs[2].
Mostly I actually liked this, because I prefer clean programs that I don't have to mess with. But a lot of other users were unhappy, because many desktop Linux users prefer knobs. Which is fine!
But what about Windows users and open source applications? Here, success may be more of a mixed blessing. I've heard several open source maintainers say that their Windows users are more likely to get angry with volunteer maintainers, and to display the sorts of behaviors mentioned in [3]. So widespread popularity isn't always a goal. Sometimes people just want to make a niche tool for other enthusiasts.
So it's worth asking whether any given project is seriously trying appeal to "the average user who just wants to get things done." Some are, some aren't.
I don't think there needs to be any friction between "knobs" and "usable design"; in may ways the absence of knobs can be deeply user unfriendly as well. It's all about how well it's designed and explained.
Not infrequently a settings page grows and grows until it becomes a chaotic mess, but that's not a problem of the knobs as such, but rather of the design of the settings page.
Also, a lot of the times the inline documentation leaves a lot to be desired. Perhaps the best example of this are many games where the graphics settings are just a jumble of technical terms with no explanation or even indication what is faster.
> Sun GNOME Human Computer Interaction (HCI), Sun Microsystems, Inc
Do you know the story behind why Sun was doing this work? I had no idea they were involved in this major culture shift in Gnome. I thought they were more invested in CDE.
You can see their focus - business users, scientists, creatives - and how that might have led to the current design philosophy of Gnome.
> Sun Microsystems, Inc. announced it is joining the GNOME Foundation [..] Sun also announced it will adopt GNOME 2.0 as the future desktop for its Solaris[tm] Operating Environment.
Be warned, above announcement is from August 2000.
And I believe OpenIndiana is still using MATE as their default DE, which is... sorta funny actually; the fork/continuation of OpenSolaris running the fork/continuation of GNOME 2.
> part of the reason why more designers don't contribute to open source is that often it requires you to rethink the entire product from the ground up
I think that's the key. Unlike software development, where you can improve things here and there incrementally, with design you need to have an overall view of what you want to do, where you want to get, how the final product should look. You can't tweak a margin here, add a border there over time, it doesn't work.
And indeed, I suspect that's also why there are so few designers contributing to open source. Anything of value they might suggest often means a big redesign of the app, which nobody will be willing to do. It's a tricky issue, to which there's no easy solution other than spending a lot of time and/or money, both of which are often lacking in open source projects.
> Unlike software development, where you can improve things here and there incrementally, with design you need to have an overall view of what you want to do, where you want to get, how the final product should look.
There's a downside to this too though. Take swagger-ui[1] for example. A few years ago I installed it at my company. It was great. Then managers wanted more features, so I peaked into the source and found it wasn't too hard to augment the HTML/JS. I added a search bar to filter HTTP APIs by dynamically altering the JSON document. I added a button to generate a PDF. I added a drop down to select release version from a database. It was quick and easy and hackable.
Then they got sponsored and redesigned it from the ground up "professionally" using React. I recently tried to upgrade to the latest version and... the level of complexity has gone up several orders of magnitude. Whereas before I just opened index.html and started hacking, now there isn't an index.html at all. It's all a labyrinthine nest of components and configuration files that somehow get magically compiled and bundled with some build process and I have no idea how to even start porting my features over.
I suppose it all makes sense to full-time React developers, but seeing as I mainly work in embedded Linux drivers, I don't really have a desire to learn React since I was previously coerced into learning AngularJS which I now regret.
So I guess my point is: if you pull in professional designers to design your FOSS, it may become less accessible and hackable for non-designers like me.
Two very different schools of thought I suppose. There's definitely a lot to be said for OSS that is quick and easy that can be flexible and modified by the end-user. It's also very nice to have source code that is readable (and of course auditable) by as many folks as possible, but I'll admit that I'm a sucker for complex (well-architected) polished codebases.
I don't understand how professional designers lead to React. It sounds like funding let to more complex design and more complex development, but those two don't lead to each other. I highly doubt many professional designers will insist that you have to implement their design with a specific library, much less do so themselves.
Professionals are going to use the latest and greatest tools at their disposal, aren't they? For web developers, that seems to be esoteric frameworks (React, Vue, Svelte, Webpack, Babel, etc. etc. etc. whatever the cool kids are using these days)
Compared to non-professionals who stick with tried-and-true glue (vanilla js, html, php, python, etc.)
It would be like if Jenkins got a sponsorship, so they hire professionals who rewrite the entire thing in Rust because it's the best suited for the job by the professionals' reckoning. Never mind that barely anyone knows Rust compared to Java.
> Professionals are going to use the latest and greatest tools at their disposal, aren't they?
Some might do that. Others might well tell you they have a professional obligation to make sound engineering decisions rather than chasing trendy ephemeral fashions.
Except my whole point was that to a designer a professional tool is Photoshop or Sketch or Figma. They're complaining good UI/UX design leads to React, when in reality following UI/UX and dev trends both flow from getting the sponsorship instead of causing each other.
> I think that's the key. Unlike software development, where you can improve things here and there incrementally, with design you need to have an overall view of what you want to do, where you want to get, how the final product should look.
I think many software developers would say exactly the opposite (and I think both would be wrong.)
Except the marketing effect of a new UI, do you have literature (or just easy explanations) that would help me understand why this should be the case?
The FOSS development model is best suited for modular software where you have a relatively stable core and dozens of independent plugins for different purposes by different authors, all implementing a well-defined interface. Any new contributor adds stuff in parallel, without being blocked.
Other kinds of software which are a particularly good fit are non-end-user-facing middleware and libraries implementing a standard or a protocol. That standard or protocol pretty much describes what the software must do, and FOSS software often becomes the "reference implementation". Think of zlib, libpng, ffmpeg.
For the regular monoliths you need a team that is much more well-knit and communication and focus is key. Each unit of code has a lot of dependencies and it can quickly get out of control without any "social" coordination.
> and dozens of independent plugins for different purposes by different authors, all implementing a well-defined interface. Any new contributor adds stuff in parallel, without being blocked.
This reminds me of Jenkins, which is the most nightmarish piece of software I've ever worked with. The plugins are of such wildly varying quality that it's hard to tell if something broke because of a plugin you just upgraded/installed, because the VM Jenkins is on got upgraded etc. And it's plugins all the way down. Plugins built on plugins. So if you try to file an issue with one plugin, they'll often just point you one plugin down the stack.
You get what you pay for, I suppose, and obviously a lot of people like the tool.
Jenkins goes south because the people using the system aren't the people configuring the system.
Consider instead a system like emacs, firefox, or mpv. Where the plugins/extensions/scripts are selected and configured by the person who's actually using them. Choosing what they want ignore what they don't, the result is a system that's understood by the person who actually uses it.
I agree with the article and am facing the same challenges in my own startup: how much, and what, to open source?
It's a platform that offers a simpler way of building serverless backends [1], and so it's naturally targeting developers. As a developer myself I know how much I appreciate things being open-source and free. At the same time it would come with huge business model challenges in my case and kind of erode what my product is all about (simplicity and having things taken care of for you).
While the article does not really offer any answers, I'm curious if anyone else has any experience to offer in this regard?
I'm in a similar position as you. Our decision was to open source our underlying framework but none of our infrastructure code: https://github.com/simiotics/shnorky
Our customers pay us for peace of mind, which takes work (and automation) beyond the core functionality of the open source product.
I don’t think that the “nerd porn” is as negative as the writer believes. If we compare FOSS to proprietary enterprise software we see how little regard proprietary vendors often pay to what engineers need at the expense of adding check-list features that attract “business” decision makers. The ability to enhance, operate, monitor, test are so much stronger in FOSS products because they are written for engineers by engineer. This can of course be taken too far, but it is, IMO, a reason why FOSS can succeed in displacing proprietary technology.
This minimalism fetish is grating. Guess what you need to "just wants to get things done"? Features. If you're in luck, these are standard features, but if not, they will be exotic features that would never be built under that "less is more" philosophy. And it's misleading to think that by only implementing the most popular core features, you'll make the most users happy. Projects often rely on those power users using their software, as these same power users will then advertise it by visibly creating great stuff in it and document it on sites like superuser.stackexchange. Not to mention that while every single exotic feature may only get used by 1% of your userbase, chances are most users will at some point need at least one such feature and would get disappointed by its lack.
A lot of highly popular contemporary open-source tools are feature-rich. Foobar, Winamp and VLC are all full of stuff you won't need (but what this stuff is depends on you) and extendable. Notepad++ has perhaps the largest number of menu items I've ever seen in a program. Not to mention browsers (whose feature creep is legitimately dangerous, and yet necessary), classic linux tools, office suites, IDEs, PDF editors... Even in the author's example (a sync tool), I'm not sure I agree. Dropbox with its (relatively) minimalist design was fun until at some point it broke for me (getting stuck in an endless sync loop). With some debug info, I may have found the issue and gotten it to work. The way it was, I just switched to Onedrive.
A more reasonable rule is probably "don't include features that could be split off into a separate tool without loss of efficiency or functionality".
I’ve been debugging a fair amount of service traffic lately, and I think I’ve about hit breakpoints in all of the major http client implementations in Node.
...
Every single one of them has so much delegation (to achieve some fucked up definition of minimalism) that it’s not even funny. And with async await it’s downright maddening. Even in node 12 with the async stack traces flag.
I’m taking over maintenance of a service and it’s throwing an unhandled promise rejection that’s a 403 error with a one line stack trace (which is in the wrapper we wrote because the library somehow isn’t minimalistic enough for our tastes). Took way too long to catch in papi. The stack trace is huge, none of our code in it at all, and the request is not even in scope for two or three frames away from where the error is thrown. This is, from a user’s standpoint, an awful library.
Anything I struggle to debug, I can guarantee at least a few of my coworkers will bring the same problem to me. Which means I spend three times as much time looking at bad library code as a junior developer would. That fosters a lot of contempt for code that is ugly on the inside.
What I really want as an industry is for us to start judging third party code by how sane the stack traces look. This has been bugging me ever since J2EE traces started going north of three pages (with the same series of four frames appearing three times). And sane stacks are going to require us to stop avoiding having a bunch of methods with a single line of duplicated code in them. Quelle horreur!
The whole point of code reuse is to reduce duplicated effort not lines of code. Arcane call stacks are huge amounts of duplicated effort, by people already having a bad day.
DRY is not worth all the lost hours and energy wasted in debuggers. Do better.
> A lot of highly popular contemporary open-source tools are feature-rich. Foobar, Winamp and VLC are all full of stuff you won't need (but what this stuff is depends on you) and extendable.
I'm not sure if you're implying that Foobar and Winamp are open source. They aren't.
Oops, I should have said freeware. (Though I thought of foobar as being OS for some reason -- probably from its aesthetic and design. Winamp, of course, predates the big wave of OSS for Windows.)
A great example (IMHO) of presenting the user with only a small subset of the available features is iOS. The tech-literacy bar to make calls, receive texts and install apps is very low, but there are a ton of features hidden for advanced users.
Some will complain that these are not discoverable and that’s true but advanced users will often be fine reading the manual and I suppose making them discoverable without confusing the average user is difficult.
Because as the bug reports come, you need to care what "advanced option" combination was in play. After fixing you need to test all possible combinations - it's an increase in cost.
Yes, but that's an entirely different problem then options confusing basic users. If you (as a developer) don't have the bandwidth to handle such use cases, then you don't have it, regardless of whether those options confuse basic users or not.
Though, for that particular problem, I think having a UI that produces an automated report for the developer which lists the state of all the relevant options/knobs can improve the situation significantly.
I recently released an open-source framework for machine learning debugging. Proper discipline can be the difference between wild success and a your project slowly sinking, like a stone to the bottom of a river.
Why? Because a customer adopting your product is risky, dangerous, and uncertain for them. They’re squeezed for time to learn your paradigm. They’re staking their reputation on the line with a boss, coworkers, and company.
The great irony is, that by adding features to support one additional customer, you harm the ten customers you already have. Ten happy customers become eleven “okay” customers, then twenty unhappy ones. Make the interface too complex? People will quit. Too many widgets, settings, and knobs will torpedo a project in no time.
I personally prefer that applications have ideal defaults instead of removing features. It should be easy to pick up an application and use it, but if you want to change something, you should be able to. This can be by using the settings dialog, or for particularly advanced features, by editing a config file. Some users have needs that cannot be met by a bare-bones application, and usually these users depend on Open Source applications that either implement their needs or allow them to change it for their uses.
Lots of this rings true, but i disagree about people only want to do the fun things.
First of all often what one person considers boring another considers fun. Optimization was used as an example, but often optimization can be really fun (its like a puzzle). More generally, in my experience with an open source project that has both volunteers but a majority of paid devs (MediaWiki), often the volunteers are motivated by making it work well for their niche and will take on really annoying projects important to their niche that have been ignored by the paid devs as not being cost-effective or a priority for whatever reason.
> All this clutter is followed by adding optional themes as a solution to the complaints people have about the user experience, which, in my opinion, can never fix the problems because they go much deeper than the superficial surface, and that is all that a theme can fix.
There's one case I've run into where themes are great. That is when one wants to improve a craggy FLOSS interface. Invariably a craggle will ask for an option to turn the ugliness back on and a non-default theme provides the perfect place to do that.
In general I feel that developers are very poor clients. Designers are better off finding freelance work or donating time to a non-profit they care about imo.
0. A lot of things are not-intuitive, and we've had to do basic UX and looking at our users to understand what the needs where (we don't use telemetry/spying). And it took a lot of time...
1. And yes, this requires to rethink some of the basics stuff for VLC usage.
2. And the nerd-porn part is very true: we solved it with 3 layers of access. Simple usage should be direct, Advanced usage for normal users should be within 2 clicks, and Geek/Pro options can be further away.
And we will have options for different usage of VLC that will impact a bit the UI (but we're making that as simple as possible, to not make the codebase too complex -> more time)
3. Finally, a lot of things had to be decided without consensus, and that requires leadership that is not the usual way we work.
I can share some of the work, if some people care...