Posted during January, 2012

Do users resize their browser windows?

Posted on

When looking at a responsively designed site in your desktop browser, it’s impossible to resist resizing the browser window in and out, watching the layout respond as you do. It’s an impressive way to demonstrate responsive design, but it is really relevant? How many users actually resize their browser window whilst viewing your site (other than curious developers)?

By day, I work on a pretty mainstream ecommerce site, so I’ve decided to find out by getting some real data. If you’re using jQuery and Google Analytics, you can do so as well easily enough:

    resize: function() {  
        _gaq.push(['_trackEvent', 'Viewport', 'Resize']);  
    orientationchange: function() {  
        _gaq.push(['_trackEvent', 'Viewport', 'Orientation Change']);  

If you’ve not come across one() before, it’s basically the same as on() but will only fire on the first instance of the event. So, if a user’s viewport is resized, it will be logged by Google Analytics (but just once in any pageview, no matter how many resizes occur). This should tell us how many people really do resize their browsers.

This should be interesting, especially when filtered by device/operating system — as Drew McLellan says:

They say users don’t resize their browser. Not true. Switching device orientation is a common post-load resize.

Once I have a good amount of data, I’ll follow up with the results.

Update 26th January 2012: I’ve added tracking that behaves in the same way to pick up orientationchange as well, so we’ll know how many of the resizes are orientation changes and how many are actual resizes.

Responsive images in HTML

Posted on

Developers working with responsive web design have a problem: <img> tags.

You can put an <img> in your markup and img {max-width: 100%} in your CSS, and the image will display as you want on small and large viewports, scaling to the width of its container. However, if your image has large dimensions like 800px wide and 600px tall (because it will be that wide on a large viewport like a desktop computer) but you’re viewing it on a small viewport like a phone, you’ll be wasting bandwidth and hurting performance by downloading that large file even though it’s being dramatically scaled down. It would be much better to have different sizes of the same image available and decide which one to use based on media queries.

Currently, HTML has no mechanism for doing this. There are some ingenious hacks out there, mostly involving server-side intercepts, cookies and JavaScript, but none are a real solution. Too many smart people are wasting too much time trying to get round this problem, and we need a way to deal with it natively in HTML. So, I’m proposing this (adapted from Bruce Lawson’s <picture> idea, and similar to how the <video> element works):

<adaptiveimg src="sweater-small.jpg" alt="Blue v-neck sweater in soft wool">
	<source src="sweater-medium.jpg" media="(min-width: 300px) and (max-width: 450px)">
	<source src="sweater-large.jpg" media="(min-width: 451px) and (max-width: 600px)">
	<source src="sweater-huge.jpg" media="(min-width: 601px)">
	<img src="sweater-small.jpg" alt="Blue v-neck sweater in soft wool">

Yep, another new element: <adaptiveimg>. It has the same attributes as <img>. It can contain one or more <source> elements, each with a media attribute containing a valid media query.

The user agent should cycle through each <source> element in order, updating the src of the <adaptiveimg> accordingly if the media query is matched. If there are no <source> elements, or none of the media queries are matched, the original src is used. Only after this logic has completed should the HTTP request for the image file take place (so there are no wasted downloads). The media queries I’ve used in the example are very simple, using just min-width and max-width, but in reality authors would often include other things such as device-pixel-ratio and color/monochrome.

Non-supporting UAs would simply ignore the new elements and render the fallback <img> as normal, but the structure would allow authors to implement a JavaScript polyfill if desired.

To be clear, all the <source>s should point to different sizes or arrangements of the same image — otherwise the content is being changed, which isn’t what we’re looking to do here. In other words, the same alt attribute should correctly describe all the <source>s.

Obviously there are a lot more details that would need to be worked out, but I think this is a good start, and I’ve sent it to Hixie and the WHATWG mailing list.

17th February 2012

There’s been a fair amount of discussion on the WHATWG mailing list, although at times it has felt like me, Matt Wilcox and Mat Marquis are just talking to each other. After a lot of feedback, mostly from the aforementioned two people, I’ve tweaked the proposal to remove its emphasis on the <img> element, which now becomes simply a fallback, and put attributes from <img> on <adaptiveimg>.

There were a few other ideas talked about, such as using a <srclist> element (a similar idea to <datalist> in Web Forms 2.0) and having an <alt> element within the new element for more “semantic” alternate text content. However, I think this core idea is the strongest, and we should push for it to be implemented by vendors (as Hixie has said before, they are the ones in control).

Content management, markup and doing it wrong

Posted on on

Mark Perkins, following up on his tweet about how content management systems should leave the markup to you:

…a CMS should exist to provide a nice way to store structured data, map URLs to some kind of template/page and give you access to the data stored within it via some sort of templating language.

Does anyone make a product that just does what Mark is describing? No bloated admin interface, no templates, no themes, no widgets, just a good API with good documentation?

White House Response to SOPA Petition

Posted on on

The White House has sent this response to me and everyone else who signed the anti-SOPA petition I mentioned recently. It’s one of those long statements that doesn’t actually say all that much. Except:

Any effort to combat online piracy must guard against the risk of online censorship of lawful activity and must not inhibit innovation by our dynamic businesses large and small.

So that must mean the administration won’t support SOPA? I don’t think so — if that was the case, they would have said “we won’t support SOPA”. There’s no commitment to anything here.

15th January 2012

Tim O’Reilly has written a thoughtful response of his own, in which he points out the lack of any credible evidence (and the lack of anyone involved looking for credible evidence) that piracy harms the economy on anything like the sort of scale that’s being suggested.

This is the part that stood out for me:

Most of the people who are downloading unauthorized copies of O’Reilly books would never have paid us for them anyway

That’s the thing: do the lobbyists and senators involved in SOPA think that once it’s been made too difficult (it’s never impossible) to get copyrighted materials illegally, they will just convert to paying customers? No way.

(via Daring Fireball)

16th January 2012

Apparently, my pessimism about the White House statement was misplaced, and SOPA has been shelved for now, thanks to several developments over the weekend.

(via @zeldman)

Build and Analyze #59: Premium Products

Posted on on

A particularly good episode of Build & Analyze this week, including a little section about code comments during which I found myself nodding in agreement with Marco — well-written code generally won’t need commenting. Looking back at some code I’ve written this week, all of the comments are not stating what the code does, but why it does it.

Months and years

Posted on on

Jeremy Keith outlining a technique thought up by Luke Wroblewski for dealing with some new HTML input types:

That was an angle I hadn’t thought of. Usually when I’m implementing new HTML5 input types (like input type="number") I put the new type in the markup and then try to come up with JavaScript polyfills for older non-supporting browsers. In this case though, the old-fashioned way is what goes in the markup and JavaScript does the enhancing for newer browsers.

It’s a great idea, particularly with date-based inputs which would be barely usable as standard text inputs, but I actually disagree with the cited example, which is using <input type="month" /> for the card expiry date field on an ecommerce payment page. I’ve been working on just such a thing recently, and come to a very different decision about how to get the input.

When you ask the user for the card expiry date, they’ll look at their card and see, for example, “05/15″. You’re then asking them to parse and translate that value so they can select it in your form as “May 2015″. Instead of making them think, I’d keep it to a standard text input, but with maxlength and placeholder attributes to help them get it right:

<input id="expiry" type="text" maxlength="5" placeholder="MM/YY" />

Better yet, I could also put a regular expression in a pattern attribute, which the browser (or some JavaScript) could use for client side validation.

A Fix for the iOS Orientationchange Zoom Bug

Posted on on

Remember the iOS scale bug? That hero Scott Jehl has cracked it.

This fix works by listening to the device’s accelerometer to detect when an orientation change is about to occur. When it deems an orientation change imminent, the script disables user zooming, allowing the orientation change to occur properly, with zooming disabled. The script restores zoom again once the device is either oriented close to upright, or after its orientation has changed. This way, user zooming is never disabled while the page is in use.

The script is less than 1KB minified (if you’re already using jQuery or another library, you could probably shrink it further). I’ve linked to the blog post, but you can jump straight to the source on GitHub.

December with the Nokia Lumia 800

Posted on on

Joe Mathewson reviewing the Nokia Lumia 800, a new phone running Windows Phone Mango, from a very non-reviewer-like point of view, as he’s actually bought one on a two year contract. It’s mostly positive, especially where the OS is concerned, and that makes me optimistic about the future of the platform (except the name “Windows Phone” which might just be the kiss of death — they should have just called it ” Metro”).

These times being what they are, I’m planning to invest in a collection of phones and tablets for testing websites on (see Brad Frost’s post) and this one is definitely on the list.