Once upon a time in web design, all you had to do to make your sites cross compatible was set them to be 960px wide and fix the issues that popped up in IE6. Ah, the old days....
Today, the internet is made up of so many moving parts it's almost certain at least some of your end users are having less than perfect experiences, due to issues you probably had no idea were happening.
We've just opened the doors on a brand new course entitled Bombproof Web Design that will help you chase off any sneaky gremlins that might be hiding away in the corners of the internet, blowing up your sites when you're not looking.
In this article, we'll be running through 7 ways you might not know your sites are exploding, each of which are deftly handled in the Bombproof Web Design course.
If you can go through all seven of these points and say your sites are solid on all counts I'll be super impressed, and you'll get a great big gold star!
The first way you might not know your sites are exploding is:
1. Web Fonts Not Rendering Properly
You may not realize it, but your web fonts can actually look notably different from one operating system to the next, even in the same browser. For example, the following three screenshots are all of the exact same site, with the exact same font settings and code.
The first is taken in Chrome on a Mac:
Okay, all seems to be well there. Let's check out the same site on Chrome again, this time through Ubuntu:
Hmm, that's a pretty unpleasant look in the headings there. You can barely make out the letter "s" and the letters "A" and "e" are almost closed solid. How about Chrome on Windows?
Gah, look at those artifacts! Every letter curve has a little tag hanging off it and overall it's pixelated and ugly.
There are several different ways you can get caught out with inconsistently rendered or even entirely absent fonts unless you have a plan for evaluating and deploying your typography choices.
2. Barely Rendering at all on Opera Mini
Even the worst web font rendering is still going to make your sites look great compared to
browsers that don't render web fonts at all, such as Opera Mini. And web fonts aren't the only thing that Opera Mini doesn't render. This is the same site that you see above, this time in Opera Mini:
As you can see, pretty much everything failed, short of basic colors and text. Opera Mini is a mobile browser designed to handle sites in a very light weight manner, allowing it to be used on lower spec devices and for those trying to conserve bandwidth or system resources. Unfortunately, part of the way it does that is by not supporting a whole range of CSS properties, particularly CSS3.
Opera Mini has a small but significant user base. To put it in perspective, stats that I've looked at showed Opera Mini use at around a third of total IE users, and higher than for Android Browser and Opera Desktop. It's quite probably the most difficult browser to wrangle today, but one way or another you'll want to have some kind of plan for it.
3. Not Accounting for User Preference
On Firefox, when you go to Preferences > Content you'll see this:
On Chrome, when you go to Settings > Show advanced settings > Web Content you'll see this:
Both of these settings panels are designed to allow users to adjust the font size of their browser to suit their needs. People with visual impairments will commonly use these settings to help them read more easily. They are also handy for people who use their living room TV's for browsing, something which is becoming increasingly popular.
It's a very common practice to set a base font size for a site like 14px or 16px against the html and body elements. However, this prevents the user's font size preferences from taking effect. If a user is visually impaired, being unable to enlarge text makes life a lot more difficult, or if the font size has been altered to suit a particular display size it can make text very hard to read.
On top of that, if a user does have a non-default font size selected it's important to have your whole layout able to scale along with it. You don't want to end up with a layout that's all out of whack because it only suits one text size.
For example, here's our same demo site again, but built without the ability to scale and the base font size set to 22px:
Yet with scaling built into the code, the same site with a font size set by the user of 22px looks like this:
You might not be able to see what's going on in the above screenshot as the image has been shrunk to fit in this column. At first glance it might look just like the very first screenshot in the article, but that's only because it has scaled up proportionally with the user's font size settings.
To give you a better idea, here's a section of the site at its actual size:
Building your sites this way means you give the user the same viewing experience no matter what preferences they have set in their browser.
4. Not Fitting All Displays Comfortably
Almost all web designers have already made the transition from desktop-only layouts to including support for common tablet and phone resolutions, but that's still only part of the picture.
The list of possible resolutions today is longer than your arm, and we then also have to factor in pixel density, the portion of the display the viewport takes up, and the actual physical size of the display.
Right now your sites could be visited by users on displays both miniscule and gigantic, and it's almost impossible to predict what combination of resolution, pixel density, viewport size and physical size your visitors will have. A 5" smart phone could have the exact same resolution as a 65" TV, yet browsing a site on each device is very different from the user's point of view.
That said, it's actually not at all difficult to create layouts that are completely flexible for all displays. With the right set of principles underlying your layout code all your sites will be equally at home on any display, from TVs at one end of the spectrum:
To tiny little smart watches at the other end of the spectrum, such as through the WebBrowser app for the Sony SmartWatch 2:
5. Bombing Out When JavaScript Fails
It's easy to assume all users will have functional JavaScript that we can depend on absolutely. JavaScript tends to play a part in almost every site, and in some cases entirely drives content through things like web components and client side rendering.
But what if JavaScript isn't as ever present as we might think?
There are actually plenty of reasons why a visitor might not see a JavaScript dependent site as you intended it to appear.
- Some workplaces enforce a network wide block on JavaScript as a security policy.
- Some mobile browsers prevent JavaScript from executing.
- Some people follow advice from security advisers and disable JavaScript at the browser settings level.
- Some people run browser extensions that block JavaScript by default so they can add exceptions on a case by case basis. For example, the most popular such extension for Firefox right now has over two million users.
- Sometimes JavaScript will just fail to properly execute due to incomplete script downloads, limited system resources or other potentially unforeseen circumstances.
The bottom line is that even if the percentage of users who don't have fully functional JavaScript is small, it's still present and becomes ever more significant the more successful and well trafficked your sites are.
If you don't have a plan, instead of your otherwise awesome blazing fast client side rendered site your visitors might just see a bunch of unrendered HTML:
Or instead of your amazing web components, your visitors might see a collapsed layout:
6. Depending on Absent Input Devices
For a long time interaction with websites was almost entirely dependent on a mouse, however you can no longer assume a user either has a mouse, or is able to comfortably use a mouse. People are very often not at a desk when visiting your sites, instead viewing through a touch based device or from the couch.
This means if your site requires mouse interactions to get around,
you might find some of your visitors can never access certain parts of your
site.
Ideally sites should be navigable not only without a mouse, but also specifically keyboard friendly. If your site can be navigated via a keyboard it very likely can be navigated via other input devices such as TV remotes or console controllers.
On top of that, people with mobility impairment, such as sufferers of arthritis or stroke for example, may prefer to navigate via an assistive device such as a large key keyboard.
And speaking of your sites working with assistive devices...
7. Not As Accessible As You Think
Don't get me wrong, I know you're probably already doing the right thing and incorporating WAI-ARIA roles into your sites and trying to make them as accessible as possible.
But what I found in my own experience is that you might think you've made your sites accessible, until you actually try to access them the same way a person with a disability has to.
Within moments of trying to navigate the web via screen reader and keyboard for the first time I felt pretty bad about some of the sites I'd built in the past, sites I'd honestly thought I created according to accessibility guidelines.
One of the main issues I encountered as I attempted to screen read my way around the internet was a lack of optimized WAI-ARIA landmark roles, which help users jump to the main "landmarks" in sites.
What I discovered was that many well meaning sites incorporated WAI-ARIA landmarks, but in a way that unfortunately didn't give any information to the user that would help them find their way around the site:
Some other well known sites just didn't use any accessibility code at all:
Including WAI-ARIA landmark roles in your code is actually super easy and adds only minutes to a project, it's just a matter of knowing how to add them in the right way.
You'd be surprised how easy it is overall to have a solid baseline of accessibility with a few simple techniques, such as optimizing heading structure, controlling color contrast, plus some of the points we talked about above like allowing font size scaling and supporting different input devices.
Make Your Sites “Bombproof”
If you checked off each item on the list above and said to yourself, "Already nailing it" then well done, you're amazing! Like I said, you get a great big gold star for being epic.
However, if you found yourself saying "Oh I didn't realize that" or "Not sure if I'm covered on that one" then it's quite possible your sites might be exploding out there on the internet as we speak - and by "exploding" I don't mean in the good kind of way!
If there was more than one of these points you weren't aware of, don't worry. It's actually a lot easier to "Bombproof" your sites than you might think. It's just a matter of being fully aware of the necessary information, and rolling out some straightforward solutions.
That's what our new course "Bombproof Web Design" will equip you to do. Through fifteen easy to follow video lessons I'll personally guide you through exactly what to watch out for, and the steps to follow to "Bombproof" all your sites from here on out.
The first two videos are completely free, so go ahead and take a sneak peak at "Bombproof Web Design" now:
Watch 2 Free Videos from Bombproof Web Design
I'll see you there!