Journal tags: s3

10

Media queries and multiple columns

By far the most common use of media queries is to execute CSS based on viewport width (using min-width or max-width). Lately there’s been more talk about using media queries based on height as well.

Paul talked about using min-height media queries to adjust content appearing above the fold. Owen Gregory wrote his superb 24 Ways article on using viewport proportions and device-aspect-ratio for media queries. Trent has documented his use of horizontal and vertical media queries to bump up the font size for wide and tall viewports.

One of the areas where I’ve found height-based media queries to be quite handy is in combination with another CSS3 module: multiple columns.

Splitting text over multiple columns is not something to be done lightly on a screen-based display. If the columns drop below the viewport then the user has to scroll down, scroll back up, scroll down again …you get the picture. It works fine in print but it’s not something that should be attempted on the web unless the entire text is visible at one time.

Well, with media queries we can get a pretty good idea of whether the text will fit on the viewport …assuming we know the length of the text.

Here’s an example (thanks to Space Ipsum for supplying the text). It splits the text into two columns if the viewport has enough width and height:

@media all and (min-width: 40em) and (min-height: 36em) {
    [role="main"] {
        column-count: 2;
        column-gap: 2em;
    }
}

If the viewport is wider still, the text can be split over three columns. In this case, the test for height can actually smaller because the text is spreading over a wider area, meaning the overall height of the text is shorter:

@media all and (min-width: 65em) and (min-height: 25em) {
    [role="main"] {
        column-count: 3;
        column-gap: 2em;
    }
}

The actual CSS is more verbose than that: vendor prefixes are still required. You can grab the example from Github if you want to have a play around with it.

Re-flex

I was in Minnesota last week for An Event Apart Minneapolis. A great time was had by all. Not only were the locals living up to their reputation with Amy and Kasia demonstrating that Kristina isn’t an outlier in the super-nice, super-smart Minnesotan data sample, but the conference itself was top-notch too. It even featured some impromptu on-stage acrobatics by Stan.

A recurring theme of the conference—right from Zeldman’s opening talk—was Content First. In Luke’s talk it was more than a rallying cry; it was a design pattern he recommends for mobile: content first, navigation second. It makes a lot of sense when your screen real estate is at a premium. You can see this pattern in action on the Bagcheck mobile site (a button at the top of screen is simply a link that leads to the fragment identifier for the navigation at the bottom).

Later on, Eric was diving deep into the guts of the CSS3 flexible box layout module and I saw an opportunity to join some dots.

Let’s say I’ve got a document like this with the content first and the navigation second:

<body>
<div role="main">
<p>This is the main content</p>
</div>
<nav role="navigation">
<p>This is the navigation</p>
</nav>
</body>

Using box-orient:vertical and box-direction:reverse on the body element, I can invert the display of those two children from the order they appear in the source:

body {
    display: box;
    box-orient: vertical;
    box-direction: reverse;
}

If I wrap that in a media query, I can get the best of both worlds: content first, navigation second on small screens; navigation first, content second on larger viewports:

@media screen and (min-width: 30em) {
    body {
        display: box;
        box-orient: vertical;
        box-direction: reverse;
    }
}

Works a treat (once you include the necessary -webkit and -moz prefixes).

I thought I’d take it a bit further. Suppose the navigation has a list of links:

<nav role="navigation">
<p>This is the navigation.</p>
<ol>
<li><a href="#">foo</a></li>
<li><a href="#">bar</a></li>
<li><a href="#">baz</a></li>
</ol>
</nav>

I could use flexbox to lay those items out horizontally instead of vertically once the viewport is large enough:

@media screen and (min-width: 30em) {
    [role="navigation"] ol {
        display: box;
        box-orient: horizontal;
    }
    [role="navigation"] li {
        box-flex: 1;
    }
}

Here’s the weird thing: in Webkit—Safari and Chrome—the list items reverse their direction: “baz, bar, foo” instead of “foo, bar, baz.” It seems that the box-direction value of reverse is being inherited from the body element, which I’m pretty sure isn’t the right behaviour. But it can be easily counteracted by explicitly declaring box-direction: normal on the navigation.

What’s a little trickier to figure out is why Firefox is refusing to space the list items equally. I’ve put a gist on Github if you want to take a look for yourself and see if you can figure out what’s going on.

Update: You can see it in action on JSbin (resize the view panel).

The new CSS3 layout modules and responsive design could potentially be a match made in heaven …something that Stephen has been going on about for a while now. Check out his talk at Mobilism earlier this year.

You’ll notice that he’s using a different syntax in his presentation; that’s because the spec has changed. In my example, I’m using the syntax that’s currently supported in Webkit, Gecko and Internet Explorer. And, as Eric pointed out in his talk, even when the newer syntax is supported, the older vendor-prefixed syntax won’t be going anywhere.

Spacelift

My sojourn up the western seaboard of the United States has come to an end. It began in San Diego with the final An Event Apart of the year, which was superb as always. From there, I travelled up to San Francisco for Cindy and Matt’s wedding celebration, followed by a few days in Seattle. The whole trip was rounded out back in California at the wonderfully titled Institute For The Future in Palo Alto. For that was the location of Science Hack Day San Francisco.

It was an amazing event. Ariel did a fantastic job—she put so much effort into making sure that everything was just right. I suspected it was going to be a lot of fun, but once again, I was blown away by the levels of ingenuity, enthusiasm and sheer brilliance on display.

In just 24 hours, the ingenious science hackers had created particle wind chime which converts particle collisions into music that Brian Eno would be proud of, grassroots aerial mapping with balloons which produced astonishing results (including an iPad app), as well as robots and LEDs a-plenty. The list of hacks is on the wiki.

My own hack was modest in scope. Initially, I wanted to build a visualisation based on Matt’s brilliant light cone idea, but I found it far too daunting to try to find data in a usable format and come up with a way of drawing a customisable geocentric starmap of our corner of the galaxy. So I put that idea on the back burner and decided to build something around my favourite piece of not-yet-existing technology: the space elevator.

The idea

Spacelift compares the cost efficiency of getting payloads into geosynchronous orbit using a space elevator compared to traditional rocketry. Basically, it’s a table. But I’ve tried to make it a pretty table with a bit of data visualisation to show at a glance how much more efficient a space elevator would be.

The payloads I’ve chosen are spacecraft. Beginning with the modest Voyager 1, it gets more and more ambitious with craft like an X-Wing or the Millennium Falcon before getting crazy with the USS Enterprise and the Battlestar Galactica.

So, for example, while you could get a TIE-fighter into the Clarke belt using a single Atlas V, two Ariane 5s, or three space shuttles, it would cost considerably more than using a space elevator, where you’re basically just paying for the electricity.

If you click on the dollar amount for each transport mechanism, you’ll see the price calculated as a tower of pennies. Using a Falcon 9, for example, will cost you a tower of pennies 22 times larger than a space elevator, assuming a space elevator is at least 38,000 kilometres tall/long. Using a space elevator, on the other hand, requires spending a tower of pennies about the same height as itself. I don’t even bother trying to visualise the relative height differences for getting anything bigger than the Tantive IV into orbit as it would require close to infinite scrolling.

I’m fairly confident of the cost-per-kilogram values for the rockets while the space elevator cost-per-kilogram value is necessarily fuzzy, given that the mechanism doesn’t exist yet. But by far the trickiest info to track down was the mass of fictional spacecraft. There’s plenty of information on dimensions, speed and armaments, but very little on weight. Mathias saved the day with some diligent research that uncovered the motherlode.

Having such smart, helpful people around made the whole exercise a joy. It was quite a pleasure to walk over to a group of hackers, ask Is anyone here a rocket scientist? and have at least one person raise their hand. The constant presence of Cosmos playing on a loop just added to the atmosphere of exploration and fun.

Implementation

I’ve put the code on GitHub, ‘cause that’s what a real hacker would do. It’s my first GitHub repository. Be gentle with me.

There’s CSS3 and HTML5 a-plenty. I deliberately don’t use the IE shim to enable styling of HTML5 structural elements in lesser versions of Internet Explorer; there wouldn’t be much point delivering RGBa, opacity and text-shadow styles to a browser that can’t handle ‘em.

The background colour changes depending on the payload. I’m using a variation of the MD5 colour encoding popularised by Dopplr and documented by Brian in his excellent new book, Designing With Data.

I’m using League Gothic by The League Of Movable Type for the type—ya gotta have a condensed font for data visualisations, right?

There’s also a google-o-meter image from the Google chart API.

Needless to say, the layout is responsive and adapts to different viewing environments …including print.

Using CSS transforms, each page of table of price comparisons becomes a handy page to print out and stick on the office wall to remind yourself why the human race needs a space elevator.

Responsive refresh

Another week, another responsive web site.

Two weeks ago, it was St. Paul’s School. Last week, it was Salter Cane. This week, I’ve been working on next year’s UX London site, implementing a nice little design refresh courtesy of Paul.

More pages will be added soon but for now, it’s essentially like a poster for the conference.

Back when I was working on the first UX London site two years ago, I was building it together with Natalie, and I mean literally together: we were pair-programming. Well, I guess programming isn’t quite right for HTML and CSS, but we were pair-writing. It was an excellent experience.

Anyway, Natalie being Natalie, the UX London site was built with rock-solid markup with a flexible layout. All the pieces were in place for a responsive web design so once I was done with the current refresh, I spent a few minutes writing some media queries.

You can see the results for yourself.

Delivering Sorrow

Hot on the heels of the work for St. Paul’s School, I’ve been tweaking the media queries for the Salter Cane website. I was switching the site over to using HTML5 structural elements anyway, so I figured I’d meddle with the CSS while I was at it.

Once again, the fact that the site was already using percentages made the process very straightforward. Depending on the viewport width, the layout changes from three columns to two columns to one column.

And once again, I didn’t remove any content for small screen devices. The natural language navigation at the top of the page—now correctly ensconced in a nav element—really comes into its own in the linearised layout, allowing for quick access to different sections of the document.

The timing of all this optimisation is fortuitous. The second Salter Cane album has just been released: it’s called Sorrow.

It already has some fans. Shaun said:

The Truth Is Nothing sounds like Leonard Cohen, Johnny Cash and Arcade Fire had a musical transporter accident. can’t stop listening to it.

Lachlan is equally enthusiastic. If you like what you hear, you can buy the physical album from CD Baby or buy the digital album from iTunes. It will be available on Spotify and Amazon soon.

All the songs are licensed under a Creative Commons attribution license which means that they are podsafe. I’m looking forward to seeing where they end up.

You can listen to the whole album on the Salter Cane site using a Flash MP3 player. The documentation for Audio Player reads:

To insert a player on the page, place an HTML element and give it a unique ID. This element will be replaced with a player. If the browser doesn’t support Audio Player, the element will not be replaced so use it to show alternative content (maybe a message telling the user to download Flash).

The example code looks like this:

<p id="audioplayer_1">Alternative content</p>
<script type="text/javascript">
AudioPlayer.embed("audioplayer_1", {soundFile: "file.mp3"});
</script>

But rather than using a P element, I used the HTML5 audio element:

<audio id="audioplayer_1" src="file.mp3" controls="controls" preload="none">
</audio>  
<script>  
AudioPlayer.embed("audioplayer_1", {soundFile: "file.mp3"});  
</script>

That way, browsers with Flash installed get the plugin while other devices—like, say, the iPhone, iPod and iPad—get the native audio player.

Whatever device you’re using, enjoy listening to Sorrow by Salter Cane.

A site for Science Hack Day

I spent the weekend immersing myself in HTML5 and CSS3.

I gave Principia Gastronomica a bit of a fine-tuning under the hood. I decided to ditch all the background images I was using to get rounded corners and drop shadows, and just use border-radius and box-shadow instead. Internet Explorer gets the same content with more pointy corners and without the illusion of depth.

I also launched a brand new site: ScienceHackDay.org. It’s a small little site designed to quickly dispense relevant information on the upcoming geektastic Science Hack Day in London on June 19th and 20th.

The front page is also a blog. I’ll be posting updates about the event there and I’ll also be highlighting science projects and hack ideas. Subscribe to the feed if you want get updates.

I couldn’t be bothered installing or writing blogging software for the site. It seemed like overkill for such a quick’n’nimble project so I’m just blogging in HTML using hAtom. It’s converted to Atom using Luke Arno’s handy service. I was going to use the transcoder on Microformatic.com but I think it uses Tidy which means it won’t work on the new HTML5 elements.

The underlying structure is a combination of microformats, HTML5 structural elements and ARIA roles. The styling is over-the-top CSS3. There’s border-radius, opacity and RGBa a-plenty. Setting colours using opacity and alpha transparency makes it a breeze to customise the colours on each page, so the schedule, location and not-so-FAQ pages all have a slightly different tint.

Internet Explorer doesn’t get any of this colourful or roundy goodness. It does however, get the typography and layout, much like the print stylesheet view. I wouldn’t do that for client work but I’m perfectly happy to do it for a weekend project.

Check out the site and if you decide that Science Hack Day looks like your kind of event, add your name on the wiki.

You can also follow @sciencehackday on Twitter to get bite-sized updates as they happen.

Making Workshops for the Web

The latest Clearleft offering is Workshops for the Web. It made sense to move our workshop offerings out of the Clearleft site—where they were kind of distracting from the main message of the company—and give them their own home, just like our other events, dConstruct and UX London.

As well as the range of workshops that can be booked privately at any time, there’s a schedule of upcoming public workshops for 2010:

CSS3 Wizardry on January 29th,
Copywriting for the Web on March 5th,
HTML5 for Web Designers on April 23rd,
UX Fundamentals on June 11th and
Usability Testing on July 16th.

The next workshop, CSS3 Wizardry with Rich and Nat, promises to be packed full of cutting-edge front-end techniques. Book a place if you want to have CSS3 kung-fu injected into your brainstem.

Visual Design

I’m pretty pleased with how the site turned out. When I began designing it initially, I thought I would give it a sort of Russian constructivist feeling: the title Workshops for the Web made me think of an international workers movement. I started researching political propaganda posters, beginning with the book Revolutionary Tides.

There’s also some fantastic propaganda material in The National Archives (and I just love the modern twist of World War Three propaganda posters). I found a treasure trove of images of American working life in the Flickr Commons collection from The Library of Congress. I started gathering these sources together and distilling some of the common components such as bold colours and diagonal lines.

This was when Jon was working as an intern at Clearleft. I enlisted his help in brainstorming some ideas and he came up with some great stuff—like using Soviet space-race imagery—and we played around with proof-of-concept ideas for creating diagonal backgrounds using CSS3 transforms.

But it never really came together for me. Much as I loved the Russian constructivist propaganda angle, I ditched it and started from scratch.

IA

I scribbled down a page description diagram describing what the site needed to communicate in order of importance:

The name of the site.
A positioning statement.
The next workshop.
Other upcoming workshops.
A list of all workshops available.
A way of getting in touch.

The hierarchy for an individual workshop page looked pretty similar:

The title of the workshop.
The date of the workshop.
The location of the workshop.
The price of the workshop.
Details of the workshop.

It was clear that the page needed to quickly answer some basic questions: what? where? how much?

I started marking up the answers to those questions from top to bottom. That’s when it started to come together. Working with markup and CSS in the browser felt more productive than any of the sketching I had done in Photoshop. I started really sweating the typography …to the extent that I decided that even the logotype should be created with “live” text rather than an image.

Build

From the start, I knew that I wanted the site to be a self-describing example of the technologies taught in the workshops. The site is built in HTML5, making good use of the new structural elements and the powerful outline algorithm. Marking up an events site with the hCalendar microformat was a no-brainer. There are hCards a-plenty too.

CSS3 nth-child selectors came in very handy and media queries are, quite simply, the bee’s knees when it comes to building a flexible site: just a few declarations allowed me to make sure the liquid layout could be optimised for different ranges of viewport size.

Given the audience of the site, I could be fairly certain that Internet Explorer 6 wouldn’t be much of a hindrance. As it turns out, everything looks more or less okay even in that crappy browser. It looks different, of course, but then do websites need to look exactly the same in every browser?

Right before launch, Paul took a shot at tweaking the visual design, adding a bit more contrast and separation on the homepage with some horizontal banding. That’s a visual element that I had been subconsciously avoiding, probably because it’s already used on some of our other sites, but once it was added, it helped to emphasise the next upcoming workshop—the main purpose of the homepage.

Just because the site is live now doesn’t mean that I’ll stop working on it. I’d like to keep tweaking and evolving it. Maybe I’ll finally figure out a way of incorporating some elements of those great propaganda posters.

Hyphen Nation

Lionel Schriver’s piece in the Standpoint called Dashed Bad Form is a witty affair, comparing and contrasting the semicolon and the em dash. Alas, the self-describing nature of the article is completely lost in the online version—though presumably not in the print edition—having suffered the all-too-common fate of emdashculation; every instance of an em dash in the article has been converted into a plain ol’ hyphen. Oh, the irony! …proper irony too—not that confused Alanis Morissette kind.

It’s probably a CMS issue. But, hey, it’s as good an opportunity as any to point to the classic article on A List Apart, The Trouble With EM ’n EN (and Other Shady Characters). It’s almost eight(!) years old now and I’d still consider it required reading.

The article makes a brief mention of the soft hyphen ( or ) but back then, browser support was pretty shoddy. Browser support was still pretty shoddy when Richard wrote Hyphens a soft problem three years later.

But now the situation isn’t too shabby. Richard’s test case is faring a lot better now in Safari, Firefox and Opera. Internet Explorer (surprisingly) has been doing it right since version 6.

Admittedly, using a soft hyphen is a royal pain in the ass compared to having a browser just figure it out automatically but until hyphenation is sorted out in CSS3—which might be quite some time—we’re stuck with inserting the entity by hand.

The Rise of HTML5

Registration opened a couple of days ago for the latest Clearleft event. UX London will be taking place from June 15th to 17th. This will be a very different event to dConstruct.

For a start, the format is based around workshops (although there will also be a day of presentations). Then there’s the timescale: UX London will last for three days. Finally, there’s the intimacy factor. Whereas the attendance for dConstruct is somewhere between 700 and 800 people, UX London will be deliberately limited to around 150.

Our motivation for putting together this event was partly to bring a kick-ass UX here in the UK for a change. But mostly we wanted to put together the kind of event that we wanted to attend. So we drew up our dream line-up and incredibly, we got everyone we wanted: Dan Saffer, Jared Spool, Jeff Veen …and Don fucking Norman (excuse my French but I find it very hard to say Don Norman will be speaking at UX London without interjecting some indication of my excitement).

Andy has written more about the event on his blog which has, over the past week, arisen from its deep slumber.

The site itself launched right before Christmas. Natalie and I did the front-end build and I’m pretty damned pleased with how it turned out. Behold the liquidy goodness!

We used this as an opportunity to really push what Dan has been calling progressive enrichment: sprinkling in some modern CSS declarations even if not every browser gets all of them—something that Malarkey has been banging on about for quite a while now.

So if you view the UX London site in IE6 it looks fine. Nothing special though. But if you view the site in a browser like Safari, a lot of little details shine through. The design is pretty much a test-case for the box-shadow property using RGBa. Depending on the browser width, multiple translucently shadowed elements can overlap and it’s interesting to see how browsers handle this (Safari’s additive approach seems correct to me).

On the markup side of things, we decided to write the site in HTML5. But wait! Isn’t HTML5 going to take another few decades before it’s finished?

Well, no. That little bit of bollocks was spread ‘round by people who misread the timeline, underestimating the importance of “working draft” and overestimating the importance of “proposed recommendation”. Admittedly, those are pretty confusing and unintuitive labels for it’s ready and it’s been finished for ages and now it’s 100% supported in at least two implementations.

It turns out that when it comes to the markup, HTML5 isn’t all that different to what has come before. It’s all the DOM gubbins—which should allow a more declarative approach to building web apps—that is the real hard stuff that requires browser support in order to work. If you’re not interested in that side of things, much of the HTML5 spec won’t even be relevant to you. For your convenience, Michael Smith has put together a markup-only version of the spec.

From a semantic perspective, the most important additions to the markup language are the structural elements such as header, article, section and so on. Bruce Lawson has put together a test case to show that you can use these elements and still style them in most browsers. For pesky Internet Explorer, you can use a neat little JavaScript trick that John Resig discovered a while back. Alas, Camino still doesn’t play nice with styling the new elements. But that isn’t going to stop Bruce realigning his site to use HTML5’s new structural elements.

For the UX London site, we didn’t go quite that far. We stuck to using divs with class attributes for our structure. But we could still build on the work that has gone into the HTML5 structural elements. Rather than coming up with our own class names, we used the names proposed in the spec: article, section, aside, etc.

Now our document structure has pre-built documentation. Want to know what class="article" denotes? RTFM.

Using HTML5 elements as a basis for a naming convention isn’t a new idea. Malarkey has written about developing naming conventions from HTML5. Jon Tan also wrote about preparing for HTML5 with semantic class names. Oli Studholme put both of those articles together to create a handy little structural cheatsheet. Use microformat class names for the small stuff; use HTML5 class names for the bigger stuff.

Apart from providing easier documentation, there’s another good reason to take this approach: interoperability. Think about how much easier user styling would be if sites shared many of the same class names. Even if you don’t think that they are the best class names—I know, for instance, that Malarkey doesn’t like the presentational smell of footer—the benefits of an aggregate shared vocabulary could be very empowering. So if you do insist on creating a CSS framework that mandates using certain specific names (a concept I despise) please, please, please use those class names.

On the subject of user styling, there’s a site ID of uxlondon-com on the UX London site. Huffduffer, another HTML5 site, has an ID of huffduffer-com on every page. But rather putting these IDs on the body element, it seems more meaningful to me to add them on the html element itself.

A couple of weeks after the UX London site launched, another event site went live: the beautifully-redesigned An Event Apart. It’s also written in HTML5. Jeffrey has written about the design and Eric has written about the markup.

Huffduffer, UX London, An Event Apart and now The Watchmaker Project …there’s quite an exciting air of experimentation around using HTML5 right now. Personally, I’ve found it to be a fun way of breaking out and trying something new. I recommend giving it a whirl. Until recently you would have needed to use validator.nu to test your markup but now that’s been integrated into the W3C validator so all your old bookmarklets and tools will still work.

Even if you decide against writing in HTML5 itself, at least consider using those HTML5-inspired class names for your structural naming convention where appropriate.

Simple Storage Service

Amazon’s new S3 service looks very interesting indeed. At first glance, it just looks like a very cheap way of storing and retrieving files — which it is — but the really fascinating aspect is that there is no user interface. It is purely a web service. As Sam Newman says:

When you get down to it, Amazon S3 is simply a large, distributed hash map with an API. Unless people build applications on top of it, it’s useless.

The creators of S3 have gone out of their way to keep the architecture as simple as possible. This is a smart move. I’m a great believer in the power of stupid networks.

Leaving aside the underlying technology, S3 is good news in purely practical terms. If nothing else, this should start a price war for data storage. Yet another barrier to entry has been lowered for anyone looking to publish anything online. Odeo and YouTube are good for audio and video respectively, but the agnostic nature of S3 means that you can store and stream on your own terms.

Hardware has been getting cheaper and cheaper for some time. Now it looks like bandwidth is heading the same way (for some amusing anecdotes on bandwidth issues, be sure to listen to Bernie Burns’ keynote from SXSW).

I’m looking forward to playing around with S3. For a service with no face, it sure looks like it’s got legs.