In a previous post I mentioned hearing a very interesting interview with Paul Davis, the head developer of Ardour (a FOSS digital audio workbench) on the FLOSS Weekly podcast. In this interview conducted by Leo Laporte and Jono Bacon, Paul Davis explains how interfaces can become overly complicated when trying to appease many expert users, and why (despite Ardour’s modular design), changing out the front-end is not as easy as it sounds. In fact, these issues directly reflect on Mattew Paul Thomas’ points 10 and 14 in his post “Why Free Software has poor usability, and how to improve it“. Let me quote those two points directly so that we’re all on the same page.

“10. Placating people with options. In any software project with multiple contributors, sometimes they will disagree on a design issue. Where the contributors are employees, usually they’ll continue work even if they disagree with the design. But with volunteers, it’s much more likely that the project maintainer will agree to placate a contributor by adding a configuration setting for the behavior in question. The number, obscurity, and triviality of such preferences ends up confusing ordinary users, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.” — mpt

And,

“14. Mediocrity through modularity. Free software hackers prize code reuse. Often they talk of writing code to perform a function, so that other programmers can write a “front end” (or multiple alternative “front ends”) to let humans actually use it. They consider it important to be able to swap out any layer of the system in favor of alternative implementations.


This is good for the long-term health of a system, because it avoids relying on any single component. But it also leads to a lack of integration which lessens usability, especially if the interfaces between the layers weren’t designed with usability in mind.
” — mpt

Ok,  keeping those points in mind, have a look at the following partial transcript of Paul Davis’ interview. Note, Paul is cognizant  of the issues, but the problems remain quite challenging to overcome. (Sorry for any transcription errors. This interview is just filled with amazing points on usability!)

[Starting at 8:44]
Jono: So, with Ardour — I come from a Q-base background. I use Q-base in my studio, and I’ve always found it pretty easy to use, and I’ve never really got on with pro-tools either; I found it a little bit too complex — I remember a while back I evaluated Ardour as an option to move over to Linux, and I found it very very complex. Is the back-end and the front-end sufficiently separated so you can kind of put some lipstick on it and make it easy to use.

Paul: Yes. You absolutely can. … And so it’s quite possible to imagine that, if somebody wanted to put the work into making a super simplified version of an Ardour interface, then you could do that still based on that back-end.

Jono: And is that a project that you are actively working on. Because, I tried Ardour fairly recently. I’m running the development version of Ubuntu and I installed it from Ubuntu, so it’s a pretty recent release. And I still found I could feel my eyeballs spinning around due to the complexity of the interface. Like I don’t care about bits and streams and any of these details. I just want to record music.

Paul: No it’s not a direction that currently I or any of the other developers are really paying too much attention to. We are very focused on workflow issues. Which is where people can identify specific tasks that they need to perform with the software. We definitely want to make sure that the task is accomplishable with a minimal number of mouse clicks and keyboard operations and so-on.

But, the general goal of trying to create a program that, for example is as easy to use as GrarageBand, which I think is a very nicely designed program for people who are new to this sort of stuff, that’s not a goal that we have right now. I think its quite a difficult problem to solve.

My experience so far has been that most people who use digital audio workstations have a list of things that they would like to be able to do very easily, and they believe that the program that is before them ought to do those things very easily. And they are right. The problem is that there is a whole bunch of other people who have their own list of things that it ought to be able to do very easily and straightforwardly. And, when you take the union of all these lists, you end up with a program that looks like pro-tools or like Ardour.

So you end up having to make some choices at some point where you  say, okay we are absolutely not going to cater to the following types of goals. We are going to limit it entirely to this set of things. And my experience so far is that when you do that you immediately run into the wrath of the user who says ‘well it was great, I got started nice and quickly and I understood how to use it but it doesn’t do this ?!? Are you crazy?’

So we haven’t really resolved that and for the moment we’re happier working on Ardour 3.0, which we can talk about as we roll along, as apposed to figuring out how we can build a really simple interface that is sort-of roughly equivalent to GarageBand. I think another way to put it is that for me, in the back of my head, I’m writing Ardour catering to audio engineers or musicians who have audio engineering skills. I’m not really writing it with the idea of targeting musicians who just don’t do that sort of thing.

Jono: So just to clarify, you’re kind of going for the professional and the semi-professional audio engineer. Kind of, those people who are passionate about audio. People who want to produce bands professionally, as opposed to kind-of the hobbyists with a laptop who just wants to put down some guitar riffs.

Paul: Yes. Yeah, that’s certainly our general goal. And I would say that I’m quite happy to come across quite significant amounts of feedback from new users who do report back to us saying ‘Oh, it was really great. I just clicked a few buttons and it all worked’. Certainly we are happy when that happens, but there is not a lot of effort going into making things really easy for that second group that you mentioned.

Jono: Some time ago, when I was looking into Ardour, and I thought it was a bit too complicated, I formed a project called Jokosher — a simplified multitrack editor. I’m really interested int he fact that you said that the back-end is completely separate. Because Jokosher was kind of build from the perspective of just throw away all the assumed knowledge of audio engineering and think of it from a completely new usability standpoint. So are you saying that we could conceivably take Jokosher interface and hook into the Ardour back-end?

Paul: Yes. You can do that. In fact, there is already a project whose name I wish I could give you right now but I can’t. There is a project that took libardour — which is basically our back-end — and I think that that project has died. There is no activity with it now. But they were attempting to build a completely modular workstation system where, rather than everything being one program, there were completely separate applications with their own windows and so-on. And that was built on Ardour’s back-end. (…)

So yeah. It’s completely possible to do that. The only thing I would say is that, of the current code-base of Ardour, approximately 75% of all the code  is the GUI. So, once you get up to talking about a fairly rich user interface with lots of things that pop up and bits that control ability, you will will probably get into a situation where you realize that the back-end is actually not that much code. And, the really hard work is actually implementing the user interface.

One Comment

  1. dni says:

    This paragraph offers clear idea in favor of the new viewers of blogging,
    that actually how to do blogging.