Redundancy is the use of more elements than necessary to maintain system performance in the event that one or more elements fails. It’s probably not a word you think about much when creating a new design, but it’s an important principle of design and one you use all the time, even if you aren’t thinking about it.
Many modern buildings have an emergency power system that kicks in if the regular power system fails. The more important the work taking place inside the building (say a hospital), the more likely the building will have one or more redundant power sources.
Buildings are also designed in a way where if one structural element fails, the load it was bearing can be spread to to other structural elements, thereby maintaining the overall system and keeping the building standing.
Naturally some systems are more important to maintain than others. Systems that help preserve human life are probably the most important to keep running. Others like the cable signal that runs to your tv, not so much. Where does redundancy fit in web design (.ppt)?
There’s a little more to redundancy than simply saying add more elements. Let’s talk a bit about different kinds of redundancy and where each type should be applied and then let’s talk specifically about web design and where redundancy improves sites and where it hurts sites.
The 4 Types of Redundancy
Redundancy adds elements in order to increase the reliability of the system While redundancy is always about having multiple elements work toward the same goal, there are a few different types of redundancy, each achieved with varying difficulty and appropriateness.
Sometimes you can view redundancy as a backup and sometimes you can view redundancy as multiple elements working toward the same goal. Redundancy can be good or bad depending on where and how it’s used.
Diverse Redundancy
Diverse redundancy is the use of multiple elements of different types. For example using text, audio, and video to communicate the same message. Diverse redundancy is resistant to a single cause of failure. If the audio goes out you can still watch the video (though not listen to it) or read the text.
The message can still get through, even though one element completely failed. We even learn better when presented with several forms of the same information.
However, diverse redundancy can be hard to implement and maintain. You would have to create the text, audio, and video after all and if the message changed you’d need to modify all three as opposed to just one.
Diverse redundancy is best used for critical systems that are important to keep running and where the probable cause of failure is difficult to predict. Each type of element can survive different failure so the likelihood is at least one will survive.
Homogeneous Redundancy
Homogeneous redundancy is the use of multiple elements of a single type. For example the individual strands that make up rope. Any single strand can fail without the rope itself failing.
Unlike diverse redundancy, homogeneous redundancy is easy to implement and maintain. What’s one more strand of rope when we’re already weaving so many others together.
The problem with homogeneous redundancy is that all the elements are susceptible to a single cause of failure. The same sharp edge that cuts one strand of rope can also cut every other strand of rope.
The use of homogeneous redundancy is best when the probable cause of failure is easy to predict. Since we know how an element will fail we can design the system itself not to fail under those conditions or use an element unlikely to fail under the known condition.
Active Redundancy
Active redundancy is the application of all redundant elements at the all times. Again consider a building and the columns used in support. Each column is always active in carrying some portion of the load, though the building itself would still stand if some of those columns weren’t there.
Active redundancy protects against overall system failure as well as element failure. Since each redundant element is active none are required to do the maximum work they could do. If an element does fail it can usually be repaired or replaced with minimal disruption to the overall system or system performance.
You want to use active redundancy (PDF) when it’s critical that systems maintain a stable performance in the event of element failure or extreme change.
Passive Redundancy
Passive redundancy (also called standby redundancy) is the application of redundant elements only when an active element fails. A spare tire is a good example. It’s there in case one of your other tires fails, but it’s passively sitting in the trunk until needed.
Passive redundancy is best for noncritical elements. If the system can run even temporarily after an element fails, it’s redundant element can be passive. It doesn’t work well for critical elements unless it’s ok for the system as a whole to temporarily fail.
This is the simplest and most common form or redundancy and is used mainly for noncritical elements within the overall system when a performance failure is acceptable.
All 4 types of redundancy should be used in combination within the overall system for best results
Using Redundancy in Web Design
All this talk of critical and noncritical elements is great, but where does web design fit in? No one wants to see their website down, but it’s rarely critical if your site is down for a few minutes. Still uptime is probably the most critical aspect of a website so let’s start there.
Redundancy in Hosting
Most web hosts have redundancy built in. In fact the more you’re willing to pay the more likely your account will come with more redundant systems. Your site might be housed on multiple servers with or without load balancing. The data center most likely has redundant power sources. You or the host should be making regular backups of the site.
All of the above are redundant elements to ensure your site the maximum uptime.
We might look at the idea of caching as a redundant system as well. We’ll serve a cached page, essentially a duplicate of the page displayed after querying the database, to help the server withstand the stress of many visits over a short period of time and for improved system performance in general.
Redundancy in Communication
I already mentioned the idea of using text, audio, and video to communicate the same information. We can add images to the mix. Different people learn in different ways so the more ways we try to communicate with them, the more likely they’ll receive our message.
Each way of delivering the message adds another layer of communication improving the overall unity of your design. One of the reasons to understand design elements and principles is to have more ways to communicate with your audience.
Within the basic principles of design things like repetition or similarity take advantage of redundancy by transferring the meaning of one element to another.
Redundancy in Navigation
We often build redundant navigational systems into a site. We might set up a specific navigational system for people and another for search engines. We might organize information based on category, hierarchy, time or tags.
We have horizontal and vertical navigation. We use breadcrumb navigation. We place navigation directly in content in the form of single links. We’ll add internal search in case our main navigation doesn’t work to get visitors to their desired destination.
We give our visitors several ways to find the same information.
Blue, underlined text is standard for links. Note that the standard is both blue and underlined. Redundancy. One or the other, blue or underlined, isn’t necessarily indication of a link. Both almost always are.
We further give the link a hover state and perhaps an active state to further indicate a link is present. Think about that. Think of all the different ways we communicate that a string of text is a link and how much redundancy is involved to communicate something so common on web pages.
How many forms of payment do you take? Credit cards? PayPal? Checks? Cash? Aren’t they all redundant after the first? If your client or customer doesn’t have a credit card, you might still sell to them via PayPal. Your client doesn’t use PayPal so you accept a check.
Redundancy is necessary when it comes to accessibility. We add alt text to images, titles, to links, labels to forms. All redundant ways of communicating the same information for a specific set of visitors.
Click paths are another redundant system we design. Ultimately you want someone to find and proceed through your checkout system, but is there only one way to arrive at checkout? Probably not.
Different people will absorb our information differently. One might need to pass through your about page, another might need to read your testimonials, a third might only care about features. We design multiple ways for them to use our sites as they want and still find their way to contact you or enter your checkout system.
Where We Don’t Want Redundancy
While redundancy is generally advantageous, someone has to set up and maintain all those extra power sources at the hospital. Redundant elements and system do come with a cost and sometimes that cost is the more important factor.
The obvious place where we don’t want redundancy on our sites is in our code. While we want to anticipate and prepare for code failure, there are usually better approaches than duplicate code.
One reason for recommending css over tables is because tables generally lead to redundant code. It’s the same reason for recommending css and javascript be moved to external files or when available linking to hosted libraries like jQuery.
As web development evolved we moved from simple html to things like php includes, again for the reduction of redundant code. Those includes evolved into templating frameworks and content management systems. All essentially for the purpose of removing redundancy and with it improving maintainability.
One idea recently put forth is the idea of object oriented css. It’s something I can’t claim to have explored enough to work with, but it’s about reducing redundancy in our css and as a result making our sites as a whole easier to maintain.
Summary
Redundancy is probably not something you specifically think about when designing and developing websites, though you likely practice many of the ideas behind adding and reducing redundancy in every site you develop.
Look for additional ways to communicate the same message to increase the odds the message is received by your audience. Provide redundant systems of navigation to help visitors find their way. Provide redundant means for completing task to help your audience achieve their and your goals.
Remember though, that redundancy comes with a cost and sometimes it’s the cost that’s more important. Eliminate redundancy in your code wherever possible to improve system performance and maintainability.
What other kinds of redundant systems to you use when designing a site? Do you consciously think of redundancy during design?
Download a free sample from my book, Design Fundamentals.
Great article and something I have not given much thought to, especially content redundancy.
I disagree with only one part. 🙂 The bit about redundancy in programming code.
I don’t think it’s called redundancy but rather code repetition or duplication. Redundancy is all about preparing for when something breaks. Repeating code isn’t preparing for when something breaks, it’s just an inefficient way to code. Your thoughts?
Thanks Aaron. Yeah, you’re probably right that in programming code it’s not called redundancy and isn’t being done to prepare for failure.
Redundant has other meanings though, and I think those meanings would allow us to call the extra and inefficient code redundant.
Enjoyed this article, especially the analogies.
too intellectual. (yes there is such a thing).
i have though about this issue as it relates to design and the amounts of content should be reversed. no one really needs to know that much about of the types of redundancy. It should be relatively self explanatory. the user doesn’t care, they just take it for granted. we as designers have to take that into account.
the article should have been %15 about types of redundancy, and %85 about how to create the positives in redundancy while maintaining originality in design. the web has a lot of the “same $#!^ in different toilets”. it’s time to flush.
You might not want to know so much about redundancy, but based on the other comments here I would suggest other people are happy to get this information.
No one said the user cared. Quite frankly most users don’t care about design in general unless it’s done poorly. It’s those of us who are designers who care because the more we understand design the less likely we’ll create a site that gets in the users way making them notice a bad design.
So what tips would you suggest for the 85% you feel missing from this post. You are free to write your own post you know. As far as this post being the same $#!^ I would highly disagree. Most posts you read are a generic list of useless tips (that 85% you seem to want) and very few actually talk about the why behind those tips.
This blog may not be the greatest blog ever to hit the Internet, but it’s definitely not filled with the same old posts you see everywhere else.
Thanks for enlightening me about redundancy in web-designs. This is a very useful article for web-designers
Thanks, interesting article! I wasn’t really aware of all those different types of redundancy. I am designing a web application with complex functionalities, and I was actually looking for information on (in my opinion) another kind of redundancy.
In our application (it’s a survey application) there are options, such as making a question in the survey mandatory.
We are wondering whether it’s a good thing to have different ways (not different ways of navigation, but really different ways) to make a question mandatory. For example a mandatory/not mandatory toggle button in the menu, but also the option to change this in the settings of the question, and maybe even with a button in a tooltip which appears when the question is selected.
Do you have any ideas on this kind of redundancy?
Thanks Lina. I wasn’t aware of the different types either until I researched this post.
With your application do you mean you want people to be able to mark the questions mandatory or not, or would this only be the admins of the site that could change the setting?
I’m not entirely sure redundancy is necessary with what you’re asking, though I may not be following exactly. Feel free to add a few more details about what you’re trying to do.
I’ll be glad to help if I can.
How can we build redundancy in outsourced developers bailing? I have seen too many projects failed because of that