Adobe BrowserLab – Excellent BrowserShots Alternative

One of the many tasks in finishing up a web development project is to make sure the design looks OK in the most web common browsers (something I wrote about a few weeks ago regarding the death of Microsoft’s Internet Explorer 6). Today I’m going to write about a couple of the browser rendering tools I’ve used and what I really like about Adobe’s BrowserLab.

What is a Browser Rendering Tool?

I wrote about this before, but the purpose of a browser rendering tool is to make sure a site looks OK regardless of the computer and browser combination a person uses to view the site. There are quite a few tools available to do browser rendering tests. What follows is my limited experience with a handful of web-based tools.

BrowserShots.org

For a long time, I’ve been using BrowserShots.org’s free browser rendering service. Basically, the BrowserShots website allows you to task a server to visit a URI and take a screen shot using  a particular web browser. You can specify the computer operating system (Windows, Linux, Safari, etc.), browser software and version (IE, Safari, Firefox, etc.), the computer’s screen size, and a few other options. It’s a great tool for the price.

However, there are some problems with the free BrowserShots service:

  1. It’s slow. It can take an hour or two to get screenshots of a particular website.
  2. It’s hard to use more than once a day. The way the system works (at least for me), you’re limited to one screenshot per address per day. So, if you make changes to a page, you have to wait until tomorrow to find out what they look like. I’ve worked around this, but it’s a pain.
  3. It’s not always working. I’ve visited the site a few times to find out it was temporarily down. If you wait till the last minute like me, you’ll be stuck.

I like BrowserShots a lot and have used it for a couple of years now, but it’s no longer my first choice.

LitmusApp.com

I used LitmusApp.com on a project a few weeks ago and I have mixed feelings. On the one hand, it’s very comprehensive. On the other, it’s definitely not free. My individual experience left me less than satisfied: I found the system was very, very slow in rendering Mac browser screenshots. Perhaps it was just the particular couple of days that I used Litmus, but I was not impressed.

I have yet to use their email rendering tool, and I think it’s probably very useful, so I’m hesitant to say too much about the Litmus system until I have more experience with it.

Adobe® BrowserLab

Frankly, I’ve never been a fan of Adobe®. Their software is bloated and their customer service is poor. When confronted with the possibility of using an Adobe® product or service, I usually run in the other direction. HOWEVER, BrowserLab is pretty awesome.

BrowserLab is a clean, easy to use browser rendering tool.

BrowserLab is a clean, easy to use browser rendering tool.

Here’s what I like about BrowserLab:

1. It’s fast. Rendering a webpage takes a few seconds. That’s faster than either BrowserShots or my experience with Litmus.

2. It’s a nice, easy to use interface. You couldn’t ask for a much better looking setup. The page also has some neat display features like zoom, side-by-side screenshot comparisons, and even ‘onion-skin’ screenshot overlays (see below). This is a premium-quality service.

BrowserLab's 'onion skin' feature allows you to layer all the different screenshots on top of each other, so you can see how elements move around from browser to browser in one view.

BrowserLab's 'onion skin' feature allows you to layer all the different screenshots on top of each other, so you can see how elements move around from browser to browser in one view.

3. It renders full-length screenshots.

4. There’s a time delay option. One problem with BrowserShots is that sometimes the screenshot is taken before the site has a chance to load completely. This means AJAX or Flash elements don’t always show up in my screenshot…sort of defeating the purpose of getting the screenshot in the first place.

Things Adobe could do to make BrowserLab better:

1. Support different screen sizes. It looks like the BrowserLab tool defaults to a screen size of 1024px wide. In all honestly, this is the ‘right’ setting to design for. Still, it would be nice to see what a site looks like in other sizes.

2. Offer the option to render a site with javascript disabled. It’s a rare situation, but it’s important to make sure a website still ‘works’ without javascript turned on. Some mobile devices don’t support javascript, and a few people have it turned off out of concern for their security or privacy.

As I’ve said, I’m not a fan of Adobe. However, their BrowserLab tool is top-notch. Hopefully it stays free of charge.

Comments

  • Kevin Menard Apr 12th, 2010

    Great article. If you decide to do a more comprehensive comparison, we’d love to hear how you think MogoTest stacks up. We have a lot of the same features as BrowserLab and then some.

  • admin Apr 12th, 2010

    Kevin – Sounds cool – just looked at the page and it’s still in ‘alpha’. Signed up to be notified.

  • Alberto Nov 15th, 2010

    Great software…..basically it does what this site http://browsershots.org/
    has been doing for years for free with a much wider choice of browsers. I suggest to save your money and eventually invest it into learning web-standards and crossbrowser coding instead.

  • admin Nov 15th, 2010

    Alberto – Are you talking about MogotTest?

    I agree that everyone should know web-standards and cross-browser coding, but the same can be said of the people who build the browsers! :-)

    Now that I no longer worry about IE6, I find myself using these tools far less.

  • Soyo Nov 20th, 2010

    Alberto,

    If a designer just followed web ‘standards’, his websites would NOT look good on every browser. As for knowing cross-browser coding, how do you think that’s done? By cross-browser testing!! That’s the only way! With every browser update, version level or not, there is a new opportunity for problems. Add to that constantly updating modules (jquery, cufon, etc.) and the operating systems themselves that run the browsers, including smart phones and other web appliances (website browsing on tv through cable emerging now) – there are so many factors! Any designer who thinks they can blindly code cross-browser without consistently checking for new issues is doing their paying clients a huge disservice. Not only do we cross-browser test our sites pre-launch, we also test them every month ongoing, and make adjustments on the fly, so they never have to worry about missing a potential client. And yes, we still do IE6 alternative, which still accounts for ~ 4/100 visitors (albeit with a small alert reminding them to consider updating). Cross-browser compliance is a constantly changing animal that should be checked consistently and ongoing. If you’re not prepared to do that, then you should not be designing websites professionally, period.

  • Jason Lancaster Nov 20th, 2010

    Soyo – You raise a lot of good points, especially mobile.

  • Kevin Menard Jun 26th, 2011

    Hey all,

    I just wanted to follow up (albeit very late) and let you know that Mogotest is no longer in alpha. We’ve been live in production for about 9 months now. Before we launched we really wanted to get our automated render issue detection in place. It has been for a while now and it works quite well. Just configure a set of URLs and we’ll let you know if a page looks different in two browsers. If it does, we give you the coordinates and CSS selector to help you track down the problem.

  • admin Jun 26th, 2011

    Kevin – Thanks for checking back in. One of these days I’ll do a full comparison of the tools available.

Trackbacks and Pingbacks

    Leave a Comment