3 ms·
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
by shaggyfrog 16y ago
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.
- jasonlotito 16y agoI 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.
- shaggyfrog 16y agoYou are being hopelessly dogmatic on this point. I'm not sure it's worth belabouring.
- jasonlotito 16y agoI'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.
- shaggyfrog 16y agoI 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.