3 ms·

"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 st

"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.

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

jasonlotito 16y ago

> 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.

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