Hacker News new | ask | show | jobs
by mxcrossb 1868 days ago
IMO the problem is that OSS developers hate any change that’s made to a UI because it breaks their workflow. As a result, a lot of OSS has old style interfaces, and it’s hard for UI designers to convince the others to make changes.
9 comments

I think that more accurate would be saying is that OSS is often developed by people already using it and used to weird interface and not benefiting from it being usable by newbies.

So there is much smaller motivation to improve it.

And avoiding change for the sake of change is something that I actually like. One of reasons why I switched to LibreOffice and later to Linux is because I am not fan of relearning interface without a good reason.

-------------

But nearly every software would benefit from running small scale UX test. Take three people, ask them to do the most basic tasks - and fix the most common problems.

Your software is much harder to use than you expect.

Related is this: sometimes you have been using a piece of software for such a long time you can no longer judge whether the user-interface (UI) is any good. You've simply mastered the steps (and keyboard shortcuts) needed to accomplish a task and it now feels "natural", no matter how clunky or clumsy the steps remain.

And there's also a widespread belief among developers that making a task easier in the UI means "dumbing down" the UI. Or that making software easier to use means it could never satisfy "power users".

Developers love to revel in arcane interface minutiae (especially for command-line tools). They think it's equal to acquiring a skill or knowledge. But it's not really. Instead, it is the perpetration of a clumsy method to completing a task. But now that the developer has mastered that method (and that feeling of "knowledge" gained as a consequence), they won't easily let go. Or be easily persuaded of a different method.

Instead, it is the perpetration of a clumsy method to completing a task.

Not in every case. For experienced/professional/power users of any software, what matters is maximizing the information density in time of both input and output. Sometimes the best way to do that appears arcane.

I want to be able to accomplish much in as little time as possible, so I want a high temporal input information density. So that might mean using a mouse instead of a trackpad for precise aiming and scrolling, or using keyboard shortcuts instead of on-screen icons. It might mean there are different mouse behaviors for ctrl-drag, middle-click-drag, etc.

I also want to be able to receive as much information about the state of the application as possible in as little time as possible. Too little density and I have to keep more state in my head and spend time jumping around. Too much density and the senses are overwhelmed. This might mean, for a CLI tool, that zero output is the best output in case of success. But for long-running processes that might be a progress bar under a list of log entries. For GUIs, the optimum might mean that there is a lot of information and a lot of actions on screen with reduced whitespace, which seems intimidating at first but is necessary to communicate the state of the system to the user.

So convincing any power user to "let go" is like asking someone to give up their legs for a scooter. Sure, it's simpler to go places in mostly straight lines with a scooter, but linear motion is only one of the many things people do with their legs that justify the arcane UI of unstable bipedal locomotion. We walk along streets, run along trails, jump over obstacles, dance, spar, climb, swim, etc.

This is not to say that scooters have no place, or that every tool is at a global optimum. But any "different method" that someone wants to propose will very deservedly receive pushback if it does not fulfill the full purpose of the old method.

A good example is the UI of Adobe Photoshop/Illustrator/InDesign, which is not at all intuitive. I was incredibly confused when I first started using them, and it took me a long time to become proficient. But now I've mastered them, the absolute last thing I want is for them to do a UI overhaul.
I do not hate when an application I use revamp its UI (e.g. Pixelmator -> Pixelmator Pro). However, developing good UX is as hard as developing robust code and high performance algorithms.

Unless the devs get UX improvement backwards (cough GNOME cough), there's nothing to worry IMHO. OTOH, for a CLI application, backwards compatibility and/or graceful depreciation is key.

Modern "UX" is just a failed premise. It favors hand holding for the novice, which someone won't remain forever, over efficiency and control for the experienced user.

"Old style" interfaces are universally better than tabletized crap, and had as much and higher quality research into the choices behind them. It's not limited to OSS. Apple is a glaring example of that right now. The Mac Human Interface Guidelines and the thought that went into the Mac OS were phenomenal. Contemporary style changes driven by users' familiarity with tabletized (or dare I say "Fischer-Price") UIs are regressions. Visible things become hidden to look "cleaner," keyboard control is ignored, oversized buttons are favored.

Much of OSS UI/UX however does not follow such excellent guidelines, but is rather a kitchen sink, and that does not in truth well serve either power users nor novice. As you are suggesting, the design must have thoughtful work applied.
Is there perhaps a way to make difficulty level selection sliders like you see in games but for these tools?
I love those blender tutorial videos, were they dont even bother to tell you were in the menue the button is for something, and instead go "press key x y z" - though 2.8 has greatly improved the whole affair.

This should in theory allow for a complete redesign of the gui though, as the core audience uses shortkeys anyway.

Its also from the facts that almost every "redesign" or presentation for one, is often full regression in use ability terms.

It does help when software users that happen to have good UI chops suggest redesign because then it often improves things, as I've seen happen with KDE and Budgie, at least. But pulling in UX "designers" who have no skin in the game and letting them play around is how you get ridiculous unusable crap like Google Pay, Apple Music, Windows 8, whatever Google is calling their Android UI now, and more.

Agreed here.

And also the attitude of "works for me" really pushes usability people out.

I think a good approach sometimes is to decouple UI from other things as much as possible, then make "classic" UI optional for the people who value that while the improvements are worked on separately. It depends on the project if that just ends up being too much of a hassle or not.
What I find difficult is the lack of communication. Programming UI changes is hard work, and when a developer isn’t convinced of the benefit to users, it makes it seem like the change is being made for the ego of the UX designer.