Towards the end of last year, Scott Jehl and the Filament Group released a small JavaScript library which experimented with the idea of “Responsive Images”. As the demo explains it can be used to load optimized, contextual image sizes in responsive layouts depending on the screen resolution. It cleverly uses HTML’s base element to redirect all initial image requests to a small 1×1 pixel place holder, so as to avoid loading more than one image.

This was principally developed to allow mobile devices to download smaller and more light-weight images, choosing which image to load based on the screen resolution of the device. As an approach this is useful in a very practical way, but it’s also an example of where one feature of a device is used to make assumptions about another feature. In this case, it’s the assumption that a small screen resolution means a low-bandwidth or low-speed connection.

This itself is driven by the sometimes misleading assertion that, “Mobile users need to save bandwidth”. That may be the case, but there is another rule that trumps it: “All users need to save bandwidth”. Performance matters, a lot, across every type of device and across every type of network connection.

A content first approach

Recently I’ve worked on a number of liquid width sites that have images styled at 100% width. This means the image could be displayed at varying sizes depending on the size of the browser’s viewport. This often leads to a scenario where quite high resolution images are loaded into the page for users that are only ever going to see squashed versions of the images.

The content driven approach to fixing this is to decide which image to load based on whether the image will be stretched beyond its true pixel width. If you stretch an image beyond its true width it begins to look pixelated or blurry. In this scenario, we want to load in a higher resolution version of the image.

I like the theory behind this approach because it embraces the principles of responsive design and applies them based on the best possible display of content rather than on essentially arbitrary and device specific pixel widths.

The code (forked from the Filament Group’s starting point) is available on Github.

At the moment, I would class it as proof-of-concept rather than bullet-proof, but I think it’s an interesting approach which is certainly worth sharing and discussing at this point.

Having said that, there is a small example of it working in the wild. This page for the Brighton Digital Festival contains images which respond in various ways to the size of the browser’s viewport. This is an interesting example because the images don’t always get smaller as the viewport gets smaller. Start with a wide browser window and the images are actually quite small. As you make the viewport smaller you will see the images decrease gradually in size and then jump to a larger size as the layout’s media queries kick in. If you refresh the page at this point you should see higher resolution images load in place of the original images.

This is a short comment on Ted Dziuba’s version of why MacOS X is an Unsuitable Platform for Web Development. Ted is right and wrong at the same time.

Unless you’re building the simplest of web sites with static pages or just PHP you shouldn’t develop on OS X. I used to. I used to compile MySQL and Apache from source, upgrade Python, install Django and a bunch of other Python tools, and leave myself in a hell of a mess, because yes, package management on OS X is a pain in the proverbial. And I hated doing this on the same machine that was my primary machine for email, web browsing, and other ‘desktop’ type tasks.

The obvious solution to this is virtualisation. Using Parallels, VMWare, or VirtualBox (my current choice) you can spin up as many sand-boxed environments as you like (which is why I don’t find much value in virtualenv). Using the same mechanisms you use to create production machines will get you most of the way to a development machine. Take a snapshot of that (or better still, use something like Vagrant) and you’ve got re-usable and shareable development images.

Why is this good?

You’ll catch bugs early. By developing code in an environment that closely matches production you’ll develop code that is more likely to work in that environment. You’ll get less bugs reported to you when your code moves into staging, or worse still production.

You’re sandboxed. You can feel free to install whatever dev tools you want on that machine, with no danger of screwing up your main desktop machine, or bloating it with crap you don’t need. Secondly, if you need a different environment for different projects you don’t have to manage them within one OS. I can’t imagine the hell on earth I’d go through to setup Apache with one lot of virtual hosts pointing at Python and Django, others pointing at Ruby on Rails, etc… all on OS X, where I write my email and sometimes open things like Photoshop and Fireworks.

You can still use OS X editors. I normally use Macfusion to mount appropriate directories of my VMs on OS X, so that I can use Textmate and other OS X tools to edit and manage code. I’m sure there is a better more fashionable approach than Macfusion, but I’m a creature of habit and it works for me.

The best thing about this is, despite OS X being an unsuitable platform for web development, you can still use it as your primary OS. It is a better, more stable, more pleasing and usable platform than any version of Windows .

When we had new people joining at Multimap (or ‘onboarding’ at Microsoft) one of the initial big hurdles for them was learning the ins and outs of the approximately 30,000 lines of JavaScript that powered the site.

One thing I used to recommend people do was to turn on a little event logging switch we had in the code that logged to the console every event fired. The application made heavy use of custom events, so by watching these events occur in real time as you navigate and use the application, you can get a pretty good insight into what is going on in the guts of it. For example, a typical output might look like:

dragStart
dragEnd
mapMove
locationUpdate
geocodeSend
geocodeReceive
adUpdate
searchSend
searchReceive
panelOpen

Not only does this give you a broad overview of what might be going on, but knowing the names of the events gives you a starting point for jumping into the code. You can now search and find the module that triggers that event, as well as every piece of code that is listening for it and waiting to do stuff.

Recently I wanted to do the same thing in another JavaScript application which is using jQuery to do its custom events.

The above code monkey patches jQuery’s trigger event and logs the name of the event to the console. It doesn’t work for the browser’s built in events, (which is probably fine as you generally know what browser events are occurring), but it does work for all of jQuery’s built in events and any custom events that you trigger yourself.

I think this is a helpful way of starting to learn a codebase. In this case, it’s not so much new people joining that might benefit, but a client’s development team who’ll be taking this over eventually.

I’ve heard a lot of people recently describing HTML5 localStorage as being a replacement for cookies, or cookies on steroids. Even the masterful Bruce Lawson said pretty much this in his fantastic Web Anywhere talk at SxSW last month. I cringe every time I hear someone say this as it’s such an obviously dumbed down version of reality.

So, to state the obvious…

Cookies are small pieces (about 4 KB max) of data stored on the client which are sent in the headers of an HTTP request to the server, typically to allow for sessions or some other kind of state to be handled across requests. They contain expiry information and are typically created by the server using HTTP headers. There is also a JavaScript API that lets you access and edit cookies, although the less said about that the better. Cookies will continue to be a critical part of your web applications despite the introduction of localStorage.

localStorage is a persistent key-value store in the browser with a full JavaScript API to set/get/remove values and events to track changes programatically. It typically allows for up to 5MB of storage, although this can be increased at the user’s discretion. Data in localStorage isn’t sent to the server as it is with cookies.

localStorage allows for a whole range of uses that cookies do not, and cookies allow for a whole range of uses that localStorage does not. There is admittedly a small area of cross-over, but explaining it in those terms is backwards, hugely undervaluing the scope and importance of localStorage, and frankly condescending to the people you are explaining it to. Please stop doing it.

The next time you’re called to simply explain localStorage or sessionStorage in HTML5, don’t mention cookies. Just simply say, “localStorage is a powerful key-value store in the browser which you can access through a JavaScript API.”

Some of the best-supported HTML5 JavaScript APIs right now are the localStorage and sessionStorage APIs in the Web Storage specification. The latest version of all modern browsers (including IE8) support these, and some support the Web SQL Database API (although this spec is no longer active and isn’t being taken further).

What all of these APIs have in common is that anything a web developer chooses to stash in them is stored unencrypted on the user’s hard-drive for an indefinite amount of time. The spec suggests user-agents MAY allow for configuration of expiry times, but I don’t know of a browser that currently does that. This means that there is a constraint on the nature of the data that should be written to these storage systems.

Over the years, two things that I’ve been trained to have flags pop-up in my head for is “unencrypted data”, and “never expires”. Not major red flags that warn “here’s a massive security hole”, but small blueish flags that warn “there’s a limit to what we should do here”.

I don’t believe this is a flaw in any WHATWG or W3C specification (and the members of these groups that I spoke to don’t believe it’s a significant issue), but I do believe there’s a conversation that needs to take place amongst web developers. A conversation that makes people aware of the limits of client-side storage mechanisms, and gets them to take the question of what they store there seriously.

Mobile Gmail

Gmail’s mobile web app stores data client-side using the Web SQL Database API. It doesn’t just store small pieces of supporting data; it stores the full headers and body of your email locally in a SQLite database that can be read by any sufficiently privileged process running on that machine.

Again, there isn’t necessarily an inherent security problem here. If your machine or device has been compromised then it’s been compromised, and there’ll likely be any number of attack vectors that you’re open to. On the other hand, when I log into Gmail over SSL, carry out all communication in an encrypted format, read my email, then log out and leave the building, I don’t expect my emails to be sitting in plain text in a store that has no expiry directive.

There are certainly counter-arguments to this, most of them along the lines of the horse having already bolted, and if you use the web then data gets downloaded, unencrypted, and exposed in various ways. These are fair arguments, but it doesn’t mean we should forget about the whole thing and not consider how and what we explicitly ask a browser to store.

Things to consider when using localStorage

• What could an attacker do with this data? Make a judgement call based on the sensitivity of the information you are storing and the value of it to an attacker.
• Is sessionStorage more appropriate? Do I really need to persist this data (or a subset of it) across multiple browser sessions, or is the value mainly in sharing data between pages, or tabs within a single session?

What would happen if every time you served a CSS or JavaScript file from your server you sent it Gzipped? Ignore whether the browser thinks it can handle compressed content, just send it compressed anyway.

Steve Souders talks about forcing Gzip compression at Google here, and this method assumes there is a significant number of browsers that won’t be able to compress it and will choke. It would be interesting to see Google’s data on that.

What if you took the Google idea:

1. For requests with missing or mangled Accept-Encoding headers, inspect the User-Agent to identify browsers that should understand gzip.
2. Test their ability to decompress gzip.
3. If successful, send them gzipped content!

And changed it to:

1. Send them gzipped content!

Do we have any real-world data that tells us practically, how many browsers would not be able to deal with that, and what percentage of users would get a broken experience?

This came up because Simon Willison tweeted:

S3/CloudFront don’t handle conditional gzip, at all? That’s a pretty shocking omission. The workarounds are really ugly…

Perhaps it is a pretty shocking omission, but plenty of people are serving compressed JS and CSS from Cloudfront, right? So is it as much of a deal-breaker as it might have been a few years ago?

This is a brain-dump that got too big for the Idea section on the Science hack day wiki so I’ve moved it over here.

Incidentally, if you like hack days and you like science, you might be interested in finding out more about what’s being planned for this inaugural Science Hack Day. Meanwhile, here’s the idea:

Given an HTML document containing tables of solar system model data, build a stylesheet (using CSS3 transforms and transitions/animations) that can present it as an animated model of the solar system:

• Would be interesting to see what could be done with only HTML/CSS, but realistically might need some scripting to make it a bit more sane. For example, to read data from the table in the first-place.
• Cubes rather than circular images of planets, so we can spin them independently at correct speeds. Might not look so pretty, but means we can aim for a more accurate model. Could use more than 6 faces to get a more ’rounded’ shape, eventually it would look spherical I guess.
• Not sure if reproducing the true elliptical orbits of planets is going to be easy, or even possible. They might just have to be circular, at least in v1.
  • Matthew below has a possible solution for that: using a scale transform to stretch the x-axis.
• Allow for rotating the entire canvas so you can zoom in and out and look at things from different angles using keyboard or mouse controls.
• Need to work out solution for scaling distances vs planets sizes independently so we can fit it on a screen. Presumably there’s prior-art for this. Would be nice to have a few different scaling methods.
• Could do a canvas version too, but probably less fun and actually pretty simple for someone with decent programmatic drawing skills (not me).

Finally, here’s the extremely crappy and ill-conceived 10 minute non-starting point, which I’ve entitled Tiny dots going round a small dot (Webkit only of course). No, none of the table’s data is used in the animations, all the values are hard-coded in CSS, and it’s almost not worth showing. But anyway, if it was all done and dusted we’d have nothing to do on hack day.

See you there?

The Web standards movement has unintentionally cultivated something of a fundamentalist attitude amongst some of it’s supporters. This isn’t necessarily a bad thing, as having extreme opinions on both sides of the argument is often a healthy sign.

However, it does mean that any good news is often rebutted with a, “Yeah, but this bit here is still crap”, style of response. Fortunately these comments normally expose a limited scope of experience on the part of the commentator, which makes it very easy for me to ignore them.

A recent NYT article by former Microsoft VP Dick Brass has been doing the rounds. It’s pretty middle of the road in terms of its judgement of Microsoft: over-run by middle management, caked in bureaucracy, both of which stifle innovation and creativity.

I’m not really going to give my take, because it seems a bit tawdry when I was only there for two years and was based in London for all of that time. Fortunately I don’t have to, because Scott Berkun unravels my half-baked thoughts very succinctly in a small part of his recent assessment of the company.

The primary problem at Microsoft regarding good design & innovation is the diffusion of creative authority. The problem is not the numbers of people at the company, or the layers of management, as many gripe about. Layers don’t help, but it’s not the problem. The real issue is the inability to grant creative authority to the few people worthy of it. Microsoft has always been a place that gives way too many people a say in matters of design, vision and user experience, and it shows in the pervasive mediocrity of the majority of its products. Films need directors. Orchestras need conductors. But if you divide things into 30 pieces and ask 30 people to play creative visionary, mediocrity ensues. The better products at Microsoft are the ones were [sic] VPs modify the distribution of authority to create clear creative authority.

I’ll quickly put that in terms that fellow colleagues of mine at the time will identify with.

Teams are encouraged to be accountable for everything that they do. Strategy, planning, design, execution, analysis. There are a dozen little teams running around, all being accountable for their part of the puzzle, without having any idea or thought about how they will link up with their neighbouring pieces to create a plausible end product.

I stand by what I said from day one. Technically, it’s a big ass iPhone. But the iPhone is really a pretty magical device. And this is a big ass one.

Here follows my prediction for myself and the iPad.

While it’s impossible for me to buy one, I don’t really want one. I certainly don’t need one. There’s no obvious gap in
my computing armour that it will fill.

That is, until the day it becomes possible for me to walk to a shop and buy one. Otherwise known as the UK release date. On that day, I will almost certainly walk to said shop and buy one.

I’m not proud of myself.