Reflections on "Intuitive"

People sometimes criticize a piece of software as being "unintuitive". In fact, its one of the most common complaints you'll hear whenever anyone starts using a new piece of software. Its often entirely justified too - its rare that a complex application manages to be obvious to every new user, or even most new users. Some software developers have a good track record here, Apple in particular, whose rules and guidelines for how to design user interfaces keeps on manage to churn out remarkably intuitive software. Well, it does as long the application is fairly simple and its scope is well defined. By the time you get to applications such as Final Cut Pro or Logic Pro, it would be hard to find anyone who found them "intuitive" in the same way that, say, iTunes or even Garageband is.

The fact that users want "intuitive" software puts some software developers in a difficult position. If their software is intended to perform many of the same goals as an existing software tool, then they can end up being faced with two possible ways to go about things:
  1. slavishly copy the precise workings of the existing tool(s), and see their work labelled as a copy-cat, derivative and "catch up" application
  2. do things differently (to some degree) compared to the existing tools, and see their work labelled unintuitive, hard to use, "unnecessarily different"

Neither of these are desirable outcomes for most software developers, but its hard to see how they can avoid either of these outcomes if they are working on software that is aimed at tasks already addressed by several successful tools. As a result, it becomes necessary to develop a rather thick skin when people make these kinds of observations. Most people who think that a particular human tool (software or otherwise) is intuitive often fail to realize just how many hours/days/week/months they have put into getting to their current understanding of the existing tool(s).

Of course, its also necessary to be open to the idea that whatever ways your application differs from "established design" might actually be wrong or inefficient. Unfortunately for us software developers, its much harder to convince users that their existing ideas of what is "intuitive" or "easy" or "efficient" might actually be sub-optimal. This is one of the reasons that a healthy open-source-centric user community is such a great asset during software development - the give and take between the developers and users in this model tends to be filled with far less exaltation and timidity on both sides and instead is often characterized by healthy skepticism on both sides that the other really knows what they are talking about. Its really great to be able to chat with Ardour users in real time on IRC, and often have both myself and the user(s) arrive at new levels of understanding of the task, possible designs and workflows and the pitfalls of each of them.

Of course, its not that proprietary software doesn't involve a certain amount of this kind of feedback, and in some cases (mostly very large companies) there is is really wonderful use of end-user testing that leads to deep insights that would not be obtained by just talking to the user. But the awareness that only the annointed developers can ever change the behaviour of the source code changes the balance of the dynamic between developers and users - here in open source world, even as "lead" developer of Ardour, I am constantly aware that anyone may come up with a patch that others see as a great improvement over the work that I did, even if I do not. This benefits users - for obvious reasons - and it benefits me (and other core developers) by keeping us honest about our power to control the design of the software. It also enforces a certain humility - the next great way to improve Ardour's operation may not come from any existing developer at all, but someone we've never heard from before.


People used to think Microsoft Word was intuitive. Then Word 2007 came out, and the menu structure changed. It turns out that those people had simply learned the old interface. Whenever I, or any of my friends, uses the “I” word, it is a joke. I don’t know how to communicate the difference between the “I” word and choosing to learn software to normal people though. They have all been using windows all of their lives and that’s what they base all future gui experiences off.

Keep up the good work Paul! The most important thing, as you stated, is that you are using critical thinking to make UI decisions, not flash and flare like some crazy plugins I’ve seen.

To all the haters: write your own frontend. : -D


Nice Statement… I must say, that I actually found ardour very intuitive when I first saw it… So “intuitive” is very subjective word… It depends on what the user knows and feels… I mainly worked with Cubase back then and the main-difference in usability (despite MIDI editing) for me was, that the keyboard-shortcuts where different as hell… I needed some clicks here and there and then I recorded my first Track in ardour… On the other hand, when I first saw Apples Logic Pro, I was overwhelmed by the complicated Interface…

Well, so I think what people think is intuitive, depends on what they worked with so far…
By the way, I think a cool thing for ardour would be multi-touch-support, imagine, use three fingers to scrub along with a song etc… Well, just of that while I was typing…


I have the feeling that many of these complaints come from people who simply have not enough understanding of how to use a tool like Ardour in general. Actually, it’s not an issue limited to Ardour at all. You can see this in IDEs, wenn beginners hit a tool such as Eclipse, or in statistics, when beginners find a statistics package “unintuitive”, just because they don’t know enough about statistics to make any sense of its functions.

If one never has wired up an analog desk and a side rack before, of course Jack routing and the Ardour mixer might appear as a wondrous miracle - but actually it’s not their fault. But if you know what inserts and sends are and how one could connect things in the analog world then I think it’s rather easy to use.


I have to agree with slackwarebilly: I have been using both Windows and Linux for a long time, and I never feel so lost as when I’m on a Mac. Some people are in the exact opposite situation: I guess it’s just a matter about being used to the environment.

I don’t mind spending time on a software to learn how to use it, just like it takes time to adapt to your new environment when you move to a new flat.
What I would call « intuitive » though, would be:

  • to be able to find a feature quickly if you know it exists but don't know where it is in the interface (coherent menus, good layout, …),
  • and to be able to discover features by simply wondering around the interface (using tooltips, contextual help, self descriptive menus, …).

The perfect counter-example for those to points, to me, are macros in Word 2007:

  • the ability to record macros is hidden in the “View” ribbon (somehow incoherent),
  • and the button “Record a macro” has the description “Start or stop recording a macro” (which is not really helpful for someone not knowing what it is about).

Before I was a 100% MS Windows user. My main working environment was 3d and CAD based. I learned how to use the most “commercial” and “powerful” well known apps, like Autocad, 3D Studio MAX, Maya, Lightwave, Lightscape, etc, etc, and I thought I was a very advanced computer user, and all my software was intuitive including the OS .

When I first saw blender 3D I thought it was a piece of crap, even “unintuitive” maybe back then it was, but everything has to start somewhere.

I later worked in GE Aircraft Engines forced to learn the UNIX OS, and quickly falling in love with it, I was even more surprised to see a small HP/Compaq common desktop pc that you buy in Office Depot running Red Hat and acting as the main file server for over 100 of these UNIX monsters with Unigraphics in them.

I realized I was on the wrong side of the tracks.

When I switched to Linux and slowly learned (and I am so happy to say that I still learn almost every day, I think that’s what makes it so wonderful, there is always mystery, and mystery always builds the passion). I learned how to use blender (and many other great apps), and now it has become my number one program for architectural renders and lighting analysis with aditional GPL external renderers.

And needless to say, Ardour is probably my favorite application of all, it does the job for me, it does it well, it does it fast and the most important, with simplicity and fun.

So to re-phrase all this, “intuitive” means that to me. Not just something by its looks (or maybe even how much you paid for it) but how it works and if it does help you get the job done, and Ardour has surely fallen into that category for me. It is one of the most professional applications I have ever used, and it is one of the most beautiful also! And I can say it is a very powerful and complex piece of software but easy to use with a nice and smooth learning curve.

So these last ten years Paul (And additional devs), you have done a hell of a wonderful job with all this, and thank you so much for it.

Next time someone tells you that what you do is unintuitive, tell them they have an unintuitive mind…


Good thoughts. I have to say that I had difficulties with Jack at the beginning, but once I was aware that Jack acted like a patchbay, it seemed obvious. My problem was the automated routing Ardour offers which confused me at first. I had no problems with Ardour itself, since it represented very well what I had learned on “real” gear like mixers, FX processors etc.

Intuitive is a strange word. “Intuitive” depends on the knowledge of the person using the software or gear. I had a certain knowledge of rack gear and how to connect it, so I find Ardour more intuitive than others who don’t have that kind of knowledge. I find the Input and Output in the mixer strips very useful, so I don’t have to go to Patchage and figure out a lot of connection lines. I can work much faster with this. Works for me, and I wish I had discovered that workflow much sooner, but maybe I am in a minority here.

I think Ardour is simply a tool that does require knowledge beforehand to work properly. As pointed out, GarageBand for example is simple and intuitive, but limited. If you want to go further and have more options, you have to learn more. I remember putting my guitar rack together. At first it was simple and easy to understand the routing. When MIDI and more gear came into the picture, I had to learn. I sat a few weekends to make it work like I expected it to.

More complexity always brings a higher barrier. I think an application as complex as Ardour can only try to make a workflow as smooth as possible. That’s certainly enough for me. What the workflow should look like is of course a point of discussion and one can’t please everybody. But I think Ardour is doing a good job here.

Personally I found Ardour quite easy to use in the beginning, having used several other DAWs (and hard disk recorders). I believe, however, that two main factors drastically increase “intuitiveness”, namely:

  1. Generic naming (and tooltips) - This is one area where open-source software in general is very good. When tasks are named in the menus according to what they do, you can use them quicker. Proprietary solutions often ruin intuitiveness by giving not only the applications themselves, but the functions they perform catchy names. This is presumably so that they can market their product as being the only one with “X”, but when people learn on systems like this, they are lost when they switch to another piece of software which perfoms the exact same function, but which has a different name in the menu or on a button. One area that I think needs improvement though, is in menu entries that packagers create. For instance, if one installs Ardour in Ubuntu, you get a menu entry that says “Ardour GTK”, and a tooltip which says “Ardour Digital Audio Workstation”. For someone new to linux, recording, or computers in general, this is all a bunch of gobbledegook. In the future, my packages will have a menu entry named “Ardour”, and a tooltip that says “Record, Edit and Mix Professional Multitrack Audio”. I realize it’s a bit wordier, but at least the end user can save time looking up DAW on wikipedia.

  2. Customizable Interface - Ardour’s ability to modify shortcuts should be standard for all software IMHO. People who have never used comparable software can be expected to learn the stock shortcuts, and those who may use Ardour on several different systems would do well to learn them too, but for anyone who is coming to Ardour from Cubase, ProTools, Logic, etc…, being able to make Ardour perform the way you expect it to (or perhaps just the way you want it to), is a huge bonus. This combined with the ability to show/hide and move dialogs, buttons, and child windows makes learning any new software easier. Not only that, but if people used this feature to its full advantage, we could easily create packaged versions of Ardour (or scripts) to make it behave like Logic for instance, or Cubase, or what-have-you, so that others coming from alternative software can make an easy transition.

Ardour is in my top 3 of the most intuitive pieces of software I’ve ever seen.


I used to wish you could observe Ardour being used by professional engineers and musicians. Many times I’ve thought “here’s an opportunity” or “here’s a problem”. Explaining work flow over IRC is a distraction when Ardour is being used and that’s when user insights are developed.

My rule is; musicians never wait for me. In my world, efficiency rules over anything that could be meant by “intuitive”. I’ll learn the software on my own time but no amount of study overcomes deficient, under developed or undiscovered work flow designs.

I’m no longer compelled by design. In part because I can find a solution for the task at hand and because IRC is an interruption. What takes a day to explain on IRC can be experienced in a moment.

If Ardour 3 can be usable but still in design then I’ll buy you a plane ticket and organize an appropriate session.

I don’t think about why I like Mixbus. I do and because of that I am adapting and redesigning my studio. I guess “why” isn’t as interesting as serving my client or producing music. I should read the gearslutz forums to find out why I like Mixbus. :slight_smile: Okay, it’s the familiarity and quality of DSP.

Just my opinion, but I think that designing a complex app for a newbie (“intuitive”) is a red herring. A better standard is to measure how smooth and fast is the workflow for the user that has mastered the interface. Measure by what the pros are doing with it, not how comfy the noobs are. That just leads to dumbing down, in my experience.

I have a strong prejudice against the ProTools model, but have been pleasantly surprised that even following that wrong (IMO) direction, Ardour provides workflow that almost keeps up with my old Sonic Solutions work environment. At the end of the day, i don’t really care about the method, as long as I get the work done and it sounds good. With Ardour, so far so good!

I’m a workflow nut myself. Ardour fits the bill.

When I started out with Ardour, in the exiting days of 0.9x, it was already intuitive enough to record a project for my first client, without having to consult a manual.

Not much has changed since, and the only manual page I sometimes look at is the keyboard shortcuts page

Thanks for my #1 creative software

@macinnisrr: I wouldn’t advice spending much time on a-la Logic or a-la Cubase customizations. I’ve been there with Inkscape, having produced shortcuts for Illustrator, Canvas etc. users, and lately with GIMP re. Ps CS4. Applications just don’t overlap a lot for a number of reasons. In some cases they almost don’t overlap at all due to workflow differences (e.g. ACD Canvas has nested groups of tools with duplicated shortcuts, so a tool in group X has same shortcut as another tool in group Y). Thus in the end you neither get complete previous-app experience, nor can use the new app to its full potential. Dead-end. It’s better to learn the new app from scratch really. All the shortcuts and all the logic in Ardour hasn’t come out of blue after all.

1 Like

One of the challenges, I’m sure, is catering to both those coming from other professional DAWs (because Ardour and Mixbus are themselves poised as professional DAWs), and those coming from little or no professional DAW experience (because of Ardour’s low-to-nonexistent entry price). Being someone in the former camp (I used to use Cakewalk), I can say that I immediately appreciated Ardour’s workflow: I found that the functionality I didn’t need wasn’t there getting in the way, and the functionality that I do need is available right from the main GUI rather than being drowned in a sea of menus and “third party add-ons”.

Had I been coming from the other camp, I can see how Ardour’s UI would have seemed a bit intimidating… however the hurdles would have been no different, and possibly fewer, than those present on any other system; except of course for the hurdles involved in getting stable audio on Linux. But audio in general is just complex stuff with a learning curve, there’s no way around it. Think of the people who ask… “do you know what all those knobs do?” Well yes, but I wasn’t born knowing it – I learned the important knobs first. :slight_smile:

Thanks again for your hard work, Paul + Ardour team… can’t wait for A3.

An advantage of opensource is the active feedback of users towards developers. The lines are short so to say. An disadvantage may be that all those different opinions of users, makes a gui complex.

You need good management of people with a clear vision towards usability, who decide at the end how the gui will look like. I can imagine, that is more easy for an company to make clear rules about how a gui should look like, then an opensource community, with all the different visions. Freedom could also a disadvantage here. Apple doesn’t give developers that freedom, but they might give them strict rules about how to do it. Also I wouldn’t be surprised if Apple has some cognitive psychologists and/or GUI expert work for them to do research /experimentation with this… it’s an profession.

A small example of an disadvantage of the opensource community way of working is the naming of plugins. You have in Ardour ‘Reverb’ and ‘Reverbs’, the same type of plugins, but different menu items… (I know this is not the ‘fault’ of Ardour devs, but an example of what might be an disadvantage of an opensource community compared to an company).

I was involved in brainstorming about an Gui of an opensource application. I was shocked by how complex it would be, because of all the users/ devs who wants to have their own favorite gui for their favorite workflow for their favorite WM. So this (individual) freedom is not always good for an application.

I think when you want to have an intuitive gui, you should also take in account, more or less, what people are used to and how other apps in the market does things or name things. (I believe that’s why Mixbus renamed some stuff (sends or something I believe)). Don’t make it unnecessarily difficult to switch from one DAW to another.

Interesting research is this btw, for GIMP:
Would be interesting if some researchers take Ardour as research subject…

I don’t say Ardour does an bad job here. Not at all! And lots of argumentation in Pauls post is true.
(Allthough we might need some video (like the mixbus video) to explain the GUI a bit better for (new) users.)

But I doubt if opensource tools and the way opensource is working is always good or better then proprietary software… We might be a bit biased here, just like people who always worked with Windows… The true is somewhere in the middle maybe :wink:

Ardour has become more “intuitive” with each release since 2.0 in my opinion. As features have been added, crowded menus have been re-organized in ways that are more logical. Tooltips do a decent job explaining what something does. Best of all, there are keyboard shortcuts for so many things and I don’t have to dig through a manual to learn them: the shortcuts I want to know are usually listed right next to the menu item I want, or in a tooltip.

The one thing I wish I could do is move the mouse pointer over a “fader” control and roll the mouse wheel around to adjust the fader’s position in sane increments (like 3 dB) and record automation that way. But most everything else is nearly perfect.

So, so many Linux developers could learn some very valuable lessons from the Ardour team.

@naptastic: your mouse wheel should work just fine on all “fader” controllers. Could you be more specific about the issue there?

1 Like

I came to Ardour a few years back!
I was using Sonar on Windows. The learning curve was just the same for Ardour as it was for Sonar ( results a lot cleaner in Ardour, maybe someone should explain how much better Ardour and Linux in general treats your sound files)

In all the Forums for Sonar the same complaints about ease of use.
Ardour is as easy or hard as you want to learn, I’m sure there a re features I have never used lying under the hood.
But I get great results from what I do use.

Learning the software is as important as learning your Guitar or whatever you play.

I think it’s useful to make a distinction intuitive' andfamiliar’ when it comes to user-interfaces. Familiarity of course depends much on people’s prior experience with other user-interfaces. But apart from familiarity, I think a user-interface can be intuitive to a greater or lesser degree. An intuitive user-interface to me reflects the internal logic of the software, and related to that, the workflows involved in the different tasks that people use the software for.

In the case of ardour, I know that the internal logic has been the most important aspect of development. I think it’s good that the design of the user-interface is guided by that logic rather than by making users feel comfortable by mimicking familiar DAW’s, because in the end, I think it’s easier to grow familiar with an intuitive user-interface than with an uninuitive one.


I have been giving this thought ever since it was bought up in the podcasts Paul did a few months back.

Maybe we should think of intuitiveness as the ability to get some sort of positive result in spite of the users lack of understanding of the software as a whole.

Lets take a simple task -recording a single track in a single take.
Lets do that task in Audacity…

  1. Open Audacity
  2. Press Record. Press Stop when you are done.

Lets try the same task in Ardour.

  1. Configure Jack - This includes dealing with the broken defaults shipped with certain mainstream Linux Distros. (not necessarily Ardour’s fault but still an added complication for the user).
  2. Start Ardour (or start jack then ardour)
  3. Create a new track. There is no obvious visual way to do this. Either the user knows what to do or they will be stuck.
  4. With the tracks having the proper inputs selected (hopefully this worked automatically) each track you wish to record has to be armed.
  5. The global record button has to be pushed.
  6. The playback button has to be pushed. Stop can be pushed to complete the recording.

The problem with this last 3 steps is that unless 3 sets of buttons are pressed the user doesn’t actually get a recording. For this simple task Audacity is intuative, Ardour is not. It is quite possible to say that Ardour is only interested in advanced users.

The reason that many users will call Ardour unintuitive is because the very first tasks they try will likely fail without some sort of external guidance (either past experience, help from another user, reading the manual or an online tutorial).

I have a few simple suggestions.

  1. The default template should have a track or two rather than none. Advanced users should be able to set their own default templates including a blank one. Also there should be a clearly visible means of adding tracks.
  2. Tracks should be created armed by default. For advanced users where this behaviour is undesirable it should be possible to switch back to the existing way of doing things.
  3. Some sort of popup hint that both the record and playback buttons are needed to record successfully(as unintrusive as possible). Visually grouping the buttons together could help give the right sort of hint.

After this the path of least resistance should look like this.

  1. Configure Jack
  2. Start Ardour
  3. Hit the Global Record Button
  4. .Hit the Playback button.
    Which is an improvement but still not as easy as Audacity.

While the basic concept of your post has merit, I have to disagree with the majority of your suggestions.

1) The default template should have a track or two rather than none. Advanced users should be able to set their own default templates including a blank one. Also there should be a clearly visible means of adding tracks.

Define ‘Clearly Visible’? You mean going into the Session Menu and going to Add Track/Bus isn’t clearly visible?

2) Tracks should be created armed by default. For advanced users where this behaviour is undesirable it should be possible to switch back to the existing way of doing things.


This works for one particular set of work, when you go into it tracking straight. That is the only workflow it works for. Any time you deal with mixing, editing, or even just importing existing sound files this is a VERY undesirable effect.

3) Some sort of popup hint that both the record and playback buttons are needed to record successfully(as unintrusive as possible). Visually grouping the buttons together could help give the right sort of hint.

I can somewhat agree with the concept of grouping the buttons, but on the other hand it also makes it much easier to hit the record button on accident in doing this. Just because a track is armed doesn’t mean I always want to record to it.

1 Like