bureau

It means “desk” or “work table” in french : how metaphoric for a blog discussing what my work's about. Get the RSS feed.

i

I'm Thibaut Sailly, an independant interface designer based in Paris. Say hello on twitter or by email at bonjour ✉ tsailly ◦ net.

Topics

Archives

© 2010-2014 Thibaut Sailly · Powered by Movable Type · RSS

December 2010

Blueprint

To my surprise (and satisfaction), the design of this blog seems to have got the attention of a lot more people I would have hoped for. This article is for the curious among you as it details the ideas and choices gone into the conception and the process used to get Bureau on its feet, back in september.

First, why this publication? My other blog, Artificial Horizon, despite posting being very sparse lately, is still active. It's a place where design as a process is the main topic, and interface / interaction articles found there way in there. But as interaction design has become my daily concern, I needed a place to talk about it exclusively; this is how the need of Bureau came to be.

Content first

The metaphor I had in mind for what the reader would feel when loading the page was as if I was handing her my last article on a printed white page, as nicely typeset as possible, and very simple. The first and easiest thing I want my reader to have access to is the last ideas I felt were necessary to express.

0

Only after that should he have the means to find out more via different navigation elements, get to know who writes this, et cætera. This is why I chose to have an illustration acting as the back-to-home button for the site instead of a word: the first thing you read is the title of the last article, not the name of the blog and its tagline. This is also why the navigation is placed down in the footer, while being easily accessible from the top of the page by clicking the info "i" in the right corner. Knowing that I wouldn't post often here, chronology and categories were sufficient enough to find your way through the posts — no need of a real navigation list on top.

Time, yours and mine

Enabling comments means spending time filtering spam, reading them and replying to them, and as a consequence means less time for other nice activities life offers like cooking or learning how to code in Obj-C. Some readers see this as being closed to counter arguments, especially when I get into rants, but it really is because I want to lower the amount of time Bureau is taking from my other interests.

I love discussions, but I also love having a good meal on my table at the end of the day, and a good meal doesn't cook itself. So there. The Twitter is ideal to send a quick feedback that won't consume a lot of your/my time. And if you feel like it's not enough, post a more detailed thought on your blog and send the link in, I'll be happy to read it while stirring this Bourguignon beef. Sorry if this is disappointing, but you have to start somewhere if you want to cut on the info hose.

About your time now : I'd like to respect it as much as possible, so I thought of displaying the reading time for each article. Writer for iPad came around with this feature so I wouldn't have to read aloud and measure the time myself for each article. But then, knowing the time each article takes from your life may not be as useful as it sounds. You can estimate that by scrolling to have an overview of the article's length.

What could be more useful for readers is a sort of a grade announcing how much time on average reading this blog would take them if they decided to become regular readers. It could be expressed in minutes per day or per week, as in "be aware reading this blog will take 8 minutes of your life each day if you subscribe to it". That may be a good feature to have on RSS readers, if only as a sanity check monitor of your subscriptions. None of these two options are in place for now, but I'll be looking into how this ratio could be dynamically calculated in Movable Type when I'll find time to (I'm not a programmer, yet).

Responsive design

Having read the A List Apart article and seen some well executed instances, how can you not be convinced it's the way to go to present your content to different type of screens or devices ?

Media queries help you target a range of screen sizes. The usability way of saying this is: they help you target different usage contexts. It's not only about how to fit such content into that much space, it's also about redefining the content hierarchy for each different context. The informations and interaction handles you need upfront are not the same wether you're visiting from your smartphone during your daily commute, from a tablet on your couch or from your 24 inches desktop at work. We shouldn't be thinking of it as a way to extend or compress a default presentation to larger or smaller screens, but more as way to adapt our voice and interactions to different situations. For this blog, which has little different types of content on its landing page, it's not much of an issue. But for more content heavy sites, viewing the use of media queries from this angle can really help you to shape up rewarding experiences for the user.

In Bureau's case, the design of the large screen layout came to be when realizing that if I wanted to respect text formatting best practices, the article's width, or measure, couldn't get larger as you'd extend the window's width. For reading comfort, a line of text can't be too long: a maximum of 75 characters is recommended. As a consequence, widening the window is only going to add horizontal white space; what to do with it then? The choice of having an illustration as a title lead the way to the answer: bigger. Illustration. Using perspective in this alternative version allows to add depth to the layout.

Body text font size is getting a 2px upgrade in the large screen layout, as when using big screens, we usually sit a little further from them. The background color is also slightly evolving from layout to layout, preventing the page emitting too much light into your already strained eyes. For a page with a white background color, when the browser window widens, its brightness rises accordingly. So I made the background color dimmer and dimmer as the window's width gets larger. It's not scientific at all, and I might need to adjust my color values to fully achieve my goal, but it's a start.

For the iPad version, thumb scrolling is a key interaction to keep in mind for the design : you should use at least one inch left and right margins to prevent your readers from hitting a link in the text body when they only want to scroll. As media queries allow it, orientation can be responded to with an appropriate style sheet. If you're visiting the site from an iPad, you'll see the larger illustration in the landscape mode. What you'll see too is that when you go from portrait to landscape, the page's width doesn't resize automatically to the width of the screen, and you have to pinch to zoom out. I have long thought I was doing something wrong but I came across this tweet from @filamentgroup and learned that it was a bug from iOS, not my code being unsufficient to cover the case.

Building it

The site went from ideas to sketch to html/css mock up to Movable Type in that order, with no other steps in between. Here are some pictures I took from the notebook I used at the time:

The html/css prototype is pretty much like the first article published here, all in its latin glory.

I decided to use Movable Type because I already had it installed on my server to run Artificial Horizon, and knew my way around it. The pages served are static so the server is not doing too much work: I guess it uses less power per page served, so it's kind of green.

Next up is the switch to html5, and getting custom layout features called for each article categories. And some easter eggs might or might not find there way too.