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.

I built recently Ardour 3,

I built recently Ardour 3, and i was greatly impressed by the new MIDI pianoroll. You see directly the notes on the editor window and can set the range interactivly. Wow ! :) You cannot make something more intuitive ;)

There are others improvements that need to be noticed like the horizontal sliders for the FX Send, now you see them all at once and can fine-tune the amounts with ease.

The dialog box to route tracks/insert/bus/outs has been revamped (i have yet to dig into this).

And another little detail that says everything, i wandered myself to try the timestrech tool on a MIDI part and, at my big surprise and pleasure, it worked ! This is exactly the definition of something intuitive. Things react as you would expect.

All that to say that the perception of Ardour is going to change positivly anyway, and lot of frustration may vanish.

Paul and team, you are on the good route ! ;)

Apple's Logic is for me one

Apple's Logic is for me one of the most unintuitive pieces of software around. I would use it if I could, but after half an hour of using it I'm already exhausted with the over cluttered interface and silly icons, and some basic functions (like nudging) being hidden away. As far as DAWs are concerned protools and Ardour are the best I've ever tried (and I've tried more or less all the major ones). I'd say Cubase next. Ardour has the advantage of not being hardware dependent (over protools) and more flexible when it comes to multi channel stuff (you are not stuck with the standard 5.1 7.1 formats).

Hi, Reading the posts at the

Hi,
Reading the posts at the beginning, i think the definition of "Intuitivity" of a new tool as "beeing able to apply prior in depth knowledge, learned from other tools of the same category, to the new tool" is a little week. For me "Intuitivity" is much more then that, and much more subjective: the "intuitive" interface of a new tool should not only reflect the internal logic of the tool but also that of the user, even if the user has NO PRIOR self experience with the category of tools (e.g DAWs, mixers ). I only demand that the user not only knows what he wants by using the tool, but also has an idea, of how such a tool works. The user should ask: "If I were the tool (the mixer), how would I do the job?". I think most people looking for an "intuitive" tool unconsiously ask themselves this question.

I've worked for a long time with Cubase, prior to using Ardour, and I think both are extremely intuitive, Ardour even more. Prior to Cubase I had absolutely no experience in audio recording, either soft- of hardware. But I had a faint idea of how such a DAW could work, and within hours I recorded my first "song". Ok then came the time I had to learn how to master my stuff, and I'm still learning. But the essence is that both tools reflected from the start on my internal logic. Other examples of "intuitive" software are, in my point of view, the incredible Reason, Hydrogen, freqtweak, QJackCtl.

Counter-intuitive are N.I Battery, Rosegarden (sorry Chris, but I love librubberband ;) ) since it took a long time to get a tone out of them (with softsynths), and lots of LADSPA plugins, mainly due to LADSPA its self.

So let me come to the point. The reason why Ardour is soooooooo goooooood is the fact, that due to strong contact of the devs to the userbase, Ardour reflects the internal logic of the majority of users, regardless to the prior knowledge of the users. So even newbies get quickly acquainted with Ardour.
Having said that,
Keep up the good work Paul, Dave, .....

We've had this discussion

We've had this discussion many times in irc, and seem to get to the same point each time. I make a workflow suggestion, usually involving adding a action to which a keybinding can be assigned, and one or several voices chime up with something like "I can't see how that would be useful", or more commonly, " well I wouldn't do it that way, so do it my way, and you'll be ok." That's not always true, no matter the good intentions behind it. And to kill a myth here. I've used music related software since its inception, more or less, and have a cabinet full of apps (win and mac) which i cut my workflow teeth on. Even so, being openminded about workflow efficiency is not just the province of developers, but users too. (Yes, some of us have solid experience, and are still willing to take a fresh appraisal of workflow, even as crusty middle aged farts.)

Ardour has a lot going for it, and yet i still find parts of it unintuitive. A simple exercise is performing a series of actions as a sequence, then examining how FEW actions can be used to complete that sequence. I think most users would be surprised at how many hundreds of actions we carry out during a session, and for those of us who work at this for extended periods each day, in large projects, these numbers are important to deal with issues like hand and arm fatigue, etc..

For the sake of politically correct semantics, you could say "intuitive" is just a word, but i think the intent is a lot more common than one might think. Most users will probably a) use a mouse for just about everything, and b) never examine their own workflow to make sure they're using the best the app can provide, for the greatest efficiency. That doesn't mean we all have the same inclination, but i think it does go a long way towards a sometime feeling of reluctance on the part of developers, to take on board more complex code work, filling in the user's perceived "gaps" in his or her workflow.

Incidentally, this discussion topic rages in the commercial world on a regular basis, and usually ends with a group of users fighting over which workflow tools are the "best", at which point the devs either quietly disappear from the discussion, or make lots of non-commital but soothing noises, using the difference in viewpoint to do nothing.

I've been honest and forthright here, from my perspective, because i don't think any app development benefits from hearing extremes, ranging from warm and fuzzy to something entirely less savoury, both of which offer little in constructive contribution. Ardour has many strong points, imho, and has some weak ones too, which in my use case is the less than optimal qwerty driven navigation, and the gaps in that navigation.

Having choice is paramount, imho, and when the user only has one, i.e. the mouse, then he no longer has control over the workflow sequence, and must resort to workarounds, usually with additional actions, presses, and clicks, as a result.

I continue to wish the Ardour team success now and in the future.

Alex.

Very nice post. It's giving

Very nice post. It's giving me serious thoughts after reading the post.