This is the archive of version one, made in 2006, launched in 2007, and active until 2012. It’s archived to preserve the original design and its content that was referenced in multiple posts, books and galleries. There’s a holding page before the new site arrives.

All entries from 2008


  1. Growing OmniTI

    Grow Collective and OmniTI logomarks, merged.

    ’Twas the week before Christmas, and all was hectic in the house.
 Or, at least, that’s how it seems! The last few weeks have been a little wild, culminating in one big event: I’m excited to announce that I’m the new Creative Director at OmniTI.

    One reason it’s such big news for me is because this is the first time I’ve been employed for many years. I’ve spent a long time in the fertile fields of freedom, or so it seems looking back. Before the turn of the new millennium, I spent most of my time skipping around the country and the world trying life on for size — finding amazing moments to punctuate the scrapes and mischief. Since then I’ve spent most of my time working with like-minded people from within Grow Collective. So, this event was a long time coming — over a year in fact — and all the better for it!

    The truth be told, I doubted if I would ever take a ‘proper job’ again. It may sound dramatic, but it was true! The ability to measure my actions by my own standards, decide what jobs I took, and report only to myself was too precious to me; I thought I’d be unemployable. It had to be something extraordinary to turn my head, and OmniTI is. In my view, it is the most important web company you’ve never heard of (especially if you’re a designer). If you’re a sysadmin, developer, or involved with the open source community, you’ll probably know that there’s hardly a single significant technology deployed on the Web today that someone at OmniTI hasn’t contributed to. If you use Apache, PHP, Perl, PostgreSQL (to name but a few), or frameworks like Cake and Solar, you’re probably reading books, using code or documentation that people at OmniTI have written, or helped create. They also have an awesome client list, featuring the likes of National Geographic, Digg, Facebook, Friendster and Ning. All that is exceptional, but not enough to pry me away from Grow Collective. The thing that tipped the balance was the culture.

    How I work is equally as important to me as what I work on, as anyone familiar with Grow will know. OmniTI started life as a family-run Internet and web operations company. It was founded by Theo, one of the world’s foremost authorities on Internet architectures, scalability and performance. Also there from the start were Theo’s equally talented brother, George, and mother Sherry. Since 1997, a lot of people I admire — like Chris — have found a home at OmniTI. They’ve grown in almost the exact opposite direction to most other companies: from operations, to data management, to web application development, and now to interface design and user experience. It means OmniTI can create and build complex web applications, but also deploy the infrastructure to support the hundreds of millions of people who might use them. They have a special approach to their work with an engineering rigor to what they create and manage. They’re a family-orientated and collaborative culture, with one of the lowest staff turnaround rates in the industry. I think it’s exceptional.

    So, when my equally exceptional friend, Chris, asked me if I’d consider joining them, I had to give it serious thought. A year or so later, and here we are. I’m stoked! Chris has also shared his generous thoughts on behalf of the company in the official article.

    A few people have asked about Grow. Up ’til now I’ve been unable to talk about it, but now I’m happy to also announce that Jon Gibbins is joining me at OmniTI! He’ll be a core component of the interface design team. Officially, he’ll be an accessibility engineer. A posh-sounding title that basically means he’ll be doing what he does best: accessibility consulting and training, interface development and quality assurance. So, that effectively means that we’ve ported ourselves to OmniTI; the core of our small interface design team at Grow has been acquired!

    Our ambition, for a long time, was to expand the co-op to take on larger, more meaty projects, and work with more amazing people. However, being so busy with client work always made managing that problematic. We had some notable successes like Alan, who’s going to continue to practice his outstanding user experience design skills from Ezyas. However, there were a couple of disappointing experiences. It became obvious that some people were not suited to working within a co-op. Especially one with such a rigorous ethical and qualitative bias. The ambitions remained, though. As the deal with OmniTI was being fleshed out, it also became obvious that we could skip the pain of growing organically, and jump straight into an organisation that already had exactly the kind of people we wanted to work with, and the kind of projects we love to work on. Not only that, but the culture had strong similarities to the one we wished to create. So, effective from now, Grow is no more. The domain and the organisation is in stasis from this point. My emotions are mixed. Looking back, I’m proud of what was accomplished over the last six or seven years, and a little sad to see Grow Collective retire. Looking forward, I’m already engaged with fantastic projects, and thrilled to be working with such great people. I have a feeling that we’ll be working with Alan again soon, as well. The best is definitely yet to come, and I’m excited to be part of OmniTI — 2009 is going to be a great year!


  2. PHP Advent Seasoning

    Ladies and gentlefolk, I give you the two-thousand and eight PHP Advent Calendar!

    PHP Advent Calendar screenshot.

    As an aside in a season that gets rudely interrupted every year with a huge, great party, the PHP Advent Calendar is adding to the fray. Some of the denizens of PHP are sharing their wisdom from a beat-up old soap box in our quiet, geeky corner of the Web.

    The entire project was launched in a mad, two-day rush, which featured the guys with real talent setting up the server, propagating the DNS, and gathering the initial content. A couple of days after the first article, for my sins, I applied some style to the interface. Twenty-four hours of key-smacking later — and with a good dose of help from the indomitable Jon Gibbins — it was done.

    The project is edited by Chris and Sean with nuts and bolts help from Jon. It is kindly sponsored by OmniTI. I have to tell you, with almost no time to get it done, deadlines looming, colleagues sweating, and the world in general turning far too fast, I’m pretty pleased with the result.

    A single typeface is used throughout. It changes depending on availability, but this seemed like a good opportunity to stretch a face or two. (Writing that made me smile.)

    Although we would have loved to license and use various typefaces not currently available in operating systems, there just wasn’t the time. Without knowing the full range of glyphs the content might need, the faces currently licensed for @font-face linking (many with slightly abridged character sets) might not have had the range we need. So, I chose Baskerville as the primary face with various fall-backs from there. Hopefully the epidemic of the Baskerville italic ampersand will ebb soon, but there are many worse things in life to see on an almost daily basis.

    You might notice the use of the golden ratio, and an attempt to coerce our awkwardly independent browsers into rendering a baseline grid.

    As always, the content was king, queen, barkeep and god: I veered away from images as decoration, considering them unnecessary. I hope nothing overshadows the reading experience. With that in mind the interface is fluid, with a minimum width to stop it all collapsing into a narrow abyss. Most significantly though, the content is genuinely interesting. There are some choice pieces over there, and if you’re interested in PHP at all, swing by, grab the feed, or follow ‘phpadvent’ Twitter for fast updates.


  3. Display Type & the Raster Wars

    ClearType is 10 years old this Autumn. For most of that time it lay hidden until Vista brought it to the fore by default. Font rendering in Internet Explorer using ClearType is good for body copy at smaller sizes; it’s a huge improvement on the Standard rendering that preceded it. However, larger display text is badly rendered. I don’t say it lightly, but every time I load a page for testing in IE7, I wince at the jaggies. What makes this worse is that Standard rendering is better at display size anti-aliasing. I used to compose scales and size headers to take advantage of smoother Standard rendering at larger sizes.

    The context in which I view the text has the most influence over my reaction: Apple. I use a Mac. My browser of choice is Safari which uses OS X’s native ATSUI font rasterisation engine. Text is as beautiful as it can be on the Web right now. If text rendering in Firefox is disappointing in comparison because of the added weight, rendering in IE on Windows is positively distressing.

    The quality of the rendering is dependent on various factors like the display type (LCD or CRT), the display resolution that has limited pixel density, the rendering engine itself, and the quality of the font file — specifically the hinting of the typeface.

    ClearType was launched in 1998 at COMDEX by a celebratory Bill Gates. In a press release, the director responsible for the ClearType project, Dick Brass, was quoted as saying:

    ClearType makes inexpensive screens look as good as the finest displays, and it makes the finest displays look almost as good as paper.

    If only that were true. OK, it’s a press release, so we assume a degree of hyperbole from exaggerateers, AKA marketeers, writing the copy. But still. Let’s look at the evidence. I built a quick test suite using Georgia, Verdana and Arial because they’re some of the more commonly used Core Web Fonts. Here are screenshots of a heading set in Arial at 36px in different browsers:

    1. IE7 with ClearType on XP Pro:

    2. IE7 with ClearType on Vista:

      Sample thanks to Ryan Brill (he was the first of many kind replies via Twitter). Thanks, all!

    3. IE6 with Standard on XP Pro:

    4. Firefox 3 OS X:

    5. Opera 9 OS X:

    6. Safari 3 OS X:

    Compare the jaggies and dire anti-aliasing in IE7 using ClearType with the Standard Windows rendering of IE6. Also compare the heavier weight of Firefox using its own platform-independent engine with that of Safari using ATSUI.

    Factual insights about the differences from professional font, browser, or raster engine developers would be welcome in the comments.

    One of the reasons for the glaring difference between IE and Safari is a fundamentally different approach to web typography from Apple and Microsoft. Apple tries to render type as true to the original typeface design as possible, Microsoft uses grid-fitting when rasterising a font. There’s more in a previous article for those interested. Studies have shown ClearType to be more legible than Standard rendering, but they only compared the two. Expanding the study to test Macs and Linux-based PCs, as well as ensuring the test group was populated equally by people who use machines other than Windows PCs, would have all helped the results be more interesting.

    Type rendering anomalies are a serious issue for web design. Designers and clients with an eye for detail want typefaces to render accurately and smoothly. Shaun Inman is right:

    Until anti-aliasing discrepancies between platforms can be resolved I don’t see even a standardized approach being accepted by discerning designers.

    ClearType fails to deliver good anti-aliasing. In my view it is a backward step from the old Windows Standard rendering. I am at a complete loss to explain why it is allowed to persist. Especially because Microsoft Typography seems packed full of experts in the field. Surely they’ve noticed?

    Typography on the Web should at least equal the sophistication of print typography, if not enrich it. To do so, type needs to be rasterised correctly, and web designers need the ability to set it with much of the same subtlety and detail available in print. Until that time, technologies like Flash, PDF, and hacks like embedding type in images, will continue to thrive. Designers will use them not just because they ‘do type better’, but because they won’t have to deal with painful inconsistencies between user agents; the bane of the browser wars, and in this instance, the bane of web typography in what seems like the age of the raster wars.


  4. Happy Birthday, Son!

    Dear Xen, you’re five today. Five years old! You left for school this morning and I was reminded, without the prompting of sentiment, but by the eloquence of your words, and the agility of your thoughts, and the serenity of your actions at such a young age, of why I am so proud of you and the young person that you are becoming.

    Every time a birthday passes I think back to how much has changed since you were born, and I look forward to how much will change in your lifetime, and hope I will be around long enough to give you the tools you need to navigate the world and grow into yourself. So, it seems apt that on the day that Guy Fawkes tried to spark a revolution in 1605, and on the day that Barack Obama won an election in 2008 to become the first black president of the United States, I share some of his words with you in the hope that when you’re ready to read them they might be useful:

    Re-affirm that fundamental truth: Out of many we are one, that while we breathe, we hope, and where we are met with cynicism and doubt and those who tell us that we can’t, we will respond with that timeless creed that sums up the spirit of a people: Yes we can.

    Happy birthday, son. I love you.


  5. @font-face in IE: Making Web Fonts Work

    All Hallows’ Eve seems the perfect time for something a little spooky. Getting @font-face working in IE may just be spooky enough. As you probably know @font-face already works in Safari 3 via WebKit and is supported in the latest Firefox 3.1 beta. With IE, that means around 75% of the world audience could see custom typefaces today if their EULAs allowed it. Fortunately, there are good free faces available to us already, as well as some commercial faces that permit embedding. Fontin is one of them and I’ve built it into this example page:

    Before we get into the nitty-gritty of making this work, which you can skip to if you wish, I thought a little history and a brief summary of the current status of the web fonts debate might be useful.

    Web Fonts: Then & Now

    Web fonts have been with us for a decade. They were an original part of the CSS2 recommendation in 1998. Recently, the godfather of CSS, Håkon Wium Lie, brought them sharply into focus with articles in CNet and A List Apart. The ironic thing is, IE has supported web fonts using the Embedded Open Type (EOT) format since 1997. The problem was that EOT was a proprietary format, belonging to Microsoft. Not for much longer: it’s been submitted to the W3C and is going through the process towards becoming a web standard.

    Since the debate opened up, the web and type communities have both been busy discussing how the future will unfold. More collaboration between the disciplines would be beneficial to both, and I’d encourage any interested designers or developers to get involved with organisations like the Association Typographique International (ATypI).

    Recently, Bert Bos of the W3C paid a visit to the ATypI Conference in St Petersburg to meet with type designers face to face. His summary of the current situation is essential reading. The debate has continued apace on the ATypI mailing list, which unfortunately has no public archives. However, if you are member of the ATypI, you can see this summary about the conference panel on web fonts by Nadine Chahine that started the debate in earnest. Simply put, type designers seem anxious about @font-face linking making it too easy to steal a font. Both Microsoft’s EOT format and direct font linking are under consideration with EOT a favourite with many. However, rather than paraphrase a wide-ranging set of opinions, I’d encourage you to join the ATypI yourselves as designers and developers to participate or observe.

    If you have other favourite comments or posts about the future of web fonts, please add them to the comments.

    As a designer, I want a straightforward way of licensing and including fonts for my work. I will pay, respect the rights of type designers as I expect mine to be respected, then get on with the glorious business of merging content with type. It’s not as simple as it sounds, though. The licensing of fonts, and the protection of the rights of smaller designers in particular, is a sticky issue. DRM does not work, so what then? Richard Rutter has shared thoughtful insights which are very much worth a read. My view is that I would be perfectly prepared to pay a separate or extra licence fee to use quality fonts on the Web. I would have no problem selling this to my clients. Embedding or linking to fonts has to be straightforward though. I get paid to think about, plan and implement design, not grapple with obstructive software (more on that later). If fonts were delivered through a third-party web service as Richard suggests, the one proviso must be that it would have to be done by someone who knows exactly what it means to scale a service for millions of users. Like most designers though, I have very little knowledge of the real security and scalability issues, but hope to see a comment from a real security expert, shortly.

    User agents are currently taking divergent routes. Bert Bos’ summary reports:

    Mozilla has stated that they don’t want EOT. But they are not opposed to letting the browser check the license, as evidenced by the proposal to let HTTP headers carry license data.

    Microsoft has said that it is impossible for them to support linking to native OpenType as long as font vendors oppose it.

    Apple’s Safari has implemented font download with no checking of licenses. They said they are against EOT, but would not be against browsers checking licenses, e.g., using Mozilla’s proposal.

    Opera remarked that there are more existing and announced implementations for downloading native OpenType than for EOT. They conclude that the market apparently doesn’t need EOT and thus they see no need to support it themselves either. W3C’s limited resources should be spend on more important standards.

    That means that designers and developers have the same perennial problem: Two different implementations to achieve the same result. Safari 3 and Firefox 3.1 beta both support direct linking to OpenType (.otf) font files. Presumably Opera will soon. Only IE 4 to IE 7 support Embedded Open Type (.eot) files. IE8 does not, but will at some point. So, to see Fontin display in standards complaint browsers like Safari 3 and IE, we need to provide two separate fonts.

    @font-face Example

    The @font-face example uses Fontin Regular by Jos Buivenga — a free face kindly provided by Jos with a licensing permitting embedding with attribution. Jos also has many other fine faces available via his foundry site, Exljbris. The example is a quick one using a traditional scale, with all of the CSS available in the <head> of the file.

    1. Set the basic font-family:

      h1, h2, h3, p, td{
      font-family:'Fontin-Regular', georgia, serif;

      Notice the 'Fontin-Regular' name — this is an arbitrary name that can be whatever you like. All it does is tell the browser when to apply the font file referenced in the @font-face rule.

    2. @font-face and .otf for standards compliant browsers:

      Ed: White space inserted for clarity.

      src: url('Fontin-Regular.otf') format('opentype');

      Note the 'Fontin-Regular' name, again. This rules basically tells the browser, when the @font-face is set to 'Fontin-Regular', use the font found at this URL.

      Screen sample of Fontin Regular in Safari 3 set at 16px with 24px line height from the example:

      Fontin in Safari 3

      When Safari renders the page, it will look for the font file, then render the text accordingly. There’s a slight delay as WebKit works. In the example you might notice that the text not requiring the loading of a font file renders quickly, but the rest is blank until the browser catches up. For reference, the Fontin-Regular.otf file is 32KB in size. Some font files can be much larger.

    3. Create the .eot file with WEFT:

      To do this you will need to download and install WEFT3, a Microsoft application for creating EOT files from TT fonts. WEFT is not able to create EOT files from an OTF. It must be converted to a TrueType file, first. WEFT is the only tool for this as far as I’m aware, although I believe there is an open source one in development. If it wasn’t for WEFT, embedding EOT files would be easy. What I want WEFT to do is convert the font to EOT, and allow me to create a subset if required. It does that, but in a nightmarish, frighteningly over-complicated way. Perfect for an All Hallows’ Eve entry. Here are a few tips I learnt the hard way:

      1. WEFT requires the URL of the page or site where the EOT font will be used. It will then ‘scan’ the pages by crawling the site to see what glyphs are used and try and create a subset of the EOT file accordingly. If it refuses to analyse a valid URL as it did for me, get granular and specify pages or sub-directories in your information architecture.
      2. If you’re using WEFT via Parallels and XP Pro, it may refuse to add some fonts in your windows/fonts directory to its database of available fonts. Try using a standalone PC if you can. I haven’t tested in any other virtual machine.
      3. Use the wizard to set up your project, but after that try it manually using the View menu item to see what fonts are available to convert, and the Tools menu item to convert them.
      4. WEFT will try to save the EOT file to a remote location. You can over-ride this manually to save the file wherever you please for you to upload yourself.
      5. Disable your original OTF fonts on your system before testing (obvious but worth a prompt).

      Be warned, WEFT is awful to use, in every way. It did not work for me running Parallels with XP Pro on a Mac. 7th Nov: After more experiments, Weft will accept TrueType (.ttf) files in Parallels. It also worked with the gracious help of Jon Gibbins and his standalone PC running XP Pro. Because it is so painful, I cannot give support for WEFT. You can try the Microsoft WEFT user community, but I can’t comment as to its usefulness, and I could not find any other support avenues.

      Hopefully, you now have an .eot file to use.

    4. @font-face and .eot for IE using conditional comments:

      Ed: White space inserted for clarity.

      <!--[if IE]>
      <style type="text/css” media="screen">
      src: url('Fontin-Regular.eot');

      These are screen samples from IE:

      Screen sample of Fontin Regular in IE6 set at 16px with 24px line height from the example:

      Fontin in IE6

      Notice the bar missing from the capital ‘A’ towards the end of the second line. The tyepface designer, Jos Buivenga is currently looking into the font hinting, with input from John Boardley.

      IE7 sample:

      Fontin in IE7

    See a full size Safari 3 screenshot, and IE6 screenshot on Flickr.

    That’s all! Try the example in different browsers to see how it works for yourself (but please don’t blame me for ClearType’s poor anti-alias at larger font sizes).


    We have only a few web fonts with a EULA that permits embedding right now, unless they are free. Please respect the EULAs of any typefaces you try out until the type community resolves the issue for all commercial fonts.

    My feeling after doing this is that EOT has potential advantages in file size over OTF, but OTF files could always be edited (as far as I’m aware) to create subsets just like EOT. Although EOT is not a DRM solution per se, it feels like one. If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long.

    What we need to encourage designers and developers to use EOT today is a good tool to create EOT files in the first place. Perhaps even one hosted remotely, where we can buy a licence, convert the font to EOT, grab the same OTF subset for complaint browsers, and get the work using the typefaces we’ve always dreamed of. WEFT is not the tool right now to enable EOT usage. In fact it discourages it.

    Regardless of what security is implemented, the font file will have to be on the audience’s machine somewhere, even temporarily. ‘Defense in depth’ is a term used by web app security experts. It would seem that the question is how much depth will satisfy foundries and type designers, and what form that depth will take.

    As a designer, I can only speak for myself to say that if OTF and TTF were supported, regardless of how easy it was to steal the file, I would still pay as required by the EULA. I have a strong feeling the vast majority of my colleagues feel exactly the same.


  6. Flipped Types

    Typesetting-Printing Office. Digital ID: 1152640. New York Public Library

    Sometimes, flipping things around can be a useful mental exercise. It can raise a wry smile. An idle comparison between print and web typography was one of those times.

    Imagine this: A client gives you a detailed brief and the content to go with it. You choose the type and design the layout, applying all of your craft and skill to every last detail of the work. With the help of a rendering expert, you specify precisely what device, screen, operating system, colour profile and browser the finished work will be viewed with. You test your work in that environment and make necessary adjustments. It’s distributed to the audience who see it exactly as you expect. That’s print typography.

    Now imagine this: A client gives you a detailed brief and the content to go with it. You choose the type and design the layout, applying all of your craft and skill to every last detail of the work. Two files are given to the audience: one with content, the other with detailed design instructions. They pass both files to their printer. The instructions ask for a specific typeface to be used. The printer may or may not have it, but will never tell anyone, so you specify a few alternatives, just in case. The audience chooses the kind of paper to use, and what size it will be. They also tell the printer what personal preferences they want applied to the design, like making the text size smaller or larger. Your work is printed for them. You never see it. You’ve already resigned yourself to the fact that it will look different for different people. By testing your work in a broad range of environments before you sent it to the printer, you’d like to believe it will look good for most people, and adjust itself gracefully. Not to worry though, someone will probably tell you in no uncertain terms if you get it wrong. That’s web typography.

    Image courtesy of the New York Public Library digital gallery, entitled Typesetting-Printing Office from Working with the hands : being a sequel to ‘Up from slavery’, covering the author’s experiences in industrial training at Tuskegee (1904) by Booker T. Washington.


  7. Twitter :focus

    Tiled background using the letters of 'twitter' to make up different words.

    The preceeding image contains words formed from some of the letters in, ‘Twitter’. They’re not anagrams because not all the letters are used in every word, but it was fun. It’s a seamless tile. If you have a use for it, please feel free under the usual licence. Just out of interest, the typeface seems to be a bespoke variant of Chickens by David Buck (SparkyType).

    I like Twitter because…

    It reminds me is that human beings are still tribal. As an example, if you check your own address book, or think about your family and friends, they probably number no more than two hundred people. We may have more in the book, but it’s rare for our intimates to be greater than two hundred people. Our networks are geographically dispersed these days. Even if your network is mostly in one location, people are so busy living that it can be difficult to stay in touch. Twitter is a facsimile of living and working in proximity for me, and provides something unique, too:

    It may often be prosaic, but I like reading about the daily lives of people I know. The small details of peoples’ lives are often the most poignant. The ambient intimacy is priceless. Working alone in my office, mild doses of cabin fever are inevitable. I miss being around people. I miss being around people I like even more. Twitter brings them to me. If we like people for their good qualities, but love them for their frailties, Twitter helps us do both. Everyday it adds texture to the picture I have of my friends.
    It also introduces people to me I would not have met, and enriches relationships with people I’ve only met briefly. This can’t be understated in developing relationships with people. In many ways, it’s even better than geographic intimacy because I can turn it on and off. Rather than subjecting my followers to every detail of my day which would be painful if we were in the same room, I can moderate what I share. The same is true in reverse. If used judiciously, Twitter is priceless for getting to know people without being intrusive.
    Information comes my way that I’d otherwise miss. The things that are fascinating or important to people I care about or respect are delivered in short bursts. I can’t count how many interesting snippets have come my way through the fingers of those I’m following or followers’ direct replies. It’s akin to hearing people think out loud. There’s a freedom I think we all feel using Twitter that enables us to throw random thoughts and links out to the world. The fact they don’t impose unless the recipient wants them to might be something to do with it. It’s unobtrusive soap-boxing at its best.
    If people have taken the time to follow a person or organisation, the chances are they are interested in what they have to say. However, the intent behind the content is important: There’s a fine balance between self-promotion and self-aggrandisement. One is the personal delight we take in sharing what we’ve done, the other is giving it the ‘big Billy Graham’ to encourage obeisance or be commercially manipulative. I appreciate it when people make announcements or share links that are relevant to me, or a delight to them. The same goes for organisations. But, if it feels like they wish to use me as a witness to their greatness, I always shy away.

    I’d like it more if it had…

    1. UK inbound SMS, again. The recent loss of SMS notifications was a blow. Like many people, I only used inbound SMS for direct message notifications. In the UK, the sender pays for SMS delivery, not the sender and the recipient like in the USA. Twitter had to bear the brunt of all charges; UK companies were too short-sighted to give a decent deal to a service that was extending SMS usage. Hey, it’s not like SMS is their most profitable service, or anything. Consider the amount of data in a single text message and how much they charge for it. For the same cost you probably get about a minute of call time transferring much more data. See what I mean? SMS equals huge profits.
    2. Friend filters. I’d like to be able to add many more people to my list of friends if I could. The truth is, when I’m head down with work, I struggle to keep up with those I follow right now. Allowing me to asign friends to groups and filter groups would enable me to track colleagues and close friends when I’m swamped but also dip into the lives of acquaintances better when I have a spare moment. Another filter in a similar vein is one all Twitter users miss: followers filters to be able to organise follows alphabetically, or chronologically, if nothing else.
    3. Hashtag filters. Hashtags are supremely useful in tracking topics — automatic linking would be good — but they could also be useful in ignoring them, too. Especially around conference time when the chatter can get overwhelming as people organise social stuff and live-tweet the talks. This is not rudeness, just signal versus noise filtering when I’m tethered to my desk.
    4. Link filters. I admit it, sometimes I’m only interested in the links people share. That would make me the hyperlink version of a gold digger, or you could say I love some people for their brain, more than their breakfast.
    5. Full archiving: I use Twitter like a narrowcast journal. The events and moments are worth remembering. Recently the archive got extended to 820 tweets, or 41 pages, but I’m pretty certain the rest are in the database; we just need a way of getting at them.
    6. (Last but not least:) Better use of :focus. Currently, the improved interface has no styles on :focus, and much more seriously, the reply, favourite and delete icons for each tweet are not available at all via the keyboard.

    Today and everyday

    I get more from Twitter than any other social web service. Take today for instance: I found out that Chris broke his toe playing football, Tim got clotted-cream fudge from a colleague, Paulo posted about his transsiberian journey, and Paul and John were spammed. ‘Eureka!’ moments they are not, and I’ve only met two of those folks in the flesh, but that’s exactly why the tweets are so valuable. I feel like I already know a little about people I’ve never met because of Twitter. Everyday life happens all the time, not just in the momentous or unique moments you remember to blog about. Perhaps that’s what Twitter is: the everyday social network.

    With a lot of help from Jon Gibbins my tweets also appear in the asides.

    I use it to watch friends’ lives unfold, and share the events of the day with colleagues. I guess I should say I’m jontangerine on Twitter. Feel free to follow, but I can’t promise to always give you the perfect signal. That’s the beautiful imperfection of Twitter posts though. If nothing else, they’re very honest, and everyone has a different voice. If you haven’t already, you should try it! If you’ve come across it already, how do you find it?


  8. Quotation Marks & Texture

    Single quotation marks pattern.

    In the last entry, I stopped using double quotation marks and started using the single version. Some super-observant folks may have noticed but if you didn’t that’s also a good thing. Permit me to explain:

    The final test for running text is legibility, so failing to notice would mean the style was not imposing on the text. The texture was good. When they occur, stylistic interruptions provide me with food for thought. If the punctuation interrupts the meaning, it demands fresh scrutiny. Double quotation marks seemed to interrupt by emphasising too heavily. Emphasis is sometimes required, but to my mind, with my style of writing, it seemed to impose on the text, altering the meaning by changing the silent voice in my head reading the text.

    Legibility is subjective, and typographers can debate the nuances of style to achieve the best form until the end of time. However, context, typeface, and content are such varied beasts that trying to style them with one set of rules is unnatural, no matter how attractive it can seem. Whatever rules we follow, being consistent is a rule that’s truly universal. Knowing why we use a particular form is another. If we can’t justify a particular usage, the chances are we’ve probably not considered it enough.

    Context is important here. American English is the lingua franca of web design, from the properties of CSS, to the majority of text we read. The best-selling handbook of American writing style, The Elements of Style by Strunk and White, only provides examples with double quotation marks followed by singles for quotations within quotations:

    “This is a quotation with ‘another quotation’ inside it in the American style.”

    However, I’m British. I live and work in the UK. In the UK, double quotation marks are also used, but there’s also a tradition of single inverted commas being used as the primary, with double inverted commas contained within them as needed:

    ‘This is a quotation with “another quotation” inside it in the British style.’

    To my mind the latter imposes much less and suits me much better. I agree with book designer Jost Hochuli in Detail in Typography:

    ‘A more attractive appearance is achieved by using single quotation marks for the more frequently occurring quotations, and the double version for the less frequent occurrence of quotations within quotations.’

    Robert Bringhurst advises us to:

    ‘Consider the face as well as the text when deciding which convention to follow in marking quotations.’

    I agree with him but on the Web a face can change dramatically depending on the browser and operating system that’s rendering it. To my mind, we have to choose an optimal version — Safari in my case — and accept degradation after that. That’s also the case with other punctuation like spacing. I’ve just used hair spaces around the em dashes in the sentence before last, but you will see regular spaces unless you’re reading this using Safari — the only browser I know of that substitutes a hair space from the system fonts if one is not available from the specified face.

    Different languages also have different quotation marks like guillemets («»), and baseline inverted commas used as left quotation marks („); they are in common use in Germany, Russia, and Poland as Piotr Fedorczyk showed me recently. Punctuation within (or without) quotation marks is another topic altogether with a set of rules that depends on context and form. For example, American English puts commas inside. British English puts them outside depending on whether or not the comma (or full stop [period], or exclamation mark) is part of the quoted text.

    My view is, whatever style we choose, we should know why, and be prepared change it if necessary. Any rules we apply should aid legibility. Web typography is immature; the constraints and opportunities of the medium may take us down many different paths but the goal of legible, beautiful text is constant.

    Good typography in running text is subtle and ambient. It enhances the text without interrupting it. It delivers meaning with clarity. In books, speech is mainly quoted in single marks. It’s a light touch. The typography removes itself from the picture being painted in our minds, and by doing so, allows it to shine. I’d like to achieve the same kind of light touch, here. I doubt my text will shine, but at least the typography will not distract you from my thorny prose.


  9. Review: Detail in Typography by Jost Hochuli

    Detail in Typography by Jost Hochuli (Hyphen Press, 2008)

    The day was only two hours old. It already felt ancient. I was writing proposals in my little office at home. The snick of the letterbox broke the tedium. A package had arrived!

    Package from Typotheque

    Inside was an array of delights from Typotheque: Specimen No. 5 of their History project, specimen books for Brioni and Greta, and last but not least, the revised edition of Detail in Typography by renowned book designer, Jost Hochuli. Nice!

    Detail in Typography was first published in 1987 in German. The translation was released this year by Hyphen Press. It discusses ‘microtypography’ — the fundamentals of legibility; everything from how we read, to analyses of letters, words, lines, linespacing, texture, and the qualities of type. In the first chapter, Basics, Jost Hochuli writes:

    ‘These are the components that graphic designers like to neglect, as they fall outside the area that is normally considered as “creative”.’

    The writing is beautifully tight. It’s 61 pages long including references and notes. Almost every chapter has rich examples lighting up the prose, which is crisp — a credit to both the author, and the translator, Charles Whitehouse.

    What I loved about it was the soft tone. No bombastic dogma, but an insightful discourse into the details of legiblity. The second chapter introduces saccades or saccadic eye motion; the science behind how we read and understand words. From that moment I was hooked. Re-reading it when writing this, I’m hard-pressed to find highlights. Every chapter is a highlight. Perhaps two points that stood out for me are:

    1. Hochuli explores how research shows that people don’t always need to see the whole letter in order to read the word: ‘the upper half of the letter is sufficient’ — ‘this would put most sanserif faces, and particularly those with the simple form of a, at a dissadvantage against classic book types’.
    2. He also explores what he terms ‘optical facts’ as opposed to optical illusions. How, when certain mathematically precise forms like circles and squares are components of type, they distort the letterform, and therefore the word, line, and the texture.

    I found the typesetting and presentation of the book a little awkward. I found the quality of print discordant with the quality of prose. Some lines are interrupted by a page spread or verso of examples. It’s beautiful in content, but not necessarily in design.

    Inside Detail in Typography by Jost Hochuli

    Any minor criticisms I have do not detract from the superb content. The relationship between cognitive science and microtypography is precisely drawn. It inadvertently demonstrates just how far typesetting on the Web has to go before some of the aspects of fine typography can shine. I found myself constantly wondering what it would take to apply the principals on the Web with CSS; for that alone, it was a great read.

    Detail in Typography is available direct from Hyphen, or from Typotheque with specimens as part of their package, and ineviatbly, lots of other places.


  10. Early Reflections on Google Chrome

    Google Chrome screenshots

    The world is abuzz with the imminent release of Google Chrome today. The screenshots on CNet were apparently from the new site that was live for a short time. The news slipped out (or leaked) when, according to the Google blog, they “hit ‘send’ a bit early” and released the Google Chrome comic strip prematurely.

    The comic is a great piece of work by Scott McCloud. It’s a gold-mine of interesting propaganda, and I’d love to link to some of my favourite sections but there’s a critical failing: none of the pages have a permalink! Some kind soul has taken the time to republish the strip so they can be linked although the site was slowing down already when I last visited.

    Does the world need another browser? Do we need another browser to test our work on? Those seem to be the questions I hear first. However, Chrome is built on WebKit, the open source engine that also powers Safari. Safari is also my browser of choice right now — WebKit passes the Acid 3 test and Safari has the best font rendering of any browser I’ve tried — so that gives me hope. Also, Chrome will be open source, and with a few new ideas may push browser science along a little bit in a good direction, especially around security, performance and the UI.

    When I heard the name, it reminded me of the DHTML tricks we used to use way back to remove the chrome from the browser window — effectively stripping it of everything that wasn’t content. Google has said:

    “We don’t want to interrupt anything the user is trying to do. If you can just ignore the browser we’ve done a good job.”

    I do a pretty good job of ignoring the browser already. However, there are problems we’ve all been working around for a long time that Chrome wants to solve. Most of the advances have a visual metaphor in their approach to tabs. Here are some of the things that caught my eye:

    The tab is king

    Tabs will be at the top of the browser window as they are in Opera, making utilities like the address bar part of an individual tab. It makes sense to me: Often I find, when talking to less technical people and trying to get them to go to a URL, they’re so used to ignoring the address bar that I have to help them find it before they can start typing. Google don’t have a URL box though, they have an “omnibox” that does everything from remembering visited URLs to giving search suggestions and allowing us to do free text history searches. It also does autocompletion. The comic strip explicitly mentions getting this right but, just in case it doesn’t, I hope autocomplete can be toggled off.

    In Chrome, the browser controls and URL box are explicitly associated with that unique tab. Everything associated with the site open in the tab is contained within it so it can be moved or detached completely from the window.

    However, people often ignore the page title, too. In the past, this has led to all sorts of wacky, useless and inaccessible page titles being used by developers to stuff keywords or just have fun. I would of liked to have seen the page title better associated with the viewport, and visible in full, not just as part of the tab label.

    Oi, JavaScript, stop!

    How many times does an errant bit of JavaScript slow down the browser to a crawl and sometimes even crash the whole caboodle? Too many times. Chrome has a whole new JavaScript virtual machine dubbed V8. It also claims a multi-threading approach that sandboxes each individual tab so it won’t affect other open tabs, which allows us to close it and kill the process if it’s getting out of hand. They’re also giving us a task manager to enable us to see which tabs or plugins are causing problems by seeing the processing running and how much memory they’re using. Sounds good to me.

    Confined pop-ups

    Chrome will associate pop-ups with each individual tab, and confine them within that tab unless people drag them out to become a new window; an enhancement to just blocking all pop-ups altogether when some are used for legitimate purposes.

    Default tab page

    When a new tab is opened, Chrome will open a tab page with nine of your most visited pages, search history, recently closed and bookmarks. It sounds like an evolved version of Opera’s Speed Dial (Flash demo), that automatically populates the holding page by default.

    Site-specific Chrome

    Taking a lead from apps I find incredibly useful like Fluid, Chrome will allow site-sepcific browsing to access sites like Google Mail in a streamlined window. Hopefully, we’ll be able to do that for any URL, and create icons in much the same way I can with Fluid now.


    Chrome would seem to take sand boxing to its natural conclusion, isolating individual sites from any other open tab, and not allowing access to anything without user permission. I’ll be interested to see what the web app security experts say about this, especially in relation to XSS and CSRF attacks. Chrome will also continually download blacklists for phishing and malware sites and warn users when they visit them. Those lists will also be open source.


    I can’t talk about a new browser without mentioning typography. The WebKit rendering engine already gives Chrome an advantage to build on for web type. All I want to say is that I hope they take a lead from the great work being done with things like @font-face support, and keep a beady eye on the most important thing a browser has to do: help us read. Hopefully, nothing in Chrome will limit the fine work the WebKit team are doing to make hinting, anti-aliasing, grid-fitting and hyphenation as good as they can be. Chrome will be released for Windows first. I’m looking forward to see how it reads, but how it integrated with OS X’s native text rendering will also be very interesting.

    One thing is…

    Google Chrome has already changed the browser landscape and it’s not released yet. We’ll see if all the web application savvy at Google Inc. emerges in the browser — I’m looking forward to it. After all, if we can’t just have one very good browser to design and develop for (oh, what luxury that would be), we may as well have another using WebKit — a rendering engine that’s committed to standards support, is open source, and doing a fine job already.


  11. Typeface != Font

    Typeface and font.

    A typeface is not a font. A font is not a typeface. It’s been said before, but confusion still resigns supreme; even the Online Etymology Dictionary and the holders of the rights to Georgia get it wrong. So, at the risk of stating the obvious, but in the hope that someone might find this useful, I’m going to attempt a little disambiguation.

    Define: Typeface

    A typeface is designed by a type designer. I think of a typeface as the design of a type family. Like every family, type families have names. An example of a type family name is Georgia. Georgia is a type family — a typeface — not a font.

    Typeface = a type family’s design

    In many non-European cultures like the Chinese, the family name comes before the personal name. For example, my Chinese name is Tan Tek Whah. “Tan” is my family name. “Tek” is my generation name. “Whah” is my first name. The last two are identify me personally. The same is true for fonts. They have a family name (typeface) and personal names (style, variant, size) that identify them uniquely within that family.

    Define: Font

    To understand why a font is not a typeface, it’s useful to know where the term came from. Here’s a (very abridged) bit of history drawn from various sources:

    Font (or previously, fount) is derived from a Middle French word, fonte, meaning something that has been melted. In type founding, metal was melted then poured into a hand mould with a matrix, to cast each individual piece of movable type, known as a sort. Font, fount and fonte have a common ancestor in the Latin word, fons, meaning spring or source (of water). They are all related to the word, fountain. So, now you might be able to see why “font” is a word that describes a variant of a typeface, and a container for casting water on Christian babies’ heads.

    Everytime a specific variant of a typeface was cast at a specific weight, a font was created. Therefore, a font is a particular casting of a typeface belonging to that type family. In electronic publishing nothing is cast, but fonts are still digitised from the design created by a type designer.

    Font = one member of a type family

    In my mind I think of a font as a variant of a typeface.

    Spot the heading error in the Georgia page by Ascender Corp, licensees of the Georgia typeface.

    Using the Georgia typeface example, the “Georgia Regular”, “Georgia Italic”, “Georgia Bold”, and “Georgia Bold Italic” in my library are all fonts of the Georgia typeface.

    Wait though, we’re not done! A font was more granular than just the variant of a typeface: Each size of those variants would, historically, have being cast individually. Therefore, a font is actually any variant in a typeface’s size and style. For example: “9pt Georgia Bold Italic” is a font as is “12pt Georgia Bold Italic”, and “9pt Georgia regular”.

    Electronically evolved terms

    These days, rather than casting specific sizes, we hit a button and the typeface variant changes size. Size has ceased to be so important because changing it has become so easy, and we don’t have to buy typefaces at different sizes. So these days, even people who understand clearly what the word “font” means have been known to use it to just describe a variant like Georgia Italic, or Helvetica Bold Condensed Oblique without reference to a particular size. That seems like a fairly logical evolution of the term to me.

    Why is this stuff important?

    Well, compared to world peace, it’s not. However, nomenclature is important because being understood is important. Struggling with my own ironic typos and awful spelling makes me doubly aware of this. There’s another reason too. I’ve been delving into the font module of CSS for a series of articles and reminded myself how confused the terminology was. The absence of the term, “typeface“ and certain uses of “font”, seemed strange to me; font-variant in particular makes no sense.

    Hopefully this explanation makes a little more sense, or at the very least, gave you an insight into Chinese naming conventions.


  12. Elastic to… Russian Elastic

    Illustration of a man standing by an anvil.

    It’s been a Russian-flavoured week so far. First came a bit of grappling with the dire unicode support in Fireworks CS3 for Andrei’s Russian-themed twitter background. More on internationalisation — or i18n for the cool kids  —  later. Suffice to say, for a bazillion pounds a license Adobe could get it right, and the core web fonts that don’t have Cyrillic glyphs are suboptimal when I’m trying to post Russian.

    However, the real purpose of this rambling post is to announce that the em and elastic layout article has been kindly translated to Russian! My thanks go to the volunteer efforts of Nickolas Loiko of CSSMake. Thanks Nickolas!

    Next up, I’m expecting a visit from Putin to discuss Georgia with me by accident. I will, of course, redirect him to Ben Ramsey, who’s Georgian all over, or so goats have led me to believe. Just to show how anything can be made into a happy co-incidence, Georgia visited the Welsh last night and won 2–1.

    Any more from me and the confusion will get ridiculous. Therefore, I’ll be going now.


  13. Events & The Favour Bank

    SXSW 2009.

    Have you ever heard of the Favour Bank? It’s a derivative of karma, using an obviously capitalist metaphor, but Paulo Cohelo used the phrase in his novel, The Zahir. That’s when it first grabbed my attention.

    “Zahir” is an Arabic word meaning visible, evident, obvious, or always present; an obsession; that’s what the novel is about.

    The Favour Bank is something we are all aware of. According to Pablo, we withdrawl from it by receiving the help of friends and contacts when we’re starting out. We also deposit in it by helping others later, after establishing ourselves. Hopefully we end up in credit. An example might be Jeff Croft’s intention to highlight the work of less well-known people who aren’t the usual suspects, but are still doing great work, regardless. I try and do the same in my asides and rare posts. Hopefully you do, too.

    I mention the Favour Bank because it fits neatly with a two events happening over the next few months; both might put all of us in credit at the Favour Bank:

    1. Web Developer’s Conference, 2008

      The Watershed, Bristol, UK. 12 November, 2008.

      This is a conference run by, and for, the students on the Web Design degree course at the University of Western England (UWE). It’s an opportunity for them to meet and mix with industry professionals. There’s some interesting talks by folks such as Patrick H. Lauke. I will be on a panel discussing working in the Southwest with Joe Leech, Rick Hurst and Peter Coles. As of writing this, my profile hasn’t been added to the panels page but everyone else is there, so there’s much more interesting stuff to read.

      The conference is free to attend, and based on last year’s event, should be fun and interesting. If you’re around at the time, consider popping in.

    2. South by Southwest (SXSW) 2009

      Austin, TX, USA. 13–22 March, 2009.

      This time I’m asking for your vote for our typography panel, Quit Bitchin’ and Get your Glyph On. It will be hosted by Samantha Warren, and fellow panel members will be Elliot Jay Stocks, John Boardley, and Ian Cole.

      We’ll be discussing web typography and I have a sneaking feeling that there will be some very different views on the panel so it should be fun. There’s also a fair amount of experience and passion there, too. So, if you can join us I’d love to see you there, but even if not, your vote would be very much appreciated! To vote, go to the panel picker page and either cast it, or quickly sign up to give us a thumbs up. Thanks!

    In other news…

    Locally, BathCamp is happening on the 13th and 14th of September at Invention Studios. I’m going to try valiantly to make it, and drop some typography musings on the unsuspecting crowd, but there’s already a heap of people going so it will be a fantastic day of geekery regardless. Keep in mind, according to BathMaster, Tim Beadle, any talk you give doesn’t have to be technical. Someone gave a talk about growing veg last year; it’s just a chance to geek about your areas of expertise in front of an audience who will appreciate the geekiness of it, no matter what.

    Away from the Southwest, Scripting Enabled takes place on the 19th and 20th of September at the Metropolitan University of London. It’s a two day “conference and hack day” that aims to break down the barriers between disabled users and the social web. The first day will be a summit to discuss and identify the barriers with anecdotal evidence from disabled users. The second day will try and solve some of them — especially in regard to existing sites  — with a hackathon. Sounds like an event bursting with social karma, and thus, very cool. My accessibility lexicon and good mate, Jon Gibbins, will be in attendance, too. I’m tempted to ask you to heckle him if you see him, but I think I’ll reserve that right for myself.

    If you know of any other interesting events coming up, feel free to share them by throwing the relevant HTML in the comments. It’s all good credit in the Favour Bank, or good karma, or however you want to describe the wonderfully seductive and aspirational concept of mudita.


  14. OSCON 2008, the Year of the Butterfly

    Writing this is my way of remembering my first OSCON. It’s also a good way of taking a break from the research I’m doing into the next web typography post. I’m also a little frazzled by moving house, and a recent period of sleep depravation after my eldest son’s operation. This is my therapy.

    The stage

    Sometime in the very early hours of Monday 21st July, after leaving New York nine hours earlier and being tortured by JetBlue and JFK, Chris and I arrived at the Doubletree in Portland. It was balmy. After the tropical heat of New York, to be cool was a treat.

    The next morning I got chance to explore a little. The center of Portland is a good place. The free tram is a great idea. Tree-lined avenues break up what would otherwise be a sterile business district into human-friendly spaces. You can walk around the city. That might sound like a strange statement to make but, in my experience of the States so far, a walkable city is exceptional enough to highlight. OSCON takes place for a week at the Oregon Convention Center which sits on the Willamette River’s east bank. A pair of glass pyramids and spires call the faithful to prayer from above the main entrance. Architectural comparisons with cathedrals and palaces are hard to resist. The pyramids reminded me of the Louvre in miniature. On closer look, the spires almost seem like an afterthought. OSCON only took up the south end of the centre. In the eery quiet of the other empty concourses a dragon boat and pendulum wait in patient suspense for admiring glances.

    Players & acts

    I’m averse to some of the more negative aspects of professional conferences. Sometimes, I get a sense of some people’s innate self-consciousness that can go one of two ways in the social mælstrom: Quiet humility that should be treasured, or competitive haughtiness attempting to mask insecurity. The latter is suboptimal. OSCON has almost none of it. Thanks to Chris, from the moment I stepped through the door, to the last night, I seemed to meet a whole bunch of people who were comfortable in their own skin, and with their own proclivities. They even accepted mine. There’s nothing so pleasant than having good things to say about people one meets. These of just a few of the characters:

    The mighty Wez Furlong was possibly the busiest man at OSCON, giving three talks, and sharing his PHP / Cocoa explorations with the world. His obscure cultural reference library is almost as smart as his code, which is saying something. Andrei Zmievski has rightly been called the social director of OSCON before now. He has a unique ability to organise dispersed techies into a night out, and find the best food and drink. Like Wez, he’s also a core developer of PHP; multi-talented like most of the folks I met.

    It was great to meet the Funkatron (Ed Finkler) too; security dude, publisher of a rather fine blog, and Spaz developer (for all of the Twitter fans out there). The Chay, first name Terry, arrived late during a great Tuesday evening at the Doug Fir. Another person who, like Ed, I’d only known via the Metaverse before. Watching Terry in live debate around Rails and PHP was a gift, flavoured with some choice vitriol, and prepended with some Physics.

    Ben Ramsey also contributed his fair share of choice phrases to that particular evening, too. He went from custard to goats to communism, all within the space of two mis-interpretations, and the unique Ramsey filter that emerges to great effect when the sun goes down. Elizabeth Naramore of PHP Women and the forthcoming PHP Appalachia conference also kept me company one Thursday night in the Vault. We put the world to rights, and lamented the joy and pain of younglings. The Vault was also the place of more Ramsey mayhem and obscure cocktails. They included a strange take on the Mojito with lemon grass, a favourite of the beatific Marcus Boerger of Google.

    Mint Restaurant, Portland, Oregon.

    The person who starred in my best picture of OSCON, was security and PHP guru, Damien Seguy. On a mis-guided first attempt to find Mint, the best restaurant in Portland (truly), Damien brought his elephant along. Arguably, his elephant had more directional smarts than us that night. I visited Mint three times during OSCON. Andrei took us there the first time (hence his accolade for finding good food.) Chris and I also dragged his royal amusing contrariness, Theo Schlossnagle there as he flew into town, assaulted the world with his brain (and huge velcro-covered lens) then departed. The third visit topped them all with an en-mass invasion after a glorious afternoon at Brewfest on the Friday. Apart from the strange Brewfest wave of sound — a cheer that started nowhere and undulated around the tents — and the excellent beer, the evian-esque gigantic atomiser was a person favourite. Who would of thought to put an urgency-inducing sprinkler system just before the queue for the loo?

    I also got to spend a bit of time on Friday with those excellent equestrians and technical authors, Luke Welling and Laura Thompson of OmniTI and Mozilla, respectively. Earlier that day, Luke and I shared the affirming experience of donating to the Electronic Frontier Foundation. For me, this was partly to support the EFF’s help for people like Luke, who’s currently dealing with a ridiculous attempt by confirmed spammer, Jim Mirkalami, to sue Luke after he re-published information on his blog that was already in the public domain. Anyway, we got the tshirt, and it was good. After such great company, great food, and drinks, Mint is definitely in my top two Stateside restaurants so far, along with Gen in Brooklyn (it has incredible Japanese-Rastafari sushi). Later that night, Chris and I said a fond farewell to Mint, jumped in a cab and headed to the airport via the Doubletree to soar back to Brooklyn on the red eye. An apt name, for sleep was not forthcoming. After a few hours rest in Chris’s place on Saturday morning, I dragged my bags into town for present shopping. I fell into another flight that evening and landed back in Bristol and the beautiful embrace of my tribe on Sunday morning. Knackered is an understatement. Then we moved house four days later.


    If this post is packed with names, that’s because OSCON was all about the people for me. I haven’t mentioned everyone I met (just those I spent most time with), and didn’t manage to attend many talks, but the atmosphere alone was worth the trip. Chris Shiflett and I gave a talk on experience-driven development which took place on Thursday. A good thing, because some of our best ideas dropped into slides on Wednesday afternoon. It was fun, but still a little raw in its first outing. We got some great feedback—almost all positive—so hopefully it will have more meat and equal amounts of fun the next time around.

    OSCON was a blast. Here’s my OSCON ’08 Flickr photoset if you’d like to see a bit more. It was superbly organised, at a great venue, with some of the best developers in the world exchanging mental energy for a conference pass. Details make big ripples when it comes to conferences. Details like the fantastic help of Shirley Bailes — O’Reilly’s conference speaker manager — who even offered to send me this year’s butterfly t-shirt after I forgot to grab one while I was there. If you wondered at the title of this post, there’s your answer. I only met a handful of people out of the three thousand or so who attended, but they made it great for me. I encourage everyone to consider going in years to come. With luck, I’ll see you next year!


  15. Collaboration at OSCON ’08

    OSCON 2008

    In just under two weeks time I’ll be delivering a joint talk with Chris Shiflett at OSCON, the biggest open source convention in the world run by O’Reilly. It happens to be my first time at OSCON, as well as my first talk. It also happens to be OSCON’s 10th birthday. Needless to say, I’m a little nervous: First, at the privilege of speaking in front of such an erudite crowd at such an important event, and second, because losing your cherry is always nerve-wracking, unless you’re drunk.

    Just for the record, I have no intention of being drunk.

    It was Chris’s idea. He thought that our working process was valuable enough to share. I’ve really enjoyed the way we’ve worked together over the last couple of years, so thanks Chris for suggesting we talk about it.

    Our talk will be about collaboration, what we’ve called experience-driven development. We’ll be exploring how we can do our best work, and enjoy the relationships and processes that get us there, no matter the size or complexity of the project. I don’t want to give anything away, but hopefully it will be fun as well as informative. With a bit of luck we’ll leave folks with some food for thought to take away with them and re-heat later.

    The talk will take place on Thursday 24th July from 10:45am to 11:30am in room E145. If you can make it, I’ll see you there! Also, let me know if you’re going, and feel free to come and say hi anytime. I’m looking forward to meeting people and generally soaking in the vibe! If anyone is considering grabbing a last minute pass, and could use a 15% discount, contact me. You don’t have to come along to our talk, but we’d love to see you.


  16. No. 172

    Number 172 on the wall outside the front door.

    When I woke this morning it seemed like any other day. The sun was shining. I liked that. The boys were mischievous. I liked that too. Nothing seemed out of the ordinary. Then I remembered: Today we get the keys to our new house.

    Our new house is on a narrow street in Montpelier. When we arrived it felt like coming home, which it is in a way. The area’s old streets are more suited to horses and people than cars, regardless of the lines on the roads. Montpelier undulates up a hillside, at the top of which Cromwell once stood directing cannon fire onto the city during the civil war. It was market gardens then. It was, according to local legend, given its name by prisoners of the Napoleonic wars who said it reminded them of Montpellier in France. In Bristolian Montpelier, sandstone-faced Georgian houses sit next to ancient cottages and Victorian terrace town houses. Our house is one of the latter. More square than usual, on one of the lower streets, with a grape vine, a pear tree, and a passion fruit bush in the garden.

    Looking out of the back door at no. 172.

    Number 172 is special for a few reasons. It’s the first house we’ve bought. Years ago, when friends were busy being career super-heros and I was busy being a itinerant vagabond I wondered if I would ever put down roots . They were buying houses. I was off to Australia on a whim, or living in The Seychelles, or running a stall on Brixton market for the summer playing French hip-hop and selling sunglasses. Until today I’ve always rented places. I fell in love with some. I fell out with others. I was always moving around and moving on. No longer!

    Another reason is that this marks a return to Montpelier. An area I fell in love with when I first came to Bristol in 2000. Artists, musicians, film-makers all paint the walls, eat a lot of organic food, smile a lot, and generally act as a band-aid on the wound of capitalism lest the world forget that life is much, much more than paying bills and buying Apple gear. Architects, hippies, designers and fiends also live here. It’s an oasis of difference: From Herbert’s Bakery to Saj’s grocers; from veggie breakfasts at The Bristolian to the friendly smell of weed in The Cadbury garden and deli feasts from Licata’s; Montpelier is special. I’m glad to be home.

    The final reason, and most important of all to me, is the most prosaic. This is ours. A family home that we own. It feels different. A calm kind of contentment.

    As I sit writing this, the day is quickly coming to a close, and I wanted to mark the moment. As the States celebrate their independence, we’ve celebrated our own in a small way. I took some pictures. It was a wonderful day.


  17. The Paragraph in Web Typography & Design

    Paragraphs are punctuation, the punctuation of ideas. After selecting a typeface, choosing the right paragraph style is one of the cornerstones of good typography. This is a brief inquiry into paragraph style for the Web.

    To collect my thoughts I put together a rough page of examples. I was interested in openings and texture more than font style, so they all share the same basic copy, typeface, size, and leading (line height). It was mostly for my own reference and will change over time, but you’re welcome to take a peek:

    Typographers use layout techniques like single line boundaries, indents, outdents and versals (drop caps etc.) to punctuate paragraphs in a stream of discourse. Block paragraphs are common to the Web, indented paragraphs are common to print. Browser vendors gave us a default block style of flush left, ragged right with a single line boundary, but there are many variants we can pick from depending on the context.

    In any project, the text itself will have its own tone, rhythm and meaning. It’s our job to provide it with a stage on which to sing. Typography serves the spirit of the text, bringing it before an audience, and then quietly fading into the background as the reader delves into the meaning. As Ellen Lupton says in Thinking with Type:

    Typography is a tool for doing things with: shaping content, giving language a physical body, enabling the social flow of messages.

    In the Web era, designers create narrative spaces made up of text, images, video, etc. We add context and legibility to those formats. We also create spaces where people express themselves. We work with enacted narratives where the content is already available, and emergent narratives to be created over time. Instead of just styling symbols, we’re styling bytes in fluid narrative spaces. We’re bytographers; literally, the writers of bytes, not just glyphs. Yet still, at the heart of this explosion in publishing, is the humble and beautiful paragraph.

    From paragraphos to paragraph

    Punctuation is a word derived from the Latin punctus, to point. Punctus is also the precursor of the period, or full stop. Punctuation was called pointing in English. It was used to indicate pauses or breaths until the 16th century. Punctuation as syntax didn’t emerge until the Renaissance.

    A paragraph was historically a punctuation mark. According to the Online Etymology Dictionary, the word paragraph has roots in the old French word paragrafe from modern Latin paragraphus or “sign for start of a new section of discourse”. That in turn is based on the Ancient Greek word paragraphos, a “short stroke in the margin marking a break in sense". The great reference of the 20th century, the Encyclopædia Britannica says:

    In the oldest Greek literary texts, written on papyrus during the 4th century BC, a horizontal line called the paragraphos was placed under the beginning of a line in which a new topic was introduced. This is the only form of punctuation mentioned by Aristotle.

    This fragment of a parchment scroll shows a paragraphos (a) indicating the line where the new paragraph starts with a break in the text (b).

    Source: The ‘Textual Mechanics’ of Early Jewish LXX/OG Papyri and Fragments by Robert A. Kraft (University of Pennsylvania), The Manuscript Fragments, s.5: parchment roll, ca 100 bce; Rockefeller Museum, Jerusalem.

    Parchment roll fragment

    Medieval punctuation employed a paragraphus—also known as a “‘gallows-pole’ or upper-case gamma, or § (later ¶)”— to separate ideas in a running discourse.

    White space did not punctuate paragraphs until the 17th century. This was the era of Ben Jonson’s English Grammar, where he recommended the use of syntactic punctuation. Around that time, the practise of indenting the first line of a paragraph became part of our standard syntax, along with the use of capital letters for the start of a sentence, and the use of a space between words.

    Technology & cost influencing style

    Materials and technology have always influenced calligraphy and typography. Papyrus was used from the 4th century BC. It was brittle, so papyrus was rolled instead of folded. Parchment codices became more popular in the 5th century AD. The finest parchment was vellum, made from the white skin of a calf. Next came paper: Invented in China in the 1st century, the first latin text was written on paper around the 10th century. By the mid-15th century it was becoming dominant. Johannes Gutenberg printed only 45 copies of his Forty-two line Bible on vellum, using paper for the remaining 135 copies because it was cheaper.

    During the industrial revolution in the 19th century, cheaper wood-based paper emerged along with steam-driven paper making machines. Intuition tells me that also influenced typography. By the turn of the 20th century paper was cheaper than ever before. The cost of inserting a single line of white space between paragraphs—the most common style today—would have reduced. The emergence of the consumer society and rise of advertising also encouraged a change in typographic style. “Fat face” display type was created for bills and advertisements; hyperbole became a style of visual layout. Before the 19th century, the insertion of a full line of white space between paragraphs would have surely been decadent. Perhaps that’s how it became commonplace. However, this is speculation; I cannot find reference to how it became prevalent, so would welcome further evidence.

    The single line boundary is the most common paragraph delimiter used on the Web today and the most common browser default style. Generally, the indent is still the most prevalent paragraph delimiter in printed books and publications. In some ways, the block and indent styles exemplify the divide between Web and print. Printing cost is still a consideration looking at some of the mistreated text in certain paperback books, but printing on a screen effectively removes cost as a factor. Usability is the only currency by which web typography is measured. That’s what we’ll explore next.

    Paragraphs in a narrative space

    The narrative space of a web site is where a story develops as a person navigates the site. This should not be confused with narrative as a text-type. However, in some cases, it does share some characteristics like a chronological order. For example, a blog is a narrative, no matter how broken. It has a chronological order (albeit reverse). Even though a blog has multiple entry points, it can still contain a chronological story. The chapters in that story (entries) may be any one or more of the traditional text-types {narrative; descriptive; argumentative; expository;} but they all form the narrative space of the site.

    The narrative space within a web site is made up of three components: content, layout (style and context), and information architecture.

    Further reading:

    1. Mark Bernstien writing in his mis-spent youth about narrative on A List Apart

    Web design narrative can be compared to architectural narrative: The design of an environmental experience from multiple viewpoints in time and space. Visitors experience a web site in much the same way.

    Web design narrative can also be compared to narrative in game design: both create the narrative space via a screen.

    In both comparisons, the experience of the narrative space is more than just style and technology. In fact, style and technology are tools to create the user experience. The experience of moving through a narrative space on the Web is complex. We understand that people may arrive in that space from any direction and context (referrer). They may be confronted when they arrive with any number of artifacts that convey narrative information (navigation, main content, calls to action, etc.). Any paragraph style must consider context as well as the meaning of the text.

    Thinking about paragraph style

    The way we approach the design of a narrative space on the Web is manifold. In most cases the content is not already available. If it is available, it may be subject to revision as part of a redesign process. The vision of the brand and the purpose of the site can seem clear, but may not be upon further investigation. Sometimes, our job as designers is to help refine both the vision and content. It’s during that stage that we explore layout and get a clue to the context in which the typography will live. We call it experience design. Only after that do we get down to experimenting with style.

    The context, meaning and tone of web copy should always determine typographic style. Reading the text in full—or at least understanding what the text might be before styling it—is a pre-requisite. A common mistake is to allow the design to dominate the text: Design for design’s sake, or even worse, fashion’s sake. The text is made subservient to the canvas that the designer wished to paint on the screen. This is exemplified by the proliferation of fun, but ultimately harmful, web design galleries. Once a user muscles past the gag reflex, or stops admiring the amazing graphical decoration, they can often realise the design is in their way. The content is obscured. The narrative space becomes broken into fragments, like pieces of torn parchment linked tenuously together by calls to action, or a nested index of links called a menu.

    Good typography makes the canvas fit the meaning of the text, not the other way around. It paints pictures with form that enrich the meaning of the words with colour, texture and movement. It is illusive, subtle, and ambient. It’s the shirt that engages from a distance. The closer you get to it the better it seems, but it takes a moment of reflection to even realise why. Robert Bringhurst says it beautifully in Elements of Typographic Style:

    One of the principles of durable typography is always legibility; another is something more than legibility: some earned or unearned interest that gives its living energy to the page. It takes various forms and goes by various names, including serenity, liveliness, laughter, grace and joy.

    When trying to energise paragraph text, meaning and context are the most important factors to consider. Meaning flows from the author. They are trying to share a message, a thought, an idea. Context belongs to the audience. They are trying to understand, extract meaning and find relevance. They’re doing so in the context of their own requirements, but also in the context of the page layout and the wider architecture of the site. A refined sense of empathy will help you find the right form for your paragraphs, if user testing cannot be part of your process.

    Choosing a paragraph style

    There are no hard and fast rules for paragraph style for the Web. Choosing a style depends on all the factors we’ve previously discussed. The 12 example styles I threw together are just a starting point and all paragraph styles need testing in context.

    You may find this place holder markup useful when testing styles.

    All browsers have good support for basic paragraph styles. However, complex treatments of versals and openings can be problematic. There are still browsers with immature standards support when it comes to using techniques like pseudo elements and adjacent sibling selectors. Our ability to specify fonts for body copy is also limited, and inconsistent rendering across platform and browser persistently frustrates creativity and precision. There’s still a lot to work with, though. Here are a few examples, some new and some that are aging beautifully:


      Rob Weychert used indents to wonderful effect in his Across America diary with text set flush left and ragged right. He also uses a deft combination of indents and small-capped openings in his blog posts. Both are a pristine example of using indents to compliment his particular style of writing. Truly a great example of bringing a love of print to the Web.


      Ed Finkler mixes a font stack of Palatino and Palatino Linotype with boundaries that perfectly suit his content. He publishes a mixture of material that’s often technical, so boundaries help delineate the technical writing for skim reading, while the larger size and typeface adds great texture to his site. For the technical material I might have defined sub-heads a little more, but his choice of paragraph style is instinctively good.


      Andy Rutledge treats paragraphs with love. On his home page, extracts from the three latest posts descend in a beautiful hierarchy of size and tone to indicate the chronology. Individual posts also cascade gracefully. Boundried blocks define his thoughts with great clarity. His material is often instructive, so this style perfectly suits the content.


      Cameron Moll indents paragraphs and uses boundaries. This could offend pedants in print but I find it wonderfully pleasing on the Web. His material is often educational so the division of points by boundaries helps legibility. However, one of the main reasons this style works so well is the font size: it could seem small but the indent with a boundary allows the text to breathe and adds great poise and texture.

    A note on indents

    If you choose to use an indent, stylistic tradition suggests that there should be no indent on a paragraph that follows a head or sub head. Tradition also suggests there should be no indent following elements like lists and blockquotes. You can achieve this without extraneous markup using adjacent sibling selectors. For example, if you have already set an indent on your paragraphs:

    p { text-indent: 2.5em;  }

    Then, to stop any paragraphs following a heading of rank 1–3 having an indent you can set:

    h1 + p, h2 + p, h3 + p { text-indent: 0; }

    However, I would caveat that with only if the blockquotes and indents are set flush left with hanging punctuation. Robert Bringhurst suggests: “If your paragraph indent is modest, you may for consistency’s sake want to use the same indent for quotations.” I agree, and I think the same can apply to lists on the Web. In both cases, a boundary is required to separate the list or blockquote from the surrounding paragraphs.

    A note on blocks

    If you choose a block style with no indent, but with boundaries between paragraphs, tradition suggests that there should be no indent on either lists or blockquotes. As you may have noticed from reading this article, I don’t always agree, especially on the Web. It depends on the content and the balance of elements. In certain instances, lists and blockquotes might be used to punctuate the running text, which can help people skim read on the Web.

    Web != print

    People experience the Web differently to print. The Web is not linear; in print people most often read sequentially, from front to back. They may flip, looking for something that catches their eye. After an initial look, they may skip back to interesting items using a table of contents or an index. On the Web this is reversed. Skipping to a certain page via the menu is habitual. This has been encouraged by bad design and web copy writing where inline links in the running text are sparse, if available at all.

    Skim reading is the norm on the Web. It may well even be the case that skimming is normal everywhere, it’s only when we become absorbed that we digest the meaning of the text linearly. It’s a way of filtering the noise in a page to try and get to the content of interest. However, this has become essential because of bad design; pages have been confused with intrusive advertisements, overbearing calls to action, and layouts that don’t serve legibility. It has forced people to skim, whether they want to or not. Better designers refuse such harmful techniques. Getting layout and content right in prototyping is essential.

    Careful choice of paragraph style (and other body text forms) can accommodate all of the differences in audience behavior and expectations. The optimal paragraph style you choose in summary pages may not be the optimal one for dense, detailed pages. A subtle change may well be necessary in different sections of a site. Choose judiciously, but most of all, designers should know why they are choosing a particular form; “because it looks good” is not a good reason on its own; “because it feels good” may well be.


  18. Reflecting on Acceptance

    Caffe Gusto on Bristol harbour

    You might already know that my entries are mostly about design with a few personal perspectives that peep out between the lines of prose. Sometimes the personal might take over. Today is one of those times. Apologies if you’re used to seeing more professional material in my feed, this is an indulgence: I’m celebrating!

    Summer has arrived with a smile the last few days in Bristol. It’s humid and bright, and somehow calm in the city. This morning was no exception. Just after rush hour, and before the shops opened for business, I swung my backpack on my shoulders, hitched into my flip-flops and walked through the old town to the harbour. I headed for the Watershed, but it wasn’t opening its doors until ten-thirty, so I wondered along the river with my camera, looking for some inspiration.

    The city noise fell away as I walked around a bend past the famous Lloyds TSB building; the only sounds were an occasional river boat chugging by, and people talking on their ’phones as they sat in the sun and smoked. I walked under an avenue of young trees in front of new office buildings and came to Caffe Gusto, nestled at the end of a grassy divide between tall office and apartment blocks called Cathedral Walk. The tables reach out towards the river at the edge of the dock. The wifi extends to the river like the rippled reflections of the morning sun on the water. I sat for a while in the shade then moved out under a parasol. That’s where I’m sitting now. A ferry just passed by, gently bubbling the River Avon with its velvet diesels.

    There are some changes in the air; as gentle as this moment, but no less significant. They might take me away from this city where I’ve lived for the last eight years to a different country. It’s an exciting time; all for the good. So, if I seem a little whimsical, forgive me: The breeze of change is blowing.

    I would like to share one important event with you: Last Thursday, I got a great email. It was from Freda Sack, type designer, co-founder of The Foundry, and President of the International Society of Typographic Designers. The opening line simply said:

    “Welcome to ISTD”

    I grinned so much I almost swallowed my ears. I had spoken to Freda on Monday last week to ask about submitting web specimens for consideration. She told me that was fine, the board was meeting the next day, and it would be considering applications if I could submit in time. To do so, I built a web page that mimicked the PDF application form and submitted it that night. I really wasn’t sure I would be accepted. Web typography is volatile: The paper is inconsistent, the printing imprecise, and the opportunities to make a mess of it are manifold. I looked at my specimens the next day (not to mention some of my rushed copy) and winced.

    ISTD logo

    The ISTD started life as the Guild of Typographers in 1928. It is acknowledged as the authority on typography in the UK, and has international standing. Applicants submit six specimens of work that are reviewed by the voluntary board. Acceptance is by merit, and understandably geared towards print typography, so submitting six examples of web typopgraphy was a slightly nervous experience. The standard required is high. In some ways I felt like I shouldn’t apply; to be accepted was a genuine surprise. It still feels very much like a seminal moment.

    I confess, sometimes when I read what others so generously write about my work, I feel like a fake. Such generosity is truly heart-warming to read, but I can’t help feeling sometimes that it’s undeserved. It would be ungracious to say so and detract from the gesture, so I just say thank you, and mean it. The same is true of my application. It might sound like insecurity, but I’m always conscious of how much I don’t know. I’m also deeply aware of my own impatience with false modesty so even writing this is a little tricky for me. The main issue is that I am mostly self-taught, spending time researching my craft alone. There are benefits to this accidental approach, but I never experienced the (presumably) reassuring consensus of formal learning, especially around typography. I never served my time, so to speak, like so many of the incredibly talented people who’s work inspires me every day. However, I believe in my own work, and how I approach my craft. That’s a problem itself: My pedantry precludes me from believing that any piece of work is truly complete. That’s why being accepted into the ISTD is both a cause for celebration and reflection.

    Navel-gazing aside, I am honoured to be a part of the ISTD. It’s driven by volunteer members, and I feel privileged to be a part of it. Hopefully, I can learn, and contribute too. Web typography is flourishing. Print designers are discovering the tools to bring their paper skills to the Web. Web designers are re-discovering the elegant beauty of type on the screen. Discussions around the CSS3 fonts and web-fonts modules are in full swing. Sites like I Love Typography are bridging the gap between traditional typographers and web designers. It’s an exciting time!

    I’m about to step away from Caffe Gusto, and take a slow walk back to my office. Hopefully this side note in my life has been an interesting read. For me, I’m just happy to be able to share the moment. Hopefully there’ll be more to come!


  19. Typographers, lend me your pain

    Dear web typographers and designers, I need your help (and your woes!) A couple of days back, Jason Teague, Director of Web Design for AOL Global Programming and member of the W3C CSS3 Working Group made a request for input from designers around the CSS fonts and CSS web fonts modules. He has volunteered to be an advocate for them, and wants our thoughts and feedback on the way forward. It’s a welcome move, and a veritable bag of snakes he’s opening, so congratulations to Jason for volunteering to take the pain. I think we should help him out.


    For my part, I’m planning to respond in detail, supported by a few test cases and examples of current rendering. Wish lists are great, but I think empirical evidence is more useful when identifying current issues and areas for improvement in the recommendations. So, if you’re a web typographer or designer and have come across problems or issues that might be worth cataloging, let me know what they are. I’ll promise to try and put together a test case and convert anecdotes to science if I’m able. Alternatively, you can just throw your thoughts into the comments for Jason’s article.

    As an example of what I think might be useful, I’m planning on discussing classic type setting techniques that are either badly supported or absent like old-style versus lining versus small-cap numerals, raised or drop caps, granular glyph weights, ligatures, baseline fixing, etc. I’ll also be mentioning browser-specific hacks I use to achieve better rendering like setting a miniscule opacity value in Firefox on OSX to de-bloat the glyphs and improve larger-size anti-aliasing.

    What do you think?


  20. An Ephemeral Site: Denna Jones

    Denna Jones is a designer, and we recently launched a site for her that is unlike any other that Jon Gibbins and I have done before. This is it:

    Screenshot of

    The evolutionary bit for us is under the hood, and to understand why, let me introduce you to Denna, herself.

    Introducing Denna Jones

    Denna’s fascinating to talk to because she is genuinely erudite. Her influences are as diverse as her roles. She’s a former Designer-in-Residence at Central St Martin’s College of Art and Design for the B.A. Architecture course. Currently, she’s Lead Artist for DLA Architecture’s Masterplanning Team, Deputy Editor of Art and Architecture Journal, and the Resident Curator responsible for delivering the arts strategy for the massive Devonport regeneration project. Most recently, Denna’s contributed to books like 1001 Buildings You Must See Before You Die and had an invitation to be the editor of a new tome in the series, 1001 Houses You Must See Before You Die.

    Luckily for us, Denna’s work with spacial narratives is often exploratory, so she was open to our newfangled experiments.

    A Web 2.0 problem

    Denna is also prolific around the Web. She documents her projects and travels using Flickr, and regularly reads, writes about, and observes Web culture as part of her work. So when she came to us to discuss a site it seemed to me she embodied a problem I’d been thinking about for a while: How can our domains be connected to our other personal accounts more naturally? Domains are our identity. However, much of what we publish is locked into other sites where we share it. It’s accessible by APIs at best, or clunky widgets at worst. Technical people can pull everything together but for non-technical people it’s not intuitive. Then there’s the issues of legacy content and copyright. Unsolved as yet, but looming. What will happen to all of our content in five, ten or twenty years time? Will we still have content strewn around the Web disconnected for the most part? Somehow we need to connect the dots. Maybe portable social networks are part of the answer, or Google’s OpenSocial. Whatever the answer, I wanted to include Denna’s existing content in her own site, and to make the future relationship between her Web activity and personal site as seamless as possible.

    Web services, say hi to

    The content on Denna’s site is delivered exclusively by Web services. We take advantage of the ability to share and manipulate data that those services provide to Denna, then let her choose what to publish on her site, and in what context. This is how:

    • Flickr is used to manage all images and some of the site copy direct from Denna’s account. That includes the main display images on the home page, the introduction copy on her work page, and the images and copy for projects. Work projects are managed via a specific Flickr collection, with each set being a project. This enables Denna to choose the display image and write a description that appears on the site. Visitors can also drill deeper via the project link to see other images that Denna has added to each project on Flickr.
    • Tumblr is used for Denna’s blog and her about page. The site archives her entries and allows access to tags and dates exactly like a conventional blog would. We also use tags to display different content around the site like the entries tagged with “projects” that are displayed on the work page.
    • Ma.gnolia is used for bookmarks.
    • Twitter is used for random thoughts and snapshots of her day.
    • Upcoming manages events.
    • Technorati is used for references to her posts in the wider blogosphere in place of allowing local comments which were considered but discarded.
    • Feedburner manages all feeds.
    • Google is used for site search.

    Jon Gibbins did the heavy lifting around the idea, using CakePHP and SimplePie to manage the incoming data. He also added functionality like Technorati reference counts, and the ability for Denna to refresh her site as soon as she published something elsewhere if she didn’t wish to wait for the automatic updates.

    Other small touches were also a pleasure to see unfold, like Denna’s footer image being her Flickr profile image, and the text describing her blog coming directly from her Tumblr byline.

    Denna’s Tumblr account is not linked because she wishes it to remain private.

    Tumblr posed the most significant problems. When we started development, tags were invisible on Tumblr. Entries could be tagged, but tags were not displayed anywhere for people to use. They were absent from the API. Jon Gibbins wrote a workaround and fired an email to Tumblr suggesting it might be good to give people some way of using tags. After a couple of weeks Jon came back to me and declared that although he hadn’t had a reply, the API had just changed to allow tag access. Perfect! We got an email a couple of days later from the Tumblr crew: Did we know that the API supported tags?

    Visual design, typography & layout

    I wanted the design to be a container to allow Denna’s own content to flourish. Although we discussed style, and helped Denna formulate her own house style, it was very much in her hands. Strangely, I had no reservations about this. Putting the choice of stock images in the hands of a client might seem risky to some folks; to me it was exciting, especially as Denna was so enthusiastic about having such an intimate level of control over her own site.

    Typography and layout have a touch of the Swiss modern using Helvetica Neue or Arial (depending on your platform) with a traditional scale. The layout is a hybrid—part fluid, part elastic — meaning it defaults to a 1024px viewport width, shrinks to fit 800px-wide viewports, but grows with browser font size until it fills the available viewport and then wraps.

    Information verbitecture

    The information architecture mostly uses verbs in the directory names—an idea that first surfaced with Chris Shiflett during our recent OmniTI design. It means that web addresses make up sentences wherever useful. For example, a blog entry has a URL of

    HTML, JavaScript & microformats

    Plain old semantic HTML is used with CSS for styling. The interface was designed with accessibility firmly in mind; all JavaScript is introduced as a progressive enhancement to PHP-powered features like the slide-show for the home page.

    Microformats are used wherever appropriate: hCard for Denna’s contact details; hAtom for blog entries; hCalendar for Upcoming events.

    There is still more things we’d like to do, but in the meantime we’ve got a great head start and hopefully the beginnings of something special for an exceptionally interesting voice on the Web.

    Parting shots

    Working with Denna was inspirational. Her boundless curiosity, willingness to experiment, and professional skill made the whole process lots of fun. Her uncompromising belief in the ability of art and design to improve people’s lives makes her just the sort of person we need consulting on the future of our public spaces. It was a pleasure to give her a quasi-professional site that hopefully embodies the spirit of collaboration, personal creativity and expression we all admire. You can read more of her own thoughts on the design in her entry, Websites and the Science of Happiness. I’ll leave you with the opening line of that entry; it’s humbling to be though of in this way:

    “The designers of this website are happiness merchants.”

    Thanks Denna.


  21. A Site for Sore Eyes: OmniTI

    You may have seen the recent case study featuring the evolution of OmniTI’s brand mark. Work on their new web site started soon after that was finished. This is what we did:

    OmniTI index

    OmniTI’s CTO Chris Shiflett and I worked closely on every aspect of the vision, brand message, information architecture, copy writing and content. For me it was the best kind of arrangement resulting in a piece of work I’m especially pleased with. Along the way we developed the kind of relationship that I’ve come to treasure, making me feel like I work in a collaborative industry, rather than a service one.

    OmniTI Sketch mark

    Metaphors for the invisible

    Discussions around the new site made me think of two interesting design problems. Scalability and performance, security, development and infrastructure are invisible arts. Historically, companies have fallen back on metaphors to communicate what they do visually: Faux boxes of imaginary software; stock photography of happy people at computers; they never worked for me. From my perspective, OmniTI is one of the finest development companies in the world. They’ve written some of the seminal technical books in our industry. They work for some of the most heavily trafficked sites on the planet like Digg, Friendster, National Geographic and Facebook. Their contributions to open source are legendary, with their utilities being used by Yahoo!, amongst many others. When tackling email on a massive scale they built the world’s fastest mail transfer agent. To reduce what they are capable of to awkward metaphors seemed disingenuous. I wanted to do something different.

    Another significant problem was how to convey personality. People buy from people, especially in a service industry. The relationships we develop are priceless. Many developers in our business—especially those who attend conferences like OSCON where they often speak—are already aware of the people at OmniTI, but they themsevles don’t tend to shout about what they do. Part of the reason for this is the culture of the company itself: Relaxed and down-to-earth but jam packed full of some of the most talented people anyone could hope to work with. Excellence has become commonplace, making celebrating it feel almost un-natural. It just happens by default. So, the web site needed to show some leg, reveal their personality as well as their work, without forcing patterns of publishing on them that would not be maintained.

    These problems made the job interesting. I wanted to accomplish three specific goals:

    1. Make OmniTI accessible. Personalise the brand, reveal the company character, and the people within it.
    2. Communicate the scale, quality and depth of what they do to technical and non-technical people.
    3. Make the whole experience of researching and contacting them simple, easy and useful.


    To try and accomplish the goals we took a novel approach to design. It might seem ad-hoc, but it was deliberately organic; we let everything develop collaboratively, at almost the same time: From setting the vision to requirements gathering, persona development and task analysis, through to information architecture and copy writing. It sounds insane, but with a condensed time-line and a lot of intellectualising to be done, it worked in a way that only a small agile team that knows each other well can do.

    Along the way we went through four related iterations of style. Each reflected a development stage in the multi-track process we embarked on. The staff started writing a personal note for their own profiles. Some chose to stay with the professional photos, others supplied their own. All of it real though and unfiltered by marketing hype. Read the personal note of Rob Speed to get a glimpse of what I mean. The iterations kept getting better. In fact, everything kept getting better. Nothing is ever perfect, but a feeling of constant iterative improvement is a joy in itself. These are some of the highlights from my point of view:

    Theme, copy writing & content

    The theme is deliberately textual. OmniTI is a company that manipulates data in ways that are so esoteric that sometimes I had a hard time conceptualising the scale, nevermind the method. Text is the prevalent form of web data. It felt right to focus on it.

    Early on I decided to drop almost all decorative images and anything that was not content from the design. The data, the typography, they became the decoration. That went hand-in-hand with the decision to let OmniTI’s people, work and clients tell the company story. We decided to have a dual section in the planet for official company news and relevant posts from the staff’s own personal blogs. For the rest of the site, any copy that didn’t reflect the spirit of the company was avoided, and that which was left would be factual, not hyperbolic. Any claims OmniTI have made are under-estimates, and therefore all the more exceptional.

    Tiered detail

    I wanted to find a way of communicating the scope of their ability in a simple way. The audience diversity made this problematic. When developing personas to identify who we wanted to reach, two stood out: The technician and the executive. Both have very different requirements from the site. Both required detail in different areas. The first answer to this was for the home page. To grab people’s attention, I had the idea to display the actual output of their work as data in real time. There were technical and disclosure issues. We settled (for now) on showing some meta-level data around the number of pages and people that OmniTI’s clients serve:

    Screenshot: 'last month we helped some of our clients publish 880 million web pages, seen by 93 million people.'

    This will evolve over time and also be stored in an archive for future reference. Even more importantly, it is no mere boast. The figures are independently gathered and conservatively rounded down.

    The next solution was to somehow ease all of the audience into the site, whether they were technical or not. The narrative pattern we developed I call tiered detail. At the first level, like the index or any of the main navigation landing pages, chunks of different data are labeled with headers that encourage page skimming to find interesting topics. Copy is short, terse, accurate. The second level, like a personal profile, is more detailed and specific but has contextual links to related second level topics. The copy has links to third level pages where the focus narrows further to provide the kind of detail some people might want. These third level areas can be on site or off site—we didn’t distinguish between the two. All detail is useful when you want it.


    Both Chris and I love beautiful, clean URLs. So when he came up with the idea of using verbs rather than nouns in the information architecture we we quickly agreed to make it so. The outcome of a fair degree of debate and wrangling is the structure you see today. The about page is, the work page is, etc. Deeper pages have a URL that forms a sentence, such as:

    All trailing slashes have been removed making for highly legible and beautiful URLs in any context. More traditional URLs are redirected to the verb, so people can still type and reach the about page. If you wish to know more, read Chris’s post, URLs can be beautiful.

    Typography & palette

    Evolving an interface from a brand, the type choices of which I had nothing to do with, is always interesting. Trying to find compliments is fascinating, even more so in a design that relies heavily on type composition and treatment for decoration. I’ll pretty much let the typography speak for itself .

    Italic Baskerville ampersands in the byline

    Highlights for me are the raised initial used in headlines which I always see as an icon, my favourite Baskerville italic ampersand used in the byline on the home page, and other subtle treatments like the semantics of the page titles or contextual links. I used a traditional scale, body copy is set in Georgia by Matthew Carter with the headlines set in a Lucida stack.

    The palette is included in this section because the typography developed alongside it, and they are irrevocably linked. Or, I should say, they are tonally co-dependent. Although the palette is autumnal, it is a counterpoint to the season, and you may see us have some fun with it over time, but the effect will persist: Type highlighted by luminosity, regardless of palette.

    Layout, functionality & accessible Ajax

    The layout is elastic in every respect to a strict baseline grid. This served the narrative theme, splitting the content in to equal chunks higher in the architecture for skimming, resolving to conventional asymmetric columns deeper in.

    OmniTI contact Ajax

    Jon Gibbins did a sterling job implementing the JavaScript effects on the site. He chose jQuery and added some flavour of his own to make everything accessible with or without JavaScript turned on. That extends to the Google Map on the contact page which fills the expanding container as font size is adjusted. Jon also audited the site for accessibility generally, applying his uniquely pedantic but practical approach to support a wide range of disabilities, especially where the JavaScript is concerned. You can read more in his post, Accessible Ajax: OmniTI.

    All other functionality was handled by OmniTI, with Theo himself building an unbelievably quick search engine with Perl in about an hour, and Chris building out the CMS equally as fast it seemed.

    Experience & narrative

    As designers, we wear a multitude of hats. In the final analysis I think we’re experience designers more than anything else. In many cases we use design to tell stories, or help a story unfold. We create spaces in which enacted or emergent narratives exist and the OmniTI site is no different. Like all real tales though, there’s still much to be told. Hopefully they have a good starting point; an authentic opening chapter where the history of the last ten years can sit comfortably with the next ten.

    For my part, I hope the story is a joy to read. I hope the design is unobtrusive and becomes an ambient signifier that adds a little texture to the content. It is a design I would have liked to implement for Grow itself, so a lot of my own predilections went into it. I was lucky: The great relationship that we have, and the creativity of OmniTI, allowed my ideas some breathing space. We took a journey that resulted in a site that is re-markedly different to other technical companies. Some might view that as dangerous. I think the opposite is true. To me it was a great project to do. Hopefully you’ll find it interesting enough to enjoy. If that’s the case, keep an eye on it; there may be some more subtle changes to come.


  22. Naked in Tahiti (where’s Ms CSS?)


    Naked again. Why, oh why every year do I feel the urge to cast off the perfidity of style and expose my structure to the world? A question never to be answered, but merely enjoyed on CSS naked day!

    Love my semanticness (sp?). Love my form, my structure, my HTML, your browser (which is actually styling the HTML right now,) and markup in general raw and unabridged.

    Hey, on an unrelated note, did I tell you about that time in The Seychelles when I was naked and kinda playing guitar with my…

    Oi! You have a filthy mind. Enjoy the day folks, long may the tradition continue!


  23. Iterations in Brand Design: OmniTI

    OmniTI flames

    OmniTI are instantly recognisable to almost anyone interested in open source development, scalability or security. Their client list reads like a who’s who of the Web. Many of their people are core contributors to open source technologies like PHP; some are co-creators of popular frameworks like CakePHP and Solar; they speak at many industry conferences and have written eight critically-acclaimed technical books; they’re probably one of the most technically erudite and accomplished consulting companies working on the Web today.

    They asked me to work on their identity to mark their tenth anniversary and the separation of the email part of their business off in to a separate entity. This is an insight into the process and how the final design was created:

    Scope & objectives

    In June 2007 the initial scope asked for a redesigned mark that would still be recognisable to people already familiar with the brand. That meant retaining many of the elements of the original, including the typeface, over the course of five iterations. This was the existing mark at the time:

    OmniTI original logo

    These are the objectives of the redesign we arrived at during the specification stage:

    1. Simplify the mark “O” and incorporate it into the type to render well for the Web at small and medium sizes as well as large.
    2. Make the mark as easy to understand as possible with the correct enunciation.
    3. Clarify the typography for the Web and provide “balance”.
    4. Make the form colour–independant and suitable for all formats: print, screen or otherwise.
    5. Make the mark unique and suitable for trade mark purposes.

    Type & typography

    Identifying the original typeface was straightforward. It was Century Gothic from Monotype Imaging: A Bauhaus-inspired geometric face designed specifically for digital systems, based on 20th Century, which was drawn by Sol Hess between 1936 and 1947 and in turn inspired by Futura. Century Gothic shipped with Windows from Win98.

    After reproducing the original type treatment, I quickly capitalised the name properly in order for it to be read more accurately. I converted the text portion of the mark to black and white, and began to play with anti-alias at low screen resolutions to show a quick revision to OmniTI before starting in earnest:

    OmniTI typography

    The weight of the capitals looked incongruous to me, but the quick revision gave us all food for thought. It set the tone for the direction the design would move in, and I got stuck in to the main body of work: Trying to find a way of simplifying the existing flaming comet and incorporating it in to the leading “O”.

    Simple & Complicated Revisions

    Iterating the existing mark forced me to go back to starting principles. Much of the form needed to be retained, but it had a significant problem: If this was an identity seen mostly on the screen, then the existing mark was too complicated, effectively breaking at lower sizes, and forcing OmniTI to use a comparatively large version for the “comet” to be rendered properly.

    The first two revisions were deliberately simplified as far as I could make them with some movement retained in the stylised “O”, but stripped completely of decoration:

    OmniTI revisions 1 and 2.

    These revisions were deliberately provocative on my part by being extremely simplified and pushing the limits of the brief. However, having something tangible gave everyone room to think and react. It made the boundaries of the brief slightly clearer and allowed me to continue with more of a feeling for the direction we needed to go in.

    From the super-simplified, the next two iterations re-introduced the trails from the original mark as flames, and swung the design in an opposite, more complicated direction:

    OmniTI revisions 3 and 4.

    This was deliberate, too. I’ve sometimes found that good results come from a design process that swings like a pendulum or an elliptical orbit around the final outcome. To find the right balance between the requirements it sometimes feel right to push the design out to the aphelion along certain lines of thought, then let the collaborative process pull it back to the perihelion where all the conditions are met and it works. That’s what happened for OmniTI. Collaborative discussion with them and their quality feedback was crucial to this approach.

    Final polish

    The final iteration combined the two approaches, with a more geometric comet that has echoes of the original, but more simply drawn. The letterforms were unlocked from the pixel grid, but with the anti-alias tightened. The acronym capitals were also adjusted. This was the result:

    OmniTI revision 5.

    During the OmniTI web site redesign (a case study will follow soon is now available) the logo was re-coloured to match the palette:

    OmniTI site logo.

    All of the iterations and development of the final brand mark were heavily influenced by the feedback of Chris Shiflett, Theo Schlossnagle, Brian Vaughn and the rest of the OmniTI folks who gave their time and opinions. This collaboration was crucial to get the end result. My job was to guide them through the technical design process and hold all of their requirements in my mind while the pixels and vectors appeared on the screen.

    It was a real privilege to be trusted with their brand. I think we achieved a good result from what is often an emotive exercise, and I’m particularly happy that we managed to build on the work that came before to reach the final design.


  24. Conditional Comments after Installing IE8 beta

    Overcoming daft hurdles before work can even start is a pain. Getting multiple versions of IE working used to be one of them until Yousif Al Saif’s excellent Multiple IE installer came along. Microsoft have a commitment to 10 years of backwards compatibility. Therefore, they should be the ones to make it easy for designers to test interfaces in multiple versions of IE. If only that were true. The virtual PC image for IE6 is painful to try and use in Vista Ultimate on Parallels. So much so that I gave up, installed XP and went back to using Multiple IE.

    After installing IE8 beta, conditional comments stopped working for other versions of IE. I sighed. There’s an easy fix though. Just re-install Multiple IE and conditional comments support will be back for IE6 and under.

    By rights, Microsoft should pay Yousif Al Saif for the service he’s provided to designers. Wouldn’t that be a nice thought? Perhaps a few donations from folks like us will be reward enough.


  25. Preparing for HTML5 with Semantic Class Names


    Some time ago I was asked in an interview whether I preferred HTML or CSS. It was a bit like being asked if I prefer pens or pencils. I made an instinctive choice. I chose HTML. It’s the typography of data; the inflection in our voices; the grid of meaning upon which presentation can flourish. I find it beautiful when done well, and that’s why watching HTML 5 unfold with new and refined elements is fascinating to me.

    This is a brief introduction to the new structural elements in the HTML 5 Working Draft, and how to use semantic class names in HTML 4.01 or XHTML 1.0 markup that correspond to the names of those structural elements. By doing so, you’ll get a head start in understanding how to use the new elements and also go some way towards using plain old semantic HTML if you’re not already.

    i. Introduction

    HTML 5 will be the first major change to our lingua franca since XHTML 1.0 in 2000; some might say HTML 4.01 in 1999. You’ve probably already seen the HTML 5 Working Draft of the 22nd January this year. The W3C HTML Working Group and WHATWG have been grafting away on our behalf, and trying to satisfy everyone in an open process. Not an easy task. Sometimes, amongst the concerns and the questions it’s easy to forget that, so I’m taking a brief second in between sips of coffee to acknowledge the hard work. Thanks, folks.

    Let’s get to know these new structural elements a little better. If you’d rather go straight to the horse’s mouth before continuing I recommend a comfy chair, and a perusal of HTML 5 differences from HTML 4, edited by Anne van Kesteren. W3C documents seem to be getting easier to read, and this is no exception. If you’re sticking with me for a while, let’s get to it:

    ii. The <header> Element

    The header element is for page or section headings. Not to be confused with a traditional masthead, which often holds just a logo mark, it should also contain one of <h1><h6> in hierarchical rank. It could also contain meta information for that page or section of a page like “last updated”, a version number, or blog entry information like published date, author, etc.

    A simple example for a page using a semantic class name that corresponds to the HTML 5 header might be:

    <div class="header">
    <h1>Page Title</h1>

    You could include the logo mark and other meta information within the layer. The next example for blog articles includes author and published date information (as well as an example of referencing the section and article elements with semantic class names):

    <div class="section">
    <div class="article">
    <div class="header">
    <h1>Page Title</h1>
    <p>By <a href="*">Author</a> on [date]</p>
    [Article content…]
    <div class="article">
    [Repeat as required…]

    iii. The <nav> Element

    The nav element should contain a set of navigation links, either to other pages, or fragment identifiers in the current page. Referencing it with semantic class names is simple:

    <div class="nav">
    <li><a href="*">Menu item 1</a></li>
    <li><a href="*">Menu item 2</a></li>
    [Repeat as required…]

    iv. The <section> Element

    A section element defines a section of a page or a distinct piece of content. It would ordinarily have a header and possibly a footer. This is how we could represent it using semantic class names:

    <div class="section">
    <div class="header">
    <h2>Section Title</h2>
    [Section content…]

    I’ve also been using <div class="section"> to define a group of layers that are related (like news and events). In such an example, those sub-sections would be nested, each with their own <h1><h6> in rank order to maintain heirarchy. For example:

    <div class="section">
    <div class="header">
    <h2>News and Events</h2>
    <p>The latest announcements and upcoming conferences</p>
    <div class="section">
    [Section content…]
    <div class="section">
    [Section content…]

    Each section could also have a layer with a semantic class name of header if the content made it necessary.

    v. The <article> Element

    This is how the HTML 5 working draft explains article element:

    “The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.”

    Multiple article elements can also be nested. We looked at the example of a series of blog posts using semantic class names in the header section. This is an example using semantic class names in a unique article page with header and footer:

    <div class="article">
    <div class="header">
    [Article content…]
    <div class="footer">
    [Footer content…]

    vi. The <figure> Element

    The figure element contains embedded media like <img> and the new elements of <audio> and <video>. It also contains an optional <legend> element performing the function of a caption. Our semantic class name version could be like so:

    <div class="figure">
    <img src="*" alt="*">
    <p class="legend">[…]</p>

    vii. The <dialog> Element

    The dialog element replaces a <dl> to contain converations like transcripts. Using it as a semantic class name is straightforward:

    <dl class="dialog">
    <dt>Speaker 1</dt>
    <dd>So I said to him, I said…</dd>
    <dt>Speaker 2</dt>
    <dd>You never. You did? Oh my…</dd>

    viii. The <aside> Element

    To quote the working draft:

    “The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.”

    I’ve been using “aside” as a class name for sidebars with mixed content, but my reading of the draft also indicates it may also be appropriate for pull-quotes and anything partially related to the main content, but not of it. See the sections relating to the ins and img elements for examples. It woud seem appropriate to use it with a semantic class name like this:

    <div class="section">
    [Section content…]
    [Repeat sections as required for main content…]
    <div class="aside">
    [Aside content…]
    <div class="footer">
    [Footer content…]

    This is what the working draft has to say:

    “The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.”

    In the changed elements section of HTML 5 differences from HTML 4, it also explains that, “The address element is now scoped by the new concept of sectioning.” This is important, because now, if you have multiple sections in a page, each can have both a header and a footer with a corresponding address in the footer for each if you deem it necessary. However, that would seem to be a rare use-case. Let’s stick with a more common one: A single footer for each page with a single address element; here’s how it might be done using a semantic class name:

    <div class="footer">
    [Other footer content …]

    x. Multiple Class Names

    Let’s recap a little: By using semantic class names, we give the information a semantic boost, and each chunk of related data is self-contained. However, it may have become obvious to some designers reading this that a side-effect of using this method, and eventually using HTML 5 elements themselves, will be lots of different content within containers of the same name. <div class="section">, for example. You might want to present different content very differently in the browser. Multiple class names will enable you to do that. class="section" can becomes class="section news", or class="section services". The "section" class name allows us to standardise some of the presentation; say, typography for example. The "news" class name will allow us to present it differently as a section variant.

    So now we have the best of both worlds; the critical structural elements are included by default with more semantic class names providing hooks to apply our creativity to.

    xi. End Notes

    Bear in mind HTML 5 is a working draft so there will probably be some changes before it becomes a recommendation. It would seem unlikely that any of the new structural elements will be removed, but a sharp eye on the draft updates might be a good move.

    Any errors in this article are my own. If you some across any, please let me know and I’ll make corrections.

    xii. References & Further Reading

    1. References:
      1. HTML 5 Working Draft
      2. HTML 5 differences from HTML 4 and specifically, the new structural elements section
      3. Semantic class names
      4. Plain old semantic HTML (POSH)
      5. <header>
      6. <nav>
      7. <section>
      8. <article>
      9. <figure>
      10. <dialog>
      11. <aside>
      12. <footer>
    2. Further Reading:
      1. A Preview of HTML 5 on A List Apart by Lachlan Hunt
      2. HTML 5 Latest Working Draft at WHATWG
      3. WHATWG on Twitter
      4. W3C HTML Working Group


  26. Adios, IE8 Meta Mayhem!

    I’ve been holding back on a comment on the recent furor about the IE8 meta http-equiv switch. Mainly because the great and the good had it covered, but also because there was already a possible workaround, which John Resig pointed out: Use a HTML5 DOCTYPE.

    Dean Hachamovitch and the IE team put out the fire yesterday with a switch of their own:

    “We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can.”

    Great news! Now the legacy application vendors using IE as the platform, and relying on less-than-perfect rendering will bear the burden of telling IE which rendering engine they need. (Another radical idea might be for folks who are refactoring applications to use conditional comments like any good self-respecting developer should.) At least, with this announcement, the folks producing standards-driven code will not face the bizarre requirement of having to tell IE8 to not use IE7’s rendering engine. Makes sense to me guys, what took you so long? OK, the problem is more complex than that. After all, as Nigel Parker of Microsoft pointed out in his follow-up post to Kiwi Baacamp where he entered the debate:

    “Microsoft’s view [is] to support backwards compatibility for at least 10 years…”

    By anyone’s measure that’s a hefty commitment, and probably leads the field for backwards compatibility. Even more so when you consider that most new “killer apps” are targeted at the cool kids using the latest OS or browser, and often don’t work without Javascript. (Nudge, nudge Twitter.) A fact that always concerns me when you consider that “universality” is at risk of becoming a hackneyed word, and there’s a whole world out there getting online, often with less money than we spend on Starbucks, and the equipment to prove it.

    Anyway, I digress. Congratulations to the IE team and the collective intelligence in our community for reaching scientific solutions, intuitively. It just goes to show all the cynics out there that, as well a flaming each other, we also have a rare capacity for collectively recognising Robert M Pirsig’s metaphysics of quality.


  27. Elastic to Elástico

    After the recent translations of The Incredible Em & Elastic Layouts with CSS article in to Italiano and Deutsch, Raul Blanco of bitebit has kindly stepped up to the plate with an Español version:

    It’s hosted for Spanish comments and discussion at Macoteca.

    Muchas gracias, Raul! Another hero to add to the ranks of those kind enough to give their time to massage my prose in to a more eloquent tongue. If Spanish is your language, please consider dropping by there to show him some appreciation, or give a little link love. Thanks!


  28. Designer PHP: A Dynamic Menu with If and Else

    Recycling PHP and HTML

    In the simple PHP include article I covered how to re-use one file in many pages. If you’re new to using PHP, read that first. Now it’s time to make file includes a bit more useful. In this article, we’ll include one file for main navigation, but make individual menu items “live” depending on the page they appear on.

    This is an article in the “Designer PHP” series of guides to using PHP for interface production. Previously:

    1. A Simple Include

    To perform this feat, we need to do three things:

    1. Declare a variable on each page to tell the menu what markup to display.
    2. Create a file with “live” and regular markup for each menu item. Add PHP to enable us to switch the markup according to the variable.
    3. Include the menu on every page.

    Declare the PHP Variable

    The variable declaration must be in every page the menu will appear on. It must be before the line of code that includes the menu so the menu can pick it up. I would normally insert it above the <!DOCTYPE… to separate the PHP from my HTML as much as possible. This is the variable declaration for the home page:

    (This variable declaration or PHP statement has two key parts: The variable reference, or name $page, and the variable value "home".)

    $page = 'home'; 
    1. The variable name $page does not change. You can change it to whatever you like, just make sure it’s the same on every page.
    2. The value 'home' will be different for each page to tell the menu what to display.

    I usually have the value match the area of the site, so in the example we’re building it will be 'home' on the home page, 'about' on the about page, and so on. You can change the value to whatever you like, and have as many values as you need for individual pages.

    Create the Menu File to be Included

    For our purposes, we’re going to create a dynamic menu for a fictitious site with three pages: “Home”, “About” and “Contact”. You can extend this to apply to as many pages as you like. This is the basic HTML for the menu:

    <div id="nav">
    <li><a href="index.php">Home</a></li>
    <li><a href="about.php">About</a></li>
    <li><a href="contact.php">Contact</a></li>

    We want two different sets of markup for each menu item: “live” markup and regular markup. In this example we’re going to attach a class to the “live” item — <li class="live"> — and wrap the link in an <em> to differentiate it even if styles are disabled. For example, on the home page, the “live” home menu item will end up looking like this:

    <li class="live">
    <em><a href="index.php">Home</a></em>

    To switch between “live” and regular markup, we will use PHP “if, and else statements”. This is the menu HTML with PHP:

    (White space and line breaks inserted for legibility. PHP is emphasised in red. Disable styles to see it in italics if you need to.)

    <div id="nav">
    <?php if ($page == 'home') { ?>
    <li class="live">
    <em><a href="index.php">Home</a></em>
    <?php } else { ?>
    <li><a href="index.php">Home</a></li>
    <?php } ?>
    <?php if ($page == 'about') { ?>
    <li class="live">
    <em><a href="about.php">About</a></em>
    <?php } else { ?>
    <li><a href="about.php">About</a></li>
    <?php } ?>
    <?php if ($page == 'contact') { ?>
    <li class="live">
    <em><a href="contact.php">Contact</a></em>
    <?php } else { ?>
    <li><a href="contact.php">Contact</a></li>
    <?php } ?>

    Copy the code to a new file in your editor. Save it as nav.php inside an inc directory in your site root.

    I have deliberately separated the PHP and HTML as much as possible. There are other ways to achieve the same result, but this removes PHP completely from within HTML tags, hopefully making it easier to read and edit.

    Let me explain what the PHP does: Each menu item is marked up in two different ways: the “live” version and a regular version. The variable we declared tells the PHP in the menu which to display. For example, if $page = 'home'; is declared, the if statement ( <?php if ($page == 'home') { ?> ) will display the “live” markup. If home is not declared then the <?php } else { ?> statement takes over, and the regular markup is displayed.

    To make any of the other menu items “live”, you adjust the variable. The menu picks it up and switches the HTML. Simple. That’s our menu created and ready for use. The next step is to include it on every page.

    Include the Menu

    To do this we use the same technique explained in the simple include article, except this time we’re including the menu file, which we’ve called nav.php. This is the PHP you need:

    <?php include 'inc/nav.php'; ?>

    Insert that in each page at the point you wish the menu to be displayed. The path ( 'inc/nav.php' ) pointing to the nav.php file is relative — make sure you change it if your pages are not all in the site root. Each of your site pages will now look something like this (with the variable value * edited as required):

    <!DOCTYPE… >
    <head>… </head>
    <?php include 'inc/nav.php'; ?>

    That’s all! Now you can get to the fun bit of styling your menu with CSS. If you need to change anything, you simply edit the nav.php file and every page will be updated. Easy, isn’t it? Let’s end with a few tips about errors and security.

    PHP Error Debugging

    If you get a heap of PHP errors on a page instead of the menu, the chances are your include file path is wrong. Check it is pointing correctly to nav.php from the location of the page calling it.

    It’s useful to know that you can navigate straight to the include file directly in your browser and see the markup.


    If the file path is wrong, you will get a 404 error.

    If no menu items are active, or one is incorrectly active in a certain page, check the variable declared at the top of the page. Does it match the on in the if condition that precedes the item you want “live” in nav.php?

    If you’ve done all that, and you’re still having problems, check your syntax line by line. The chances are you’ve missed a tiny mistake. It’s a pain but a good way to learn.


    I grabbed a moment with web application security guru, Chris Shiflett to have him check my PHP. This is what he said:

    Whenever you’re working with a server-side programming language such as PHP, it’s good to be aware of potential security problems, because a simple mistake is all it takes to create one. If you follow Jon’s example, you’re safe, but what happens when you need to modify it to suit your own unique needs?

    Rather than complicate a wonderful tutorial, I’ll just point out that you should research further before doing either of the following:

    1. Add any additional PHP code to your includes.
    2. Use a variable in your include statement, e.g. include "inc/$template".

    If you need to do either of the above, you should first read a little more about remote code execution.

    Further Reading

    Control structures on

    Can You Translate?

    After a wonderful response to the em and elastic layout article, I’d love to hear from anyone who’d like to translate this, or any other article in the series. I’ll be happy to host your work, like the previous Italian translation, or you’re welcome to publish it yourself. Just drop me a line.


  29. Designer PHP: A Simple Include

    Years ago I was introduced to PHP. Since then, using simple PHP includes has saved me huge amounts of time in revising and editing HTML, so I thought I’d share some basic tips and hopefully save you some time, too.

    This is the first article in a series of basic designers’ guides to using PHP for interface production.

    Including CSS style sheets, JavaScript files, and image files in HTML pages will be familiar to most people. PHP includes work in a similar way: Create one file with a chunk of HTML in it (like a menu or a footer) and include it in multiple pages using a bit of PHP. Change the contents of that one file and every page that includes it displays the change. Sexy, eh? Let’s get started:

    What is PHP?

    In case you don’t already know: PHP is a programming language that works on the server—server-side scripting—in much the same way that JavaScript works in the browser (“client-side scripting”).

    All good hosting services have PHP installed on the server. You can find out what version and modules you have installed using phpinfo(). PHP also powers many of the most popular sites in the world. However, all we need to know for our simple purpose is this:

    PHP allows us to create a single file on the server, and include the contents of that file in multiple pages before they are delivered to the browser.

    Creating PHP Files

    Make sure your hosting service supports PHP. Then, instead of saving your site files with a .html or .htm extension, save them with a .php extension. They won’t render any differently in the browser, the extension just tells the server that the file may contain PHP which will need to be executed before the file is served.

    Before creating PHP includes, I usually create the first page of a site in the normal way, but save it as .php. I only pull chunks of HTML out to includes when I start building other pages in the information architecture.

    Example: A Regular HTML Footer

    Web sites usually have a footer that is constant across all pages making it perfect to be included using PHP. This is a simplified example of a regular page with the footer included inline as usual:

    <!DOCTYPE… >
    <head>… </head>
    …main content
    <div id="footer">
    …footer contents

    Making the Footer a PHP Include

    1. Create a directory in your site root called inc to contain all of your includes and keep your files organised.
    2. Remove the whole of the footer markup and paste it into a new file in your editor. Save that file to the inc directory as footer.php (it can be whatever you wish).
    3. In the regular site pages, where the footer would usually be, replace it with a bit of PHP to include the footer.php file:
    <?php include ("inc/footer.php"); ?>

    Important: The file path ("inc/footer.php") is relative to the location of the page including it — make sure it points to the right place from any given page in your site.

    With that bit of PHP in your pages, the footer.php will be included in the page at that place.

    Change the markup in footer.php and it will change for every page where you have included it. Now, when you need to change the date in the footer to include the new year, or change anything about it, you only have to change it once in the include. That’s it! You can make any bit of markup an include.

    More Complex Includes

    PHP becomes even more useful for designers when the state of HTML objects needs to change depending on what page they appear in. For example, the markup and style of main navigation items will change to indicate which item is active. I often apply a class and either disable a link or wrap it in <em> tags. You can do all that in a single menu include. In the next article I’ll show you how. In the meantime, if this is new to you but you’re enthused by it, take a look at if/else statements yourself.

    Further Reading

    1. PHP tutorial from
    2. PHP introduction from W3schools


  30. From Elastic to Elastisch

    Screenshot of

    Another hero volunteer has been kind enough to translate the Elastic layout article—this time into German. All praise to Pascal Birchler for taking the time to wade through the detailed prose and extract some local meaning from it.

    Die unglaublichen Em & elastischen Layouts mit CSS is available on his web site where discussion and comment in German would be most welcome. Thanks, Pascal!

    Thanks to Michael Kalina for the kind email correcting my title for this post. It’s now been changed to actually make sense to German-speaking folks!


  31. Gong Xi Fa Cai (Happy New Year!)

    Rats rejoice, this is your year! I include my father amongst that number, and have a bottle of fine Cognac around here someplace to prove it.

    It’s 4706 according to the Chinese calendar. I find myself musing today that the Western new year is so arbitrary, having no relationship to either solar or lunar cycles and yet it still looms larger in my mind than the Chinese version. If we were going to get truly pedantic, new year celebrations would either be at one of the solstices for obvious reasons. Or would they be calculated on a lunisolar basis anyway, as with many South East Asian calendars? I forget, but my main thought was how arbitrary the Western New Year is in comparison.

    Maybe we’ve taken a few backward steps: The Sumerians would celebrate their new year around the Vernal Equinox (or the first new moon following,) and the Mayans had a logical calendar of 13 months based on lunar cycles.

    Whatever your opinions on my random thoughts for this season, may you and yours have a great new (Chinese) year!

    Normal bulletins will resume shortly after the weight of work shifts to a more comfortable position in the next few weeks. On the cards soon: Hybrid, sliding layouts in CSS, more on narrative, experience design and typography, in no particular order.

    I know I’ve been a little slack in 2008, but I’d rather have quality over quantity every time, a bit like Ratatoille.