Browser what? Browser Ubiquity Testing is testing your site in popular web browsers to ensure that each visitor has the same experience on your website. It’s a very important, yet often overlooked step. I’m going to share some of my experience with you today and hopefully show you what you need if you want to be serious about Browser Ubiquity Testing.
First, it helps to have a Mac and an PC at your disposal. Better still is to have a Mac and THREE PCs at your disposal. Why? You need the Mac to make sure that the popular Mac browsers render your site correctly. You need three PCs because there are currently three Windows operating systems in the market, each with a fair share of users. Why can’t you just use a Windows 7 machine with IE 8 for your testing? Because it doesn’t render the same as IE 8 on XP or Vista. You may hear that it’s all the same, but it’s just not. Each OS has its own version of Flash, Java, Silverlight, etc. Each performs just a bit different. Each browser renders CSS differently. Each browser also auto-corrects bad code differently. If you designer or developer tells you your site will look right in all browsers, ask them to prove it to you. Make them show you the browsers they’ve tested. Ask about mobile. Ask about a Mac. Ask about XP, Vista and 7. That’s like twenty two different browsers, and unless they are a fanatic about user-experience like me, they just haven’t done the work.
Let’s take a look at the browsers I use to test websites.
|IE 7||IE 8||IE 8||Safari|
|Firefox||Google Chrome||Google Chrome||Opera|
I use those different browsers on the different machines because each one renders a little bit differently. I don’t care if someone says that Safari and Firefox share the same basic rendering engine, they aren’t 100%. Sometimes you’ll see subtle differences on how things work on a site ie. how flash works in a browser, how it renders CSS, java, etc.
Don’t forget mobile browsers! Mobile browsers do not see the site like everyone else. I can’t tell you how frustrated I’ve been when trying to view a site from my phone only to find that the whole thing is coded in flash, or, even MORE frustrating is to find a flash navigation! That just makes my blood boil. I’ve got a client right now that had a big pretty flash slideshow on their homepage and some developer thought it was a good idea to nest their main navigation in the flash. Not one user who came to the site on a mobile device could get past the front door, let alone see any content. The simple solution is to write a bit of code to detect flash capabilities and deliver the right content to that browser. “What?! Content Delivery?!?! Isn’t that cloaking???” Calm down. In this example it’s perfectly fine. I know because I had a nice conversation with Matt Cutts about this a couple years ago at a Pubcon (Or SMX Advanced I can’t remember) and Mr. Cutts said that as long as the alternate content is in the same spirit as it’s fancy counterpart, it’s ok. Oh, by the way, guess another browser that can’t see Flash very well… Googlebot.
When you find a difference in a browser, and you will, what can you do about it? Some tools are available to help troubleshoot the code of the page to fix the problem. 99% of the time the issue is caused because a browser’s rendering engine decides that some code is “wrong” and then it makes a decision about how to “fix” it. Since each browser’s rendering engine makes different decisions about how to fix the code it doesn’t like, it displays differently. That’s when a tool like Firebug comes in handy. Trouble is that it only works well in Firefox right now. Not to worry, you can usually make the corrections in there and it’ll work for other browsers. The reason the corrections will work in other browsers is because you are fixing problems that are messing up the rendering. The problems can be HTML issues, CSS hierarchy problems, etc. Since you are fixing the code the browsers don’t have to decide how to do it for you, which is what messes up the page!
Unless you’re pretty technical, you might have some trouble fixing errant code. Best to just test the site in the different browsers as possible, and tell your developer that there are problems, what they are, and even provide screenshots so they can figure it out. Also, keep in mind that there are some issues with older versions of browsers because they just don’t render code correctly – even if the code is correct. You should consult with your developer about how to fix this type of issue. If they don’t know, find one that does.
Check your analytics. Users come from all different operating systems with all different browsers and devices. If they can’t get in your site because you haven’t done your due diligence, you’re not going to get their business.
2 thoughts on “Browser Ubiquity Testing”
I have also added to my browser arsenal the iPad and all the browsers available in Ubuntu.
This is so frustrating, why can’t all sites work in all browsers? [A game site] for instance, in Opera and Firefox, it tells me my players has not installed correctly to restart my comptuer or uninstall and then reinstall it. So then I go to IE to find the game I want and download it, in IE it says it’s in Queue, but it never downloads. Really really really frustrating.
I have to do the same thing on my laptop but it DOES download using IE but no other browser. Why can’t these developers get together and make all sites work in all browsers? I hate having to open different browsers to see certain sites or download certain things.
Comments are closed.