GarageBand: More interface inconsistency

Posted by Pierre Igot in: GarageBand, Macintosh
April 12th, 2004 • 4:58 am

With GarageBand, Apple has once again strayed away from their own interface standards. The document window is neither a standard Aqua window nor a brushed-metal window — but some kind of plastic-wood hybrid window. Obviously, the intent is to mimic the look of actual studio gear. I am not necessarily against it, in so far as, to me, GarageBand is in the same category as computer games — which often have non-standard interfaces in an attempt to create a special atmosphere for the gaming experience.

The problem I have is when the use of such non-standard interface elements leads Apple to seemingly forget to implement standard behaviours that should still be part of the interface, no matter how non-standard it looks.

For example, in spite of its non-standard interface, GarageBand is still based on the traditional application / document windowing model. The project that you are working on appears in a window in the GarageBand application. The title of the window is the name of the file in which the project is stored in its entirety. In other words, we have a window whose contents refer to a file that can be revealed in the Finder.

Why is it, then, that I cannot command-click on the file name in the window’s title bar to bring up a pop-up menu with the path to the file it refers to?

The problem is of course that, contrary to what the interface seems to imply, you cannot have more than one project window open in GarageBand at the same time. If you try to create a second project in a new window by selecting the “New” command in the “File” menu, GarageBand forces you to close the current project. And you cannot leave the application open with no project window open. If you close the current project window, GarageBand quits!

I really don’t see why Apple had to adopt such non-standard behaviours. I understand that working on a GarageBand project is a rather demanding computing task, and that the limitations of today’s hardware make it difficult to work on more than one project at a time — but that doesn’t necessarily mean that Apple had to use all these non-standard conventions. I don’t see, for example, while command-clicking on the window’s title bar could not work as expected. And I don’t see why the application cannot be left open with no project window open.

3 Responses to “GarageBand: More interface inconsistency”

  1. Pierre Igot says:

    Yeah, obviously it’s a 1.0 application — but it’s pretty good for a 1.0 application :). I agree that loop manipulation is not exactly intuitive — but it looks like it depends very much on the position of your cursor. For example, you can select part of a sample if you put the cursor over the bottom half of the sound wave, but if you put your cursor over the top half, clicking and dragging moves the sample itself. Takes some getting used to.

  2. Matthew says:

    yes, ive sort of noticed the position of the cursor thing. it should be a key modifer really – ie hold alt to loop and apple do clone etc.

  3. Matthew says:

    i think theyve prevented more than one file open for memory/new user issues but it is REALLY irritating.

    and you cant drag tracks around and scaling/looping samples seems inconsistent (sometimes it will sometimes it wont) but hopefully theyll fix most of it in V2

Leave a Reply

Comments are closed.