6 ms·

"Oh, and the next time you see a warning used instead of undo, send the designer of the application/website a nice e-mail suggesting that they implement an “und

by pan69 16y ago

"Oh, and the next time you see a warning used instead of undo, send the designer of the application/website a nice e-mail suggesting that they implement an “undo” feature instead." A typical designer point of view on the world. Has the author any idea of how much time (therefore money) it can take to implement Undo features across the board? I don't think so. Successfully implementing Undo functionality can be a daunting task. The question simply comes down to; is it worth the money investing in this feature? For most applications it simply isn't, no matter what mister visual UX dude thinks or says.

redcap 16y ago
Implementing an undo feature is certainly harder than just providing a popup, but I think at least for me using a popup is a reflex and we should at least think about using an undo feature. I agree with the author that habitual responses to dialogue buttons can be dangerous, so I suggest considering this on a case-by-case basis - not just as to whether it's worth the money, but whether it will significantly reduce user distress.
ubershmekel 16y ago
It's all about software development and usage norms. Yes, it's difficult to bootstrap undo functionality. But look at mobile apps, they never ask "are you sure you want to leave?", they just make sure that whenever you come back - everything is exactly like it was before. Users EXPECT this behavior and developers feel obligated to implement it. Concerning deleting by accident - I think it's just that we have bad software usage/development norms. Who knows, maybe this will improve with time.
- wallflower 16y ago
  > But look at mobile apps, they never ask "are you sure you want to leave?" I know your context was about something a little different but just to be nitpicky, most iOS apps we develop prompt the user if they want to leave the app and launch Google Maps to get directions and/or thank them for wanting to donate - Safari will be launching shortly and/or tell them to wait while we launch the e-commerce page.
- jerf 16y ago
  Some things really have to be in the lowest possible level of your code to work, to come back later and bolt them on is incredibly difficult. Correctness of encoding, localization, and good unit testing are some of my usual examples; start with them from day one and they don't cost you that much, add them into a project that has gone for 10 man years without thought and you're in for some pain. Undo functionality is like that. You have to start with some sort of ability to make it easy to create your "actions" in some way where every one of them can be reversed, and in some cases the OS itself makes that very hard. How do you undo "close program"? Like you said, but didn't quite spell out, with a fundamentally different OS where suddenly it's easy. You can make a Microsoft Windows program that will automatically open in the same state you left it in, but first of all, it's much harder than it is on a phone, and second, I very much hope that you thought of that from day one because otherwise you're probably in for some pain just refactoring your program to the point where it is possible.... Ideally you would work in some language that makes undo that easy, but it's really hard because so much of the system is fighting you. I've toyed with this but UIs themselves are fundamentally not undoable so you burn a lot of time just telling the UI how to roll back. It really needs to be fundamentally woven into the entire system and that will probably be decades, if ever.
deleted 16y ago
[deleted]
ugh 16y ago
I’m not following you there, what has the difficulty of implementing undo to do with whether or not it should always be at least suggested as a clearly superior solution? I’m not seeing any assumptions about the difficulty of implementing an undo feature in that sentence (except that it’s not impossible and that some companies have been capable of implementing it). Where do you find those? I think your prejudices got the better of you.
- damoncali 16y ago
  I can undo the shit out of Adobe Illustrator, and I still wind up losing work from time to time. How is that clearly superior to accidentally clicking "OK"?
  - ugh 16y ago
    I’m not claiming that undo will protect you from everything. (It doesn’t.) I’m merely claiming that undo is preferable (“clearly superior”) to no undo. Are you saying that Illustrator would be just as good without undo?
    - damoncali 16y ago
      That's where we disagree. Sometimes an alert is just what you need, and can be better than an undo function (which can get rather complex as your ui gets more sophistiated - hence my illustrator issues). Illustrator is clearly better with undo, but I don't think basecamp, for example, would be.
      - ugh 16y ago
        I’m honestly not following you. I have trouble understanding in what way a warning could ever be better than the ability to undo. Why would it be?
        damoncali 16y ago
        There are some things that you change or delete frequently, and that have little value - the points in my illustrator file, for example. I might want to move one a bit, delete it, and then put it back. This is when you want an undo, and are willing to pay its price, both in ui complexity and implementation cost. Other things, you want to delete only occasionally, and may be of high importance, like a character in a video game. this is when you want an alert. If it's not something you do all the time, it's not habit forming ( in the context of this particular game). It adds no complexity to the ui and has nearly no implementation cost, yet it helps protect your important data.
jayliew 16y ago
This is a legitimate point of view, that perhaps developers don't want to hear. Disclaimer: I'm a developer, so I understand the challenge to undo. However, I also realize that I'm building for normal people (i.e. not myself). There is no need to be defensive, nobody is attacking anybody. This is just another "best practices" thing. update: just to add one more note: end-users don't care if the person who built the product like/dislike implementing an undo feature, end-users care if it's easy for them or not.
- lukeschlather 16y ago
  The biggest problem with undo is that sometimes allowing the user to recover from a particular action is also undesirable behavior. If I accidentally typed my username and password into a file, I want it to go away, right now. There's a somewhat worrying trend with applications such as Facebook and Google Apps where software is more concerned with making users believe it's doing what they need it to do, and less concerned with doing what users need. I'm not saying this necessarily crosses the line - if I have the space on my server I'm storing lots of incremental backups. But there's always a trade-off. And some people might rather be assured that when they hit delete that it goes away forever than that they never lose anything they meant to keep.
- pan69 16y ago
  What I was trying to get at is that this is often not a "Best Practice" decision. As if the developers didn't think of implementing undo functionality... Implementing such a complex feature such as undo if often a business decision, if anything else.
  - jasonlotito 16y ago
    Maybe it's the belief that it's a complex feature that hinders them? Implementing an undo feature isn't really complex for most things a user does. Outside of anything real time, most things have the capability of having an undo element added to them to some degree. Even then, real time actions can still be undone (credit card transactions, for example).
rbranson 16y ago
Agreed. It becomes especially complex in a distributed system with multiple users having access to the same data. For instance, even a simple message exchange, which has no data interdependency issues, an undo feature requires some kind of design trade-off. Either the application lies to the user and delays the sending of the message to allow for an undo period, or it allows the message to be delivered to the other user, but then allows the delivery to be un-done. However, in the later scenario, if the receiver reads the message before it is "unsent," then you aren't really providing a reliable undo facility.
irondavycole 16y ago
You're suggesting that "mister visual UX dudes" (like me, for example) don't take complexity of implementation into account when making design decisions. We do. It's part of the process. Note that he said to send the designer the e-mail, not the developer. The designer on a project should always know where the current UX problems in the product are, even if they are too expensive to fix at the time.
- kelnos 16y ago
  Then I applaud you for having awareness of issues outside your immediate domain. I know quite a few UX people who know nothing about implementation and think everything is easy to do.
  - irondavycole 16y ago
    I don't even think it takes knowledge of implementation, just respect for it. I've had engineers ask me to fix certain design problems that would take weeks of prototyping and user testing to actually nail down in a meaningful way. Good devs appreciate the difficulty and we find a solution that fits the schedule, bad devs think design is easy to do. It runs both ways. Let's avoid making needless blanket statements and concentrate on working together.
Jach 16y ago
There's a lazy solution: do what Gmail does. Rather than have an actual undo stack, especially for those pesky things like removing information from the database, just delay action for 5-30 seconds and offer an undo button until the time expires.
- d0mine 16y ago
  It is not a real undo it is a warning with timeout.
  - phillco 16y ago
    "LAUNCHING MISSILES (click here very quickly to undo)..."
    - d0mine 16y ago
      "cancel" and "undo" is not the same thing. You can cancel the launch. But you can't undo it. It is thermodynamically impossible.
      - phillco 16y ago
        Right. But that's how Gmail is marketing it. "Undo send" gives you the impression that Gmail is reaching through the tubes and yanking your message back for you, but in reality it's just cancelling a launch that didn't happen yet.
      - jpitz 16y ago
        Yes, but there's a compensating transaction you can apply to the missile up until the time it reaches the target.
  - blahedo 16y ago
    You're right that it's not a "real" undo, but it is better than a warning with timeout; on a warning, it demands that you click (habitual action) after which there's no going back, but with this system it demands nothing, the message stays up, and you click (non-habitual action) only when you want to cancel.
zem 16y ago
the partition magic guys didn't seem too receptive to the suggestion. bunch of stick-in-the-muds.
- Hemlockz 16y ago
  Ha ha.... Undo repartition. At what point should users be responsible for their own clickings?

by pan69 16y ago

redcap 16y ago

Implementing an undo feature is certainly harder than just providing a popup, but I think at least for me using a popup is a reflex and we should at least think about using an undo feature. I agree with the author that habitual responses to dialogue buttons can be dangerous, so I suggest considering this on a case-by-case basis - not just as to whether it's worth the money, but whether it will significantly reduce user distress.

ubershmekel 16y ago

It's all about software development and usage norms. Yes, it's difficult to bootstrap undo functionality. But look at mobile apps, they never ask "are you sure you want to leave?", they just make sure that whenever you come back - everything is exactly like it was before. Users EXPECT this behavior and developers feel obligated to implement it. Concerning deleting by accident - I think it's just that we have bad software usage/development norms. Who knows, maybe this will improve with time.

wallflower 16y ago
> But look at mobile apps, they never ask "are you sure you want to leave?" I know your context was about something a little different but just to be nitpicky, most iOS apps we develop prompt the user if they want to leave the app and launch Google Maps to get directions and/or thank them for wanting to donate - Safari will be launching shortly and/or tell them to wait while we launch the e-commerce page.
jerf 16y ago
Some things really have to be in the lowest possible level of your code to work, to come back later and bolt them on is incredibly difficult. Correctness of encoding, localization, and good unit testing are some of my usual examples; start with them from day one and they don't cost you that much, add them into a project that has gone for 10 man years without thought and you're in for some pain. Undo functionality is like that. You have to start with some sort of ability to make it easy to create your "actions" in some way where every one of them can be reversed, and in some cases the OS itself makes that very hard. How do you undo "close program"? Like you said, but didn't quite spell out, with a fundamentally different OS where suddenly it's easy. You can make a Microsoft Windows program that will automatically open in the same state you left it in, but first of all, it's much harder than it is on a phone, and second, I very much hope that you thought of that from day one because otherwise you're probably in for some pain just refactoring your program to the point where it is possible.... Ideally you would work in some language that makes undo that easy, but it's really hard because so much of the system is fighting you. I've toyed with this but UIs themselves are fundamentally not undoable so you burn a lot of time just telling the UI how to roll back. It really needs to be fundamentally woven into the entire system and that will probably be decades, if ever.

deleted 16y ago

[deleted]

ugh 16y ago

I’m not following you there, what has the difficulty of implementing undo to do with whether or not it should always be at least suggested as a clearly superior solution? I’m not seeing any assumptions about the difficulty of implementing an undo feature in that sentence (except that it’s not impossible and that some companies have been capable of implementing it). Where do you find those? I think your prejudices got the better of you.

damoncali 16y ago
I can undo the shit out of Adobe Illustrator, and I still wind up losing work from time to time. How is that clearly superior to accidentally clicking "OK"?
- ugh 16y ago
  I’m not claiming that undo will protect you from everything. (It doesn’t.) I’m merely claiming that undo is preferable (“clearly superior”) to no undo. Are you saying that Illustrator would be just as good without undo?
  - damoncali 16y ago
    That's where we disagree. Sometimes an alert is just what you need, and can be better than an undo function (which can get rather complex as your ui gets more sophistiated - hence my illustrator issues). Illustrator is clearly better with undo, but I don't think basecamp, for example, would be.
    - ugh 16y ago
      I’m honestly not following you. I have trouble understanding in what way a warning could ever be better than the ability to undo. Why would it be?
      - damoncali 16y ago
        There are some things that you change or delete frequently, and that have little value - the points in my illustrator file, for example. I might want to move one a bit, delete it, and then put it back. This is when you want an undo, and are willing to pay its price, both in ui complexity and implementation cost. Other things, you want to delete only occasionally, and may be of high importance, like a character in a video game. this is when you want an alert. If it's not something you do all the time, it's not habit forming ( in the context of this particular game). It adds no complexity to the ui and has nearly no implementation cost, yet it helps protect your important data.

jayliew 16y ago

This is a legitimate point of view, that perhaps developers don't want to hear. Disclaimer: I'm a developer, so I understand the challenge to undo. However, I also realize that I'm building for normal people (i.e. not myself). There is no need to be defensive, nobody is attacking anybody. This is just another "best practices" thing. update: just to add one more note: end-users don't care if the person who built the product like/dislike implementing an undo feature, end-users care if it's easy for them or not.

lukeschlather 16y ago
The biggest problem with undo is that sometimes allowing the user to recover from a particular action is also undesirable behavior. If I accidentally typed my username and password into a file, I want it to go away, right now. There's a somewhat worrying trend with applications such as Facebook and Google Apps where software is more concerned with making users believe it's doing what they need it to do, and less concerned with doing what users need. I'm not saying this necessarily crosses the line - if I have the space on my server I'm storing lots of incremental backups. But there's always a trade-off. And some people might rather be assured that when they hit delete that it goes away forever than that they never lose anything they meant to keep.
pan69 16y ago
What I was trying to get at is that this is often not a "Best Practice" decision. As if the developers didn't think of implementing undo functionality... Implementing such a complex feature such as undo if often a business decision, if anything else.
- jasonlotito 16y ago
  Maybe it's the belief that it's a complex feature that hinders them? Implementing an undo feature isn't really complex for most things a user does. Outside of anything real time, most things have the capability of having an undo element added to them to some degree. Even then, real time actions can still be undone (credit card transactions, for example).

rbranson 16y ago

Agreed. It becomes especially complex in a distributed system with multiple users having access to the same data. For instance, even a simple message exchange, which has no data interdependency issues, an undo feature requires some kind of design trade-off. Either the application lies to the user and delays the sending of the message to allow for an undo period, or it allows the message to be delivered to the other user, but then allows the delivery to be un-done. However, in the later scenario, if the receiver reads the message before it is "unsent," then you aren't really providing a reliable undo facility.

irondavycole 16y ago

You're suggesting that "mister visual UX dudes" (like me, for example) don't take complexity of implementation into account when making design decisions. We do. It's part of the process. Note that he said to send the designer the e-mail, not the developer. The designer on a project should always know where the current UX problems in the product are, even if they are too expensive to fix at the time.

kelnos 16y ago
Then I applaud you for having awareness of issues outside your immediate domain. I know quite a few UX people who know nothing about implementation and think everything is easy to do.
- irondavycole 16y ago
  I don't even think it takes knowledge of implementation, just respect for it. I've had engineers ask me to fix certain design problems that would take weeks of prototyping and user testing to actually nail down in a meaningful way. Good devs appreciate the difficulty and we find a solution that fits the schedule, bad devs think design is easy to do. It runs both ways. Let's avoid making needless blanket statements and concentrate on working together.

Jach 16y ago

There's a lazy solution: do what Gmail does. Rather than have an actual undo stack, especially for those pesky things like removing information from the database, just delay action for 5-30 seconds and offer an undo button until the time expires.

d0mine 16y ago
It is not a real undo it is a warning with timeout.
- phillco 16y ago
  "LAUNCHING MISSILES (click here very quickly to undo)..."
  - d0mine 16y ago
    "cancel" and "undo" is not the same thing. You can cancel the launch. But you can't undo it. It is thermodynamically impossible.
    - phillco 16y ago
      Right. But that's how Gmail is marketing it. "Undo send" gives you the impression that Gmail is reaching through the tubes and yanking your message back for you, but in reality it's just cancelling a launch that didn't happen yet.
    - jpitz 16y ago
      Yes, but there's a compensating transaction you can apply to the missile up until the time it reaches the target.
- blahedo 16y ago
  You're right that it's not a "real" undo, but it is better than a warning with timeout; on a warning, it demands that you click (habitual action) after which there's no going back, but with this system it demands nothing, the message stays up, and you click (non-habitual action) only when you want to cancel.

zem 16y ago

the partition magic guys didn't seem too receptive to the suggestion. bunch of stick-in-the-muds.

Hemlockz 16y ago
Ha ha.... Undo repartition. At what point should users be responsible for their own clickings?