Tag: Web

Some years ago browser testing meant just testing in Firefox, Safari and possibly Opera, and cursing and testing in IE6. Good standards support in current browsers has made development easier on one hand, but more complex than ever on the other hand with the demands of responsive design, the rise of mobile and websites themselves becoming more advanced.

Now on the desktop we have to worry about Chrome, Firefox, Safari, Internet Explorer 7,8,9 & 10, and on ‘mobile’ there’s at least Safari for iOS (phone and tablet), Windows Phone, multiple versions of the Android Browser, Chrome for Android, the BlackBerry Browser, Firefox, Opera Mobile and Opera Mini.

This post describes a snapshot of my current browser test setup and it’s the third part in my “web dev on Mac OS X” series. The first two were about utilities and web development apps. I’ll try to keep this series of posts up to date as the tools of the trade change.

Latest versions of Chrome, Firefox, Opera and Safari

You should of course have all the latest versions of the most popular desktop browsers. Ideally it would be a good idea to have older versions too, but since both Firefox and Chrome update themselves automatically, this is not much of an issue (see Arstechnica’s browser share analysis from last October)

Since Firefox 3.6 was the last version not to be updated automatically, I like to keep it around, since it has quite a few issues with some HTML5 elements and CSS3. An easy way to install an old version of FF alongside the current version is via portableapps.com.

Internet Explorer 7, 8, 9 & 10 in VMWare

Internet Explorer testing is annoying, because installing multiple stand-alone versions of IE is difficult, and in some cases impossible. I currently have a VMWare virtual machine running XP with IE versions 6,7 and 8, installed using Multiple IE. Unfortunately this setup is somewhat buggy, but it works. I have a separate Windows 7 and 8 VM’s running IE 9 and 10 respectively. This can get messy and requires a lot of HD space. Also, testing local websites requires editing the hosts file of each VM.

Mobile testing

The Real Thing

Testing on real devices is essential, and at least before going live I try to test on as many devices as possible. Since my own collection is limited (Android, iOS and S60) and there’s no open device lab near me, I occasionally visit the local department store and try out all the phones on display. Necessary, but not very practical for quick debugging.

Adobe Edge Inspect

For devices that support it (ie. Android and iOS), Adobe Edge Inspect is a great time saver. Basically it allows you to browse the same site synchronously on your desktop and your mobile via a mobile app and a browser extension. Even Edge Inspect doesn’t allow browsing local sites though, and that’s where the next solutions come in.

Opera Mobile Emulator

Opera Mobile Emulator simulating a Nokia N9

The Opera Mobile Emulator is an excellent and easy way to test a responsive web site in a huge number of different sized displays. It’s a useful tool whether your users use Opera or not.

iOS Simulator

The free Mac OS X Developer Tools include an iOS simulator, which is at least 99% identical to the actual devices (iPhones and iPads). The emulator allows rotating the device, simulated shakes etc. This is probably the mobile testing tool I use the most.

Going forward: Remote virtual machines with Browserstack

Maintaining all these emulators is messy, to say the least. So I’ve been eyeing Browserstack, which allows testing in IE 6-10, recent versions of Chrome, Firefox, Opera, and best of all, emulators of most Android & iOS devices of significance. From my point of view the only thing missing is Windows Phone. Oh and Symbian would be nice too.

The interface is really easy to use and straightforward. You input the address you want to test, choose an operating system and browser, and that’s it. Using a remote desktop via a browser is of course fairly slow, but the really killer feature of Browserstack is the ability to test local sites (like testsite.dev). This often makes Browserstack more convenient than the alternatives.

Final Words

Browser testing is a complicated business, and your needs will depend on the type of site you’re developing and user demographic. Testing in more than one browser is a start, but mobile testing has also become a must. In a year or two it might even be more important than desktop browser testing, if it isn’t already.

Testing on a real device gives a good feel to the restraints of that device, but remember your iPhone/Samsung/Nokia model isn’t the only one out there. As more and more varied devices enter the market and testing needs get more complex, tools like Browserstack are likely to be the only realistic testing option for the vast majority of designers and developers in the future.

2012 Update: This techniques outlined here have been mostly outdated by CSS3 Media Queries, which I recommend using instead.

This is a follow-up to last week’s post, Should we design for wider screens?. In this post I’ll demonstrate with a simple example how easy it is, with CSS and a bit of jQuery, to make layouts that adapt to the many different screen sizes out there.

Example HTML

At the top level, my example HTML page has a #wrapper div, which contains a #header, #main div containing all the interesting stuff, and a #footer. The main section has #content, #primary, #secondary and #tertiary divs for the different content areas of my page. The first two content areas, #content and #primary are wrapped up in an additional #container div, but your own markup may obviously differ.

Prepare your styles

The basic idea here is to have different CSS styles for each width. The styles could be changed directly through jQuery, but that would quickly result in a lot of messy code. Instead, we’ll use jQuery only to change one class attribute. Initially I’ve added the class ‘normal’ to the body element to ensure a sensible default for browsers with JavaScript disabled, but we’ll also need styles for ‘wide’, ‘slim’ and ‘narrow’. This is easy to do with CSS descendant selectors:

Unfortunately versions 7 and older of Internet Explorer deal differently with percentage widths compared to most other browsers, and can result in some funny behaviour. I see two primary ways to deal with it: either feed IE 6 and 7 it’s own rules (e.g. a tested, fixed-width layout) or just make sure that the percentages never add up to 100 %. A nice explanation of this annoying feature can be found over at OJTech.com.

The jQuery

First of all I need to include jQuery, and perhaps the easiest way is to use Google’s jQuery for this. The main bit is a function, checkWidth() that (you guessed it) checks the width of the browser window and sets the body class attribute accordingly. The code below should be pretty self-explanatory.

In addition to this, all I need is some code that will tell the browser when to run the checkWidth() function.

That’s it! View the finished demo EDIT: I’ve managed to lose the demo at some point in time. Anyway a better and more flexible way of doing this is CSS3 Media Queries, and you should use them.

After starting to write this post, I read the latest issue (#200) of .net magazine and noticed a mention of a very cool way to do a similar trick using only CSS media queries! Media Query demo by Bruce Lawson. Haven’t tried it out yet, but I definitely will.

Hope you liked the post, feel free to tweet it, or leave a comment below.

More and more people are using wide-aspect monitors to browse the web. According to forecasts by Tobii (Swedish eye-tracking equipment manufacturer) wide aspect monitor penetration will be almost 100% by 2012. I think those numbers might be a bit optimistic, since Tobii obviously wants to sell their new wide-screen eye-tracker. Despite that, a very large number of web users are using screens with well over 1024px width, but almost all web sites out there are designed for lower resolutions. This got me thinking about fluid layouts again, and I decided to share my thoughts.

Fixed-width equals compromise

In the Beginning web sites were fluid, that is the content adapted to browser width. Today, most web design is fixed-width. That is, we build web pages to a maximum of about 900-980 px to accomodate the majority of screens. I’ll be the first to admit that most of the stuff I’ve made is fixed-width. Even my own blog is designed to a 700px width! It’s generally easier to design this way, especially if the design originates in Photoshop, which is essentially static. Also, fluid layout generally used to mean ridiculously wide and unreadable blocks of text.

Problem is, designing this way is a compromise. Many users today have wide screen laptops with 1280 px width or more, but their screen height may be a mere 700-800 px. Subtract from that the space taken by browser toolbars, taskbar/dock etc and you’re not left with much. On these height-challenged displays we should be using all the horizontal space we can to provide users with the information they need. But what about those narrower displays then, or people who simply choose to have their browser window at a narrower width despite having a large display? We’re not going to force them to *gasp* scroll horizontally or resize, are we? That would be silly. The answer is “intelligent” fluid layouts.

Fill that width!

On sites that have clearly separable content blocks we could be building layouts that intelligently re-arrange according to browser width. That of course does mean some more work put into the design phase, and possibly ditching Photoshop as a layout tool! The above image is a wireframe of what a user would see on a wide screen (over, say, 1100px).

Narrowing down

On screens about 1024px wide we rearrange slightly, moving one content block (eg. recent blog posts) below the first one.

The narrower the screen is, the more we pile blocks on top of each other. This obviously requires more vertical scrolling, but all the content still remains accessible. Most importantly, we’re always using the best arrangement possible for the width of the browser.

Your thoughts?

What are you’re experiences of designing fluid layouts? Are there downsides to this, apart from the increased time needed for design? I’d like to here your thoughts, so please comment and share this on Twitter if you think it’s worth a discussion.

In Part 2, I’ll show an example of implementing the above with CSS and some jQuery, with sensible degrading in browsers with Javascript disabled.

Can anyone suggest a good online feed reader and webmail which doesn’t begin with a G?

Google Buzz created quite a stir from the start, with concerns over it’s privacy policy. The first time I logged in to see what all the buzz was about, I thought is was odd enough to see “followers” who I definitely know have never used ANY social media service. Some of them were probably just confused by the “Try Buzz” -notice and have since forgotten about it.Continue reading “Bad Google!”

I decided to experiment with some of the new elements in HTML 5 and built my blog theme from scratch (with the help of the Carrington framework though). I’m now rolling article, section, header, footer and other stuff. Because IE needs a Javascript hack to enable support for these elements, I wouldn’t consider doing this in any client work, but hey, this is MY blog! Continue reading “Experimenting in HTML5 and CSS3”

If Facebook goes bust, or perhaps more likely, ceases to interest me, how do I get all my content out? I’m mostly thinking about notes, photos and the like, but why not status updates too. Who’s to say real-time updates on my life don’t provide interesting reading in 10 years time? Or 20? Will they still be accessible then?