GarageBand: ‘Save’ doesn’t become inactive after it’s been used

Posted by Pierre Igot in: GarageBand
December 2nd, 2004 • 1:28 am

This is a perfectly example of how Apple manages to screw up even the most basic stuff when putting out new software that has been supposedly built from scratch and should at the very least comply with the most fundamental standards of UI design.

If you have a music file open in GarageBand and press command-S or select the “Save” command in the “File” menu, GarageBand saves your file, but the “Save” command in the menu stays active and you can select it again right away.

This doesn’t make any sense. If the file has just been saved and I haven’t made any changes to it, there is nothing else to save, so the “Save” command should become disabled and stay that way until I start making changes again.

It seems to me that this is something very fundamental in UI design. How can a new application build in 2004 by Apple — of all software companies — not even comply with such a basic standard?

This is the kind of stuff that I expect from a company like Microsoft, which cannot even get the most basic stuff right 20 years after the introduction of the graphic user interface. But Apple? Come on…

Of course, it’s a mostly “cosmetic” thing and most users will never notice it or be bothered by it. But Apple doesn’t make products with “most users” in mind. They make products that are based on simple, intuitive, consistent design and attention to detail. But sometimes, obviously, they let some very fundamental flaws slip through. It’s rather unfortunate.

6 Responses to “GarageBand: ‘Save’ doesn’t become inactive after it’s been used”

  1. ssp says:

    I tend to think that what Apple does here is a good way to do this. And it’s a feature you see everywhere in Cocoa apps, not just in GB.

    To begin with, there shouldn’t be many inactive menu items, as you’ll just start wondering why you can’t use them. That’s much more irritating than hitting the save button for no real effect.

    Also keep in mind that you may have the same document opened in several applications at the same time. In that situation, there may be changes to the file from one app that you want to overwrite with the original version from the other. (While this sounds absurd, trust me that I’ve had many encounters with apps that have the behaviour you suggest and I found myself inserting a space and deleting it again just to be able to have the file re-written in place). Or you could delete a document’s file while having it opened in an application. For sure you’d want to be able to just hit save in that situation as well.

  2. Pierre Igot says:

    I simply cannot agree with this. But I agree that other Cocoa applications, such as TextEdit, seem to be affected as well. Not a good thing!

    I don’t buy this “there shouldn’t be many inactive menu items”. How many is too many? This is rather arbitrary. Either you agree with the meaningfulness of inactive menu items, or you don’t. It’s hard to imagine a user wondering why he can’t save a document when he’s just saved it. It’s basically asking him to question the very meaning of his actions.

    At the same time, you suggest that this behaviour might help with documents open in several applications at the same time. Are we really talking about the same type of user as the one who might be confused by inactive menu items here? It seems to me that you are referring to a completely different situation, which most users are not likely to encounter (same doc opened in several applications at the same time). In this particular case, you definitely cannot have a GarageBand file open in another application at the same time.

    Sorry, but I think this is simply wrong.

    If it’s Apple’s way of straying away from the app-centric design towards a doc-centric design (something that I definitely would like to see happen!), then I need to see other signs that this is definitely the direction in which we’re headed. As I see it now, it’s simply inconsistent and unexplained behaviour.

  3. ssp says:

    Of course there are different user types. But why restrict any of them unnecessarily?

    The situations I described may not bee too realistic for GB files, but as I pointed out it’s not a GB ‘feature’ that you observed but a general one.

    If your point is that commands which don’t have any effect should be inactive, how far would you go? Disable the Copy menu item once text has been copied? Disable Select All when everything is selected? Disable the ‘Name’ item in the Finder’s sort-by menu if everything is sorted by name already? Disable the Preferences Menu item if the preferences window is frontmost? …

    My point would be to just disable the menu items which cannot work in the current situation.

    In the days where computers and applications run for weeks, I also don’t think a person would be stupid just because they ask the computer to save a file twice in a row. Those commands can be hours or days apart.

  4. Pierre Igot says:

    We could probably have a fairly long discussion about the relative merits of disabling each menu command. My main problem is consistency and the user’s confidence in his machine. In today’s computing world, there’s probably only so much we can do about trying to preserve consistency. What bothers me is that, depending on which application I am using, the “Save” command becomes disabled after use — or not. And from the user’s point of view this inconsistency makes no sense.

    As for user confidence, I’d argue that saving is a particularly important action and that the user needs clear confirmation that his action has been registered and completed properly. I don’t think it’s treating a user as “stupid” to disable the command once it’s been used, until the document is changed again. Even if two consecutive Save commands are days apart, if no change has been made to the document in the interval, why should the Save command remain active? On the contrary, the fact that it has remained active is likely to confuse the user, because he can come back to a document much later and wonder what changes have been made to the document that he might not have recorded, since the command is active. You cannot expect the user to remember whether he’s made any changes in the past several days or not.

  5. Evan Gross says:

    It’s Cocoa that’s doing this – an app can override this behavior – I think I tried to but it caused me grief elsewhere.

    Although it is handy sometimes to be able to save even when a document isn’t “dirty”, I also think that Save should be disabled when there’s no change to be saved. I tried in Spell Catcher X, but didn’t have a lot of success battling the framework in this particular case.

  6. Pierre Igot says:

    Evan: Interesting. Fortunately, SCX can be set to autosave on close, so I tend not to worry too much about this in SCX, and hadn’t noticed the problem there. But it’s definitely there too :).

Leave a Reply

Comments are closed.