I'm sure OP is getting lots of comments now! I'm not sure the rapid timing is really the cuprit here. I would argue that there are other UI factors at play:
* The text doesn't get cleared from the comment box after the comment is sent
* The submit button has no visual affordances to indicate whether it is valid. It looks exactly the same when the form is populated or empty. A conventional UI approach would inactivate the submit button until all the fields are filled.
So despite the message that the comment has been posted, it doesn't appear as if the state has changed as a result of pushing the button.
I think clearing the comment box and inactivating the submit button (which doesn't appear to be a native OS UI element) after submission would help users understand that the state has changed. Alternatively, I think displaying the acknowledgement message on a new page with no submission form would achieve something similar. It could even have a "post another comment" link back to an empty comment page.
Alternatively, I think displaying the acknowledgement message on a new page with no submission form would achieve something similar. It could even have a "post another comment" link back to an empty comment page.
This is exactly what nearly every other form I've used in the past does. I didn't try this one but it sounds like it redirects back to the form again? If so, I can definitely see double/triple-posting happening.
I know some forums will actually compare contents with the last post you made, and show a warning message "You already submitted this post".
This is the real answer. Every other comment box or form I've seen on the Internet clears the content when the form has been submitted. I would suggest making them disappear altogether
I think you are mostly right, but I've heard this effect observed elsewhere.
I recall a blog post about TurboTax or some other tax software. The part where it says "checking your returns" -- if it takes longer, people view it as having "done something".
You can probably check a tax return, which is really about 100 numbers, or maybe 10,000, in less than a millisecond. But it's better if takes like 10 seconds.
Someone might know what I'm talking about and have a link ...
I do think it's partially the latency, but the UI concerns you pointed out are probably more important in this case.
I considered submitting a duplicate of my comment as a bit of silliness, but found this surprising when I submitted my first comment too… so my second comment was instead much more similar to this observation you shared here.
This is the #1 heuristic in the old Nielsen usability principles. It's called 'visibility of system status'.
Users have been trained by years of experience that errors are often immediate, while real 'work' takes a little while to happen. From that POV the conclusion is correct - adding an artificial delay is the common solution, though it can also be handled by other forms of feedback.
In this case, the success message is appended after the form. A few tweaks that could help:
- make the fields become read-only after submission
- hide the submit button after success
- replace the whole form with the success message
These would help both to eliminate confusion, without the introduction of artificial delay, and to prevent double submission.
I love this. Classic usability problem, "misleading" user feedback, and an assumption based conclusion that puts the blame elsewhere.
I don't mean it bad, it's very hard to deep digger when people literally identify the thing you assume the issue is. It's why in usability/UX/any design it's so important to dig deeper, ask "why" a bunch of times, play the devils advocate, try to proof yourself wrong, and never ever take any sort of feedback at face value.
It's what I like about usability/design, you can assume a bunch of things based on all sorts of seemingly quality information, make a coherent plausible argument, and still be incredibly wrong. It can be very humbling. This case might be pretty basic, but this is a very common pitfall. It's why testing and validating your assumptions is so essential.
I have not tried the form (don't want to spam), but the fact that people are able to submit the same comment twice is probably a good place to start. Fixing that with some improved feedback will likely go a long way.
> It's why in usability/UX/any design it's so important to dig deeper, ask "why" a bunch of times, play the devils advocate, try to proof yourself wrong, and never ever take any sort of feedback at face value.
This applies to any user feedback, not just UX... faster horses and all that. Most users do not introspect enough to figure out the core of the issue they are experiencing - if we do our job well, we do not merely empathise, but go on to dig deeper than they are capable of.
The users click the button, get told it worked, but their comment is not visible to them. The fact they can't see it is why they suspect a problem I think.
A UX improvement might be to update the success page to show their message back to them with a prominent "Pending review" message very close and very obvious next to their message.
The user explains that they expect some additional UI affordances to indicate that the comment was submitted, but the author chooses to interpret this in such a way as to tickle their personal web-so-bloated horn, and sounds very pleased with themselves for having done so.
Well to be fair, the author says the user specifically identified the speed of submission as suspect. If that’s true (and I have no reason to doubt it, there is a long running UX trope about adding artificial delays because users find fast results untrustworthy or unsettling in some way), it’s possible they didn’t fully understand their own psychological reaction: it was fast and it provided feedback in an unusual way.
If my comments (posted to the site before coming back to see the HN discussion) are reviewed and pass muster to be posted, they’ll reflect these thoughts as well.
It's just bad UX that has nothing to do with timing. Clicking submit doesn't change the state of the form in any other way. It should hide all the fields, include the button, and just show the message. Then they can't submit twice.
Maybe it's not that obvious to someone who doesn't do UX?
It seems most form builders either have the form clearing behavior by default, or redirect to a new page. The person creating the form never even has to think about it that much.
And it's not like bloated web pages would take any longer. I could have an SPA in whatever framework, littered with ads and whatnot, but just doing a request to save a comment and displaying a message on success would really not take any longer.
It's quite common for UIs to introduce fake latency on purpose so that users trust the application more. When it goes too fast, users don't trust it, so a benevolent deception is introduced.
One other thing I would check is disabling or removing the submit button after the first click. Just an onclicked event to set the disabled attribute will go a long way.
Double-clicking on a lot of sites will submit the form twice. If people are waiting, they will click again, and again.
I build front ends closely with a design/"UX" team, and this is a real thing. We intentionally add delays, especially on "save", like what the author is referring to. People expect there to be a delay, so a UI without the delay is unexpected. We have unintentionally trained users to expect to wait for the computer to do certain tasks.
One thing I’ve found effective—related to where I thought this post was going before it veered off my predicted path—is instead of adding delay, changing the state of the UI element that’s being interacted with immediately. This still shows work is being done, without adding any more delay than the time it takes to change state.
My expectation was that this was going to be a case where users were trained to double click, and they were triggering multiple requests that way. Of course the solution to that is to prevent the second click before it happens, and visually indicate that the button was clicked. The same approach applies here. Users expect to see state change when they perform actions.
I don't know about you guys but I think its pretty fast. I'm from the UK and got a 34.5ms response time using network tab on safari. I looked up the IP address of the host 151.236.217.16 and the server is located in Amsterdam it seems. I'm guessing if your in the states it would be 150ms? Anyone can confirm out of interest?
177ms from west coast of NA, but that is slower than I would have estimated. Other than HN, almost everything else I use regularly feels subjectively way slower, although I've not checked response time.
This is a good explanation for some behavior I see on one of my sites. The site is barebones html with a tiny amount of js to support an email list signup form. There's some quick validation on the backend but the response cycle is super quick. I get double signups every now and then.
I think comment forms should not accept a double submit of the same thing within 10 seconds.
Also, I suspect some of the delay in handwritten stuff is important processing like antispam checks.
CPU and network efficiency are wonderful things. But if a lightweight solution can't provide the same level of features and convenience as a modern package, I would toss it without a second thought.
My original personal site was handmade HTML with a PHP header. I eventually got rid of it for DokuWiki and never looked back.
If it was a pro site, I think I would just use WordPress.
It is an impressively high performance site you have though!
One thing you can do here (and I think Hacker News does this) is debounce comments, to reject submissions that come very quickly with the exact same content. Perhaps it was added for exactly this reason ;)
An engineer at a major auto insurance company told me about an app they had for insurance appraisals. If a person got in an accident, they could open the app, take pictures of the damage, and see what how much they'd get back from insurance. The first version would send you back an appraisal almost immediately. He said they had to add a ~24 hour delay because a lot of people thought it was impossibly fast, and that their claim hadn't been reviewed thoroughly enough.
If the comments aren't published automatically, but await your manual review, then why didn't you go with "comment by emailing me"? Was speed the motivation? (Obviously sending mails is far from fast.) Or did you consider a textbox to be a "smoother" experience for your users? Or just for the fun of implementing the comment system?
It's not entirely "comfort of the bloated web". We as humans have trouble perceiving something happening "faster than the blink of an eye". So, faster than 300ms or so. It's not uncommon for fast UIs to deliberately introduce delaying animations or some other indicators to trick us that yes, things did happen.
Even if OP doesn't want to add "artificial restrictions", they could still prevent commenters from wasting time retrying posting their comments by detecting when they're submitting the same comment twice, and making it clear what's happening then.
* The text doesn't get cleared from the comment box after the comment is sent
* The submit button has no visual affordances to indicate whether it is valid. It looks exactly the same when the form is populated or empty. A conventional UI approach would inactivate the submit button until all the fields are filled.
So despite the message that the comment has been posted, it doesn't appear as if the state has changed as a result of pushing the button.
I think clearing the comment box and inactivating the submit button (which doesn't appear to be a native OS UI element) after submission would help users understand that the state has changed. Alternatively, I think displaying the acknowledgement message on a new page with no submission form would achieve something similar. It could even have a "post another comment" link back to an empty comment page.