Edward Yarnold

I’m a fairly regular user of the twitter web front-end, and of Facebook. Both of these have tremendously wide audiences and are hugely popular. Twitter recently attracted a bit of negative press from the technical community for replacing the old, fairly standard URL structure with one that uses ‘hashbangs’ and is fully dependent upon Javascript to serve the correct content. But I’ve another more user-centred complaint about Twitter (and Facebook) relying heavily on Javascript for fundamental parts of their apps (e.g. the ability to tweet, and ability to comment on stuff). That is the removal of the ability to ‘refresh’ or ‘resubmit’ a request…

Let me give some background. I live in quite a rural location, where the broadband is far from perfect. My packet loss rate is higher than desired which means that sometimes requests for web pages or web services fail in some way. This is not normally a problem; if the page partially loads or stops loading, I hit refresh and generally get the whole page. All fine!

In ‘the olden days’ when processes such as updating your Facebook status or posting a tweet were done through bog standard HTML forms posted by the browser to a new page request, it didn’t matter when the page I was posting to didn’t get posted to fully, or didn’t respond, because I could hit refresh (or press the submit button again or whatever) and the request would be resubmitted.

Some web developers (myself, at times, included) HATE impatient users who will press buttons twice or refresh the page because it’s taking too long. In a lot of apps this means that the action is applied however many times the button is pushed (e.g., two or three orders are placed instead of one). But the reality is, sometimes there is a genuine need to refresh or resubmit, because nothing is *ever* going to happen with the first request that was sent. This could be due to an internet connection problem or a server-side problem.

Now, more and more web sites seem to favour the “no new pageload is necessary” approach which, in itself, I do not have a problem with – at all. What I do have a problem is is when the developers choose to disable the submit button once I press it – permanently. Because if nothing happens for 2 or 3 seconds, I am pretty damn sure that that status update or tweet is never going to get posted. What I would like to do at this stage is to resubmit the request. But at this time, there is no easy way to do this:

• I have not requested the page in a traditional sense in the browser, so I can not push the ‘refresh’ button; that would reload the whole page and typically delete the tweet or status update that I have written.
• The submit button for the form is permanently disabled, so I can’t press it again to submit again.

Even if the JS implementation gracefully degrades (e.g. if I have no JS support I get the “old fashioned” style normal form), this situation occurs for people with JS enabled. Just because a user has JS enabled doesn’t mean that their web connection is faultless or that they won’t need to push that submit button twice!

I was trying to think of a way around this issue that doesn’t require scrapping the AJAX submission all together, and came up with only one potential solution, which is to disable the submit button but only for an elected period of time (say 2 or 3 seconds), so that if the request doesn’t get responded to in that time, the user is given an opportunity to re-submit.

Anyone else’s ideas of how to work around this problem would be gratefully received through the comments section; I don’t want to write software that frustrates people in the same way that this frustrates me!

This entry was posted on Tuesday, February 22nd, 2011 at 11:57 pm and is filed under Best Practice, Javascript, Usability, Web Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.