Users do resize their browser windows: Take 2

Posted on

A while ago, I wondered about how often and in what way users really resize their browser windows, and set about finding out, only to get some dubious data that suggested my method was off. A (very late) second pass with a much better script for getting the data has yielded some more believable (and hopefully useful) numbers:

Device Visits Resizes O/Changes
Desktop 9271 191 2.06% 10 0.11%
Tablet 5233 479 9.15% 311 5.94%
Mobile 7435 1194 16.06% 482 6.48%
All 21939 1864 8.5% 803 3.66%

What is this telling us?

Over a 10 day test period, 8.5% of visits to the site included a resize of 50px or more in either dimension, and 3.66% included an orientation change (these will register a resize event as well, unless the viewport is almost square). That’s significant enough that we should keep it in mind when designing and developing fluid and responsive sites.

Also interesting is the difference between device types1, which shows that resizes are much less likely to occur on the desktop (where in turn the resize is much less likely to triggered by an orientation change), whilst the opposite is true with mobile, and tablets are roughly in the middle.

One lesson here is that when you’re doing things in JavaScript that are affected by the size of the viewport, it’s best to get the viewport dimensions live every time you need them; it won’t be enough to get them once when your script first executes and store them in a variable, since they may change after that.

Update 15th April 2014: A kind reader ran the same test on the desktop version of a mainstream ecommerce site with over 1 million visitors per month and found that 2.03% of visits included a resize and 0.4% did an orientation change, which goes some way to validating these findings.

  1. This is based on the grouping done automatically by Google Analytics with UA string detection. Imperfect, but still worth reporting on. 

Microformats 2

Posted on on

I somehow missed this when it was announced, but the second version of Microformats is a significant improvement — much nicer classnames, less verbosity, and most importantly less markup cruft.

(At this point Google’s Structured Data Testing Tool doesn’t recognise the new formats, but that should change soon.)

Heart of a Gambler

Posted on on

I really liked this episode of The Talk Show featuring the impossibly knowledgeable Glenn Fleishman, with Bitcoin as the main topic. There’s no real layman’s explanation for how Bitcoin works (I think you need to understand public/private keys and hash functions to really get it) but after listening to Glenn it all made sense to me for the first time. Sort of.


Posted on on

Great JavaScript library for dealing with dates, for use in the browser and in Node. If you’re doing anything beyond trivial with dates in JavaScript, this could save you a few headaches (it did for me today).

App-pocalypse Now

Posted on on

A bit of a rant by Jeff Atwood, but I basically agree with everything. The sooner companies stop obsessing over building apps when they don’t need them, the sooner native apps and the web will benefit.

Revisiting the “Cookieless Domain” Recommendation

Posted on on

A good post with good data which strongly suggests that serving CSS from a separate cookieless domain is actually worse for performance, as it will block rendering while it does the extra DNS lookup.

Responsive Image Container

Posted on on

A long post from Yoav Weiss about his idea/proposal for a responsive images container file format. I’d love to see something like this get off the ground.

Why is Progressive Enhancement so unpopular?

Posted on on

Drew McLellan:

JavaScript is brittle and intolerant of faults. If a dependancy is missing, it stops. If it hits unrecognised syntax, it stops. If the code throws an error, in some cases it stops there too. If part of the script is missing, it likely won’t even start. As careful as we are to code defensively within our JavaScript, it counts for nothing if the code doesn’t run.

As good a case as I’ve ever heard for progressive enhancement in a single paragraph. Sadly it’s likely to fall on deaf ears for the most part.

Social sharing buttons without the pain

Posted on

This post from the team caught my eye the other day, and in particular this quote (which got bounced around Twitter a lot):

We prioritise rigorously based on evidence of user need, and this particular feature has been queued for a long time because zero end users have ever requested it, and all users in several rounds of guerrilla testing were able to share GOV.UK links to social networks easily by copying and pasting them.

Nothing surprising there; users aren’t demanding this feature because they can already do for themselves what this feature does. However, having buttons right there on the page removes a little friction, and the visual prompt could encourage more people to share the page — that would surely be good news for almost any site.

The trouble is, using the embedded widgets for social sharing (e.g. the Twitter “Tweet Button”) is a bit of a performance problem.

The problem

I tested this quickly by measuring the performance of a page containing only the embedded widgets for Twitter, Facebook1, Google+ and Pinterest. If you care about front-end performance, you won’t like the results2:

Screenshot of Chrome DevTools network tab showing 41 requests, 395KB transferred and 19.73s load time

As well as the performance problem (which in my opinion is a deal-breaker on its own) there is also privacy to think about — all of these widgets track the user to one degree or another, and as distaste for this sort of thing becomes more common, you don’t want to be seen as complicit.

The solution

Happily, it is possible to have social sharing buttons without these downsides, because although they’d very much prefer you to use their custom embedded widgets, the four social services I mentioned a moment ago all offer a way to share content via a good old-fashioned URL with query string parameters:

Service URL Query Params Details
Twitter url, text, via, related Intents
Pinterest url, media, description Pin It Button
Facebook u Share Button
Google+ url Share Link

These URLs will redirect the user to the normal/mobile version of the service as appropriate, so whether your site is responsive or you have separate sites, the URLs will always be the same.

Using these URLs, the markup for a social buttons module will look something like this:

<div class="sharethis">
    <h2>Share this</h2>
    <ul class="group">
        <li><a class="twitter" href=";text=About+David+Goss&amp;via=davidjgoss&amp;related=davidjgoss">Twitter</a></li>
        <li><a class="pinterest" href=";description=About+David+Goss">Pinterest</a></li>
        <li><a class="facebook" href="">Facebook</a></li>
        <li><a class="googleplus" href="">Google+</a></li>

As for styling, you have a blank slate, so you can do whatever is best for your site. This way, the buttons won’t look awkward next to one another or stick out from the rest of your site’s design. If you want to include icons, all the popular sets and fonts have them, and if you want to get the brand colours right, here’s a cheat sheet:

Service Hex RGB
Twitter #00B0ED 0,176,237
Pinterest #CC2127 204,33,39
Facebook #3B5998 59,89,152
Google+ #DF4A32 223,74,50

If you need inspiration for the styling, several designers on Codepen have come up with great concepts:

With the performance and privacy downsides now removed, adding these social buttons to a site should be a lot more palatable than before.

  1. Facebook makes this difficult; unlike the other three services, you have to be logged in to a Facebook account (which I don’t have, so I had to use my wife’s) in order to generate a share button. This seems like a needless hoop to make developers jump through. 

  2. In fairness, these widgets have been improved a lot. If I’d done this exercise a couple of years ago, the results would undoubtedly been much worse. 

CSS is for developers

Posted on on

Lea Verou is tackling the notion that writing CSS doesn’t make you a developer, and I fully agree. It’s a testament to the design of CSS that it’s accessible to just about anyone, but it takes a developer to extract the most from it.