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.
Visual Feedback in Google+
I’ve been using Google+ for about two days now, and I have to say – I’m impressed. While they certainly still need to iron out a few things, I’m happy to see they’ve put some serious thought into polishing the social experience. While testing out some of their features, I noticed a “Feedback” button that appeared on the bottom right of all their pages. When I clicked it, I expected to see a fairly standard feedback form, where I could describe the problem, and then submit. Boy, was I wrong.
Sure, the feedback form was there – but they also added the ability to highlight or black out elements of the page. With the highlighting controls, you can easily point out the area you’re commenting about, while also providing additional information, if needed. Furthermore, if you’re concerned about privacy, no problem… just black out the information you consider sensitive. Altogether, I find this a refreshing new approach in the process of collecting user feedback, one that also has interesting possibilities. For example, Google could potentially compile statistics about the most highlighted page elements, which could give them a great high-level view of what people are talking about the most. Are they doing that? Who knows – I just know that I’d like having that data to work with, from a development perspective.
When using the feature, you can either hover your mouse over page elements, and Google will give you an easy way to select them, or, you can simply drag to create a rectangle of any shape.
By the way, if you’d like an invite to Google+, simply contact me at mref…@gmail.com. Once invited, you might have to wait a little longer to be allowed in, but at least your place will be reserved.
Testing Web Performance by Throttling Bandwidth
In the past, I often found myself wondering how some of my websites would perform when accessed from a low bandwidth connection. Unfortunately, I had no convenient way to test such a scenario, so I usually just forgot about the idea. I recently found myself in a similar scenario at work, and my searches returned a useful tool, Speed Simulator, by Vikas Patial:
Speed simulator is a simple throttling proxy which allows you to see how your site behaves under different connection speeds. It was written by me to test AJAX/Flash loaders and see how much my time took to load. You can simulate various speeds like that of a modem or a ADSL. A pre delay function is also there to help simulate delays due to DNS, connection establishment etc.
Here’s what it looks like:
It simply acts as a proxy, so all you need to do is point your browsers to access the web through Speed Simulator. You’ll then be transported back to the good ol’ days where most people had to wait for websites to load.
To do this:
- Click Start, and search for “Internet Options”. Launch it.
- Click on the “Connections” tab.
- Click the “LAN Settings” button, found within the “Local Area Network (LAN) Settings” section.
- Once the “Local Area Network (LAN) Settings” dialog appears, locate the “Proxy Server” section.
- Enable the “Use a proxy server for your LAN” checkbox, and enter the following:
- Address: localhost
- Port: 8080 (reflect the port listed in Speed Simulator)
Press OK to save your changes, and then simply click “Start” in the Speed Simulator window.
That’s it – all you need to do next is launch a browser, the bandwidth should be throttled. I’ve seen it work with Google Chrome and Internet Explorer. Configuring a proxy in Firefox requires different steps, but should work just as well, once configured.
I can see myself using this tool in the future, and not only for simple performance tests. For example, I can use it to test for possible timing-related flaws in JavaScript code. Definitely a welcome addition to my web development tool set.
Reviewed byBrian Ricard
Two Inexplicably Dangerous Characters
Yesterday, as I was writing an e-mail to one of my employer’s clients, I encountered a strange bug with Excel. The e-mail I was writing included instructions that the client should perform, and one of the steps actually involved creating a CSV file, which would then be opened in Excel. Before sending the e-mail, I decided to step through the instructions myself, and make sure everything worked as I expected. When I reached the CSV step, I found that while I could export it fine – I couldn’t open it in Excel. I’ll guide you through what followed using a really simple example CSV:
ID,NAME
1,KARA
2,GAIUS
3,SAUL
As you can see, the above CSV contents are completely valid. However, when I tried to open it in Excel 2000, I received this error message:
When I tried to press the OK button, Excel just gave up loading the CSV. While I didn’t know what they meant by “SYLK“, I assumed something was wrong with the CSV export. Maybe there was an invalid, invisible character in the file, preventing Excel from parsing it – perhaps making it think it was another format. To test this theory, I used one of my favorite features in Notepad++, one that allows me to see all characters, even those which are normally invisible.
Using the feature, I could tell that there were only carriage returns (CR) and line breaks/feeds (LF), which are perfectly valid for a CSV.
With that possibility ruled out, I decided to try the same CSV in a newer version of Excel – the 2007 edition. When I went to open it, I was unfortunately greeted with the same type of errors:
Despite these errors, through the selection of the appropriate dialog options – I was at least still able to view the CSV within Excel:
At this point, however, I was really intrigued – so I googled the original error message I received in Excel 2000. I found a Microsoft article explaining the behavior, while also offering a workaround. When reading the article, I could barely hold in my laughter:
SYMPTOMSWhen you try to open a text file or a comma-separated variable (CSV) file, you may receive the following error message:SYLK: File format is not valid
CAUSEThis problem occurs when you open a text file or CSV file and the first two characters of the file are the uppercase letters “I” and “D”. For example, the text file may contain the following text:
ID, STATUS123, open456, closed
Note This problem does not occur if the first two letters are lowercase “i” and “d”.
WORKAROUNDTo open your file in Excel, open the file in a text editor, and then insert an apostrophe at the beginning of the first line of text.
How to Insert an ApostropheTo add an apostrophe to the beginning of the first line of text in your file, follow these steps:1. Open the text file in a text editor, such as Notepad. Click before the first character in the first line of text. Press the APOSTROPHE key on your keyboard (‘).2. On the File menu, click Save. Quit the text editor. You can now open the file in Excel.
Source: http://support.microsoft.com/kb/323626
I think you need to be a developer to truly appreciate how funny this is. I had to mention this bug to the client, because the likelihood of the ID being the first text in the file was pretty high. Even then, I mentioned they should read the Microsoft article only if they encountered the problem. No way am I going to explain the awkward workaround myself.
So, I confirmed that the bug was still present in Excel 2007. I just hope that Microsoft fired the developer that came up with the SYLK detection logic. Assuming that a file is a particular type based solely on the first two characters (“ID”) is a big risk, especially when those two characters are part of the alphabet, and are also common in IT. I’m guessing there are complexities I don’t see… or at least, I hope so. Either way, their workaround is really unbelievable… they’re actually telling people to add an apostrophe as the first character of the file. I’m aware that Microsoft is a large complicated beast with many different teams involved in releasing bug fixes, but this one is just so ridiculous.
An Easier Way to Search for Domain Names
In the past, whenever I wanted to search for available domain names, I checked with individual domain registrars. While this worked, it really wasn’t optimal- every time I wanted to check another domain’s availability, I had to press Back in my browser, re-enter a domain, re-submit the request, and then I’d know. Most websites were set up like this, unfortunately. Furthermore, if I wanted to compare domain registration fees, I’d have to check multiple websites.
I’m happy to say that these inconveniences are now no longer an issue. The solution lies in a site called Instant Domain Search. The webpage aims to facilitate the process of searching for a domain, and to do so, it:
- searches automatically as you type
- lists different rates from leading registrars
- lists domains names that are for sale
Check it out:
Personally, I’m never going back to the old method.