Thoughts On Cross Browser Testing (And a Tool to Simplify the Process)
If I were asked to identify one primary annoyance associated with a web development career path, it’d be the abundance of browser inconsistencies. From the consumer’s point of view, the web is an endless source of content, and they are given the ability explore that world. Browsers permit such exploration, but the resulting experience depends on a multitude of factors, most of them transparent to the consumer.
There’s an organization known as the World Wide Web Consortium (W3C), and their entire goal in life is to ensure the long term growth of the Internet. In accordance with this objective, the W3C took the time to define standards for the core technologies they created, such as HTML and CSS. Yet, the reality is that browser developers don’t necessarily adhere to these standards, as there’s no way to enforce their adoption. While some respect the standards, others instead travel the road of partial compliance, with proprietary technology added in. As a result, when a consumer tries to access a website, he may face a situation where it:
- loads properly, and all appears to run well.
- encounters issues when loading, but remains usable.
- encounters issues when loading, resulting in a broken interface that cannot be used.
- refuses to load, and asks the consumer to launch a supported browser.
Photo by Johan Larsson
Even with the best outcome, scenario 1, there may still be “problems” that are invisible to the user. For example, it is very possible that the source code includes browser detection logic that is used to cater the content to the consumer’s browser. If all browsers supported the standards fully, such handling would be unnecessary, and developers wouldn’t need to worry about browser-specific code. As a result, the web would speed up for all. On desktop computers, that performance gain won’t necessarily be crucial to the experience; however, keep in mind that mobile phones are increasingly web-enabled, and yet, have a fraction of the resources that desktop computers do.
Scenarios 2 and 3 suggest that the website creators may not have devoted enough time to testing with different browsers. After all, in most cases, a website should be identical regardless of what browser is being used to access it. Without such a guarantee, some users may suffer a flawed experience.
Scenario 4 is rare, but is usually encountered in a business context with highly specialized web applications. The rejection of a particular browser doesn’t necessarily mean that the standards weren’t being followed – perhaps the web application was designed to take advantage of one specific browser’s feature, one that isn’t offered elsewhere. This is not necessarily a bad thing, though I would argue that it enforces limits that would otherwise not be there. However, if we’re talking about a public website that refuses a visitor solely because they are using a specific browser, I’d consider it more of an insult to the open nature of the web.
So finally, a web developer must take browser differences into consideration. Thankfully, things are improving – for example, the infamous Internet Explorer 6 is now finally on its way out. Good news, sure – but it isn’t a magic pill. There are still plenty of browsers and browser versions out there, and like it or not, they differ. To test properly, a developer must have a way to run their code in multiple browsers, which usually requires the use of virtual machines. At least that’s how I used to do it, until I found a better approach.
Meet BrowserStack, a web-based cross-browser testing tool. How does it work? Well, it’s actually a pretty clever idea. Users are simply asked to enter the site they wish to view, the browser they want to view it with, the browser version, and the operating system. They will then be given web access to a virtual machine that has the requested webpage loaded, in the right environment and browser. Here’s an example below:
The panel on the left makes it very easy to change any of the parameters, while also offering popular debugging tools. I was initially impressed by their ability to switch between configurations with relative ease. Then, I found out that they also allow you test local content by using SSH tunnelling – now that, I found even more impressive. Add the fact that they have multiple versions of Safari, Chrome, Firefox, Internet Explorer, and Opera – and you’ve got quite a service.
For those interested in testing it out, they’re offering 30 mins of use for free, but beyond that, you’d have to look at their pricing plans. If I were still doing web development as a full time job, I’d love to have access to such a tool – the time it saves would add up quickly.
Identifying a Font from an Image
Ever looked at a logo, and wondered what font the designer used? From an image alone, identifying the specific font can be difficult, particularly if it isn’t among those commonly seen on the web. Thankfully, a web service titled “WhatTheFont” facilitates this very scenario, while also allowing users to buy the font, once identified.
Below are screenshots revealing how to use the service, with the Google logo uploaded as an example.
As the above image illustrates, the service is pretty good at identifying characters, but it isn’t perfect. It asks the user to identify specific letters, eliminating the risk of false assumptions. Once the user validation step is done, the search results are shown.
Clicking on any of the search results will bring up a page dedicated to the font, where purchasing options are available. So, much like my previous post about reverse image lookups , this is an impressive website, both visually, and functionally. I recommend you try it out, especially if you’re into web development.
Web-based vs Offline Help Systems
As you probably know, I work for a software development company – and during a routine lunch hour, I began wondering why our software still shipped with offline help files (CHM), rather than offering the help files online. You see, every now and then, our company discovers that the help files are missing some information; however, we can’t do anything about it until the next release. Sure, we can temporarily alleviate the problem by creating external knowledge base articles, but it doesn’t fix the fact that clients have the same help files, without the new information. This situation brought an interesting question to the table:
Why don’t our products have web-based help?
Example of web-based help
I came up with numerous advantages and disadvantages:
Advantages:
- Help content can be updated at any time, regardless of product and version.
- Help articles can be easily referenced via URL.
- Whenever I’m doing support, it often occurs that the solution to the customer’s problem is found in the help system – they either missed it, or they didn’t look. Rather than just tell them to read the help, I usually include the help content as an attachment. I figure it is more convenient for the client, and that improves the support experience. I also make sure to mention that it can be found in the help, and I tell them what to search for. This is all well and good; except that copying help content from a CHM (my company’s typical help format) isn’t perfect. When I paste it into Wordpad, the images are not preserved – so I often have to copy them myself, one by one, to the Wordpad document. This requires manual work on my end, and that’s not ideal. If we had an online help system – I could simply link them to the article, and they’d be a click away. Plus, if that help content needs to be updated, I’m sure they will have access to the latest version. On the other hand, if they were to re-visit the attachment months after I originally provided it, it may be out of date.
- URLs are lightweight, unlike attachments – they are easy to share.
- Search engines will see much more related content
- Not only will the ranking improve, but other message boards and sites may link to the help content, which should also help.
- Could potentially increase the number of web site visitors
- Better features, potentially. Some widely-used offline help formats are now considered obsolete.
- Some help files are no longer supported, like WinHelp:
- The CHM format is old – it was originally created for Windows 98. Though they updated it through the years, I would not be surprised if Microsoft eventually started discouraging it as well, in favor of the newer Help 2 format (HXS extension).
Ever since Windows 3.1, Microsoft included the Windows Help program (WinHlp32.exe) with new releases. WinHlp32.exe is used to view 32-bit Help files that have the .hlp file name extension. Starting with the release of Windows Vista and Windows Server 2008, Microsoft has decided to no longer include in WinHlp32.exe as a component of the Windows operating system. Microsoft made this decision because WinHlp32.exe has not had a major update for many years, and it does not meet our standards for all new Microsoft programs. Microsoft realizes that this may cause some problems for customers who want to upgrade to Windows Vista or to Windows Server 2008 but still rely on 32-bit .hlp files. Therefore, Microsoft is making WinHlp32.exe available as a download from the Microsoft Download Center.
Vista's Help starts off with offline data, and is updated in the background, via the web
- Possibility of embedding rich content.
- A good example would be demo videos. Personally, I usually prefer watching how a feature works, rather than reading about it.
Disadvantages:
- Internet connection required
- A local copy may be a necessity. Personally, I like a flavor of that idea – start them off with an offline cache, and enhance that with the ability to update the help content on the fly. I really like Vista’s help – they offer that mechanism.
- Both offline and online help systems have be maintained
- If applicable. see previous point.
- Some users are annoyed when they are thrown to a web help system
- I’ve felt this personally, and it usually occurs when I am within the context of a Windows application – say, Paint.NET. When I click “Help Topics” in the Help menu, it launches a browser window. It is definitely not what I would expect to happen when I’m using a Windows application. I don’t expect to need a browser; therefore, the behavior usually frustrates me. It’s not very quick, either – the browser needs to initialize, and then load the webpage. Not all browsers are very good at loading quickly, so this is normally a pain. Eventually, I get over the initial frustration, and realize that the online help system proves to be pretty good. The funny thing is – I’ll get frustrated all over again if I temporarily forget that the applicaiton will launch a web browser, which is common the first few times.
Paint.NET will throw you to an online help system when you click this menu option.
- I’ve felt this personally, and it usually occurs when I am within the context of a Windows application – say, Paint.NET. When I click “Help Topics” in the Help menu, it launches a browser window. It is definitely not what I would expect to happen when I’m using a Windows application. I don’t expect to need a browser; therefore, the behavior usually frustrates me. It’s not very quick, either – the browser needs to initialize, and then load the webpage. Not all browsers are very good at loading quickly, so this is normally a pain. Eventually, I get over the initial frustration, and realize that the online help system proves to be pretty good. The funny thing is – I’ll get frustrated all over again if I temporarily forget that the applicaiton will launch a web browser, which is common the first few times.
- Competitors have access to detailed help content
- If your product is available for evaluation, then your help files are already out there; however, if it is of limited availability, and security is a concern, then maybe this point is valid.