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

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,

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

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

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

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

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

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

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. :) Okay, it's the familiarity and quality of DSP.

Just my opinion, but I think

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.

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

@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.

An advantage of opensource is

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 ;)

One of the challenges, I'm

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. :)

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

Ardour has become more

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

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

I came to Ardour a few years

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

I think it's useful to make a distinction `intuitive' and `familiar' 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

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

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.


Maybe we should think of

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.

I'll use this as a starter.

First, Ardour and Audacity have different purposes; and, while I use Audacity for a few things, the 'record is a record+play' behavior is one of my strongest dislikes. Intuitive, in the context of a DAW, should, to me at least, mean 'familiar to those who have used professional multitrack recorders before' not 'familiar to those who have used CoolEdit before.' Every professional multitrack machine I have personally worked with operates like Ardour in this respect, where 'record' is 'record+pause' and not 'record+play' and where tracks have to be explicitly armed for recording (for track safety, of course).

Ardour has extreme routing and tracking flexibility, but flexibility is a two-edged sword.

The meaning of inuitive is audience-dependent, as inuition is determined by an individuals prior experiences and their ability to observe those experiences.

Your entire post rests on

Your entire post rests on some specific assumptions about what someone wants to do with a tool like Ardour. You are clearly convinced that the default purpose for a new track is to record audio, and experience over the last 10 years has shown that this just isn't true. It was actually my assumption at first too, and early versions of Ardour completely ignored the possibility that people might have existing audio material that they wanted to use ardour to arrange rather than recording new material. When you throw in the fact that the other tools to which Ardour is most similar do not rec-enable new tracks by default (I'm not even sure its an option), and you can be sure that this is not a change we would make. If someone were to submit a patch to make this a user-controller option, I'd be happy to consider it.

One change that will happen in 3.0 (I actually though I had implemented this already, but it appears not) is an option for 1-click record (which makes pressing the global-rec-enable button start the transport rolling).

I think it is extremely important that you stop comparing Ardour to Audacity. They are no more comparable than Bias Peak and ProTools, which is to say that they each have very important roles to play, and they overlap a little bit in their functionality. However, they are not intended to be replacements for each other - Audacity would have to do an unbelievable amount of fundamental re-engineering to be able to do even half of the editing operations that Ardour makes possible.

@seeblade 1) By clearly


1) By clearly visible I mean must be visible on the screen, a menu item however logical does not meet this criteria. Here such an action must be a prompt as the user may not specifically understand the concept that they must add tracks before they can record. Making this visible acts as a hint or a clue that this is what they need to do.
My suggestion would be to add a small strip in the track area itself that could sit just below the the bottom track that offers what right clicking in this area currently offers. This makes things slightly more intuitive for new users and I don't believe it would get in the way of advanced users.

2) On reflection I would suggest that you are right and instead the default template would come with two tracks come with a two armed mono tracks or a single stereo armed track. My first suggestion was overkill and probably would disrupt the work flow of most users. By having the first two tracks armed it should be easier for a new user to spot that newly added tracks need to be armed to work.

3) The buttons could be grouped visually but present large enough target areas not to be hit accidentally. If we are very clever the buttons need not be adjacent but still grouped visually (for example a line drawn connecting the elements may be enough to help suggest that they should be used together).

I could perhaps produce some mockups of these ideas if you believe they might help.

Mockups are never a bad idea

Mockups are never a bad idea if you are discussing GUI changes, however I suspect in as far as the first suggestion, that you would be removing Real Estate for little benefit, and screen real estate is already pretty scarse. I am not sure I agree with the need for this myself, for whatever my opinion counts.

The third option a mockup wouldn't be a bad idea on I don't believe though. I am as of right now not for it or against it.


@Paul I was looking at

I was looking at recording as a use case and considering what would happen if I forgot everything I knew about the software and started from scratch. In my case the first thing I would try to do is record something and unless I was very lucky or I read the documentation (which is something that I unlike most people I know actually do) I would have failed at Ardour gone and used Audacity instead. knowing what I do know would have been something of a Tragedy.

I haven't considered what would happen if my very first task in Ardour was to mix. I suspect it might go a little better than my first thought experiment. It also might change some of my recommendations. (I will try it when I get a chance).

I am not suggesting that Ardour should become like Audacity or any other software. I like the flexibility and power of Ardour and I would not want that compromised. At the same time I can see see some places where new users may easily become unstuck. I think that adding some visual cues will go a long way towards helping this and done in the right way these should not hinder intermediate or advanced users. Also defaults may be changed to reduce the cognitive load of first time users however this may be a little harder to not get in the way.

@seeblade Consider in the

Consider in the first instance that no extra screen real estate would be used. If there are no tracks then the space where tracks go is empty. As the track list grows the add new tracks item would remain at the end of the list so it would be the first item to disappear off the screen. It would then also be right next to where the new tracks would appear in fact the first newly added track would replace it position wise which would often be desirable.

The third option may take a little extra screen real estate. But I shall see if I can find a way to minimise that.

Consider in the first

Consider in the first instance that no extra screen real estate would be used. If there are no tracks then the space where tracks go is empty. As the track list grows the add new tracks item would remain at the end of the list so it would be the first item to disappear off the screen. It would then also be right next to where the new tracks would appear in fact the first newly added track would replace it position wise which would often be desirable.

Ok my first impression based off this description is a good one I will admit.


@danni: as i've explain in

@danni: as i've explain in many different contexts, i'm not really interested in promoting the idea that you can do audio engineering, with a computer or without a computer, without understanding what you're trying to do. The cognitive load for first time users is important - this task is NOT simple, and software should not be trying to convince them that it is. That doesn't mean it should be presenting unnecessary roadblocks either, of course. If there are places where Ardour does that, I want to know about that.

@Paul your position is quite


your position is quite understandable and in large part I happen to agree with it. I am rather interested in the roadblocks myself and it is those that I am trying to describe.I think i particular that it is important that a first time users not be completely unsuccessful at achieving anything at all in the program. If that is the case such a user may assume that either Ardour is broken or it won't work with their computer or that it is just too unintuitive. I think once somebody gets past that point they are more likely to put effort into learning how to use the software properly.

I could be wrong

@Danni: While I can see

@Danni: While I can see where you are coming from with your suggestions, I have to agree with Paul and Seablade. If you want to work an a large multi track project, recorded or otherwise, you would do one of the following:

1) Use Ardour as you would any professional DAW, in which category it falls currently.
2) Read the manual, or get a video like the one for Harrison Mixbus.
3) Get an audio engineer to do it right

Driving a car is quite intuitive, but even so, it takes some lessons, and a licence before you are let loose on the roads. It boggles my mind why people think that driving a mixing desk or DAW that has hundreds of potential controls should be running at full speed in the first few minutes.

I am all for making things easier, but changing the fundamentals of a system control can make it less intuitive.
Think about it. If I were to change a basic control, like my computer keyboard to suit my language better, others could have problems with using it.

From what I've read here, we

From what I've read here, we all want Ardour to be relatively easy for the starter without taking what Ardour is. And I think Ardour could be easier for newbies with the tools it already has. First time users need an easy starting point from where they can go further.

To lower the barrier, Ardour could provide templates, such as a "Beginner Session", where there are tracks already connected to the inputs on the soundcard, maybe also channel templates for vocals, guitar etc. with basic plugins like a compressor, reverb etc. with basic presets already loaded. The timelines could be reduced to only the essential lines. This would lower the entry barrier considerably. If one provides a popup window with a link to the FLOSSmanual when loading a beginner session, it would be a good entry for starters, I think.

This could be a good compromise without altering Ardour and without hiding the necessary complexity, but at the same time making newbies familiar with it and give them an early success to think "I can do this". And from my experience an early success is just the boost most users need to learn more, even if something is very complex. Ardour has already every possibility to be simple enough to provide an easy starting point, it's only a matter of providing it. And maybe my suggestion could be an easy way to do that.

Oh, and while we are at the topic, I have one little thing I'd like to mention: I wanted to save a channel template in the mixer window and name it, but the little window for naming the template had only a "Cancel" button. I pressed "Enter" and everything was saved fine, but I think not having a "Save" button there could be a little confusing to some.