The print-on-demand service that I’ve chosen for my book has a fairly nice web user interface with lots of Ajax code. Generally, that web application is one of the best aspects of doing business with them. That’s why I was surprised to find a rather amateurish flaw in their shopping cart. Here is the screenshot:
Notice the “do not click Place Order more than once” message. Someone has obviously identified that customers have been clicking more times than needed, but offering a warning message is not the way to solve the issue. In fact, such a message is a huge warning signal that something is wrong.
I’m pointing out this case in particular because it is one of the most frequent problems I’ve seen in Ajax sites, and one so easy to avoid. The proper solution is incredibly simple: always disable the form as the first step of asynchronous processing. It is very easy to block the “Place Order” button before an Ajax call goes out to the server, and doing so would technically prevent anyone using a proper browser to place the same order twice. For high volume sites, like this one, I always recommend implementing some sort of double-order analytics on the server just in case, because exceptions do happen, but just a simple JavaScript command to disable that button would save everyone a lot of trouble.
|
|
Or you could follow this technique outlined by Mark Nottingham
A basket should always have an unique id. When a second order comes in for a previous order, it is easy to discard the second one.
One could just as easily disable the “Place Order” button once it’s been pressed. It’s not great security, but assuming (since it is an AJAX site) that Javascript is already necessary for the user to have gotten to this point it makes the change trivial.
If the user doesn’t have javascript, disabling the “Place Order” button will fail to prevent double orders. Therefore, the fix should be implemented server-side first. Disabling the button after one click is a great addition, but it shouldn’t be the primary means of preventing double orders.
In general, all sites should be usable with javascript turned off.
It’s also worth noting that the four prices on that page are in two different fonts and three different sizes, no two of them are aligned, and there’s no indication of what the second occurrence of 5.57 is actually supposed to mean.
Don’t label labels!
@Christian von Kleist
I disagree, unless we’ve accidentally gone back in time to 1994. If you’re using the internet with a browser that is incapable of using javascript, kindly get off the internet. The rest of us would like progress in this platform we call the internet.
@Christian von Kleist: Quite true, but if the user doesn’t have javascript, they’re not going to be using the AJAX interface, which is the cause of the double orders in the first place.
“In general, all sites should be usable with javascript turned off.”
This used to be good advice but today I think it’s unrealistic. Most of the sites I use on a daily basis (many from Google, for example) require Javascript. For better or worse, it’s no longer unrealistic requirement.
Still, you have a salient point and the Javascript solution should not be the only one.
Disable *with a timeout* of course! I hate when AJAX call fails and I’m left with disabled form and can’t retry.
@Brian @nanreh
So it seems you think that visually impaired people, those using assistive devices and anyone with the cheek to use the web via a text-mode browser should be banned from your technicolour all-singing, all-dancing “internet.”
What really surprises me is *your* 1994 attitude of “accessibility doesn’t matter.”
JavaScript is now a part of life on the Internet. In a way, if you dont use JS, then your website typically isnt as nice as your competitor. While it is important to consider accessibility requirements, I feel that as designers and programmers, we are limited by the abilities of screen readers and related technologies.
My point is that the screen reader software cant deal with too much JavaScript, so we developers must work around that. But, what if we all said “to hell with them” and started using JavaScript everywhere (which is where it looks like we’re headed anyway) then what do the screen reader programmers have to do? They have to improve their software! This makes it better for everyone, all around. So instead of getting on each other’s backs about accessibility, we should be on the screen reader’s backs about improving their technology.
You don’t need a single line of Javascript if you write your server-side to recognize multiple submissions and redirect to an order status page. This prevents situations like the one kL mentioned, in which the request gets lost in the net and you can’t submit again because the button is disabled.
Our intranet app uses tons of JS. You can’t even log in without JS enabled. Screen readers work just fine with it. I can’t remember which ones we currently have people using, but JAWS is one of them.
The idea that accessibility tools are as limited as Lynx is a common misconception.
@Bryan @Alan
But it’s all very well to declare that we should say “to hell with them” from your ivory tower of Windows Vista with all the latest plug-ins installed, but for the visually impaired person just trying to get some simple task done you arrogance is extremely damaging. I happen to do a lot of text-mode browsing, simply because I am working remote via SSH quite a bit, I know quite a few people in the same situation. We don’t all run Windows and we don’t all have graphical displays.
The web is built on the principal of universality. Web pages are meant to work on every device out there, no matter what shape/size or ability. If you don’t know what “progressive enhancement” means you shouldn’t be in this industry.
Being in India, I often use the Indian Railways site. They follow the same method of preventing users from re-submitting the form. You can observe this by visiting their site (http://www.indianrail.gov.in/) –> Train Between Important Stations –> click Get It button –> click Get Availability button. You get a message asking you not to re-submit.
I don’t think they use AJAX, though, but still if some error does occur, then the user is stuck.. Of course, he can always refresh… Or may be they are confident about the robustness of their code…
I once clicked the Get Availability button, and immediately pressed Esc (jus testing). Further clicks of the button were met with the message, “Please wait… availability query is in progress…”
@Brian: I browse with Firefox and NoScript, so by default Javascript is disabled for every page I visit. It’s safer and cuts out a lot of annoying clutter.
i ignore these warnings and often resubmit order forms if they look like they’re timing out. i’ve never been charged twice for anything, and i assume that if i ever am then a quick email or phonecall will resolve the issue. why worry?
asking people not to resubmit forms is like asking people not to use their back button – it ain’t gonna happen.