My Dev Setup, part 3: Browser Testing

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

Google Chrome with Web Inspector

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

IE 8 running in XP, IE 10 running in Windows 8

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.

Microsoft offers free VM images for IE7-10.

Mobile testing

The Real Thing

Testing on iPad, iPhone, Nexus 4 and Nokia E51

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

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

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

Apple 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.

Browserstack running IE7 in Windows XP

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.

Browserstack is a subscription service (starting at $19 per month for an individual user). If you feel like trying it out, there’s a Microsoft-sponsored three-month free trial available. CrossBrowserTesting is another similar-looking service, although I haven’t tried it out.

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.

Miten varmistat, ettei käyttäjää suututa niin paljon

Emme yleensä pidä siitä, kun jokin menee pieleen tai ei toimi. Vielä vähemmän pidämme siitä, että meitä syytetään asioista, jotka eivät johdu meistä. Varsinkin suuressa ja ihmeellisessa “ATK-Internetissä” itsesyytökset ovat herkässä, kun jokin ei menekään niin kuin piti.

Tätä tunnetta voi huomattavasti vähentää fiksuilla sanamuodoilla, kuten Twitter tekee, jos viserrys ei jostain syystä mennytkään perille:

Twitter error message: we did something wrong

Anteeksi! ME teimme jotain väärin.

Syyllisyyden ohjaaminen yksiselitteisesti palveluun helpottaa hitusen käyttäjän oloa ja kannustaa yrittämään uudestaan. Ainakin kerran.

Miten saat käyttäjän suuttumaan

Yritin hiljattain varata vuokra-autoa kolmesta eri yhdysvaltalaisesta autonvuokrausfimasta verkon välityksellä. Lopulta vuokraus onnistui, mutta parilta ensimmäiseltä firmalta jäi asiakas saamatta yksinkertaisesti siitä syystä, etten tykkää siitä että minua kiusataan.

Hertz veti pohjat. Varauslomakkeen yhteydessä kysytään paikkakunnan lisäksi, minä päivänä ja mihin aikaan auto halutaan vuokrata. Tämän jälkeen käyttäjälle näytetään lista autonvuokraamoista, jotka sijaitsevat lähellä toivottua paikkaa. Ajan kysymisestä huolimatta lista sisältää myös vuokraamoja, jotka eivät ole auki toivottuna ajankohtana. Epähuomiossa valitsin siis vuokraamon, joka onkin kiinni, ja sain seuraavanlaisen ilmoituksen:

Hertzin virheilmoitus

Tässä vaiheessa vain hitusen kiukuttaa.

 

Eipä tässä mitään, ajattelin, ja napsautin hyödyllisen näköistä “Help me find a location” -linkkiä. Hertzillä on vähän erikoinen käsitys auttamisesta, sillä seuraavalle ruuduilla avautui lista kaikista maailman maista, joissa on autovuokraamoja.

Lista kaikista maista, joissa on Hertzin autovuokraamo

Nyt jurppii oikein kunnolla.

Tässä kohtaa alun suhteellisen miellyttävä käyttökokemus hajosi täysin, ja vaihdoin firmaa. Vinkkinä siis vastaavanlaisia sivustoja toteuttaville: huomioi myös virhetilanteet! Tässäkin tapauksessa olisi suhteellisen yksinkertaista tallentaa muistiin käyttäjän alun perin toivoma sijainti. Tämän tiedon avulla olisi helppo näyttää uudelleen lista vain kyseisellä paikkakunnalla sijaitsevista vuokraamoista. Vieläkin parempi vaihtoehto olisi ehkäistä virhetilanteiden synty alun perin huomioimalla vuokraamojen aukioloajat.

Mukautuvaa verkkosuunnittelua

Aki Björklund kirjoitti eilen blogissaan ytimekkään arvion Ethan Marcotten mainiosta Responsive Web Design -kirjasta. Luin saman opuksen toissaviikolla, ja allekirjoitan täysin Akin näkemyksen, että kirja on pakollista luettavaa kaikille verkkopalveluiden suunnittelijoille ja kehittäjille.

Olen pohtinut, mikä olisi hyvä suomenkielinen vaihtoehto responsiiville. Responsive tarkoittaa sanakirjan mukaan vastaanottavaista, myötämielistä ja herkästi reagoivaa. Näistä mikään ei oikein tunnu hyvältä kuvailemaan verkkosivustoja. Itse olen alkanut käyttää ilmaisua mukautuva: Sivusto, joka toimii ja näyttää fiksulta kaiken kokoisilla ruuduilla mukautuu ympäristöönsä (ainakin joiltakin osin). Suunnittelua, joka tähtää tällaisten sivustojen toteuttamiseen voitaneen silloin hyvällä syyllä kutsua mukautuvaksi verkkosuunnitteluksi.

Flexible fluid layouts with CSS and jQuery (Part 2 in series)

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.

Should we design for wider screens? (Part 1 in series)

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

Browser screenshot

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!

Wide web page mockup

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

Normal width web page mockup

Narrow web page mockup

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.

Bad Google!

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

Experimenting in HTML5 and CSS3

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

Owning my content

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?

Continue reading