I don't like the word at all when describing interfaces. It's an overly broad term that in my experience doesn't tend to lead to very good conversations about what's good or bad. Case in point, we recently did a complete UI make-over at $JOB and the bossman keeps referring to it as the new 'more intuitive UI'. We moved a few buttons around and changed some font sizes, but the most visible change is the completely new colour palette. So yeah.

I'd also argue that nobody is born with an intuition to work a DAW or any other piece of software, and in that sense I think it's just a misleading term.

I think there are much better words to use to talk about whether a UI is successful or not: "Familiar" is a good word, because then you can ask "familiar to whom" and have a good conversation about what kind of users you have, their backgrounds, how much work you expect them to put into learning your software, etc. "Internally consistent" is another thing you can talk about and to some extent quantify. Being "discoverable" is another thing where you can talk about the balances between having everything right in front of you and a complete information overload. And of course, you can't really get around whether or not a UI is attractive, displaying good colour sense and being visually balanced and such. While you can certainly make pretty things that are impossible to understand, I would tend to argue that there is a bare minimum of prettiness needed to make something that's friendly and engaging.

(PS: Thank you very much for Ardour, it is a remarkable piece of software.)

"The only intuitive interface is the nipple, everything after that has to be learned."

And even that's not universal, it's quite normal for newborns to struggle with feeding.

I don't think it's about familiarity at all. I think it's about mapping domain knowledge to users tasks with as little friction and unnecessary complication as possible.

You might think that's the same thing as familiarity with existing software, but it really isn't.

For example: Cubase. You can do a lot with it, but it's a mess of accreted features with some bizarre near-duplications, all splattered around almost randomly. A good few are entirely hidden. You won't find them unless you read the manual and/or watch a video - if you can find it.

A lot of people use it, but it's not a model you'd want to copy.

Ableton Live is more of a mix. Some features are very intuitive, some are less so. But someone has at least thought about typical task-based workflows and tried to minimise the number of UI entities and clicks required to perform them.

None of this is mysterious. The principles of good UI design are well known: minimise clicks, minimise pages, minimise the number of entities that users need to remember, avoid multiple access points for features, avoid hidden modes and secret key combinations (unless it's a command-line app, sort of), group related features, concentrate on implementing the most common tasks with as little friction as possible, avoid constant mode switching, avoid long lists of unrelated items, try to handle windows and dialogs intelligently to avoid clutter, make all operations as consistent as possible, follow general OS and industry standards. (Etc.)

Of course software is specialised and if you don't know anything about DAWs - or photo editing, or 3D - you're going to have to climb a learning curve.

But domain basics are standard. If you know them a good intuitive tool should be able to make them available with as little friction as possible. And a really good tool will anticipate what you're trying to do and make it even easier than you were expecting it to be.

Thanks for Ardour. I've been using it on an off for a couple of years now (every time I get the itch to remix some pop song that's stuck in my head).

I will say that I consider Ardour unintuitive, and reading your post on the forums I think we have different takes on the perspective used for this criteria. You seem to be making the argument for users coming from other DAWs to Ardour, whereas Ardour was for me was the first DAW I used. Thus rather than comparing it to existing tools I always try to find out how to do X, and often I have to Google for help because what I expect to be possible is not straightforward/"intuitive".

Let me give out two examples that tripped me up recently

1) Wasn't able to easily reorder my tracks. I would have found intuitive to be able to drag & drop tracks within the main view. Instead I had to switch to the mixer view to reorder them.

2) I was playing around with a song that had around 20 stem tracks. Grouped them out by voice, melody, percussion. But once grouped I couldn't find an easy way to solo an individual track within a group, as the solo button would solo the entire group. For me a group specific set of controls would be intuitive, whereas existing buttons changing their behaviour is not. If I recall correctly I had to click the group name in the main view for it to become uncolored (disabled?) for individual controls to effect individual tracks.

Re: 1: View > Show Editor Lists and then you can drag & drop in precisely the same way as in the Mixer window.

Re: 2: the primary modifier key (Ctrl on Linux/Window, Cmd on macOS) overrides group operations universally. So click on a solo button for one member of a group, solo the whole group; Primary-click ... solo just that member.

1) That's definitely useful info, I was not actively aware of the Editor List. If it shows up on the first Ardour startup I probably closed it out just to have more room available in the default setup.

2) Also wasn't aware of the "primary modifier key". What I noticed from giving it a quick try on my project is that when holding down Ctrl cannot solo a single track in the Show Editor Lists -> Tracks & Busses window (clicks are prevented). Nor does it allow me to adjust individual volume sliders per track within a group. But seems to work for all the other track controls.

Re 2: the editor list "Tracks&Busses" tab uses a GTK TreeView for displaying status and offering controls.

GTK's treeviews don't make it very easy (understatement!) to make cells in the treeview detect keyboard modifiers. When you click on the green/gray box in the solo column, mostly what we know is that you clicked, we don't tend to get modifier info. I was referring to tbe buttons in track headers/mixer strip, but you're right it should be consistent/universal. I'll see what I can do.

Regarding faders not being group-overridden by the Primary modifier ... yes, that's true. Ctrl-drag on the fader provides finer-grain control. However, there's a reason for this difference. In general, we recommend that people use VCA's for group gain control and disable shared gain control in a group. It gives you a much more flexible working style, and is a feature typically found only on extremely expensive mixing consoles. Ardour offers both SSL and Harrison style VCAs (i.e. heirarchical/stacked or parallel), depending solely on how you set things up.

My instinctive reaction to any software product advertised as "Intuitive", "Simple", or "Fast", is full-on Generation X "what utter bullshit" skepticism.

A greenfield software project in an inherently complex domain may be intuitive, simple, and fast at first, but claiming it will stay that way is like advertising a rock you throw into the air as "Flying".

The "intuitive" thing is largely the sum of the usability issues that open source developers typically don't have the time/resources to fix or even gather data on.

E.g., how many new users have gotten frustrated with the default setting one of your users described which doesn't allow drag-and-drop of tracks in the view? 0%? 100%? If you knew the answer and that answer motivated you to make an improvement, then that moves the software one notch away from "unintuitive" toward "intuitive."

Most open source projects probably cannot easily get the type of data needed to make these assessments with much accuracy, so they find other ways to grope toward UI improvements. Nevertheless, what non-technical users call "intuitive" is still a real thing, and they know that because they've felt the frustration of "unintuitive" UI choices eating more than their fair share of cognitive capacity.