<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Undo &#8212; Not Confirmation &#8212; End of Discussion</title>
	<atom:link href="http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/feed/" rel="self" type="application/rss+xml" />
	<link>http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/</link>
	<description>Instant Usability &#38; Web Standards</description>
	<lastBuildDate>Fri, 30 Jul 2010 00:31:00 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mike</title>
		<link>http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/comment-page-1/#comment-493282</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Tue, 02 Mar 2010 08:20:45 +0000</pubDate>
		<guid isPermaLink="false">http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/#comment-493282</guid>
		<description>I agree with you 95% of the way, but there are cases where undo is not good enough. 

Here at felspar.com we&#039;ve implemented a bulk emailer service, which we integrate with our bespoke system. One of our clients can potentially email around 150K customers with the click of a button. At that point, undo is not possible, as, once the email has been sent and received, it cannot be sucked out of the recipient machine by an undo operation. So, we have various test and preview screens before a final confirmation to send. 

In a perfect world, perhaps email could be un-sent or corrected... and network connections would never go down after sending.. and people could un-read emails. etc. Unfortunately, we don&#039;t live there.

Moral of the story: you often can&#039;t undo changes that have escaped into the big wide world. In thoses cases, make sure the users know exactly what they are doing.</description>
		<content:encoded><![CDATA[<p>I agree with you 95% of the way, but there are cases where undo is not good enough. </p>
<p>Here at felspar.com we&#8217;ve implemented a bulk emailer service, which we integrate with our bespoke system. One of our clients can potentially email around 150K customers with the click of a button. At that point, undo is not possible, as, once the email has been sent and received, it cannot be sucked out of the recipient machine by an undo operation. So, we have various test and preview screens before a final confirmation to send. </p>
<p>In a perfect world, perhaps email could be un-sent or corrected&#8230; and network connections would never go down after sending.. and people could un-read emails. etc. Unfortunately, we don&#8217;t live there.</p>
<p>Moral of the story: you often can&#8217;t undo changes that have escaped into the big wide world. In thoses cases, make sure the users know exactly what they are doing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pik</title>
		<link>http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/comment-page-1/#comment-395535</link>
		<dc:creator>pik</dc:creator>
		<pubDate>Tue, 12 Feb 2008 14:22:33 +0000</pubDate>
		<guid isPermaLink="false">http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/#comment-395535</guid>
		<description>Graphics are nice but isn&#039;t this a stateful utopia ? isn&#039;t the back button supposed to do the same work ?</description>
		<content:encoded><![CDATA[<p>Graphics are nice but isn&#8217;t this a stateful utopia ? isn&#8217;t the back button supposed to do the same work ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hannes</title>
		<link>http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/comment-page-1/#comment-275291</link>
		<dc:creator>Hannes</dc:creator>
		<pubDate>Sat, 29 Sep 2007 15:24:48 +0000</pubDate>
		<guid isPermaLink="false">http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/#comment-275291</guid>
		<description>As Aza mentions in Part 1, the elements do not actually get deleted in the moment when the user clicks on the delete link but in an onUnload hook. IMHO the UX is even better when the elements do not get removed from the page, but grayed out/disabled and the delete link gets renamed to undelete. This enables the user to undo an arbitrary deletion instead of being forced to their inverse order.</description>
		<content:encoded><![CDATA[<p>As Aza mentions in Part 1, the elements do not actually get deleted in the moment when the user clicks on the delete link but in an onUnload hook. IMHO the UX is even better when the elements do not get removed from the page, but grayed out/disabled and the delete link gets renamed to undelete. This enables the user to undo an arbitrary deletion instead of being forced to their inverse order.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Baekdal</title>
		<link>http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/comment-page-1/#comment-272569</link>
		<dc:creator>Thomas Baekdal</dc:creator>
		<pubDate>Thu, 27 Sep 2007 07:40:52 +0000</pubDate>
		<guid isPermaLink="false">http://justaddwater.dk/2007/09/27/undo-not-confirmation-end-of-discussion/#comment-272569</guid>
		<description>Interesting - nice find.

May I add a 5th point: Problems with handling Undo in the browsers memory. 

Sure you can use AJAX to store previous &quot;states&quot;, but that implementation is also slow because it requires a roundtrip to the server. The browser should be able to store the previous states in memory - which the browser does very poorly. 

Also, how do you undo writing something, and then accidently hitting some key that either reloads the page or move to a different page altogether (in a web application). 

Undo is extremely important, but damn the browser is annoying :)</description>
		<content:encoded><![CDATA[<p>Interesting &#8211; nice find.</p>
<p>May I add a 5th point: Problems with handling Undo in the browsers memory. </p>
<p>Sure you can use AJAX to store previous &#8220;states&#8221;, but that implementation is also slow because it requires a roundtrip to the server. The browser should be able to store the previous states in memory &#8211; which the browser does very poorly. </p>
<p>Also, how do you undo writing something, and then accidently hitting some key that either reloads the page or move to a different page altogether (in a web application). </p>
<p>Undo is extremely important, but damn the browser is annoying :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
