ISO 27001:2013 - Information Security Management Systems was released in September and slipp ...(more)...
Back when Django 1.5 was released with experimental Python 3 support I was all excited: at long last I could seriously think of moving on to the latest and greatest python released so far (Python 3.3). Sadly I haven't been able to convert all my projects yet, due to dependencies not being compatible yet.
I noticed that python 3 adoption has been steadily accelerating for django related packages over the past few weeks. The release of Django 1.6, bringing official (non-experimental) support for Python 3, is probably not stranger to this trend. So to keep track of which of my projects are ready I added little badges to requires.io:
Requires.io is free for all public projects hosted on either BitBucket or GitHub. Beware though, it's all still quite alpha/beta-esque, and sadly still running on Python 2.7...
By Vasudev Ram
XMLtoPDFBook is a publishing tool I created, that allows you to create simple PDF ebooks from text content in XML files.
I had blogged about XMLtoPDFBook earlier, here:
Create PDF books with XMLtoPDFBook
XMLtoPDFBook now supports chapter numbers and names
Today I added some support for a Table of Contents feature to XMLtoPDFBook. Here is the updated program:
# A program to convert a book in XML text format to a PDF book.
# Uses xtopdf and ReportLab.
# Author: Vasudev Ram - http://www.dancingbison.com
# Version: v0.2
from PDFWriter import PDFWriter
import xml.etree.cElementTree as ET
import xml.etree.ElementTree as ET
# global variables
sysargv = None
sys.stderr.write(message + "\n")
# Get command-line arguments.
xml_filename = get_xml_filename(sysargv)
debug("xml_filename: " + xml_filename)
pdf_filename = get_pdf_filename(sysargv)
debug("pdf_filename: " + pdf_filename)
# Parse the XML file.
tree = ET.ElementTree(file=xml_filename)
debug("tree = " + repr(tree))
sys.stderr.write("Error: caught exception in ET.ElementTree(file)")
# Get the tree root.
root = tree.getroot()
debug("root.tag = " + root.tag)
if root.tag != "book":
debug("Error: Root tag is not 'book'")
# Initialize the table of contents list.
toc = 
# Initialize the chapters list.
chapters = 
# Traverse the tree, extracting needed data into variables.
debug("-" * 60)
for root_child in root:
if root_child.tag != "chapter":
debug("Error: root_child tag is not 'chapter'")
chapter = root_child
chapter_name = chapter.attrib['name']
chapter_name = ""
debug("-" * 60)
# Create and set some fields of a PDFWriter.
pw = PDFWriter(pdf_filename)
pw.setFooter("Generated by XMLtoPDFBook. Copyright 2013 Vasudev Ram")
# Write the TOC.
pw.setHeader("Table of Contents")
chapter_num = 0
for chapter_name in toc:
chapter_num += 1
pw.writeLine(str(chapter_num) + ": " + chapter_name)
# Write the chapters.
chapter_num = 0
for chapter in chapters:
chapter_num += 1
pw.setHeader("Chapter " + str(chapter_num) + ": " + toc[chapter_num - 1])
lines = chapter.split("\n")
for line in lines:
sysargv = sys.argv
# Check for right number of arguments.
if len(sysargv) != 3:
if __name__ == "__main__":
except Exception, e:
sys.stderr.write("Error: caught Exception" + str(e))
You can run it as follows:
python XMLtoPDFBook2.py vi_quickstart2.xml vi_quickstart2.pdf where I've used my vi quickstart tutorial, first written for Linux For You magazine, as the input XML file.
Here is a screenshot of the first page of the resulting PDF ebook - the Table of Contents:
And here is a screenshot Chapter 3 of the book:
I've pushed the code (as file XMLtoPDFBook2.py) to my xtopdf project on Bitbucket.
- Vasudev Ram - Dancing Bison Enterprises
Exactly a year ago, I shared some data around the Android Engagement Mystery. That is, while Android is dominant in smartphone marketshare across the World it lags behind iOS in engagement. A year later have things changed?
- In 2012, the Android operating system ran on 75% of the smartphones shipped in the third quarter. Apple's iOS was second with 15% marketshare.
- In 2013, Android took 71% of all sales across 12 key markets versus 21% for the iPhone over the 12 weeks ending October 31. (source)
- In December 2012, 64% of Android devices were running version 2.x of the OS and only 34% were on the latest version 4.x. This led many to hypothesize that lower engagement on Android was due to a lesser user experience on older devices with Android 2.x. (source)
- In December 2013, only 25.7% of Android devices are running Android 2.x and 74.2% are on 4.x. Yet the engagement differences continue. (source)
- Thanksgiving Day and Black Friday 2013 saw record online sales. iOS-based devices drove more than $543 million dollars in online sales, with iPad taking a 77% share. Android-based devices were responsible for $148 million in online sales, a 4.9% share of mobile driven online sales. (source)
- On Thanksgiving 2013, iOS ended up accounting for over 21% of all sales, and $121.61 per order. Android accounted for only 4.6% of sales. (source)
- For every $1.00 in app download revenue earned by iOS developers, their Android counterparts earn just $0.19. That's five-times-greater return rate for developers. (source)
- Ads on Apple's iOS posted return nearly 1,800% higher than the same ad running on Android. (source)
- iPhone users spend an average of 19 cents per app downloaded against just 6 cents per download for their Android counterparts. (source)
This post is a rough transcript from my talk at Handheld Conference last week in Cardiff.
I’ve a confession to make. I’m an armchair mountaineer. I’m too much of a coward to actually put myself in the type of risk mountaineers do, but for the last decade or so, I’ve been reading as many mountaineering books as I could get my hands on. And I’d like to start by telling you a famous story of Alpine mountaineering.
This is the North Face of the Eiger in the Bernese Alps in Switzerland. The Eiger (meaning: Ogre) is a staggeringly difficult face to climb. Nearly two vertical miles high of ice-coated loose rock. It’s a treacherous place. It’s also the place I proposed to my wife in 2003. But that’s another story. The story I’m going to tell you starts in 1936.
In the winter of 1936, Andreas Hinterstoisser (pictured), Toni Kurtz, Willy Angerer and Edi Rainer set about tackling the face of the Eiger – then unclimbed. They’d established the rough route, and after a day had reached an impassable, sheer area of rock just underneath the Rote Flüh – a prominent feature on the face.
Let’s leave that story there for now and come back to it later.
Let’s talk about responsive design.
Responsive design has changed my work and, ultimately, how I do business. This talk is about how it’s done that. But before I do that, I’d like to tap about the definition of responsive design.
If you talk to some people, responsive design is just fluid grids and media queries. To other people, it’s that your website fits on a tablet or mobile phone and changes to adopt. To others, it’s the way to save money by consolidating teams. Responsive design – like AJAX, or Web 2.0 – has become a buzz-word to represent a change. A change in our industry. A change in the way people are consuming content. That’s the type of responsive design I’m going to talk about.
I’m going to talk about three specific areas of how it has challenged the way we work at Mark Boulton Design.
1. Structured content
It’s strange to think that there was a time on the web where content was a second-class citizen. As a student of editorial design, I’ve always found this odd. In the past, whenever I heard ‘content is king’, my response was generally ‘er, yes’.
Responsive design has challenged how we commission, create, edit and design for content. I’d like to talk a little bit about how this has affected two clients of ours. Firstly, our work with CERN.
Different content for different people, at different times, on different devices.
I’ve talked about CERN before at conferences, but not really in this amount of detail. When we started working with CERN a few years ago, the whole project was framed in one sentence by the head of the CERN web team…
We have a content problem.
And they did. They didn’t really know who their audiences were, how to talk to them, or what they wanted. Following months of research, it became clear the audience for the CERN site was comprised of students, scientists, the general public and CERN staff. Interestingly, all of those four large groups had a common need: updates. They wanted to know what was going on. But here is the problem: each group of people needs to hear the same update in different ways. Let’s take an imaginary use-case of an announcement for a new particle that’s been discovered.
For the general public, they are generally learning a lot about CERN from elsewhere. Not on the CERN site. So, they are coming to the site from another trigger – either another website, or the TV, or a magazine or newspaper – and their overall comprehension of the work done at CERN is minimal. The update needs to be worded to accommodate that. But that update also needs to appeal to scientists working in high energy physics and associated fields. They want the detail, in the language that suits them. Already, our one update is fragmented. Throw in students and educators, then our update is going to have to work very hard if it’s just one piece of content.
Therefore in the CERN redesign process, the editorial structure of updates needs to be fragmented and structured in such a way to accommodate different words for different audiences. A responsive design challenge that has nothing to do with how something looks, but how it is structured and how it works in the CMS.
This brings me onto my second point on structured content.
We’ve also been working with Al Jazeera for a few years on redesigning their digital platform. Throughout that process, in just that short space of time, we’ve seen the rise of responsive design and how it affects how content is created and viewed. One example of this is just the process of how news works.
We often think of a news story as a page. A useful, familiar construct. It has a headline, a stand first, some paragraphs and maybe an image or a map. But after studying how their editors work, it became clear that this is not what a news story is. News is always moving.
A story starts as a seed. Something that comes down the wire…
There has been an earthquake in Japan.
Nothing more. Not yet.
Then, over time, the story grows and, like a snowball rolling down a mountain slope, more content starts getting attracted to it – maybe a tweet, other articles, images, video, timelines, quotes etc.
Because a news story is not a page. A story is the link between bits of content. The question here is how do we – meaning editors and designers – curate and cajole this content to most effectively tell the story?
The answer does not lie only in design. The answer lies in how content is structured and categorised. Meta-data is the new Art Direction.
Responsive design has been perhaps most visible in its ongoing challenges to process. How we do what we do is coming under increasing pressure, and here are several ways in which I’ve noticed how.
I started out working in advertising. As a student, I was an intern for a couple of years at an agency in Manchester. Other than the work, one of the things that has become clear now I run my own design business.
When advertising agencies talk about work, they talk about it in terms of accounts, not projects. When you win work, you win an account – for a period of time. An account is commitment over a period of time.
We will work with you on all our projects for 12 months.
This means a client will invest in you, and the time it takes you to learn their business, familiarise yourself with the challenges and give you the space (and budget) to do great work.
Projects are not a commitment. Projects are relatively risk-free.
You will deliver this website for this much money in this time-frame.
Approaching work this way leaves little room for any ongoing commitment, from client or agency. It’s like a first (and only) date. And with that comes a distance.
Over the past couple of years, I’ve seen my peers move from agencies and studies move to products and client-side. In doing so, they are closer to the problems. With the space to move in an agile way without the constraints of any binding commercial relationship. This reminds me of a story from Kevin Spacey about his work on the House of Cards
Kevin Spacey recently gave a rousing talk at The Telegraph in which he talked about how TV commissioning works in the US. He went to all the networks in the US to pitch the show. They were all interested, but each one wanted to do a pilot. A pilot which, in 45 minutes, would establish the major plot-lines, introduce the characters, the love-triangle, the cliff hanger.
“It wasn’t through arrogance that we weren’t interested, but we wanted to tell a story that took a long time to tell. We were creating a sophisticated, multi-layered story with complex character that would reveal themselves over time and relationships that would need space to play out.”
The House of Cards was about the long game.
To me, many web projects can feel like a pilot. Relatively low risk, low on commitment to work together without the time and space for the problems to play out. Proximity to the problem – a hand forced by responsive web design’s challenges – comes from working closely, over a long period of time. An account, not a project. A season, not a pilot.
The project rope-a-dope
In 1974, Muhammad Ali and George Foreman fought in the ‘Rumble in the Jungle’ in Manilla. Forman was the favourite having beaten Ali three years before. he was strong. Young. And a great boxer. He was sure to win.
Throughout the fight, Ali let himself get hit on the ropes. To give the impression he was tired, lose, and close to defeat. All the while, he was whispering in Foreman’s ear ‘You’ve got nothin”… ‘nothin”. Forman blew himself up trying to knock him out. This technique was coined the ‘rope-a-dope’.
Just going back to my last point for a moment. One of the results from being closer to the problem is that you have more exposure to the mess of design. Making things is messy. And to some people – especially clients, who can expect nice shiny things handed to them – may not be expecting to be exposed to that.
Sometimes they will freak out. And it’s our job to sit back on the ropes and take it on the chin. But, instead of goading them, we should offer words of reassurance. We should shift our process to something that may feel more comfortable. You have to break a few eggs to make an omelette, after all.
Where is the design?
Getting in the browser sooner. Looking at content sooner. Iterate. All of these things have a knock-on to design and how it’s received by a client.
For a few years now, I’ve talked about the fidelity curve. A simple graph to explain to clients that over time, we increase the fidelity of a prototype and slowly layer on the visuals. This is so we can fail quickly on low-risk, low-fidelity work. Mostly this is good and works well, but recently, I had an interesting discussion with a client in which they asked where the design was.
It’s an interesting question, because in this process, the design is everywhere. And unless you take the client along every step of the way – knee deep in the mess of design, being closer to the problem – then how do you manage the expectation that, at some point, a client will expect a presentation, or a reveal’ of how the product will look.
3. The Trend
“I want a responsive…”
As I said, responsive design is a trend. Or, rather, an awakening. As such, a lot of organisations and businesses are behind the curve . But one thing many people aren’t asking (and, I know this because I ask) is ‘is it worth it?’ or ‘Do you really?’
In 2011, our first responsive site was a site for World Skills London. It was a fun project, geared around a single event in London in which 200,000 visitors would attend and watch the various activities in the competition. As part of this project, we designed a responsive map. A cool diagram with a responsive image map that would scale and allow users to get from A-Z in the event by using their phone. Cool.
Except, during the project retrospective, it became clear that, actually, only 25 people used it. It was not needed.
Back to Hinterstoisser
Let’s go back to the Eiger and Hinterstoisser and three other men trying to climb the North Face. If you recall, after a day or so, they had arrived at a seemingly impassable face of rock under the Rote Flüh. After much deliberation about trying to re-route, Hinterstoisser decided to have a go at traversing the feature. And he succeeded, and with that, opened the gateway to the rest of the face and rest of their climb.
Today, the same traverse is still used across the same slab of rock.
Last week, I did a survey on Twitter about the business of responsive design. After 500 or so responses, it’s clear that everyone is finding everything hard right now. The change is so big, and so rapid, that we’re struggling to keep our heads above water. And this especially goes for those working in-house or clients.
Breaking new ground is always difficult.
But, just like Hinterstoisser, take heart in knowing that what we’re working on right now is a legacy for designers and developers in the months and years ahead.
There is a storm coming.
For those of you reading this who have experienced a severe weather event know all too well the sequence of events leading up to it. First, there is a warning – either through the media, verbally, or from the old woman in town who can feel it in her bones. Then, there is the sense of it coming, and that can take minutes, hours or days. Either way, there is a feeling of calm before the havoc. Battening down the hatches, preparing your self, property, business and family. Preparation is important in surviving something potentially catastrophic.
I read a post today from the Karen Mcgrane called Responsive Design Won’t Fix your Content Problem. It was nicely validating for me reading what mirrored so many of Mark Boulton Design’s clients, especially over the last eighteen months. The post describes the difficulty organisations are with adapting to their digital content being published across a variety of channels. Reconciling that against existing business and technology structures is hard for big organisations but, in my experience, that’s what’s been happening for the past years.
Responsive design is our storm. Acknowledging the way the web really is, and reconciling it against the plethora of new devices and reading behaviours has been a seismic shift in the creation and reading of digital content. Organisations have been spending the last couple of years coming to terms with it.
Quoting Karen’s article from a recent project she was working on:
Our executives assume that since they made the decision to go responsive, every other decision would just be tactical details. In fact, implementing responsive web design raises issues that strike right at the heart of our business and the way we work. We need to fix our review and approval processes, our content management system, our asset management system, our design standards and governance. We need to clean up our outdated, useless content. But it’s hard to get people to step up to solve these bigger problems, because they don’t think they’re part of “responsive design.”
This exactly mirrors my experience.
What starts out as desire to change for the better, to make a web product responsive, is the start of problem escalation. Before you know it, organisations are talking about needing structured content, but to do that they need a new CMS, but to do that, they have to procure a new CMS and migrate content. Now, that’s not all bad. Organisations have been doing this. Preparing solid foundations on which to create digital experiences for wherever the user may be.
The storm. The critical mass of creating content for an increasingly broad digital space is just around the corner. Are you prepared?
Following on from my post about speaker and audience tips, I thought I’d also share a few tips for conference organisers from a speaker’s perspective.
I’ve spoken at well over fifty events over the past few years to upwards of about four thousand people. Along the way, I’ve had mixed experiences of what it’s like to speak at conferences big and small. Mostly, of course, the experience has been great. Organisers are lovely people, who work extremely hard and appreciate you being there and look after you well. But, as always, the devil is in the detail. If you’re thinking about organising a conference this coming year, maybe bear some of these details in mind.
Logistics. Well in advance, give the speakers the logistical details; who’s meeting them at the airport, where they’re staying and for how long, what time the parties are, what other commitments they have etc. If you don’t have them, let them know you don’t have them yet and that you haven’t forgotten them.
Pay them. Even if it’s a small amount, but especially if your conference is for profit and relies on the quality of their talks to sell tickets. Of course, travel expenses should be covered. Now, this may not apply to some ‘community’ conferences with many, many speakers. But, for most, it applies.
Arrange travel. Book their flights (and make sure you ask for their frequent flyer number), pick them up from the airport, ferry them around if need be. They’re not to be pampered, but don’t underestimate peoples anxiety in foreign countries.
Put them in a nice hotel. Again, consider the details. Make sure the hotel has confirmed the booking, and they know when the speaker is expected to arrive. Once, when arriving late at a conference hotel, I was told I didn’t have a room and ended up sleeping in a meeting room on a makeshift bed for the night.
Confirm with them the pre and post talk events. Is there a speaker’s dinner? If so, where, when, what time (and where) is everyone meeting.
Sound and technical check. A lot of speakers like to get this out of the way before their talk. They will want the name of the person they need to report to – either a stage manager, or a conference volunteer – in order to sort that out.
Dongles. Make sure you have every known projector dongle available. People lose them all the time. Also, spare clickers and batteries is a good idea. Most speakers will be well-prepared and carry their own, but just in case.
Tea. This is personal. Not everyone drinks coffee, and I would like tea at my breaks.
Alcohol. Again, this is personal, but not everyone likes a piss-up. So, the after party should not necessarily be at a club where you can’t hear yourself think with as much free spirits as you can drink. Consider attendees may want to talk amongst themselves in a grown-up setting after a long day sat down. We’re not all party-animals.
Green rooms. It’s important that speakers have somewhere to go and work, or cram their slides, or be by themselves with their nerves. This is very important for me. Last thing I want to do before I go on is mingle. I’m generally nervous and want to focus on the job at hand. It has been known for me to hide in the toilets for a while.
Rights. Don’t ask for exclusive rights over speaker’s content. This happens, and increasingly so, actually. A conference will explicitly say that you are not allowed to talk about the same stuff in other places. Nope. That will not do. A lot of speakers produce one or two talks for the entire year.
Video. If you’re going to video me speaking, and charge for those videos of me and my content, you should explicitly ask me. Not because I’ll say no (not every time), but because it’s nice to be asked. And, sometimes, I may be talking about content which I want to actually use at a later date for myself in a filmed workshop, or talk.
Get a good MC. If you have someone introducing each speaker – and you should – then make sure that person is energetic, funny, personable and just plain pleasurable to listen to.
Have a stage monitor. I use scant notes in my talks, but the most important thing for me are my pace notes see point 14. If those notes are on my laptop screen all the way over on the lectern, it’s sometimes a bit unnatural for me to be flitting back and forth. It’s much better, if you can, to have a monitor on the front of the stage showing Keynote’s presenter display.
Set the expectation for Q & A. If you plan on doing Q & A let everyone and the speaker know. If you don’t plan on it, then don’t – after the speaker has finished – say ‘thanks, Mark. So, any questions audience?’. Invariably there won’t be any, because nobody – including the speaker – was expecting it. Also: it’s generally a bit of a bum note after the rousing ending to a talk see point 11.
Your conference is not your ego trip. Everybody, including the speakers, are incredibly grateful for the effort you’ve put in over the year to produce a great conference. But, chose a time and a place to thank people. In between each talk isn’t it. Also: my guess is that most people in the audience have bought tickets to hear what the speakers have to say, rather than as a favour to you.
Your conference is not your platform. Building on point 16, I’ve been to a few conferences where there is an agenda – a point to be made by the organisers – either by who is speaking, or about what. If you have one, and that maybe fine, but please let speakers know before hand.
Talk to your speakers about their content. This is important. Many speakers will not have their talk ready until right at the last minute (especially me). But, they will have a pretty good idea of what they will be talking about. Talk to them. design the conference and the material. Create an experience for the attendees on underlying threads in the talks. It’s my feeling attendees should feel like they’ve been to a show, than seen a collection of people speak. It should feel united.
360 Degree Feedback. As a speaker I’d welcome the opportunity to feedback to the conference organisers about the conference. Consider a method of gathering feedback from speakers.
Feedback from the audience. Feedback on speaker’s talks is generally through Twitter, which is an almost immediate response and gauge on how you’ve done. Mostly, it’s a good tool in that regard. Other conferences use questionnaires. I find this a clumsy tool and metric on which to base a speaker’s performance. One glance at Twitter, and a few conversations in the hallway, should confirm to you if it was well-received or not. I welcome constructive feedback. I don’t welcome ‘I can’t understand this Englishman’s accent’, or ‘that was boring’. That’s not a conversation. It’s a verbal drive-by. I know people have quit speaking because of this type of ‘feedback’. It’s not helpful.
That’s it for now. It’s worth saying I’ve never organised a conference, but I do know how much time, effort and money it takes to do so. I’ve nothing but upmost respect for people who do. That said, I hope these few tips help in a little way if you’re thinking of giving a conference a go.
I’ve been speaking for a good few years now, and over that time, I’ve amassed a bunch of little tips and tricks I use to make it more of a pleasurable affair. This post was prompted by a colleague of mine, Nathan Ford, who, this morning, asked for some tips as he has a couple of speaking gigs lined up next year.
So, here we go. Some tips for speakers, and for audiences (from a speaker’s perspective).
Smile. This is a fun thing to do and you are thrilled to be there (even if you want to vomit in your shoes at that point).
Check your flies. You don’t want that breezy feeling half way through a code demo.
Take off your lanyard. It can bang against your mike.
Take off your earrings. If you have long, dangly ones they can interfere with headset microphones.
Do a sound check and walk the stage. If it’s being filmed check for black spots on the stage and avoid them. Get comfortable with the size of the stage, especially if you plan on wandering around.
Never apologise. You know your mistakes, your mistakes in your slides, things you forgot to say, technical issues. What the audiences doesn’t know, doesn’t hurt them.
Make sure you have water. A bottle by the lectern is enough. But, don’t drink it all the way through your talk like some kind of nervous tick. It’s just there for emergencies.
Use a good clicker. Check the batteries.
Check your radio mike is off before you go for an emergency pee. You don’t want to do a Naked Gun.
Don’t fall off the stage, but if you do, don’t acknowledge it. See point 5 to avoid this.
Finish strong. Empower the audience. Encapsulate your main point in one sentence. That last sentence should stay with everyone. Pause. Then say ‘Thank you’. Then the crowd will clap.
Don’t hide behind the lectern. It can feel like a barrier (or a safety net). Sometimes this is tricky if people are doing code demos or the like, but personally, I can feel like it’s a barrier between me and the audience.
Gaffer tape! If you do stay behind the lectern, pack some gaffer tape in your bag. Lectern’s have a habit of having a small lip that Macbook Airs tend to ride ride over. On a number of occasions, I’ve had to tape my laptop to the lectern.
Pace yourself. Put in pace notes in your slides. Just a simple 5:00 will do. Meaning, ‘At this point, I should be 5 minutes in’. This helps me know when to speed up, or fill. Plus, it’s a good barometer of your overall pace.
Make your point, but don’t make it angrily. Passion can sometimes come across as shouty arrogance.
Don’t say ‘can you hear me?’. If they can’t, they’ll let you know. Good sound crews will fade up your mike as you start speaking.
Focus on your words more than your slides. Again, this maybe personal, but I’d rather listen to well considered points, than look at pretty slides.
Find a friendly face in the first few rows. Try to block out the people looking angry, bored or just asleep. Yes, people fall asleep.
If you finish early, don’t worry, it just means people get more coffee.
Dress comfortably, not necessarily smartly. That doesn’t mean a suit, or a blazer, or a fancy dress. It means dress so you’re not thinking about your clothes. If you’re thinking about uncomfortable you are – for whatever reason – you’ll be off your game. People aren’t there to see what you have on, but what you have to say.
Don’t sell yourself, your company or your product. It’s not the place. People will not listen and get angry.
Questions and Answers. I’m not one for Q & A, but if there is, then make sure you repeat the question before answering it. Don’t take for granted everyone else has heard, plus, if your talk is being recorded, then listeners will need to hear it.
Is it being recorded? If the talk is being recorded make sure, when referencing something visual, you also provide enough context over audio so that people listening understand. Less of ‘this thing over here’, more of ‘I’d like to draw your attention to the heading in this example’.
I think, above all else, remember that if you’re planning on speaking this coming year is to enjoy yourself. Yes, it’s stressful. You’ll be nervous, you’ll be thinking ‘why am I doing this?’, but there can be so much fulfilment in sharing your work with your peers. And, really, that’s what it’s all about, isn’t it?
And, now, if you’re attending a conference this coming year, then here are a few tips, from a speakers perspective, on how to get the best out of attending the actual talks.
Be in the room. Personally, I’m not one for laptops, iPads or phones being on, but I understand people take notes on them. People also Photoshop pictures of the Queen and engage in Skype conversations with their mum. My guess is, these people aren’t listening.
Try not to fall asleep. I get it. You’re tired, you were out late last night, it’s warm and dark. But, really, it’s quite off-putting if, as a speaker, you’ve spent weeks fretting over the next 45 minutes and some bloke is catching flies in the front row.
Huddle up. Move along the row to the centre so people can get a seat.
Don’t talk, or heckle. Only the most experienced speakers (and I don’t count myself in that group) can deal with that kind of interruption. Plus, it annoys the people around you.
Be a friendly face. It means a lot to catch a friendly face in the audience. A disgruntled face can derail a speaker or a talk.
Be on time. Get in your seat in plenty of time before the scheduled session.
Listen and think before you tweet. I’d like to think people give talks the time to play out before forming an opinion. Sometimes, it can take 20 minutes for a speaker to make their major point.
I get the content in Word, copy into the various boxes in the CMS and then see how it looks. Normally I spot a few typos, or it doesn’t appear where I want it to, then I have to go back and find the article again – which isn’t so bad, it’s normally at the top. The real pain is when I have to add another link to that list over there. (whispers) Normally I ask James (a developer) to do that for me, though as I can’t do it.
This was a conversation I had with a person recently about how they use their CMS. A real-life content person. I say content person, not ‘creator’ as you may have noticed she doesn’t write the content. She just ‘gets it’. She’s a piece in the publishing workflow. A cog in a machine. And our tools are failing her and are only going to get worse.
In that workflow, there is a bit that’s a clear trend amongst the people I’ve spoken to about this.
then see how it looks.
And that’s the thing, right there.
Since we’ve been using computers to make websites we’ve tried to make them like print. Of course, early on, that was fair enough. It was familiar. We knew the rules and tried to make the web like it. Even now, with the realisation that the web has changed – or rather, we’re being honest to the way the web is. It never really changed, we just tried to make it something it wasn’t – we’re still enforcing a print-like mental model on it. Not necessarily us designers and developers, though. This is coming from people who write and manage content. Just like printing out an email before they send it, they will want to preview a website to see how it looks.
The problem is this: The question content people ask when finishing adding content to a CMS is ‘how does this look?’. And this is not a question a CMS can answer any more – even with a preview. How we use the web today has meant that the answer to that questions is, ‘in what?’.
Let me first off define what I see WYSIWYG. WYSIWYG is not a limited toolbar for adding semantic value to your document.
The kind of toolbar you find on Medium, or on Basecamp. As you can see they are similar. They are used for applying semantics to document structure; giving words emphasis, making unordered lists, or numbered lists, making words headlines. However, they’re not there for the user to get creative. They do not change the colour of a word.
When I think WYSIWYG, I think of the Word toolbar. This type of WYSIWYG is for adding tables, images, forms, type and colour. It’s a toolkit to create pages of content. Just like desktop publishing. And that’s the dangerous thing. Content creators are used to having these tools at their disposal so they can craft their document. Why? Because writing isn’t done in a CMS, it’s done elsewhere.
Times -are changing- have changed
It’s been a turbulent few years for web designers and developers. We’ve had to relearn what we’ve created and finally acknowledge – through the timeliness of Responsive Design – that the web is a fluid and chaotic place, and we should be embracing it and not making it like print. We’ve learnt to deal with the loss of control. The problem is, though, our content people are still thinking of pages. They’re still thinking of previewing. Of designing for the desktop. They’re writing in Word and fine with it.
So, that’s the challenge. How can we help people – just as we have – relearn how the web is now?
Just like when people have a content management problem, a lot of people are turning to technology for the answers. And just like content management problems, my experience is software can’t fix it. Because it’s a people problem, not a software problem.
The three places of content management
There are three spaces * for content people – not creators, because not all content people create loads of content. Some just manage it – push it from here to there. Those places are:
- A space for writing. For writing and structuring.
- A space for management. For adding meta data, workflow, configuration and managing roles and people.
- The website space. Basically your website. A place where you begin the access user journey. Or preview your content. Generally the starting points for lots of little administration tasks.
- There are other spaces, too. The developer space, where the site is administered and created, managed and evolved. Sometimes this is through an administration interface, but not always. Sometimes it’s just through an API.
The problem I see is that the CMS tries to deal with all three spaces equally well. And as such, generally fails to deliver an optimal experience because it’s trying to do too much. What if your content management system was actually three distinct applications designed to work together? Just a thought.
But, back to WYSIWYG.
The issue with WYSIWYG for me is that by using them the content person is considering the content as what they see. But content is more than that. Especially if it has meta data, and is split up and compiled from here and there. A ‘page’ maybe a dynamic template pulling in content from a dozen places. How do you change meta data there?
If we consider the majority use-cases of correcting typos, restructuring slightly, or small on the fly editing, then the smaller toolbars for adding semantic value are useful. But for most use cases, a WYSIWYG is not useful for content people. It’s just familiar.
Inline-access, not inline-editing
One of the other pain points of a complex dynamic website, where ‘pages’ are created with bits of content from all over the place is ‘where the hell do I go to find that bit of content to edit it?’. That is a painful moment in a content person’s daily life. Normally, after watching them, they go off deep into search, or ask someone else who knows better. Accessing these smaller nuggets of logic-based content is problematic. This is why inline-editing and WYSIWYG is coming to the fore – addressing the use case in the live environment.
Why is this a problem?
As I said before, it’s hiding the truth. That being, the content is more than you can see. Instead of inline editing of the content, why not just make the start of that journey a little easier? Why not provide a way of quickly getting to exactly that bit of content with a link? There we will see all of the stuff that is the content but not the words: the display logic, taxonomies, meta data etc. But if we want to change a type, we can do that with our little toolbar.
Not one tool, but many. Not one way, but many.
Structured content is the right way to go. It makes our content portable and malleable. In fact, it makes it much more useful. Slapping a WYSIWYG on top of a form field is not the way to go. That’s not structured. Live WYSIWYG is not the way to go for large-scale websites because it reinforces that content is just what you see. When, in fact, a piece of content could have a whole bunch of other headlines and summaries that would only be displayed in certain contexts, along with meta data and rules. We need access to ALL THE CONTENT and provide simple, little tools to let people make typo changes and apply semantic structure and the like once they’re looking at the content in a staging environment.
‘How does this look?’
should change to:
‘How does this read?’
Device agnostic. Screen size independent and devoid of design. Let’s help content people focus on what the words and pictures are, rather than what the words and pictures look like.
My uncle is a quiet man. He smokes a pipe with a wry smile. Like he knows something you don’t. For years he restored traction engines; huge, victorian, steam-driven machines. He did it for the love of it. I have wondered if he did to escape. Like a lot of men that age, he spent a lot of time in his shed on his own, surrounded by the smell of oil, grease and pipe tobacco. A dusty pile of tabloid newspapers in the corner. Slowly whittling away on a small piece of metal, making some grommet or flange or something.
Sounds romantic doesn’t it?
Now, how many times have you heard web designers and developers talk this way about their work? For me, it’s been increasingly. And personally I find it concerning. For starters, it’s a designer-centric way of working. It’s a selfish exploit to pour love into your work. If you’re working commercially, who pays for that time? You? Well, that’s bad. The client? Well, that’s ok if they see the value. But many don’t.
Giving your work love is not just about giving it time. But, time can often be better spent than whittling away on some nubbin’ or grommet just because you think that’s where you can give the work your love. Your craft.
Over the past few years, I’ve spent more time on projects not whittling. Whittling happens in the very latter stages of work and I really don’t find myself in that place very often. Mostly that’s because the clients I work for have a myriad of big, sticky problems that need working out before you start ‘crafting a user interface’, whatever that means. I’m more often than not in a place where my own job, as a designer, is to not make something I love. But to make something appropriate. Something that does the job well. Something that responds to a hypothesis and serves a need. Not necessarily something loved and beautiful. And that’s ok.
Craft is an emotional word not appropriate to describe the job of designing. It’s too self-centred. Too mired in arts and crafts and puts a difficult-to-measure parameter into the minds of clients.
‘I want a beautifully crafted interface from a passionate designer’
‘I want a self-centred designer to spend way too long on the shiny than actually solving the problem or having the difficult discussions’.
If my uncle was restoring traction engines for a living, he would’ve been out of business. Craft is love. And love takes time. And time is scarce and probably best spent elsewhere.
Twenty years ago today, CERN published a statement that made the World Wide Web freely available. To mark this anniversary, CERN – together with Mark Boulton Design – are starting a project to restore the first website and the associated assets of the World Wide Web project.
I first started using the internet in about 1988. I had a mate whose dad worked for IBM so he had an early PC connected – via the phone line – to a rather sophisticated little modem. The internet wasn’t the web back then, it was a mix of bulletin boards, rudimentary email clients and IRC. You may think that it was a primitive, but in reality, the prospect of near live discussions and collaborations with people all over the world was pretty incredible. As friends do, we lost touch, and my connection to the internet was lost with it. I did other things: failed my A-levels, learnt martial arts, chased girls, learnt the guitar and went to art college. My connection with internet picked up again in 1994. And, oh boy, was it a different place entirely. In just a few short years, the web went from idea to proposal to freely available. And the world was changed forever.
As web designers and developers, we spend a lot of time trying to explain the difference on the web. “It’s not TV, it’s certainly not print” (oh, no, it’s definitely not that). The web is its own thing. But unlike other media – ones which have physical artefacts, which get left behind to rot, to be found and stuck on a shelf in a museum – the web doesn’t have that. Pixels don’t decay, they just disappear. Forever.
Preserving our digital heritage is as important as preserving our physical heritage. There are a few people and organisations in the world who get this: The Long Now Foundation and Archive.org, to name a couple, but I’m not sure that’s enough. The need to preserve must come from our desire to learn from the past. I have two young children and I want them to experience the early web and understand how it came to be. To understand that the early web wasn’t that rudimentary but incredibly advanced in many ways. Currently, it’s impossible to do that. And, together with CERN, that’s what we’re hoping to provide.
From today, we’ve started work on the project objectives. The talented web team at CERN have already reinstated the first URL and uploaded a version of the website from about 1992. The restoration has begun.
To keep up to date on the project you can read the project blog where we’ll be posting updates on progress. You can also follow on Twitter @thefirstwebsite.
Read the announcement from CERN and two opinion pieces from Robert Cailliau and Vint Cerf
When I passed my driving test, I had a couple of advanced driving lessons a few months after. One day I remember particularly well was when my instructor told me I had to provide a running commentary to my driving. It went like this:
“I’m currently driving at 38 miles per hour in a 40 mile an hour limit area. There is a child by the road and moderately close parked cars. I’m approaching a zebra crossing and there are no pedestrians so I’m proceeding with the flow of traffic. Up ahead there is a t-junction, so I check my mirror before slowing and approaching the junction in second gear. Indicating left. I look left and right…”
You get the idea. It’s a good exercise but I couldn’t keep it up for long – especially as someone who doesn’t really like to talk when I’m driving. The aim of the exercise was to put you firmly out of your normal driving preference and teaches you externalise your thinking and focus on your observation, rather than the physical mechanics of driving a vehicle.
Think Do Thinking
A good few years ago, I wrote about my experience with the Myers -Briggs psychometric questionnaire. Whilst the validity, and reliability, of them as a tool for assessing personality is certainly up for debate, I’ve found them useful in understanding my preferences. Probably the most useful to me is highlighting my introverted preference. To clarify: this doesn’t mean I don’t like people, overly concerned with my own thoughts or ability, or am socially outcast. What it means is I prefer – most of the time – activities which are solitary. It’s been that way my whole life. When I look back at the activities I’ve done over the years, they’ll always been solitary: martial arts, athletics (javelin), angling, using computers, drawing and painting. Now, I ride a road bike. Mostly on my own.
When I step outside of my preference – which I do all the time – it takes extraordinary amounts of energy. I’m physically and mentally drained, even if I’m having an amazing time. Simply being outside of my preference has that effect.
More does not equal better
Designing and building websites is a collaborative affair. It takes many people to build some of things we work on, and constant, close client contact is essential in doing so. But, I’d say we do it only when it’s appropriate to the best work given the people involved.
I see plenty of banner waving for collaborative working. Co-designing, pair programming, brainstorming, collaborative workshops. The overwhelming message is that these tools are better for reaching consensus, sharing work, and, ultimately, lead to better work. Well, I’m not so sure that’s the truth. Given my introverted nature, sometimes these activities can rush the process too much. They allow no time for me to think. Instead, I’m sitting there dreading the ‘tell everyone in the room what you do on this project, and a funny anecdote’ question. Yes. That still happens.
For many introverts, this is not good work. And it certainly doesn’t lead to better work.
If you’re one of those people who thrives when working in groups. Someone who gets a real kick out of developing product ideas in a brainstorm environment, or think it’s great co-writing user stories in a room of eight people, plenty of coffee and doughnuts, then great. I’m happy for you. And no doubt, you’ll end up with something you’re very happy with as you prefer to work that way. But, please, stop forcing this way of working on those of us who’d rather not under the notion it’s better.
Personally speaking, a lot of the time, I’d rather listen to what you have to say and go and have a good think.
For a great insight into the power of introverts (and how to get the best out of them), you should first watch Susan Cain’s TED talk, then buy her book.
In 1955, Beatrice Warde gave a presentation to the Typographer’s Guild in London (now, the International Society of Typographic Design) which later became an essay titled: ‘The Crystal Goblet, or Printing Should Be Invisible’.
A wonderful piece of writing in which Warde describes the role of typography – or rather the role of the designer - in printing. The general premise is that good typographic design shouldn’t be seen.
When you listen to a song in a language you do not understand, part of your mind actually does fall asleep, leaving your quite separate aesthetic sensibilities to enjoy themselves unimpeded by your reasoning faculties. The fine arts do that; but that is not the purpose of printing. Type well used is invisible as type, just as the perfect talking voice is the unnoticed vehicle for the transmission of words, ideas.
Let’s take that last point. Morgan Freeman has a memorable, wonderful speaking voice. One that adds colour and weight to the words. His words are not just audible, and understandable, but they are rich with personality. His voice adds to the words he speaks.
I disagree with Warde. Type should not always be invisible, it should be appropriate. Sometimes, it’s a typeface’s job to be overt, loud and suggestive, in order to communicate the content in the best way. But, yes, sometimes typography has to melt away into the background. To support the content and the reader. To help them.
On the web, because we’re quite often presented with long-form text (and by that, I mean more than a few paragraphs), we get a little obsessed with body copy. Good typesetting of body copy should be like that of setting a novel; the type should disappear. But, not all typography is body copy, and to consider it in these narrow terms is to do the practice of typographic design a huge disfavour.
Whenever we design with words, we’re designing with type. And words are not always long form paragraphs designed to be very easy on the eye. Sometimes it’s a logotype, a button, a richly designed layout, a data table or form. The application of typographic design is just so broad that to say it all has to be invisible is to imply the goals of typographic design are the same across the board.
Legibility is a baseline requirement for typesetting anything. It’s like edible food. It shouldn’t really be a measure of what is good or not. Just like audibility and comprehension are baseline requirements for speech. There is more flavour in words; spoken or printed. There is more flavour in type, that if applied well, transcends content from being merely legible, to that of being pleasurable. After all, that’s why we have different typefaces: each brings with it characteristics that flavour the words.
Nick Cox says in his article, ‘Typography should be visible’:
In my opinion, there is merit to visible typography because in the hands of a competent typographer, a text can truly sing. Not because they have left their mark out, but because they have worked their art on the words.
I agree which him completely. It’s the difference between something edible and exquisite. The difference between average and better. Which is why all this invisible, reductionist UI approach is starting to grate on me a little because it suggests we have the same goal for all our work; to make it invisible. It’s more complex than that. It’s an over-simplistic measure of success that is put far more eloquently than in this post from Timo Arnall.
Of course, I say all of this under the one big caveat that, in typography, there are no rules. Just good decisions. But, let’s make some decisions shall we? Not make everything invisible because, apparently, that’s the way it should be.
Eighteen months ago, I blogged that we’d started working with CERN on redesigning their site. A dream project for me. And one that is in its final chapters as the site went live last week. But, as with all great stories, as one chapter draws to a close, another starts.
This week I’m at CERN in Geneva, but I’m not working for CERN. Mark Boulton Design has been asked by ATLAS to help them redesign their public website. It’s another dream project.
ATLAS is a collaboration of three thousand physicists, engineers, computer scientists and support staff, in forty countries, in one hundred and seventy institutions from around the world. One big scientific melting pot, who have built one of the most complex machines known to man which is connected to the Large Hadron Collider. They’re one of two experiments to independently observe a particle that behaves consistently with the Higgs Boson. In other words, whilst they share similarities with CERN, they’re actually quite different.
I’m thrilled to be working with such a progressive, interesting group of some of the smartest people on the planet, working on some of the most historically important work that humans have ever done.
Last week, CERN quietly redirected their URL to the new site. And Mark Boulton Design and the CERN project team saw the chapter close on nearly two years of work.
There is much to talk about with a project of this scale. Probably the first thing to say is that this was not a website redesign project. The project started with the very simple statement: ‘we have a content problem’. I’d like to think it’s a problem we solved, but it also went much deeper than that.
CERN is an organisation that supports collaboration. In fact, CERN is comprised of many collaborations; more community than organisation. We have a bit of experience designing with communities, and the teeth we cut with the Drupal community came in very useful here.
As we all know, the question ‘why wasn’t I consulted?’ can derail almost any endeavour. This was no exception. So, early on in 2011, the Mark Boulton Design team spent months talking and listening. In fact, the majority of our first six months on the project was spent trying to understand CERN’s audience – both internal and external – and what CERN does for them.
As in 2008 and 2009, when we worked with the Drupal community, designing for community relies on one thing: listening for trends. Design by committee doesn’t work because there are relatively few stakeholders and sometimes with big egos. Design by community works because of the sheer numbers and relatively flat hierarchy. Instead of ensuring the boss is consulted, it’s more important to consult with just two types of people: those who have influence, and those who have a big mouth. Get both of them on-side, and your job will be easier.
CERN started with a content problem. To really understand how content was to be reorganised, rewritten, and – in some cases – deleted altogether, we needed a plan. Not only that, we needed to understand how this content was being consumed and where. We needed a content strategy.
We embarked on a good few months of content research – audits, interviewing, process-audits and the like – before producing a strategy that sat alongside a new Communications strategy from the CERN comms team. Together, these would redefine how content is created and managed at CERN, and how it gets published to the web.
The new content for CERN is Future Friendly. It’s adaptive – meaning it’s carefully chunked into small fields in the CMS and tagged with really great meta data so it’s able to shift and flex into different containers. No WYSIWYG here. Just really smart, well-structured – and reusable – content.
To my mind, good design decisions rely on good research. And for this project, we had some great research throughout. A broad amount of data was gathered by various means and filtered down to the design and product team. Not by way of reports and documents, though. In my experience, these often get cast aside. No, in our team we had Emma embedded with the design team. Always present with up-to-date insights into the audience needs so that she could literally sit beside us to help us guide some of the design decisions.
But it’s not just for us.
CERN now has detailed information about their users available for anyone who creates a website, or writes for the web, at CERN.
I’ve written about the design strategy for CERN before. How the content needed to inspire, educate and inform the various audiences of the website, but we needed a simple model in order to map the content and the subsequent presentation of the content. Our Make Mantra – Create Wonder – was born, and is still used today as way of gauging how content is to be created and presented.
Practically, we did a lot of prototyping and very little else. Prototypes became the way we experimented with concepts, discussed and communicated ideas, worked on responsive elements. These prototypes then quickly moved from static HTML into dynamic lo-fi Drupal prototypes. This was so editors could get writing content quickly – actually using the tools they would eventually use on the site. All the while, we were continuing to iterate. In all, I think there were 5 or 6 alpha releases, 8 betas and many, many pre-alpha prototypes.
The new CERN public website runs on Drupal 7 (the most recent version of Drupal, that we designed the UX and UI for). It’s mostly an out-of-the-box installation with a few bespoke modules that integrate with internal services such as CDS (CERN’s media server) and Indico (the event management database).
I don’t often do it, but this is the bit where I get to gush a little. The people involved in the project is pretty epic. But, there was a core team of designers, developers, product leads, researchers, content strategists and journalists that deserve a mention. Without them, this project would not have turned out the way it did.
Mark Boulton Design
- Dan Noyes: Project lead
- Silvia Tomanin: Drupal development
- Cian o’luanaigh: Editor
- James Gillies: Department head, project sponsor
Such a smart team. There are of course countless others – probably hundreds of people – I could thank. But, this isn’t the Academy Awards. If you helped, you know who you are, and I’m very grateful.
A special project
This project always was a bit different. CERN is a special place, yes, but it takes a degree of risk and subsequent trust for an organisation of this scale to work with an external company for such a length of time. CERN invested time and energy to work with us at Mark Boulton Design. When we suggested radical changes to process due to our research findings – things that have had disruptive effect on the communications of the organisation – they didn’t flinch. They knew it was the right thing to do. And supported us in our proposals. That takes a very special type of client; one that is willing to truly partner with a design company. And, I’d like to think the results speak for themselves.
Not just a website
When I reflect on the past two years work on this project, it’s easy to think of it as ‘bloody hell, that’s a long time to make a website’. Well, yes, it is if that’s all we did. But, in the words of James Gillies, Head of CERN communications team and project sponsor:
The launch will mark a significant change in how the Organization facilitates communications within the CERN community, as well as how it presents itself to the world. The first thing that you will notice is that the website looks different, but the most significant changes run deeper, and they form the basis for a new communications architecture.
He goes on to say:
There are many ways we could have chosen to build the new CERN website. We could have asked designers to create something beautiful. We could have created a template for content. Or we could have tweaked our existing websites. Instead, we went back to basics and reflected on who we want to reach and what their needs are. Then we asked them to help us. All our stakeholders have had an opportunity to influence our new website, and many of you have taken that opportunity. We have conducted regular audience research through online polling, usability testing, and in-depth one-on-one interviews, receiving feedback and input from thousands of users. I would like to thank everyone who got involved: your feedback has directly shaped many of the design decisions and turned this into a real community effort.
You see, it wasn’t just a web site. It was helping CERN understand who they’re talking to, what they’re saying, and how to say it. Then, giving them the means to do it.
You can read more about the CERN launch from James Gillies.
Breakpoints. Break. Points. Points at which things break in your design.
But, at what point did they start becoming ‘the point at which I will create a new layout entirely’, or ‘the point at which I introduce a new canvas’. What started out as a method to optimise your designs for various screen widths has turned, ever so slowly, into multiple canvas design. We’re creating pages again, and we probably need to stop it.
A breakpoint should not necessarily be a point at which we wholesale swap out to another layout. It can be – and I think there are good reasons to make some of those big, macro changes to grid system or navigation patterns. BUT, I think we’re missing a trick for using breakpoints to make lots of subtle design optimisations.
Jared Spool said in his recent article strategy for responsive design
A responsive design can have multiple breakpoints, say for a small-screen phone, then a large-screen phone, then a tablet, then a laptop/desktop. Many teams try to decide on breakpoints using average screen sizes.
However, it’s better to look at what the content and navigation wants to be. By letting the content and navigation drive the breakpoints, teams find they can often get away with fewer screen configurations. For example, a high-resolution Retina iPad might easily share the same configuration as a well-constructed laptop display, while lower resolution tablets might just need a little adjustment to that same configuration.
Our experience at Mark Boulton Design is that we can actually tend towards more breakpoints than fewer if we take the approach of optimisation rather than a device-centric, display-size approach. We’re moving towards including all media-queries in-line in the CSS, rather than abstracting them into their own 480.css file, and we keep the big macro-layout changes in the Gridset CSS. But, interestingly, what we’re seeing is we have less styles associated with more breakpoints as we’re not creating a whole slew of different, fixed layouts and all that goes with that.
‘But, what is content-out design?’
I first discussed the idea of content-out design in the context of a page. A page with edges that is used to define an aesthetically pleasing layout within. On the web – especially the responsive web – we don’t have edges, so it’s best to define your layout from your content. But – and I get asked this a lot – what does that actually mean in practice?
Firstly, it means defining your grids (your big macro break-points, and the columns and what-not) from actual content and not from devices or screen widths. This could be the size of an image, or an ad-unit, or the typographic measure. Just some ‘fixed’ constraint. This will give you your grids.
As you’re building out your responsive design, you should be focussed on watching how the content adapts as the viewport changes. Somethings I look out for:
- Type size and leading. Does it need to change?
- White space (macro and micro). Do you need to adjust margins and padding?
- Vertical space. Do you need to reduce it and make the content more or less dense?
- Flow. How is the readers eye movement going to change as you change these elements?
- Words. Are there now too many on one line? Or too few?
- Source order. Are the right things in the right place?
Focus on the in-between
Content-out design means defining your underpinning design structure from your content, and then focusing on what happens in between ‘layouts’. This approach of optimising your design by adding media queries (I like to call these optimisation points than break points, because nothing is broken without them, just better), means you are always looking at your content as you’re working. You become more aware of the micro-details of how the content behaves in a fluid context because your focus shifts from controlling the design in the form of pages, to one of guiding the design between pages.
For more reading on this, have a look at ‘There is no breakpoint’ by Ben Callahan in which he details optimisation points in a little more technical detail.
Things are a changin’
I find this period of change we’re in right now fascinating. Not only is centuries old design theory being rewritten, but the process of how design happens is changing too. It’s becoming more collaborative, more fluid, lower fidelity. Less about being squirrelled away in a dark corner crafting a beautiful thing, and more about scribbling away in public and repeatedly throwing our work in a big trash can. And the more we’re doing that, the better we’re getting.
Optimisation points are just one way we can start thinking content-out. And thinking content-out is what we need to be doing to create truly native experiences on the web – wherever the web is.
My four year old daughter attends a rural primary school in the Vale of Glamorgan in Wales. The school performs in the top 3% in Wales. Consistently. It’s over-subscribed with waiting lists to attend. The head teacher greets every pupil – by name – at the school gates in the morning. She even knows my name. It’s a school you feel part of. And the government wants to close it.
We learnt this week that, as parts of plans to change catchment areas for secondary schools, that my daughter’s wonderful school is in a list of a few schools that are pencilled in for closure. The pupils will be sent to other, under-performing, under-subscribed, urban schools. We have a small window to fight these changes, but it seems that once this process gets started, it’s difficult to reverse.
When I picked my daughter up yesterday, she told that the head teacher had told them in assembly that everyone is going to fight for their school. That mummy’s and daddy’s should write letters, they should too, and we should make posters. A wonderfully simple attitude to a dreadful situation. I gave her a hug.
As soon as we got through the house door, my daughter went straight to her desk and asked me if she could write a letter to the men in charge. This is it:
Change. I love my school. Please don’t close it. Change your mind. Love, Alys Boulton.
This is what the men in suits don’t see. They don’t have to sit there and explain it to a four year old that thinks it’s all going to be stopped with a couple of posters. They don’t think about the illogical idiocy of closing a top, over-subscribed primary school. They think about numbers and averages. They don’t think about rural communities, or try to understand why this school is doing so well. No. Thinking about averages leads to average. And who wants that?
So, we’re going to fight. With every last breath, I’m sure this school is not going down without a fight.
On the run up to Christmas, that wonderful annual advent calendar 24 Ways published an article called: How to make your site look half decent in half an hour . In some designer quarters, this was jumped upon as a load of unconsidered twaddle written by a developer who shouldn’t be dishing out design tips. Aral Balkan took this task and has written a great article that follows my thinking as to what ‘design’ is. All good. But, I’d like to comment on what I thought that 24 Ways article was about, and really the indication of a perception of design across web professionals.
For the past few years, I’ve been teaching a workshop based on my book, Designing for the web, to lots of web people, but mostly to developers, front-end devs, UX folk and project managers. All of them have come along to the workshop to learn just one thing:
‘How do I make this thing I’ve done look less shitty?’
Now, if you’ve read my book, or my blog for a while, you’ll know that I see design as a holistic practice; a practice of understanding content, of audience needs and goals, of brand, of psychology, and, of making things look less shitty. As much as designers would like to think we’re the guardians of all things considered practice, taste, and learned process. We’re really not. Some of the best designers i’ve worked with have embraced the passionate learning of students and amateurs. People who are not interested in becoming professional designers, but want just enough knowledge about an aspect of design to make their thing better: be it their resume, their website or their father’s cafe menu.
Getting stuck in
There is nothing wrong with getting stuck in. I’m not a carpenter, but I’ll get stuck in and learn and renovate my bathroom. I’m not a bike mechanic, but I’ll learn enough to maintain my road bike. I’m not a developer, but I’ll hack around with a bit of PHP to get to where I need to be. Many people would not class themselves as designers, but they can arm themselves with techniques to make themselves better at an aspect or technique of design.
There are many ways to Define The Damn Thing, but for me, design is really just the result of a bunch of questions and answers. These questions may be asked by the materials you’re working with, the constraints of the project, or the audience you’re designing for. They may be big questions such as ‘how can we increase quarterly revenue by redesigning this checkout procedure?’ Or, they may just be small questions like: ‘how can I make this content just look a little less shitty?’. These are both equally valid questions.
The answers to these questions are design. Some answers are big. Some are difficult. Some seem like magic. But most, in my experience, are well-trodden cowpaths of practiced techniques. Simple little things we do to make less shitty things.
So, design is veneer. But Aral is right, it’s not just veneer. Even if you wanted it to be, visual design is not a thing, and we should be mindful to not present it as such. But that’s not to say we shouldn’t help people who aren’t designers make less shitty things by giving them a few hints and tips along the way.
The humble hyperlink is an incredibly simple, powerful tool on the web. In fact, many would say that our ability to link one resource to another via hypertext is what makes the web what it is. But, I think this humble link could do a little more than it currently does.
What’s the problem with links?
When the web was invented, the hyperlink linked resources together. That hasn’t changed. What has changed is the type of resource that may be linked. In the early days of the web, resources were documents of text. They then changed to images or tables of data within text, but it was still text. Now, an html document is still the resource, but the primary piece of content maybe something completely different: video, audio, a download to a file, it may be secure. A link may trigger an action along with linking, such as going fullscreen, a pop up, or linking to another site. All of these things are valid links, but we have just one element with a bunch of attributes in the code to describe them. I’m not so sure it’s enough any more.
What do I get when I get there?
Here’s a link to some content
It’s correctly marked up in the HTML, but perhaps badly framed editorially. You, as the reader, do not know what that destination is until you click it. ‘Just make the link text better’, you may be saying. Ok, how about this:
Here’s a great article about cats
That’s better. It’s implying a link to an article. The meta data for the user expectation of this content is in the content itself. But, we can’t always rely on our content creators to reliably do this. And what if the content was more complex, like a report:
Read our annual report
Is this a link to a web page, a PDF, a word file, a link to download an app from the app store? What is this?
And that’s the issue. I’d like to know what I’m getting before I click it. I think we need more meta data around our hyperlinks that can give us more of an indication what we’re getting before we get it. I became painfully aware of this just a couple of days ago when I clicked a link and started downloading an HD video, over Edge, that started auto playing. Luckily I wasn’t on data roaming at the time.
How can we give more meta data with our links?
There could be a few ways we could do this. Obviously, we could just write the type of link, destination and other stuff in the content. But, if that destination changes somehow, that’s an added overhead for the content creator. Plus, you could end up with quite verbose link texts.
We could use the
<type> attribute introduced in HTML5 to specify the Media type (formally MIME type) of the linked document. This is exactly what we should be doing, actually, but the options don’t necessarily map to our content needs, or provide all of the content type requirements. For example, I may want to link to a video, as that’s what I want the reader to watch, but the HTML resource is not a video at all, but a video embedded in an HTML page with a whole bunch of other things. In that case, the
<type> attribute would be inappropriate. The same could be said for audio, or any other primary content that is embedded within an HTML document.
I feel we need two things: some visual affordance for the user that they’re going to a particular type of content; and this affordance is rendered through an attribute, or something similar, in the HTML of the link.
We’re already doing this. Sort of.
In designing around this problem, I’ve noticed through my research that we’re already doing this. We already have conventions used on sites like Wikipedia, and others, for indicating, after a link, what will happen when you click it. Here’s are two examples from the BBC and Wikipedia.
The thing is both of these examples use the icons to append list items. They’re not in paragraphs immediately following the link wherever that link may be.
Like Jeremy, I like Sparklines a lot, too. Edward Tufte describes them as:
…a small intense, simple, word-sized graphic with typographic resolution.
Sparklines are efficient representations of complex data that typically sit within content to provide additional semantic value to the content. They’re a small hit of additional information. A picture speaking a good few words.
And I think he’s onto something there and it’s something we could use for this problem.
What would it be like to expand on what we have now? How could we provide more meta data – where appropriate – than just an icon as demonstrated on Wikipedia and the BBC.
What we could do, is include some more information, for quick visual digestion, alongside an icon. We could take Tufte’s Sparkline rationale and apply it to this small, inline iconography. We could use a Sparkicon.
I’m defining a Sparkicon as a small, inline icon with additional link meta data to describe either the content and/or the behaviour when the user clicks the link.
I’ve looked a couple of examples of how this might work. The first example shows two icons to indicate behaviour when we click the link. The first is a full screen icon, the second is one we already know: an ‘external site’ link.
The second set of examples are icons for particular content or media types: comments and video. The comments includes a count of existing comments attached to the link document. The video spark icon includes a video duration. This could also include things like aspect ratio, or HD, or whatnot.
Degrading the reading experience?
I think the challenge with sparkicons would be to give enough feedback to the user to let them know what’s going to happen, or where they’re going to go, or download and what are the consequences of clicking this link. That’s the important thing, and history tells us we can’t rely on the words to do that.
But we also need to be mindful how much of an interruption this will be to the ebb and flow of reading long form content. Also, how much added visual noise would this add? At this point, I just don’t know, but I plan on putting this to test soon on a couple of projects: both personal and professional.
There are plenty of challenges, particularly how this could just be some kind of applied graphics through a simple addition to a link attribute. Standardisation is also an issue – this type of icon would be only really useful if it’s a shared convention.
But, it’s just an idea right now that i’m plugging away at. More to come.
Pattern primers, style guides, pattern libraries. They’re all the rage. And they make good sense, but I think we’re in danger of working back to front.
At Mark Boulton Design we get quite a few project enquiries and over the past twelve months we’ve seen an increase in requests for these repositories as a project delivery. This is just fine for us, as we tend to propose them anyway in some form or other to document our work. But there is an inherent concern in delivering this type of thing to a client. When is it done? And how is it created? And making sure that is discussed with a client, in depth.
My first exposure to style guides was through print and branding. Corporate style guides are rules of execution; position this logo like this, use these colours, this type, crop photos this way. Adherence to the guide is critical and there’s always someone policing them. Having been involved in the creation of a few of these printed style guides, they are always designed after a body of work and then – almost without exception – never updated to reflect slight organic changes as a brand or design system grows. This is why digital style guides are good. They allow growth.
I’ve read recently that some designers are starting with patterns. Taking small modularised chunks of content and then compiling for display in different circumstances. This, of course, if great for taking an adaptive content approach. Thinking of our content in small chunks is useful. But, I can’t help but thinking that approaching design in this way is a folly and will result in generic, cookie cutter work.
When to abstract?
DHH from 37signals wrote a great post recently about the abstraction of code and when it should be done.
Future coding is a lot like playing the roulette. If you can guess where the requirements of tomorrow will land today, you’ve just scored the ultimate programmer’s prize: looking like a wizard. You saw the future and you were right! High five, brain!
That’s the almost irresistible draw of “flexibility”—often just a euphemism for building half or whole features before you know how they’re supposed to work or whether you need them. Just like in Vegas, the worst thing that can happen is to be right about this once in a while.
And that’s exactly how I feel about creating style guides. There’s a lot of talk about us designing systems for the web. Well, sometimes, we’re not designing systems at all. We’re designing a couple of pages for a marketing web site. Creating a whole pattern library for a project like that is not only overkill, but completely inappropriate.
But the same can be said for a large scale project too. If you don’t know what the patterns are, you could be abstracting too early – bowing to the lure of future flexibility.
I guess it’s a question of balance, and one I’m becoming acutely aware of recently. For me, style guides are still there to document a design system. But they’re not a tool kit of parts. Before you design a tool, you have to know what to fix first.
I started this blog in 2004. Nearly a decade later, I’d like to think my motivations for writing this blog are are same: it’s a diary, first and foremost. A place where I can document my thoughts, observations, theories, design critique and more. It’s also a place where I can engage in a wider discussion. My blog post responds to yours – or your tweet – and so we go around.
Over the past couple of years, we’ve seen more and more great industry-focussed magazines that publish online and off, but the flip side to this is I’m noticing more people writing for these magazines and less so on their own blogs. Why is this a problem?
Considered, well-written, edited, and produced content is hard – and time-consuming – to do. Writing an article for one of these successful publications is not an easy thing (well, for me it’s not). Not only do you have to have something notable and interesting to say, but you have to stick with it through the editorial process. You get pushed, prodded and cajoled along the way – mostly for the good, I should say. But sometimes, you may begin with a pithy throw-away idea that wouldn’t amount to a couple of paragraphs on a blog (kind of like this blog post, really), but through the process it gathers weight – and in some cases bloat – to fit the requirements of ‘an article’. And articles are different to blog posts.
In traditional news journalism, this is the difference between a feature and a piece of news. A feature is a story. It has a beginning, a middle and an end. It’s designed to have a less time-sensitive, longer shelf-life. But ‘news’ is transitory – documenting a period in time. It doesn’t have a structure like a feature does, and probably doesn’t have to adhere to the same editorial workflow. What we’re seeing on this increasing number of publications are features. And because the authors are writing these pieces, we’re seeing less shorter form writing because that type of content has no-where to live, other than blogs and everyone’s busy.
I’d like to see more balance again. More short, scrappy blog posts (like this one), written off the cuff and in the moment. Sometimes, I’d like to read the author’s actual voice, instead of a homogenised edited one. There has to be a space between 140 characters and 3000 word feature. We all need to blog more, I reckon. Roll on March.
Every couple of years I write a short post to document the year before. This was my Two Thousand and Twelve.
The year started with me taking a month off client work to finish writing my book. It went well, but one year on and i’ve still not finished it. It’ll be done soon.
I blogged more in 2012! Hurray! I redesigned this blog and took it back to how I wanted it: simple, designed for long-form content. Most importantly, it now runs on Statamic and is designed for how I write. I’m really rather enjoying it so far.
2012 saw Emma, Alys, Nansi and I take a holiday in Portugal for a couple of weeks well-earned rest. Alys started school and in September, we all moved house. Going from a relatively new house that we’d spent ten years getting exactly how we wanted it, to a two hundred year old cottage that we’re currently ripping to bits. It’s been interesting and 2013 will be the year I skill-up on DIY. From plumbing to plastering, I plan on doing it all myself, starting with the bathroom.
The summer was amazing. Non-stop sport for three months: from Le Tour, to Wimbledon, to Euro 2012, to the Olympics. I’m still suffering withdrawal.
This year has been a great one for Mark Boulton Design. We’ve worked with some great clients, and continue to work with them into 2013 on some really exciting projects.
We launched a product in 2012, too! Gridset continues to thrive helping people make responsive grid systems for the web in a jiffy without miring themselves in all the difficult maths.
Five Simple Steps released A Practical Guide to Managing Web Projects, and announced a series of smaller books coming up in the next couple of months. We’re really rather excited about it. Five Simple Steps continues to be a heap of work for Emma and the team, but ultimately rewarding despite the late nights!
I travelled quite a lot in 2012 with conferences and business trips. All in all, I was away 80 days and visited nine countries: United States, Doha, Dubai, Australia, Germany, Netherlands, France, Switzerland and Portugal. I spoke, and taught workshops, at some fantastic conferences this year – a great mix of local, small single-track events and larger multi-track events: IA Summit, UX Bootcamp, Future of Web Design, Reasons to be Appy, DrupalCon Munich, Reasons to be Creative, Smashing Conference, Refresh LX, Fronteers conference, Web Directions South, and Beyond Tellerand.
I’ll still be speaking next year, with a couple of events already lined up in the first half of the year that I’m very excited to be part of.
What does the new year hold? I’m not a big one for predictions or a follower of trends, but this is where my focus will be:
Writing, speaking, teaching. As I said a few weeks ago, speaking and teaching is an important part of our work and I’m honoured to participate of a community where we (largely) welcome it.
Balance and Focus. I’m reading a lot, recently, about people ditching social networks, over-sharing, spending more time making axes and keeping bees etc. But this is happening to a certain age of person who’s been doing this web-thing a while. This reactionary behaviour is something socialogists have been seeing for a couple of decades now in the general public in the UK with regards to technology. What it represents is a desire for balance. I’ve spent the last two years working on balance, and up until the last few months of this year, I’ve been better at it. And that doesn’t mean using Twitter less. It means making sure I give myself, my family and my work equal amounts of time and attention. I’ll be spending 2013 getting even better at doing that.
On to work stuff…
Community. I hope it’s a more considerate year. I’ve had a gut-full of embarrassing, unconsidered discourse on Twitter and I hope we see a lot less of it this year in favour of responses in blog posts or in person. I hope it’s a year of respect.
Web Design. I don’t think responsive web design will be the defacto method of web design. Not yet. As long as advertising revenue models exist, and platform channels (eg. m.sites with their own profit and loss), there will be difficulties getting that to work responsively. As I talked about at the end of this year, designing responsively impacts many parts of organisations. But, I do think responsive web design is no longer a trend. It’s a bunch of techniques that have proved themselves useful and relevant, and will probably continue to be so.
I hope it’s a year of a CMS shake-up. I hope it’s a year in which open source CMS communities break out of their IRC bubbles and start working with writers, editors and designers. I hope they become less feature-focussed, and more human and organisation-focussed. I hope we see as much effort going into the design of our back-end systems and work flows as we put into our web site designs and user flows.
I hope it’s a year where we stop Defining The Damn Thing. Design is design. I hope the term ‘visual design’ stops getting used. It’s not a thing.
I hope Google stops giving us great, free, cool things and then deprecating them. I’ll pay from the off.
I hope Twitter starts behaving like a media platform instead of a product. I’ll pay for flexibility, freedom and content.
I hope Adobe stops acquiring everything. They need a big, scary, great competitor.
I hope it’s a year we have a more balanced industry view. I think we need more publications, more voices, more speakers, more blogging, better journalism, better reportage, broader guidance, better conferences, more meet-ups. We rely too much on a small set of voices that guide the industry one way and another.
I hope we all take a moment, every day, and think about the importance of what we do. We’re defining, designing, launching, and iterating upon a medium. It’s big. And important. But… if you have a bad day, nobody died, right? That’s important to remember.
So. That’s that. I can but hope.
Oh. And, in 2013 I hope I stop starting sentences with the word ‘so’. I’m British, and we don’t do that.
I hope everyone has a successful, fruitful, happy 2013. Thanks for reading.
The evolution of the grid from geometric form and canons of page construction is quite clear. In no other period of history was the grid used as a core aesthetic as was in the 1950s and 60s where it emerged – almost simultaneously – from several design schools in Europe. From then, the grid system’s influence has been pervasive.
Today, the grid is viewed by many designers with equal amounts of distain and fervore. Its detractors – and there are many – claim a grid system is visual straight-jacket, designed to inhibit creativity and that using one produces dull work. Of course, I think that’s rubbish; there are no bad grids, just bad designers. In the hands of a competent designer, a well-constructed, considered grid system is the frame on which the fabric of the design is hung. It should create balance, provide landmarks and visual cues. It should allow the designer to exercise just the right amount of creativity and provide immediate answers to layout problems.
For the past 800 years, the printed page has been constructed in pretty much the same way; from the edges. The desire to create the most aesthetically pleasing book always starts with the size of the physical page. That page is subdivided to give us the optimum place to put our text and images.
Fast-forward 800 or so years to 1997.
The web is just about hitting the mainstream. I was working as a junior designer in a small firm in Manchester, UK. Typically, as the young guy in the studio, it was my job to create the websites for clients whilst the ‘serious’ designers looked after the large fee-paying clients on their branding, print design and advertising and what not. Remember, this is the early days of the web.
Designers who were exclusively designing for medium back then were doing what they knew; applying the rules of print design to the screen. We used tables for layout, shim-gifs and all manner of terrible ways to achieve our goal of ordered, controlled layout. And it drove us all crazy. And you know what? Despite all the great progress made in the last 15 years – web standards, inclusive design, UX, semantic thinking etc. – when you really think about it, as designers we haven’t really grown that much. Or rather, we’re still trying to force what we know into a medium that it doesn’t quite fit. Our practice of creating designs for the web is still mired in the great thinking that was done over the last 800 years. But who can blame us? 800 years of baggage is hard to get rid of! But that’s what we need to start doing; we need to start thinking in a new, and different way.
‘There is no spoon’
For print design, the ‘page’ is the starting point for creating your layout. The proportions define the grid within. The content is bound the book for pleasing effect. The ratio of the page is repeated in the smaller bodies of text for a feeling of connectedness when the reader moves from one page to another. For print design, the process of designing grids, and the layouts that sit on top of them, is a process with one fixed and knowable constraint: the Page. On the web, however, there is no page.
Consider the browser for a moment. The browser is a flexible window into the web. It grows and shrinks to the users screen size. The user can move it, stretch it, scroll it. The edges are not fixed. It is not a page, but a viewport.
Let us pop back to 1997 again. I’ve just been asked to design a website for a new art & architecture gallery in Manchester. The project is an exciting one, with some great potential for some really creative design and layout work. Typographically, it was a bit of a dream project. I’d been involved in the branding, the logotype design and the design work for the publications. I’d designed a grid system that would work across all of the media from flyers to signage – a kind of universal grid with the proportions of the logo as its starting point.
The time came when I had to knuckle down and design the web site. I started the design, as I usually did, on paper. Then Photoshop. Then Dreamweaver (trying to avoid looking at the code it produced – not because I was purist, but because it scared me to death!). The website design I created was based on a fixed width, fixed height modular grid. It had it all: ambiguous navigation, hidden content, images instead of text, all created with tables. It was cutting edge. But I know now, I hadn’t created a website, I’d created a brochure that happened to be on screen. I knew then, as I do know, that it was wrong. What I’d created had no place on screen at all – the wrong design for the medium. Instead of trying to understand the web, and the browser, I’d taken my existing thinking and shoe-horned my controlled design into it.
Now, let me ask you a question. If you replace Photoshop with Fireworks, Dreamweaver with Textmate, and tables for layout with Web Standards, how many of you are still designing this way? How many of you are still thinking of pages and edges? It’s ok. I am still, too.
800 years of baggage is hard to shed. There’s a lot of engrained thinking. Thinking that is, in fact, really great design and compositional theory. But, because of the attachment to the fixed page, we’ve not accepted the web for what it really is: fluid, chaotic, unordered, open. On the web, there is no page.
If there’s no page, no thing with edges, then how can we begin to define a grid? One of the goals – as described by Jan Tschichold – was to create a layout that is bound to the book. How can we bind anything on the web if there is no page from which to start? I propose we stop trying to find the browser’s edge. We stop trying to create a page where there isn’t one, and we welcome what makes the web, weblike: fluidity. We start creating the connectedness Tschichold talked about by looking at what is knowable; our content.
It has been said that as web designers, we’re not designing around content, but rather we’re designing places for content to flow into. Particularly in large organisations, it was commonplace for designers not to know what the content is, or would be, but rather, at best, they’d have some idea of how the content would break down. At worst, they wouldn’t have a clue and basically guess. ‘Oh, this is an article page, so it must have a bunch of headings, some body copy, some lists’. Feel familiar?
Separation of content and presentation is the mantra of the Web Standards movement. So you may think this disconnect started when the web standards movement was in full flow, but it started way before then. I look back at when I worked in web design agencies in the early 2000’s and, as a designer, I was off in my little corner designing the three templates that the client was paying for, and that the Information Architect had defined. I had wireframes of these exemplar templates and was pretty much following them the number. What I was doing was designing in the dark. I had my blinkers on. I had no idea what the content would be in 6 months, 1 year, 2 years time. In fact, I’m pretty sure the client didn’t, either.
What I was doing was designing a box. A straight-edged, inflexible box that couldn’t grow with the content as it didn’t take into account existing graphical assets, either. Thankfully, skip 10 years to the present day and things are getting better. We have content strategy. We have a relatively mature UX industry. As designers, we’re in a much better position to know, not just what the content will be right now, but what it will be in 1,2 ,3 years time. Now we have this knowledge, we can use it to our advantage: by using it to create our grid system.
A NEW CANON
I’ve talked about baggage. Hundreds of years of thinking in the same way: canvas-in. We’ve taken grid design theory from the world of the physical page and tried to make work in a medium where there are pages with no edges. A medium where the user is able to manipulate the viewport. Where context matters – is the reader sitting at the TV, a desk, using an iPad or hurredley walking from one meeting to another snatching some news on the way on their mobile device. Where do we begin to design on these shifting sands and still retain the reason for using a grid system? Before I get on to that, let’s remind ourselves what those reasons are:
Grid systems help connect or disconnect content. They help people read and aid comprehension by chunking together similar types of content, or by regular positioning of content, they can help people navigate the content. Connectedness helps brands tell a consistent story in layout.
Help solve layout problems
We all need answers to layout problems. How wide should a table be? What should the whitespace be around this boxout? Grid systems help us with that with predefined alignment points.
Provides visual pathways for the readers eye to follow
A well-designed grid system will help use whitespace dynamically and in a powerful way. By filling a space with negative space instead of content, we can force the direction of the readers eye more effectively than anything else.
As with the printed word, the word on screen would benefit from some rules of form; a new canon of page construction for the web. A way of constructing harmonious layouts that is true to the nature of the web, and doesn’t try to take constraints from one medium into another. That starts with the content and works out, instead of an imaginary fixed page and working inwards. I’m going to repeat that, because it’s important: we start with the content and work out. Instead of starting with an imaginary fixed page and work in.
The new canon can be best described as an approach. A series of guidelines, rather than a single diagram to be applied to all. This first part of the canon are a series of design principles to adhere to. These design principles were created to provide a simple thought framework, an Idea Space; a set of guiding principles to be creative with.
Define a relationships from your content. If none exist, create some.
A grid for the web should be defined by the content, not the edge of an imaginary page. Look to your content to find fixed sizes. These could be elements of content that is out of your control: syndicated content, advertising units, video or, more commonly, legacy content (usually images). If none of those exist, you must define some. Make some up. You have to start somewhere, and by doing it at a content level means you are drawing content and presentation closer together.
Use ratios or relational measurements above fixed measurements.
Ratios and relational measurements such as pixels of percentages can change size. Fixed measurements, like pixels, can’t.
Bind the content to the device.
Use CSS media queries, and techniques such as responsive web design, to create layouts that respond to the viewport. Be sympathetic to the not only the viewport, but to the context of use. For example, a grid system designed for a small screen should be different to that intended to be viewed on a laptop.
By using these principles to design to, we’re drawing closer relationships between our layout, content and device. Tschichold would be proud.
– This blog post is an excerpt from my upcoming book on designing grid systems for the web, published by Five Simple Steps.
Last week, there was an argument on the internet.
As usual, it started on Twitter and a flurry of blog posts are cropping up this week to fill in the nuances that 140 characters will not allow. So, here’s mine…
[Aside: I did actually make a promise to myself that I wouldn’t get involved, but, I find that cranking out a quick blog post, gets my head in the space for writing generally.]
I started speaking at web conferences in 2006. After attending SXSW the year before, I proposed a panel discussion (with the lofty title: Traditional Design and New Technology) with some design friends of mine: Khoi Vinh, Jason Santa Maria and Toni Greaves and moderated by Liz Danzico. I was terrified. But, in the end, it was fun – there was some lively debate.
I wanted to do a panel at SXSW since seeing Dave Shea, Doug Bowman and Dan Cederholm sit on a CSS panel at SXSW in 2004. Not because I saw the adulation, but because I saw – for the first time – what it was like to contribute to this community. To be part of it. To give back: be it code, techniques, thoughts, debate or discussion. And I wanted a part of it. So, that’s what I did. I started blogging – I felt I had some things to say, about typography, grids, colour theory. All of the traditional graphic design stuff that mattered to me. Not because of some egotistical trip, but because I genuinely wanted to make things better. Trite, I know.
Fast forward a couple of years and I’m speaking at the inaugural New Adventures conference in Nottingham for my friend Simon Collison. On that day, every speaker up on stage was trying to give the best talk they could. Not because of the audience, not because of who they were, but because of Simon. It was personal.
The talk I gave at new Adventures took about two years to write. Yes, it took me that long to write a twenty five minute talk. You throw that into the equation, a high-risk personal favour for a good friend, plus my family and best friend in the audience, and you’ve got a recipe for bad nerves and vomit. And I did vomit.
But, I got up there. Cast aside the nerves and held my head up and spoke for twenty minutes on things I’ve been thinking about for years. It was received well. Afterwards, all I did was sit in the green room for about two hours and didn’t really speak to anyone.
My natural preference
It may surprise you that most speakers I know are not extroverts. I don’t mean extroverts in the way you may think, either. I mean it in the Myers Briggs type: they are not the type of people who gain energy from other people, they gain that energy from themselves. I’m one of these people, too.
Being on stage is firmly out of my comfort zone. Firmly. I’ve had to learn to harness the nerves and put them to good use. A good friend of mine calls this ‘peak performance’ – the nerves help you bring your ‘A’ game.
My natural preference is to be on my own, working. Either thinking, sketching, writing, building, exercising… whatever. All through my life, I’ve enjoyed solitary sports and pastimes, from angling to cycling. Now, that’s not to say I’m a hermit. I’m not. I’m pretty sociable when I need to be, but it’s not my preference. So being on stage – sticking my head above the parapet – takes incredible effort, and then afterwards, I generally want to go and hide in a corner for a bit. It wipes me out.
So, why do I do it? Why does anyone do it in this community? If you’re a regular speaker, or your first time? Almost everyone I know does it because they want to give back. They have something they’d like to share in the hope it may help someone else in a similar position.
This brings me full circle to my opening sentence. Why, then, knowing all of this, is there a general feeling of discontent in a vocal minority that speakers who do this regularly are:
- In it for the ego
- Not doing any real work
- Not leaving room for new speakers
I’d like to address these points from my own experience.
In it for the ego
Why would someone get up on stage and speak to hundreds of people? Sure, some may get a kick out of that. People applauding you feels nice. But, let’s be clear: that’s not egotistical. That’s being rewarded, and there’s nothing wrong with that.
Not doing any real work
I wrote about defining ‘work’ last week. I see speaking as part of my work as a graphic designer. If you’ve studied graphic designers, art directors, ad copywriters and the like, you’ll know that a lot of them speak to their peers – either at conferences or through publications. Writing and talking about what we do with each other is work. Not only that, it’s fucking important work too. Without it, there would be no web standards, no open source, no progression.
Not leaving room for new speakers
Experienced speakers leave room for everyone. Experienced speakers do not run conferences: conference organisers do. And conference organisers need to put bums on seats. Just like a big music festival, you need the draw, but also you need the confidence that a speaker will deliver to the audience. Every experienced speaker I know works damned hard to make sure they deliver the best they can, every single time. They’re professional. They don’t screw it up, or spring surprises. They deliver. And that’s why you may see their faces at one or two conferences.
A couple of months ago, I saw Heather Champ talk at Web Directions South in Sydney. Amongst many hilarious – and equally terrifying - stories of how she’s managed and curated communities over the years, she came out with the nugget:
“What you tolerate defines your community”
— Heather Champ
At this point, I’d like to ask you this:
What will you tolerate in this community?
Will you tolerate a conference circuit swamped by supposedly the same speakers and vote with your wallet? Or will you tolerate conference organisers being continually beaten up for genuinely trying to do the right thing? Will you tolerate speakers being abused for getting on stage and sharing their experiences?
Will you tolerate harassment, bullying and exclusion?
As I’ve said before, Twitter is like a verbal drive-by. It’s fast, efficient, impersonal and you don’t stick around for the consequences. Let’s stop it.
The log messages generated by a piece software tell a story: what, where, when, even why and how if you’re lucky. The readers of this story are more often than not other programs: monitoring systems, performance tools, or just filtering the messages down to something a human can actually comprehend. Unfortunately the output of most logging systems is ill-suited to being read by programs. Even worse, most logging systems omit critical information that both humans and their programs need. As part of my work at HybridCluster I’ve been working on fixing that.
Problem #1: Text is hard to search
Let’s say you want to find all the log messages about a specific person. A first pass of log messages might look like this:
Sir James Chettam was going to dine at the Grange to-day with another gentleman whom the girls had never seen, and about whom Dorothea felt some venerating expectation.
If Miss Brooke ever attained perfect meekness, it would not be for lack of inward fire.
You could do a text search for log messages containing the text “Dorothea”, but this is likely to fail for some types of searches. You might want to searching for actions involving dinner, but then you would need to search for “dine” and “dinner” and perhaps other words well. A library like structlog that can generate structured log messages will solve this first problem. You could define a “person” field in your messages and then you can search for all messages where
person == "Dorothea" as well as other structured queries.
Problem #2: Referring to Entities
Every time a log message is written out you need to decide how to refer to the objects being logged. In the messages we saw above “Dorothea” and “Miss Brooke” are in fact different identifiers for the same person. Having structured messages doesn’t help us find all messages about a specific entity if the object is referred to inconsistently. What you need is infrastructure for converting specific kinds of objects in your code to fields in your structured log messages. Then you can just say “log a message that refers to this Person” and that reusable code will make sure the correct identifier is generated.
Problem #3: Actions
Most log messages in your program are going to involve actions:
Not long after that dinner-party she had become Mrs. Casaubon, and was on her way to Rome.
A marriage has a beginning and eventually an end. The end may be successful, presuming “until death do us part” is a form of success, or a failure. The same is true of all actions, much like function calls in Python are started and eventually return a result or throw an exception. Actions may of course span multiple function calls or extended periods of time.
Actions also generate other actions: a marriage leads to a trip to Rome, the trip to Rome might lead to a visit to the Vatican Museum, and so on. Other unrelated actions are occurring at the same time, resulting in a forest of actions, with root actions that grow a tree of child actions.
You might want to trace an action from beginning to end, e.g. to measure how long it took to run. You might want to know what high-level action caused a particular unexpected low-level action. You might want to know what actions a specific entity was involved with. None of these are possible in most logging systems since they have no concept of actions to begin with.
Those are the problems. In my following posts I will talk about the solutions, being built as part of a Python library called Eliot. We hope to open source Eliot at some point in the future, but the general design ideas should be applicable anywhere.
The post Logging as Storytelling appeared first on HybridCluster.
Update: We just added Christian O'Reilly as a speaker
As both the year and our alphabet reach their end, we are organizing again an amazing Python meetup evening, just before the holiday season. Our friends of w.illi.am/ are graceful enough to host our event at their offices near UQAM and Benelux.
We are hoping that this edition will allow you to get an answer to life, the universe (42), and everything in between , either way it should be fun !
- Rory Geoghegan – Module of the Month: csv
- Éric Araujo – Person of the Month
Pablo Duboue - Introduction à Lamson plus the poisson magique play-by-email RPG gateway
Simon Charette - Comment contribuer à Django
Christian O'Reilly - Outils pythons pour l'analyse scientifique de l'électroencéphalogramme (EEG)
Cette présentation fera un bref survole de quatre projets à code source ouvert écrits en python et voués à l'investigation scientifique de l’EEG : Spyndle, BlockWork, Analyzer et Navigator. Ces outils sont complémentaires et forment ensemble une plateforme bien adaptée pour le traitement distribué de volumes importants de données.
- Marc-Antoine Ruel - Construire Google Chrome, un changement à la fois:
Google Chrome a 5 ans et est rendu à la version 31. Chaque nouvelle version contient au delà de 7000 changements.
Venez écouter comment une infrastructure écrite en python peut supporter une armée de développeurs, contenant une bonne proportion de contributeurs externes à Google, qui veulent intégrer des changements à toute heure du jour et de la nuit.
Monday, the 9th of December 2013
w.illi.am/ offices 400, boul. de Maisonneuve Ouest, bureau 700 (http://goo.gl/maps/035B0)
- 6:00pm — Doors open
- 6:30pm — Presentations start
- 8:15pm — Break
- 8:30pm — Second round of presentations
- 10:00pm — One free beer offered at Bénélux just across the street
We’d like to thank our sponsors for their continuous support:
- Savoir-Faire Linux
 - Wikipedia, Answer to the Ultimate Question of Life, the Universe, and Everything (42)
A feature that has recently landed in
git master on GitHub
and will be released in 1.2 is the ability to log into
This lets one make use of an already existing
Single Sign-On (SSO)
infrastructure instead of requiring Zato admins
to memorize additional credentials.
Here's how to enable it:
Open the config file at /path/to/web/admin/config/repo/web-admin.conf
Change the OPENID_SSO_SERVER_URL to a URL your SSO server uses
Stop and start the web admin
For each user in web admin:
- Make sure the user has been already created, let's say it's 'myuser'
- Issue the new zato update openid command, for instance
% zato update openid /path/to/web/admin myuser https://sso.example.com/myuser
- zato update openid - the command to invoke
- /path/to/web/admin - path to web admin's top-level directory
- myuser - username whose OpenID claimed ID should be set
- https://sso.example.com/myuser - claimed ID of the user
No restarts are needed after updating a given user's credentials.
Note that enabling SSO disables regular password based authentication. To revert to the latter, set OPENID_SSO_SERVER_URL to ""
and restart web admin.
This post demonstrates how you can configure a very decent environment for Python development with Emacs, in just 60 seconds.
A dream is now true: The first time you start Emacs, it automagically downloads and configures all plugins you need. Emacs is then just ready to work and you can start typing code immediately.
For the impatient
1. Save configuration files you eventually have!
$ cd $HOME
$ tar cpf dot-emacs.ORIGINAL.tar.gz .emacs .emacs.d
$ mv .emacs dot-emacs.ORIGINAL
$ mv .emacs.d dot-emacs.d.ORIGINAL
2. Remove any Emacs configuration files you eventually have.
$ rm -r -f .emacs .emacs.d
3. Install Python libraries
This should be done preferably inside a virtual environment.
$ workon py276 #-- py276 is a virtualenv I'm using
$ pip install epc
$ pip install jedi
$ pip install elpy
4. Download my .emacs file onto your home folder.
$ cd $HOME
$ wget https://raw.github.com/frgomes/dot-emacs/master/dot-emacs.el
$ ln -s dot-emacs.el .emacs
4. Start emacs. It will configure itself when it first run!
$ emacs test.py
Features in a nutshell
- python-mode, cython-mode and nxml-mode: ditto
- jedi: provides auto completion
- flymake: highlight syntax errors as you type
Please let me know if you find issues. In particular, I don't have Windoze boxes, so the automagic configuration thing was never tested on it.
This script was designed to run on Emacs 23 onwards but only tested on Emacs 24. Please let me know if you find issues.
Please point out typos and bad English.
You can also suggest plugins or tools I missed. This is very much appreciated and may benefit my workflow as well :)
So... thanks a lot for your suggestion!
Known IssuesIf you are behind firewall, you may (or may not) face download problems which involves HTTPS protocol. As far as I know, this is a bug on a third party library which Emacs depends on.
If Emacs opens the message window and vomits hundreds of errors coming from file cython-mode.el ... that's because your proxy server refused the https request and returned an error message in HTML. It's easy to fix this issue:
$ cd $HOME/.emacs.d/plugins
$ rm cython-mode.el
$ wget https://raw.github.com/cython/cython/master/Tools/cython-mode.el
Chances are that now cython-mode.el is OK, since wget performs the request the way it needs to be in order to work properly.
That's it: ready for coding in 60 seconds :)
-- Richard Gomes
VMware have released security advisory VMSA-2013-0014 "VMware Workstation, Fusion, ESXi a ...(more)...
As of today, PythonAnywhere supports Python 3 web apps for all frameworks that work with Python 3. We'd love to hear any feedback people have.
To create a Python 3 web app, just click the "Add a new web app" button. If you have an existing web app that you'd like to switch over from Python 2.7 to Python 3, drop us a line with the "Send feedback" option.