Following on from getting the project proposal and contract signed off during Part I, I’ve procured the content and brand assets so now it’s onto planning and design concepts.

Wait, “procured the content”? That sounded easy! Listen, I know. Planning for, authoring and managing content is hard. We wouldn’t be building entire web apps or writing whole books on it if it was easy. But this project is not an exercise in content strategy; it’s a small, single-page site with a very specific purpose: promoting a bi-annual comedy show. The content consists of:

• Site title and description
• Details of next show (Date/time/venue, booking methods)
• Name, photo, profile (55 words), testimonial quote and link to YouTube videos for each of the 4 acts
• Mailing list signup form
• Links to Facebook and Twitter accounts, and sharing links

Getting started

Gathering snippets of visual inspiration and marking up the content in HTML have been the first two steps. I find marking up content early a great way to familiarise myself with the subject matter, at the same time as actually getting the work done. The difference this time has been my “mobile first” mindset.

Knowing that, at the most basic level, visitors will experience a single-column layout has helped me better focus on content hierarchy: most important at the top, least important at the bottom. No decisions influenced by a more “designed” layout. Traditional wireframes have always felt too influential in this regard. When beginning design concepts, I’ve often felt trapped by the wireframe layout that the client has already signed off, when in many cases all the wireframe needed to do was define simple hierarchy.

Branding work was completed by a separate company prior to kick-off on the website, with a creative direction intended to be reminiscent of 19th century circuses. I’ve received logo variations and a colour palette, but little more. This has been a bit of a blessing, as I can help shape an appropriate web presence for such a young brand without overbearing print guidelines.

Building a prototype

With the content all marked up in gooey, semantically rich HTML, I’ve defined styling for typographic and basic layout elements in global.css. Choosing 14px as my ideal text size, my measurements for type and imagery are based on the 2:3 ‘Musical Fifth’ ratio, and resulting modular scale. While I’ll be further integrating this scale into the design as the site progresses, I didn’t want to get too caught up in it at this stage, as I had quick and dirty layouts to prototype.

There is no existing Punchline website from which to deduce statistics on visitor resolutions or devices, so I’ve chosen to use the display areas of common devices as breakpoints for my media queries. These media queries, declared in a separate screen.css file, only get served up to devices with a minimum display area of 480px (iPhone in landscape mode). Devices with display areas of less than 480px, like “feature phones” or common smartphones in portrait mode, simply get served up global.css. From there it’s been a case of choosing the most suitable grids for the given content and display area.

Breakpoints and layouts

Note: The acts featured in my prototype and design are NOT the real acts appearing in the show. They’re simply examples I’ve picked for the purpose of this write-up, to protect the integrity of the real show.

Devices with a display area of up to 479px will see a single-column layout; each content block stacked on top of another. Devices with display areas of between 480px and 599px see a two-column layout; each act assuming a column (with two acts stacked on top of the other two) and the show summary, mailing list signup, social links and footer all spanning the width of both columns. Display areas of between 600px and 767px retain the two-column layout, but receive a couple of extra snippets of content that weren’t absolutely necessary at smaller sizes.

This is where it starts to get a bit more interesting. Display areas of 768px and larger see the header pulled out to the left-hand side, looking more like a sidebar. This element is given position: fixed; to retain it’s position as the document scrolls (it’s kind of important, seeing as it contains the booking information). The mailing list signup and social links are absolutely positioned above the acts to take the place of the header. The headline act assumes the full width of the main content area, with the middle slot and opening act still split into two columns underneath it. The compere appears underneath these two acts, spanning both main columns.

This three-column layout then morphs into a four-column layout for display areas of 1024px or larger, with the compere coming up to join the two other acts in columns underneath the headline act. There is no change for display areas of more than 1200px yet, but I’ll likely progressively increase type sizes to maintain readable measures and eventually set a max-width on the site container.

1. < 479px
   
2. 480px – 599px
   
3. 600px – 767px
   
4. 768px – 1023px
   
5. 1024px – 1199px
   
6. 1200px >
   

Because each layout is liquid, all that’s really happening from one breakpoint to another is the addition (or subtraction) of floats, percentage widths and margins. As a result, it’s been super quick to knock up the prototype.

It’s sure as hell not pretty, but take a look. Resize your browser to see the breakpoints in action.

Static visual mockup

I found my base typographic sweet spot in the process of creating the prototype: 14px Georgia with a 1.5em line-height. I also chose Rosewood Std Fill for both h1 and h2 headings, as it made sense historically; Adobe based it on an 1874 design, which fits nicely into our 19th century bracket. But other than basic typography and layouts, I’d done no visual design work at all.

Though the brand assets riffed off old 19th century circus artwork, I was told specifically that the site should have “a hint of circus”. Take from that what you will, but I heard: don’t design a page that’s meant to look as if it’s inside some god-awful circus tent or staring down a lion’s throat, just drop enough hints and people will get it.

I’ve based my static visual mockup on the 1024px-and-up layout, employing an eight-column grid (960px wide). It’s hardly the greatest thing I’ve ever designed, but as a first-pass concept, it feels developed enough to send off for some feedback. I deliberately didn’t work into it too much; it’ll develop in due course.

Why 1024? It’s the easiest reference point for the client. They’re used to browsing websites of around this width on their desktop anyway, and this layout is, I suspect, likely to be the one visitors see most.

I emailed the client a link to the visual mockup set in a browser, accompanied by a video. In both the email and video, I emphasise the fact that this mockup is an “artist’s impression” of what the final site may look like. In the video (a screencast), I simply take a few minutes to explain my reasoning behind the responsive approach and demonstrate the breakpoints in action. This should help the client understand what is otherwise a potentially lofty concept, or at least a relatively new one. Particularly if they’re not a complete nerd.

Potential issues

Getting to this point has been an interesting (and at times downright fun) process, and though it feels like I’m making good progress, I’m left with more questions than answers…

Q: How will I get around loading large inline and background images across potentially weak data connections (not to infer strength of data connection from device resolution, of course)?

A: Only load large background images past certain breakpoints? For inline images, load smaller versions by default and feed large versions to more capable devices with Filament’s script?

Q: Will browsers, like IE6, 7 and 8, that don’t understand media queries simply get served up the basic linear layout?

A: Without JavaScript enabled, yes, though there is the option of using css3-mediaqueries.js to mimic the work media queries are doing. The idea of having an entirely JS-dependant layout does feel wrong to me, but I’m not ruling it out for these cases. Alternatively, simply serve up the 1024+ layout to IE7 and 8, as they would otherwise get were the site not responsive at all. IE6 will likely get a basic, linear layout.

Q: Will lettering.js and fittext.js work well enough, and how will I avoid all this JS load for small screen users who won’t even get to see the results?

A: My plan is to set the complicated type using lettering.js and FitText. I’m a bit apprehensive, as I’ve never properly integrated them into a site build. As for avoiding JS bloat on devices that can’t even make use of it, people much smarter than me allude to the fact that it isn’t easy. So, yay.

Until Part III…

Two streams of thinking I’ve found fascinating to see develop over the past year or two are “responsive” (or “adaptive“) web design and a “mobile first” approach. Perhaps because I’m never really involved in mobile-specific projects, it feels like responsive web design has generated more discussion and prompted more writing amongst those I know. But however separately these topics have been discussed, it feels as though they share the same ethos: we can create better experiences by embracing the inherent flexibility, power and dynamism of the web.

Hearing Jeremy Keith speak at DIBI last week helped clarify a lot of the thoughts I’ve been having surrounding the topics. To begin creating better experiences, the first step we need to take as designers is to start relinquishing this delusional idea of control we have over our designs as concrete visual pieces. Every time we fire up [insert your graphics editor of choice] and punch in canvas dimensions at the beginning of a project, we’re simply perpetuating this fallacy that the web is some kind of fixed canvas we can design for. It isn’t. It never was.

640×480? 800×600? 1024×768? Basing the width of a website on the resolution of a desktop computer monitor, particularly when we have no idea what the viewport width might be, has never been the right thing to do. But now, finally, the reality of the exploding mobile landscape has brought the inadequacy of our approach into sharp focus.

Design for the web demands an approach further divorced from the visual communication practices of the past. This is not to say we should disregard any of the undeniably crucial work of designers over the course of history; we should must learn from them and carry that awareness with us always. I don’t think it’s possible to reach our full potential as designers of the web without doing so. But the web is a unique medium unto itself, and designing for it should be approached appropriately.

Why all the babbling?

Being a designer for a product, I rarely create websites these days. But I’ve taken on a small project that, in the process of completing, will hopefully help answer some of the questions I have about responsive web design and design for small screen (by doing, as opposed to just reading about).

I’m not claiming that what I’ll be doing is in any way groundbreaking. I personally know people employing the same, or at least similar, techniques in their work right now, and have been for some time. But I know more still who aren’t, so I’m keen to open up my own experience in the hope it might act as some sort of reference. Through comments, it’d be great to build some discussion around the approaches I’m taking as I work through the project.

The project

The website is for a new company hosting bi-annual comedy shows in Edinburgh. It’s purpose is simple: to be the primary source of information for upcoming shows, providing visitors with methods of booking tickets, and encouraging them to sign up to the mailing list.

With the project proposal and contract signed, the first step has been to procure the content.

Part II next week.

I’m particularly taken with Frank’s  ’Atlantis‘, though that’s not to dismiss the others in any way. Each design plays wonderfully with it’s particular time-period while still embodying the style of the designer.

It begins with the brief. The brief defines the project objectives, informed by business goals, tactics, requirements and restrictions. It should broadly outline the content required to achieve these objectives, be it information about the products your client sells; company background information; latest news. Whatever. Brainstorm with your client, conduct user research and study competing sites to guide discussion as to what content is required. If it’s a redesign, you might have rich analytics data to accompany all of their existing content. The brief is signed off before any IA or design work begins.

IA (Information Architecture, if you’re not into the whole brevity thing) isn’t simply about site structure. IA covers user research: user needs, aims, behaviour and knowledge. It allows you to look at content you have, content you need, how to plan for it and how to group it. It should explore and define required content in detail. Format, length, intended audience and relevance to any specific tasks. Is it structured content, like a product page, or unstructured content, like a once-occurring ‘About us’ page? IA is not just a sitemap.

Once you’ve communicated the IA to your client, content authoring can begin. Fail to communicate the IA properly and you can kiss your deadline goodbye. The client must understand what they’re expected to produce. I can’t stress this enough: make sure your client grasps fully the breadth, detail and purpose of the content they are expected to produce.

Your IA work should’ve given you enough of an idea about the content to begin designing the framework for it. With the IA signed off, your design work and your client’s content authoring begin — in tandem.

Don’t leave your client out in the cold. They need reassurance that the content they’re authoring is good, just as you need to know it’ll work harmoniously with the design. Communicate constantly. Writeboards or Google Docs are handy for this kind of collaboration. Provide feedback and incorporate the latest content into your designs. There should be a continual conversation between the developing design and the developing content.

As your client edits and refines, so you design and build. More time spent editing and refining means a better end result. No last minute content dump into the CMS. No long, drawn-out ‘content population’ process, delaying launch. No need to look on in terror as your templates implode with all the extra content they didn’t tell you about. Donna Spencer says it best:

“Content shouldn’t be treated as an afterthought, or something to be “poured” into the website. Content is the website“

I’m only scratching the surface of a workflow here. If you’re really interested in producing better web content, I’d highly recommend Kristina Halvorson’s ‘Content Strategy for the Web‘ and Donna Spencer’s ‘A Practical Guide to Information Architecture‘.

My method of presenting designs to clients will be of most benefit to you if your workflow is similar to mine. I typically arrange to present designs for a maximum of 2-3 key pages, in order to establish a creative direction. I begin the design process with pencil and paper, sketching out rough page layouts. I then move into Fireworks, fleshing out my sketches into broad content blocks and exploring form, colour and typography. Having established the treatments of these primary design elements, I further develop page composition and refine detail elements before stopping.

By this point, many of us would’ve worked the provided text (or at least lorem ipsum placeholder text) into the designs and would be saving out the 2-3 pages as flat images to send over to the client. Almost everyone I know does this, but I think there’s a better way.

Markup is your friend

I know I’m not alone in saying that working with text in Photoshop or Fireworks can be a royal pain in the arse. Selecting fonts each time from the drop-down menus, trying to manage text styles across multiple pages, deciding which type of anti-aliasing to use, having to own the fonts you want to use in your designs, no way of showing :hover states… it’s laborious, cumbersome, expensive and incredibly inefficient when you know the pages will have to be built later anyway.

The alternative? Write the content out in HTML, style it with CSS and overlay it on top of the design in the browser.

Having already settled on a creative direction in my graphics app, I export the first page design. I then grab my text editor, centre the exported image in a browser and add repeating backgrounds—where applicable—using CSS. I write the content out in lovely old semantically-rich HTML, style it with CSS and absolutely position the content over the image. Here’s why:

• I’ve started writing re-usable HTML and CSS during the design stage, saving me time on build later.
• The text is rendered the way my client is used to; the way they’re combination of OS and browser always does it. No decisions need be made about anti-aliasing styles.
• I’ve opened the door to a huge range of web-licensed fonts with Typekit, Fontdeck and @font-face, negating the need to purchase them outright.
• I can now easily manage all text styles across multiple pages using CSS, an otherwise painful task in a graphics app
• My client can interact with :hover and :active states for links.
• I can quickly turn around those small, annoying text changes my client has just requested without having to open a big clunky Adobe app.

Of course, you can take it further by creating elements with HTML and CSS to replace those in the exported visual, bringing you closer again to final build. For example, I tend to weigh up the time needed to grab a jQuery plugin (including time required to undo/redo any work) and throwing it into my designs, versus trying to explain to the client in words how it’ll work when it’s built. The main thing is you to work as efficiently as possible; don’t spend more time than you’ve scheduled realising elements from your visual in HTML and CSS if you know there’s a chance your client will reject them.

Do it right and nothing is wasted

Marking up your content in HTML for presenting designs means you can keep it all and you don’t have to rewrite it later. Even though you won’t be able to keep all of your CSS, the only thing you should really have to refactor are your positional styles. The point is that content is a constant. Though it might change, it’s not an element that’s going to disappear. Anything you can do to manage it’s associated styling more efficiently and ease amendments to the content itself is good.

Now, let’s look at an example:

Show me something fool

The example is an adaptation of a site design I’ll be launching for a client next month. Every bit of text is inline. My client sees the mockups in their browser from day one, which is of course where the website will live anyway. My client also understands immediately how the ‘Featured case study’ fade in/out works, saving me time having to explain it or point them to someone else’s jQuery tutorial page. The main background and footer background always span the full viewport width using CSS, so the client doesn’t have to imagine how their site will look when it’s repeating background(s) aren’t being chopped off at a width of 960px.

So why not do it all in HTML?

If you’re reading this, chances are you’ll have read at least one or two the cases put forward for mocking up entirely in HTML, avoiding graphics apps altogether. It just doesn’t work for me. I get sucked into a hyper-analytical coding bubble too early and it really inhibits my creativity at what should be a design concept stage. I’m glad it works so well for the guys at 37Signals, but to that end: the methods you use should be chosen as the best match for the type of work you produce. Fireworks and Photoshop are still necessary evils for me; there are tasks I can achieve quicker there than with HTML and CSS. More importantly, there are often times when I’m simply more comfortable creatively in Fireworks and Photoshop. Whilst it’s good to push the boundaries of ones knowledge, I think it’s equally important to know when you’re comfortable with your tools and to make full use of the benefits that brings.

The caveats

If you’re not comfortable working in HTML and CSS, the way I present mockups probably isn’t for you. That said, I’m neither the quickest nor most proficient front-ender around. Any opportunity you have to brush up on (or begin) learning HTML and CSS is one you should take. I’m also not claiming that this technique is applicable in every situation; I’ve found it to work most efficiently when presenting 2-3 pages for client approval. I wouldn’t recommend presenting 10 pages like this, as you’re going to make more work for yourself recfactoring your positional styles.

It’s important you have some existing CSS to use when doing things this way. Don’t write everything from scratch; it’ll take too long. I use a continually evolving default folder and file structure for all new build projects, including a structured CSS file providing a framework for common element styles, a reset and a sprinkling of other bits and bobs. This helps to speed up the process of writing the CSS I need to present my designs to the client.

Depending on your working environment, my techniques may not work for you either. If you’re a one-man band, then of course you can usually do whatever you want. If you work as part of a larger team, it’s important to bear in mind your team members’ capabilities. If someone has to pick up and amend your designs but they don’t know HTML or CSS, it’s going to screw up the process, along with your timescales.

All that said, if you can see the potential benefits of my method working for you, just give it a shot. I’d love to hear how you get on.

• Download Photoshop templates
• Download Fireworks templates
• Download Photoshop & Fireworks templates

View the repository on GitHub →

Although the margin widths of these uniform grid templates do vary, each one adheres to an overall width of 960px. All of the templates are released under a Creative Commons Attribution-Share Alike license, meaning you can distribute derivative works but only under a license identical to the Attribution-Share Alike license. They may be used for commercial purposes, but you may not sell them.

Nathan Smith, creator of the nifty 960 Grid System, already provides 12, 16 and 24-column grid templates that work well if you’re designing to build with his framework. But as someone who doesn’t actively use CSS frameworks, I wanted a greater variety of grids to aid in my site designs. I figured if I made them, I could release them for general consumption and maybe try to give a little something back to the web community that I’ve taken so much from!

Please, if you notice any issues with any of the templates or have suggestions on how to improve them, let me know. Thanks.

In the article, John Nunemaker says he prefers writing selectors and their attributes on the same line because it:

• Makes selectors and their attributes quicker to scan
• Reduces the size of the CSS file
• Saves him time when creating and editing CSS

I’ve created both single-line and multi-line stylesheets myself, and I’ve experienced more effective methods of speeding up the creation of a stylesheet whilst maintaining a friendlier method of formatting, and better ways to reduce it’s file size too — without having to resort to using single lines. The context I’m providing for my methods is that of a team environment, where multiple designers and developers will have to maintain the CSS you create, and where the CSS will be version-controlled. Even if you create and maintain CSS entirely on your own, I still believe using this kind of environment as a benchmark is hugely beneficial.

Stop scanning and get alphabetical

Visually “scanning” large CSS files wastes time and creates fatigue. Why not just search for your selector by keyword? Alternatively, simply inspect the element using Firebug, read the selector’s line number from the ‘Style’ panel and use the ‘Go to line’ feature of your text editor (Cmd+L in TextMate). Provided you are Commend+Tab’bing (or Control+Tab’bing if you’re on Windows) between apps, all of this take seconds and saves you scrolling up and down a honking great CSS file.

If you are a “scanner”, a great deal of scanning fatigue can be avoided simply by formatting the main sections of your CSS in a structured manner and by listing your selector attributes in alphabetical order. “That’ll take forever!” I hear you say. Wrong. When my developer colleagues Matt and John (the best two front-enders I’ve known) got me listing my attributes alphabetically, I was surprised at how little extra effort and time it actually took. Believe me, any extra time or effort it does require when you begin coding this way is paid back in dividends when it comes to scanning your file. Even before you begin scanning selector attributes, you know roughly that border-radius will be near the top, and z-index will be right at the bottom. Other designers and developers maintaining the CSS can immediately benefit from the formatting. It makes so much sense.

Single-line isn’t tidier

Browser vendors are implementing CSS3 modules into their rendering engines at different times and in different ways. This forces us to use vendor prefixes such as -moz- (Gecko: Mozilla, Firefox), -webkit- (Webkit: Safari, Chrome) and -o- (Opera) as part of our selectors. Imagine for a moment you want to put rounded corners on an element, and you want each corner to have a different radius. It would look something like this:

div {
	-moz-border-radius-bottomleft: 5px;
	-moz-border-radius-bottomright: 6px;
	-moz-border-radius-topleft: 3px;
	-moz-border-radius-topright: 4px;
	-webkit-border-bottom-left-radius: 5px;
	-webkit-border-bottom-right-radius: 6px;
	-webkit-border-top-left-radius: 3px;
	-webkit-border-top-right-radius: 4px;
	border-bottom-left-radius: 5px;
	border-bottom-right-radius: 6px;
	border-top-left-radius: 3px;
	border-top-right-radius: 4px;
}

That’s bad enough, but it’s infinitely more scannable than it’s single-line variant:


div { -moz-border-radius-bottomleft: 5px; -moz-border-radius-bottomright: 6px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 4px; -webkit-border-bottom-left-radius: 5px; -webkit-border-bottom-right-radius: 6px; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 4px; border-bottom-left-radius: 5px; border-bottom-right-radius: 6px; border-top-left-radius: 3px; border-top-right-radius: 4px; }


Although this is an admittedly obtuse example, bear in mind that this is only for the border-radius styling of the element. It’s quite feasible to think that there could be another five or six attributes added onto this selector in order to achieve the desired styling. “But I don’t have wrapping turned on anyway”, you say. You’re still going to have to do a lot of back-and-forth along that old x-axis of yours when scanning for attributes.

Consider the majority

The vast majority of front-end designers and developers I’ve worked with prefer the multi-line approach. It’s more familiar to them, and as a result find it easier to work with. In a production environment where there are very large CSS files in need of maintenance by different people of varying skill levels, it makes sense to use methods that the majority is comfortable with. Creating code that multiple designers and developers are at odds with in a company only results in friction and causes frustration, slowing the pace and creating resentment.

Why make debugging harder?

If you use version control (and let’s be honest, you should), you’ll no doubt have had to compare two conflicting files in your time using some sort of diff utility. Sorting this kind of stuff out is never fun, but we can at least take steps to make it quicker and easier. In his article ‘Be kind to your friends: hit return‘, Jason Cale mentions:

If you have declarations that are all on one line, you cannot diff effectively as the changes are not clearly marked.

If you find it hard scanning through a single-line formatted CSS file, try scanning two at the same time. It saps time and is a frustrating exercise. There are more important things to be using your time for.

But what about file size?

If the size of your CSS file is very important, try using a tool like YUI Compressor or Minify to compress your files for serving up on a live site, keeping your own multi-line formatted copy nice and tidy.

I don’t want to come off as if I’m preaching here; if single-line formatting works for you, cool. But if the CSS you’re authoring is to be implemented or maintained by multiple people, try to think about how you can effectively reduce their workload.