I'm normally one who vastly prefers function over form and UIs that get out of the way of someone who knows what they're doing instead of catering _strictly_ to the use cases of the lowest common denominator.

But even I think the Calibre UI is pretty awful.

This is why we need more design expertise in FOSS. Your form/function dichotomy is incorrect.

You have software domain knowledge and experience working with spaghetti interfaces assembled by developers rather than designed by experts. You find them more functional because it fits your existing mental model of an interface. However, these interfaces are vastly less functional to everyone else.

An interface that only facilitates beginner workflows is poorly designed. I rarely see these in the wild, but the culprits are usually non-designers pantomiming their understanding of ‘designed’.

I do, however, regularly see developers misinterpret interfaces designed to facilitate advanced functionality for non-developers. Focused views with controls and readouts obscured as appropriate, but functionality exposed through key shortcuts or other means are what most people expect, and it’s a whole lot easier for a developer to learn those usage models than for non-developer users to learn how to use a hundred buttons and readouts acting as a thin wrapper around an API.

> This is why we need more design expertise in FOSS.

The secret probably is having well defined roles: whoever writes the code shouldn't be involved in interface design and vice versa, unless they prove themselves good at it, as the two tasks require very different sets of skills. This is easily accomplished in commercial software writing where roles are defined and salaries paid, but in the FOSS world where everyone and their cat want to be the famous developer, the UI designer role is rarely recognized for its importance.

And the main barrier to design work being integrated into FOSS is usually the attitude of project maintainers. I know plenty of designers who’ve worked as developers and all of them contribute to FOSS… just not as designers. The attitude of the post to which I responded is a perfect example of it— the way developers do it is the advanced way to do it but designers just want to make the Tonka version for idiots. It doesn’t fly in commercial software but FOSS is fun for a lot of developers specifically because they don’t have to listen to a project manager telling them to make it pixel perfect just like the designer asked. And hey — it’s their Project and they can do with it what they will, but it rubs me the wrong way to see those same people blaming users for struggling with their “advanced” interface and scoffing at the utility of experts and their work.

There’s definitely some utility in separating roles— as an experienced designer and developer I can assure you that making the right design decision is a lot harder if it’s going to be a pain in the ass for you to code — but the most important factor is having the right expertise for the task. We’ve all seen the cargo culted loopdy loop code written by non-experts armed with tutorials, and having one of them do the design and one do the coding won’t work out any better. Same thing with devs and UI work. Design is a wholly different skill set that requires study and practice.

While I'm sort of rephrasing what DrewADesign said, I think, it's not a matter of "form over function" as much as the difference between a UI designed around the tasks to be done versus one designed around the underlying data/function models. The latter can be very "functional," but that doesn't necessarily make it a good interface.

Calibre's UI isn't illogical or nonsensical, and it can do everything you probably want when it comes to managing an ebook library, converting between book formats, and taking files and off ebook readers. But it doesn't feel like anyone involved with the UI design ever really thought about it from the perspective of "how do I make the common tasks easy" rather than "how do I ensure all the functionality is exposed".

I think the classic design phrase "form follows function" best describes the ideal.

That is, when designing something, and especially when there's nothing to yet dictate what the form should be, let function guide you to it.

If you were to ask "how should a table lamp be designed", I would point to its function -- to give diffuse light and allow switching it on and off -- as the primary guide. Make that work well. Don't let the form get a life of its own that will distract from the function. Rather, the form should serve the function and make it beautiful.