User and Social Experience Design
Artificial feedback loops are ones closed with assumptions and not real system feedback upon the completion of a process such as saving information in a database.
One of my issues with web user interfaces — particularly ones that use AJAX for dynamic postback of data and instructions — is the disconnect between client-server-client when it comes to providing feedback. This is an issue generally in poor programming but I want to look particularly at the effect on users in this case.
Often systems are not developed as closed-loop circuits and thus changes on the client may not accurately represent the state of the output. You may see a success message on the web page but it doesn’t mean the database actually committed your new or modified record – it could just mean your input passed the client-side form field validation and was pushed off to the server.
Generally you’ll get away with an artificial closed-loop system because the assumptions you make that artificially close that loop will be valid most of the time. But things go wrong; the database times out, there was a mismatch in client- and server-side validation parameters that missed an edge case and doesn’t throw an error in the routine that returns the response, mod_security blocked the request etc.
You cannot fire and forget a request or collect your feedback half-way through processing the request. If the purpose of an operation is to save a user’s changes then the user has an expectation that any feedback they receive is indicative of the system state upon the full completion of their request.
If you decide to make assumptions about how the request will complete and close the loop short of full execution of the request then assuming your produce gets past testing it’ll mean that most of the time it’ll be ok. But what are people going to think of the reliability and trustworthiness of your application if it tells them it successfully saved their information and then they find out later that it didn’t? Are they still going to have confidence in the security and privacy of your website if they know that your site lies to them and deceives them?
Closing the feedback loop is not hard. You know what the request is, where it’s being handled and where it ends. You can get the information you need to provide genuine feedback. Re-querying the database if you have to to verify the successful committing of data will use additional resources and will take extra time yes but sometimes you have to compromise a bit on performance in order to check your facts rather than having your application telling users porkies.
Examples
This sort of issue is more common than you think. Take Twitter for example; there is a server-side character limit on the Location field in your profile. Up until very recently you could go over that limit and submit the form. It would tell you your changes had been saved, but they wouldn’t have been.
WordPress in the latest version when I hit Save Draft on a new post it ends up creating three draft posts. I didn’t ask it to duplicate … I said save! If the software bothered to check it would notice it had screwed and and either fix the issue by removing the duplicates or as a last resort tell me what had happened so I could fix it manually. But no, it reports everything is ok.
And of course there are progress bars. I don’t think I’ve ever seen a software installation, file decompression, virus scan, upgrade, download or any other sort of progress bar actually look like it’s based on any meaningful measure of progress.
For a non-web example look at commercial jets: Boeing airliners use a hydraulic control system (as opposed to Airbus jets) which due to the mechanical nature of the system means that pilots will feel when controls are being unresponsive or resisting, indicating a problem with the plane or the environment. However for an Airbus with electronic controls that direct closed-loop feedback is not present – only a separate system of electronic monitoring and reporting. The lack of connectedness between the request and response systems introduces risk of inaccuracies or uncaught problems.
Closing the loop will ensure there are no gaps between the point where you decide to gather your information for user response and the actual completion of processing the request because it is in such gaps where your unknown errors are thrown or things break down and go unreported.
// purecaffeine.com is a user interaction and UX design, social media and Government 2.0 blog run by professional Canberra, Australia web user interaction designer Nathanael Boehm, licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia License.
