"Store the previous state" sounds great in theory. Doesn't always work in practice.

Storing the state of the system may involve a non-trivial amount of both storage and/or time. Or the backing store may not allow for reversing a deletion.

pan69 really said it all: these ideas sound great to designers, but cause nightmares for the programmer that actually has to implement it.

> Storing the state of the system may involve a non-trivial amount of both storage and/or time. Or the backing store may not allow for reversing a deletion.

That sounds like an excuse. The problem isn't with the undo. It's with the rest of the system, so clearly their are other problems to address first.

To put it bluntly, this is an ignorant response. Many systems have constraints beyond the control of the developer. It isn't an excuse to say, for example, that doing save/load from a PS2 memcard is slow and non-trivial; that's just the way it is.

A good designer will have a deep understanding of the capabilities and limitations of the medium they are working with. (Think Jonathan Ive and the countless testing they do using all sorts of different construction materials.) A poor designer will come up with a grand idea, but no idea how to implement it, and then blame the programmer if it's impossible to do.

I said in another comment that certain cases (like games) are the exception of the rule. But in context with the article, what I say stands. Implementing undo for users is fairly trivial. If it's not, their are other problems that need addressing.

You are being hopelessly dogmatic on this point. I'm not sure it's worth belabouring.

I'm coming off that way, and I apologise. I wasn't clear. I believe the original article was mostly discussing these factors within the confines of web based applications, which is what my comments here have assumed. Obviously their are exceptions to the rule, and a true undo is not trivial. However, a true undo, and an undo that meets the users needs are different things entirely. While it's unfair for me to suggest that implementing undo is trivial, it's also unfair to assume that implementing undo has to be difficult.

I think we have common ground, here. If it's reasonable to put in undo (pragmatically speaking, in terms of money, time, technology, etc.) then I agree the user is better off having it than not.