1

It's common for modern web applications to be split into a UI that runs locally in the browser, making requests to backend services that just return data, not UI components.

Is there a pattern to support gradual failure of such a UI? E.g., on Stack Overflow, if the search service were offline, we'd want to allow reading and commenting to continue to work, but gracefully handle that search isn't working at the moment.

  • 2
    Hi, Joe, welcome to the site! The title of this, at least, it pretty darn broad and rather technical. This whole site is about "good UX" - can you edit to be more specific and concise, while leaving out any unnecessary tech? – Tim Grant Dec 8 '16 at 21:52
  • I'll try to make it less technical and more specific. Thanks. – Joe McMahon Dec 9 '16 at 1:26
3

I think what you are looking for is Graceful Degradation of User Interfaces.

Gmail does a very good job of letting users know very gracefully that something is not working. Everything else seems to look just fine and yet it conveys the message. Look at: https://pbs.twimg.com/media/CDQ9NJtUEAEImsq.png

If this somewhat resonates with what you are trying to achieve, you could try playing with an error message on/near the UI component and rendering in its disabled state.

Say for example, you have a search bar, product listing and filters. For some reason, your search bar fails to retrieve results for the search autocomplete, you could try extending a line below it and say "We cannot receive search results right now, keep browsing in the meanwhile".

Similar stuff can be done with Filters and the Listings too.

Let me know if I caught your problem correctly.

| improve this answer | |
1

Graceful Degradation is still a valid concept foundationally, but it's become a bit dated in practice. Modern frameworks have allowed a lot more flexibility in not only the platforms deployable to, but the range of errors handleable when bad/missing data returns. Treating unknown calls returned from a service driven UI begins in the user story writing and design phase. You just have to know what you want it to do.

Without taking away from anything laid in the foundations of Graceful Degradation, you might begin more simply by writing user stories that handle situations you are concerned about. Using your 'Search' example, a User Story might sound like this:

As a Stack Overflow user I want to be able to search topics, so that I can find threads of interest to me.

AC1 - Given the search engine returns bad or missing status, when I browse Stack Overflow, then show page components that are functioning...

You could refine this to a fine level of granularity, so that the page will resolve until a certain critical level of usability is gone. You could also define specific 'oops' situations where you would not want to provide any bad experience due to bad/missing service information.

The best thing to take away from the Graceful Degradation concept is the notion of requirements > design > prototyping > implementation. The discipline is in thinking through the errors before they happen - not reacting to them after.

| improve this answer | |
  • This is very useful advice; I'll take this back to my team for our next design go-round to make sure our next iteration has pre-planned for what to do if a service outage occurs. – Joe McMahon Dec 16 '16 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.