Since I’m knee-deep in grids at the moment – both the book and Gridset – the theory, and thoughts on how it could and should apply on the web, is very much at the front of my mind. Last night I had a reminder on Twitter of the upcoming CSS3 Grid Layout draft. I recalled I wrote about it last year proposing some slight amendments regarding the addition of the module attribute. This would be a big change. It’d be great if it were considered, but I’m not hopeful.
However, that change not withstanding, one thing that really needs to change in this draft is the terminology used. Terminology (with some slight interchangeable differences) that has not really changed for many years in grid and layout design. Why reinvent it? Why define existing terminology to that more suited to spreadsheets and tables?
So, this morning, I emailed the working group to consider these changes. I’m posting this here for those who are not on the working group who may have opinions on this who can get in touch with me. I’d love to hear your thoughts, concerns and questions regarding this draft and how it fits with the established graphic design theory. I am of course on Twitter, or you can email me on this site.
In reference to: http://dev.w3.org/csswg/css3-grid-layout/#core-concepts-of-the-grid
I’m confused as to the need to invent new terminology with regards to grids that have existed for centuries. I’m also a little concerned that the mental model this terminology builds is one more similar to tables and spreadsheets (where these terms could be interchangeable) than to grids and layout.
Specifically on the terminology:
- Grid Lines are known as Gutters.
- Grid Cells are known as Modules (or Units – the term is interchangeable). They represent the smallest building block of the grid.
- Combinations of modules vertically are Columns *if* they run the full height of the grid.
- Combinations of modules horizontally are Rows *if* they run the full width of the grid
- Combinations of modules both vertically and horizontally are Fields.
There’s a lot of great stuff in this draft, but some of the theory of designing grids has been around for centuries. If we could start to align CSS with existing terminology, and existing mental models of how layout is designed, then all the better.
Just a thought…
For more information on this, I wrote a blog post last year that expands on some of this thinking: http://www.markboulton.co.uk/journal/comments/rethinking-css-grids
Thanks for your time and consideration,
– August 2nd, 2012
Recently at Mark Boulton Design, we’ve been working on a redesign of the global visual language for a large sports network. Like many web sites delivering news and editorial content, they rely on advertising for their revenue — either through multiple ad slots on the page, or from video pre-rolls.
Early on in the project, we discussed Responsive Web Design at length. From an editorial and product perspective, it makes perfect sense. Who wouldn’t want their content adapting to a device their reading it on? Who wants to pinch-zoom again and again? From a business and product perspective, we’ve seen this from multiple clients who want to take advantage of certain interactions on certain devices — swiping for example — for users to better engage with the content in a more native way. All good. And then advertising comes along and things get challenging.
Here’s the problem as I see it:
Let me go through each one of these in turn:
A large number of sites rely on advertising for revenue. Many of those sites will benefit from a Responsive Web Design approach.
The content for free expectation on the web has been around since it started. Many websites — where you pay for the content in other forms, such as newspapers — had to adopt this model, but use advertising dollars to pay for it. With the absence of any other revenue stream on these sites, the only other alternative is paywalls/subscriptions, and we’re seeing a few of these start to come through in mainstream newspapers now — The Times, for example.
As I mentioned earlier, many of these websites will benefit from a responsive web design approach. The consumption of this content has changed along with the plethora of devices and viewports. As I’ve talked about before, designing a ‘best fit page’ is becoming increasingly challenging if you acknowledge how usage has changed and will continue to change in the coming years.
Web advertising is a whole other industry.
There are sub-industries within web design as a whole that generally don’t talk to each other — such as gaming, gambling, porn, seo. Web advertising is another. These sub-sets each produce technology advances that everyone else benefits from. They deeply understand their audiences and how they interact within those verticals. But they don’t talk. Generally. For an industry that is built upon open standards, sharing, communication then this can be damaging.
Ad units are fixed, standardised sizes.
Hurray for standards! Because of the inherent reuse of advertising colatoral, this stuff had to be standardised. The Internet Advertising Bureau has been documenting emerging standards in web advertising for years now.
This is all good, especially for creating grid systems. Khoi Vinh talked about deriving a grid from an ad unit (PDF slides) when I shared a stage with him in SXSW in 2007. They are a fixed content element — unchangeable and standardised across a website. They’re knowable.
They are commissioned, sold and created on the basis of their size and position on the page.
This is perhaps the biggest issue for me. For example, a sales teams basically have a page ‘template’ with ad slots. Position A, B and C. In A, you can fit a Leaderboard. In B an MMU, and C a button. Also, if an advertiser pays lots of money, they can have a takeover. A takeover includes banners down either side of the page which join up to create a wrapper. Sometimes Leaderboards in position A can be pop-overs or flyouts. Sometimes, crazy stuff can happen where someone throws a ball from ad position B to A. Yes. Seriously.
The sales team then proceeds in selling the slots to advertisers who in turn provide the ‘creative’. This could be animation, video, graphics - increasingly a combination of all three - that are embedded in the page by a scheduling application. They’re sold based on the impressions rather than clicks.
That’s a lot of variables to account for. But, web advertising is becoming an increasingly aggressive industry. Advertisers and web sites are looking to innovate to engage users through marketing campaigns that align across multiple media. And web sites need to be accommodating.
Sales teams through many industries are also largely commission-based. As a sales person, you have a basic salary (or sometimes you don’t), and then you earn more depending on what you sell in the month. And here’s the thing. A sales team need a simple model in order to sell ads: a template with slots and a list of ads that can go in then. Now, let’s introduce Responsive Web Design into this.
Let’s say, you have the minimum amount of break-points: desktop, tablet and small screen. A sales team has a template with Slot A (the primary slot) that accommodates a Leaderboard for the desktop. But then that changes to a MMU for tablet. And changes again to a thin banner for small screen. A sales person has to understand they’re selling ONE slot for this. And an advertiser has to understand they’re paying for ONE slot for this. However, they’re supplying three times the amount of creative. And this is just a very simple use case. What happens with a takeover? Everyone wants as much bang for their buck as they can muster.
Many ads are rich (including takeovers, video, pop-overs, flyouts and interactions)
Increasingly, ad units are not confined by their pixel borders. Take-overs combine multiple ad units to give an overall effect of taking over the page. Flyouts show and hide a layer on hover. Pop-over do the same but in a different way. Video autoplays. Animation completely breaks out of the ad unit and can fly around the screen: how ever annoying that might be. My point is that the notion of advertising being confined by their pixels is also becoming increasingly grey. How would you accommodate a flyout for a small screen, for example? Another type of flyout for each breakpoint? So now the advertiser has to produce three times the amount of complex creative for the same, single ad slot? In order to make this commercially viable, they’d be looking for a deal then.
Those are some of the practical logistical things I can think of to challenge the notion that you can just ‘serve a different ad for each break point’. It’s just not that simple when millions of dollars are at stake.
So what can we do to improve this?
Well, some responsive sites are incorporating ad units now. But not many.
Boston Globe has incorporated an MMU ad unit. They’ve done this by fixing the width of that column and have the ad unit occupy that space as the viewport is reduced down to a single column.
The good news is, this is a problem a few in the industry are seeing as an opportunity. ADO published a press release just last week:
to deliver cross-media web innovation, user experience design and integrated advertising for brand, agency and publisher clients specifically around mobile full-service responsive web design.
Matthew Snyder, CEO of ADObjects adds:
We wanted to share our vision on 11.11.11 since we believe a critical part of the right digital strategy is to build a cross-media mobile strategy with complete 1-to-1 parity multi-screen design. With one recent client we were able to see 4x more traffic and 30% of the traffic to mobile via responsive design methods due to search and social link matching over conventional mobile web platforms
If these numbers are to be believed, then there is a considerable ROI for advertisers to work to adopt responsive design and an ad strategy that would match.
Now, let’s get down to brass tacks. How would approach building out a complex responsive web site that had multiple slots?
The existing model is based on advertiser filling slots, as shown in this diagram. Each is sold to perfectly fit an available slot. If none are sold, the website defaults down to a stand-in.
Firstly, I’d sell slot ‘packages’ rather than single slots. This requires an ad sales team to clearly explain what those slots and sizes are, and they’d be served on that basis. For example, an advertiser would buy a package for slot A. The creative to deliver against that package would be a Leaderboard, an MMU and a small banner for small screen.
Then, of course, the templates need to be able to detect the various widths and serve the correct ad based on that width.
Complex ads such as flyouts and takeovers would require much more thought and change. How could you effectively engage with an audience across the various viewport sizes when there is rich interaction involved?
As I mentioned, of course all of this is with a caveat that the advertiser is buying a slot ‘package’, rather than a single ad to fill a single slot. And that a sales team would sell it as such. This is the crucial difference, and for me, the biggest barrier to this change - it’s cultural and not technical, that requires a lot of explaining, and they always take the longest to do.
The template > slot > ad mental model is engrained both in advertisers, planners and web sites. Providing space for ads needs to be broadened into multiple spaces for one ad concept. This requires closer collaboration between advertisers and web sites, designers and marketeers and sales teams.
Over the past six months I’ve been working on this problem: speaking to sales teams, product owners, designers and as @kerns mentioned on Twitter this morning, the one thing that is plainly lacking at the moment is demand. I’d go one step further and say that the thing that’s missing is benefit. If the benefit can be clearly shown to advertisers and websites — in terms of an increase in penetration, reach, and ultimately, revenue, then we’ll start to see some movement.
– November 15th, 2011
Off the back of this article in Net Magazine last week, and the subsequent few tweets popping up in my stream, I’ve finally managed (in no small part from the help of Nathan and Alex) to pull together some of my thoughts and concerns regarding CSS grids and how they could (or, maybe, should) be created.
CSS Multi-Column is really simple. Basically, you divide a element into columns. This is already well-supported in many modern browsers.
Flexible Box Layout is a module that automatically resizes elements within another element without having to do a lot of painful maths.
Let’s concentrate on Grid Layout, as this is potentially the most designer-friendly and should match existing mental models.
The underpinning unit of measurement in a grid is The Module. From that starting point, Modules are combined to create columns and fields. Grid Layout doesn’t acknowledge the existence, let alone use, of the Module. Instead it dives straight into columns and rows. Which brings me on to my second point:
grids have been around for quite a while and there is established words for things like Columns, Fields, Modules and Gutters. It’s my feeling that the CSS grid module should speak the same language as designers, not that of developers.
The starting point for any grid system is defining your module size. The module has also been referred to as a unit. I’m using module for reasons that will become clear.
To summarise, a module is a repeated rectangle, with gutters in-between, that, when combined, form columns and fields. A module size should rarely be defined, but derived from a fixed, knowable constant to be designed with: image sizes, ad units, video sizes, to name a few examples.
Following the Grid module’s syntax, firstly we define our container div to display as a grid:
I then define my grid module with ‘grid-module’ as 50 pixels wide, and 30 pixels high:
grid-module: 50px 30px;
This of course be defined in percentages, or Ems:
grid-module: 8% 2%;
This is why I’m not using the terminology of unit for the module: in a grid system, the module is a unit of measurement. You combine and align content based on modules.
Similar to the Em, the Module becomes a user defined unit of measurement. And I’m proposing that we use that new unit of measurement to build our columns and fields.
The next thing we need to do when building a grid is defining the gutter widths and heights. Please note, there, that gutters are also the horizontal spaces between units as well as the vertical.
For this example, I’ll stick to something simple, like 21px.
grid-module: 50px 30px;
There’s a reason for the 1. Quite often, you may want to visually separate columns of content with a keyline; a line that runs vertically in the middle of a column. If your gutter is an odd number, with an even number of pixels either side of it, it means that 1px is available for the keyline. The syntax for this could be similar to border:
grid-module: 50px 30px;
grid-gutter-keyline: 1px solid #333;
Of course, this keyline would be on every, single module - both horizontal and vertical. We would, of course, have to add this to columns and fields.
A module is modular. Meaning it is repeated, both on the x-axis and the y-axis. We know that the y-axis is difficult to work with on the web due to content reflow. We just can’t control that vertical height yet. But, we can, and do, define the x-axis.
We use ‘grid-x-count’ to define the width of the grid. And this is the first time we introduce our new unit of measurement; The Module, or ‘md’. In this example, our grid is 10 modules wide, or ‘10md’
grid-module: 50px 30px;
Now, all you need to do to see your grid is to add a background colour to the module:
grid-module: 50px 30px #ccc;
Next in the process of designing a grid is defining your columns. Now, you should have a pretty good idea of these from how your derived the Module. For this, I’m using the same syntax as the existing proposed Grid CSS3 module. But, for me, the exciting thing is, I can now use the new ‘md’ unit of measurement to define the width of my columns. So, let’s say I want to create a column 2 modules wide on the left, 1 module wide on the right, and then a centre column of the rest. The ‘fr’ unit here is defined in the existing Grid Layout specification:
I add the ‘grid-columns’, with the first column as ‘3md’.
grid-module: 50px 30px;
The second column sees the introduction of a second proposed new unit: ‘fr’ - short for ‘fraction’, which is proposed in the existing Grid Layout proposal.
grid-module: 50px 30px;
grid-columns: 3md, 1fr;
Finally, I add the last column of 2md wide:
grid-module: 50px 30px;
grid-columns: 3md, 1fr, 2md;
That’s my columns sorted. Now, I need to add the horizontal fields. How we might use these fields are for things like headers, content areas and footers.
We add the fields in the same was as the columns: using our new ‘md’ unit. Now, you may well ask: ‘why can’t I just use pixels for the height of my header?’. Well, you could, but then you’d have limited connectedness to the underpinning grid structure. As such, you header might not feel like it belonged to the other things on the grid. A grid, after all, is about creating unity.
grid-module: 50px 30px;
grid-columns: 3md, 1fr, 2md;
grid-fields: 3md, auto, 1md;
So now we have our grid. Three columns and three fields, but all built upon a new user-defined unit of measurement: The Module.
There are other things that I would find useful for a CSS grid module to provide. How cool would it be for CSS to be able to give you pain-free baseline grid?
A baseline grid provides vertical rhythm within your grid, so that type and images align across columns. It’s possible at the moment, but fragile. Wouldn’t be great if it were a simple declaration that magically applied a baseline grid so that all elements would vertically snap to it?
I’m thinking something like this:
Speaking of snapping. Snap To Grid is a behaviour that many designers are familiar with. It’s generally a toggle on/off in layout software. You create a grid with guide lines, and then you can toggle ‘Snap to Grid’ on so that elements that you position on the canvas, ‘snap’ to the grid you created instead of float nearby.
Now, this is fine for layout software - where the behaviour is drag and drop - it’s a little different when we’re positioning things in a document. To be honest, I’ve no idea how this could work, but the goal is that instead of positioning by pixel, we could ‘snap’ to our grid. Making the grid and the tools smart, so we don’t have to do so much work manually.
Now you have defined a new base unit of measurement, you can use it to position content relatively to the grid (instead of relatively to something arbitrary like pixels).
As I discussed earlier, I feel the existing proposed Grid Module for CSS has a number of problems, and what this article aims to do is rectify those.
Grids are not made of columns and rows. Columns and fields are created by combining Modules. The first step in the process of creating a grid is not creating columns, but deriving and then defining your module size. Then everything else comes from that.
By creating a new user-defined unit of measurement, we’re able to continually bring the designers attention back to the grid. Not pixels, or Ems or %. Designers get this. It matches their mental model. But I think it goes beyond that. Having another unit of measurement that is specifically used for layout means that we can create a consistent, underpinning connectedness throughout our design. We can create padding and margins from the module. We can position elements relatively by the module size. Very useful, I’m sure you’ll agree.
For example, Gutters are a well understood term amongst designers for the space in between modules of a grid. They are replaced in the Grid proposal by the term Grid Lines. In my experience, the space in between a column is rarely thin enough to be called a line. In fact, quite often in layout, columns are separated by a visual keyline (as I mentioned before), with space either side.
One of the challenges for designers trying to get into web design, particularly trying to learn CSS, is the differences in terminology and also the mental models of how things are created. It’s why tables were so popular early on. It’s because the process of defining tables and rows for layout was familiar to designers. The terminology for designing grid systems has been around a long, long time. It’s taught in design schools all over the world, and baked into design software. It works. And if it ain’t broken, why fix it?
There are plenty of holes in this proposal. I’d love to take it forward into a proof of concept. Is this workable beyond simple three column layouts? How would this work for responsive designs? What about mobile?
But I think there’s something in this. It just makes sense to me as a designer for the CSS Grid module to be using terminology I understand; for it to support the process and mental model of creating a grid; and provide me with a new unit of measurement — the Module — so I can use it to create connectedness across my design.
There are no comments on my blog anymore, but I’d like some debate and discussion around this, so ping me on Twitter and I’ll provide an ongoing QA at the bottom of this post.
– August 8th, 2011
Back in 2003, when I first got wind of Web Standards, I was working at the BBC in Cardiff. I read Jeffrey’s book and followed the excited writings of Doug, Dan and Dave. The web was electric with promise of a new direction. And all the while, I was working with some developers who questioned my excitement with new Web Standards pathway that was being laid before my eyes:
Why do you want to do that?
Table are better, because Tables WORK!
We can’t change, this is the better way because we can be sure the website will behave in the same way on all browsers.
CSS isn’t for layout, it’s for changing the colour of things.
Web Standards is a trend.
And so it went. Week after week. Month after month. Until some big sites were launched that made people sit up and take notice. The Wired redesign, EPSN and the PGA site. yes, all the while, there were the naysays. The people who refused to accept that Web Standards was an acceptable way forward and, overall, a Good Thing. This is happening today with Responsive Web Design. Although, we’re seeing it at a faster rate and, as a result, there’s a lot of nuances that are perhaps not being addressed in the advocacy of this approach.
Let’s start at the beginning…
Last year, Ethan wrote an important piece on A List Apart called Responsive Web Design. It detailed the combination of a few techniques he’d previously written about under one ‘approach’. Then, in Seattle in March of last year at An Event Apart, that approach was combined in a ‘Perfect Storm’ of presentations from most of the speakers; a collective understanding that we need to move things along in a particular direction.
A few people have been advocating this approach over the past eighteen months, myself included. To me, Responsive Web Design is a set of techniques that serve to solve a bigger problem that I’ve been exploring for two years: Content Out not Canvas In. I’m excited about Responsive Web Design as an approach, as it helps me frame some of my thinking into practical implementation. Flexible grids, images and media queries give me some of the tools to let me create what’s inside my head. But, that doesn’t mean it’s for everyone, or for every project.
Let’s skip back to today…
This morning I got wind of a blog post from Luke Jones about his frustrations with the implementation of the collection of Responsive Web Design techniques. I share some of his frustration. But, just like with Web Standards before it, we need to go through this period of discovery. Pushing boundaries and breaking them is a vital piece of the design puzzle and we’re very lucky, in this industry, to be able to do this type of experimentation (you know, without anyone dying or anything). However, the interesting part of this post is the ensuing comment discussion (95 and counting at publication of this post). it’s clear to see that there is an awful lot of confused designers out there trying to work out if this thing is valuable and should we use it. Let me just cherry pick a couple of comments:
That’s the thing, I’m not saying it looks bad I’m just saying what’s the point? I haven’t seen a valid reason for changes in browser widths affected how a website is displayed. Luke Jones
“That it changes at all is a red mark against usability, the user loads the page, the expectation as to the structure of that page is set. ” Stuart Frisby
Users (me especially) do not want to see a site change when resizing the browser.Luke Jones
This final comment from Luke actually encapsulates the problems:
I think that’s exactly it: there is overkill and inappropriate usage going on with the new technique. I honestly think the only people who notice a lot of the responsiveness are people like us, which makes it a waste of time.
I agree with this. But, that’s ok. Responsive Web Design is REALLY NEW and NOBODY knows how to do it properly/right/appropriately yet! We’re all just experimenting. And THAT’S FINE!
If the approach is deemed to be appropriate, then there is no reason why it can’t be done. If people do it on their own blogs, because they want to experiment, then that’s fine. It really is.
We’re all just trying to work this out.
Like it or not, web design is maturing to a state of recognising the importance of content, presenting that content in different contexts that are appropriate for the users of those websites and applications. We’re also challenging web design practice that has been around for 15 years or so, and graphic and typographic design practice that has been around for close to a 1000 years!
This will continue to hurt. And when Responsive Web Design matures, something else will come along that will challenge us again. And that’s how we grow. That’s how we move this thing forward.
Just as Web Standards was a shift in how we create websites, Responsive Web Design is part of another shift. It may be a little trendy at the moment, as people grapple with how to use it, but quickly – together with other things like Content Strategy, and the One Web, and Mobile First etc. - it will become another tool in this shift to a better, ‘Content Out’ web.
– June 20th, 2011
I’m going to leave the detailed explanation to Andy, but in a nutshell, the group is going to help the ‘W3C’s CSS Working Group to better deliver the tools needed for tomorrow’s web’. I’m particularly interested in having the opportunity to be involved in the several layout modules which have thus far been proposed.
Andy’s rounded up a fantastic bunch of designers and developers here. Hopefully we’ll have the collective clout to influence things in a positive way in the months to come.
– October 8th, 2007
There has been a lot said recently about Vertical Rhythm. Richard Rutter began the work on 24ways last year with the piece ‘Compose to a Vertical Rhythm’. This was built upon by Wilson Minor on A List Apart recently with his article on Baseline Grids. All sound typographic advice. If you haven’t read both of them, I’d urge you to do so now otherwise you know what I’m on about it in this post.
At @media this year, I presented ‘Five Simple Steps to Better Typography’. Step two in my presentation was was Vertical Rhythm where I reiterated some of the excellent points Richard made in his article and also the presentation we both gave in at SXSW in March. I also added something of my own: Incremental leading, or Incremental line-height.
Working through both Richard’s and Wilson’s articles, they both treat the sidenote in the same way. They align it directly to the vertical rhythm unit. This is correct of course. But, to my eye, the line-height in those sidenotes, as it’s a smaller type-size, is too large. 10px on 18px leading is stretching it. So, how do we reduce that line-height whilst still adhering to the vertical rhythm we’ve established. Once again, we look to print design for that answer.
In editorial design, there is a technique used for sidenotes and boxouts that aligns to the baseline grid, or vertical rhythm. It’s called incremental leading.
Here we have a simple page of text based upon Richard’s example. There is an H1, some text, a sidenote and a footer. They all align to an 18px vertical rhythm shown in red.
To my eyes, there is too much line-height to the sidenote. So, how can we reduce this line-height, but adhere to the 18px rhythm?
Instead of aligning every line in the sidenote with the vertical rhythm, when you use incremental leading, you align, say, one in every four or one in every five.
Here’s an example with incremental leading set to align every fifth line of the sidenote to every fourth line in the main content.
Adding in the vertical rhythm grid once more we can see the line alignment.
Firsty, make sure you read Richard’s article and apply the rules to body of text. Once you’ve got the 18px rhythm set up and everything’s aligning as it should, then you can look at the sidenote.
As we’ve decided we want to align 4 rows of the main content to 5 rows of the sidenote, we begin by finding the value, in pixels, of 4 rows combined.
Four lines of the main content.
18px x 4 = 72px
Then we find the value for 5 lines of the sidenote.
72px ÷ 5 = 14.4px
To calculate what 14.4px is in ems (in relation to the body, and the type size for the sidenote)
14.4px ÷ 10px = 1.44em
We then add the values to the CSS for the sidenote.
You can see this working in this example.
However, note the top margin. I really had to fiddle around with this manually to make sure the alignment was correct. I did try and work out the maths for it, but it proved to be very difficult as really I needed to find the cap-height value of the typeface in order to provide a margin.
Martyn, a bloke I now share an office with (who is also a Mathematics graduate), provided me with this diagram to illustrate my problems.
As you can see, the problem is I needed to find the value of ‘x’. In order to do that, I’d need to know the value of ‘b’. The difficulty arises from trying to align the baselines and the only way of doing it was aligning it by eye. But, if you can fathom it out, then I’d be grateful.
Now, all I need to do is find the time to apply to this site and the new business site.
– June 15th, 2007
In the Web Standards community we hear the words ‘Semantic Markup’ thrown around a lot as a concept—the right thing to do— but I know a lot of designers who are trying to learn this stuff are being confused by the whole ‘semantic thing’.
It’s a difficult task for a designer, who primarily thinks very visually, to relate to a concept like semantics in a document when all they want to do is create something.
After doing a ton of research over the past couple of weeks I’ve begun to notice links and patterns between typographic theory and Web Standards.
I’m going to keep this quite brief and hopefully practical from a design and development point of view.
First of all, I’ll explain some of my thinking.
In most documents there is a typographic structure and a hiearchy of elements, from letters up to chapters. Here’s a list, which is by no means complete, that explains what I’m on about:
You could of course go more granular than this, but I think it illustrates the point.
From this you can see how, by looking closely at the content, that the language can be broken up into chunks, into bits of semantically functional elements. So, you could argue that:
This perhaps the key to successful typographic design. Making sure the graphical representation of the content matches the mental model of the reader, or conceptual structure stipulated by the author (or preferably both).
As I mentioned earlier, designers often struggle (in all the Web Standards malarkey) to make the connection between their design, the content and then the code. The code bit seems very abstract initially. Hopefully this next stage will help explain how the gap can be bridged painlessly.
We have our model for matching the semantics, or meaning, of our document to the design we create:
Now, add to that our step for XHTML:
The graphic and XHTML structure of a document should reflect its conceptual structure.
Therefore our finished web page will:
I’m going to put this into pictures to help explain what I’m on about. If anything it might help me firm up this theory a bit.
So, let’s put this in the realms of reality. Let’s say you have a brief from a client, who happens to be an estate agent, to build a web site for him. Most of the content for that site will be house details. Currently he produces single sided documents with the house specs on and he wants you to build the bulk of the website using this information.
So, here’s the house details:
As you can see, there’s very little visual design been done to this document. The first task then is to establish the document’s conceptual structure, its semantic elements, from there we can identify our typographic structure.
Once that is done, forgetting the design for the moment, we can (again, using the documents conceptual structure), label those elements with their corresponding XHTML tags.
The document conceptual structure is retained, we now have our XHTML structure (our semantic markup). Focussing then on the design we can make the typographic structure match the conceptual structure (still retaining our XHTML structure)
And there we have it. A typographic design, which has been tagged up with semantic XHTML, which retains the author’s conceptual structure.
The benefits of going through the process in this manner is that it’s from a designer’s perspective, there’s less of a leap conceptually into the land of code where document structures are common place (OOP etc.) I’ve been following this model for a couple of weeks now and it works pretty well. It streamlines the process of assigning heading tags for example which have always been quite arbitrary in the past.
For those designers who are coming from a multi-disciplinary, or print, background and have trouble with this whole ‘semantic markup’ thing, please give this a go and let me know what you think. In fact designers who have been doing Web Standards for a while please give this a go and let me know how you get on with it. I’d be interested in knowing your thoughts.
– November 24th, 2005
Here I am, sat on a train, stuffed full of Sushi awaiting the train to finally pull away so I can start my long trip home (about four hours depending on which signal’s decide to fail). After buying my 12inch iBook in July, this is the first time I’ve used it in a truly mobile capacity and so far it’s going well. Anyway, I’m not going to go about sushi, trains or laptops in this post. Today, I had the great pleasure of attending the ‘CSS for Designers’ workshop hosted by Carson Workshops in London. What a day it was.
I’ve sat here for a good ten minutes now thinking where to start on describing today, so I’ll just start at the beginning.
Carson Workshops is a UK based company doing really great things. Ryan and Gillian’s combined talents are managing to get the most talented and inspirational speakers from around the world over to the UK, as well as events in the States, to give day long workshops to the industry.
Like a lot of web professionals (do I fall within the bracket Andy? Molly? I’d like to think so :)), I try to attend as many conferences as I can in the web industry, such as @media, SXSW, unfortunately I couldn’t make it to dConstruct, but I was there in spirit. These conferences are generally very good. The wide variety of speakers give informed presentations on a plethora of material. However, these panels and presentations rarely last more than an hour, and from my experience, there’s only so much you can gain from them. Workshops, such as the one attended today, are a very different beast all together.
I’ve met Andy before in person, very briefly, at @media in London in June and found his presentation very inspirational from a designer’s perspective. Andy talks the same language as me. Japanese. No, seriously, Andy’s design talents are but the tip of a Web Standards trifle. I mean, Iceburg. The guy just really, really knows his stuff. Not only all the creative design stuff, but also how to implement it using web standards. The most important thing, however, is Andy can explain this stuff in a language designers can understand. No mean feat. The same can be said about his co-presenter, Molly.
It was great to finally meet Molly. If there’s one person in the web industry who embodies the passion that first got me interested in this medium, then that’s Molly. The thing that got me about Molly, as she was presenting throughout the day, was the incredible depth of her knowledge. Like Andy, she really, really knows her stuff but in a slightly different way, from a different background. The two of them working together throughout a whole day worked very well indeed. A great double act. Not quite Morecombe and Wise though, more like Cannon and Ball :)
Ok, that’s enough back-slapping (the troll’s will be queueing up otherwise). What I’m getting at is, if you get the change to go to a workshop like this or listen to either of these guys speak, then do it.
As I was saying earlier, a workshop format is very different from a conference. In a conference format you only get a snapshot of the presenter’s work, on a subject they choose, in a format and structure which may not be totally up to them. How much can you really gain from this format in practical terms? Yes, they’re great for inspiration, for steering you in the right direction, but generally they lack specific detail and the opportunity to ask very specific questions in the context of a project you may be working on. The workshop format changes all of this.
This was a full day workshop, from 9am until 6pm with reasonable breaks for lunch and coffee. So, it was a long day to sit in front of a projector and listen to two people talk about the same subject. Or so you may think. In reality, it wasn’t like this at all. With some nicely designed slides, a user-friendly agenda (meaning it wasn’t all design in the morning and theory in the afternoon) and regular swapping over by Molly and Andy it made the day go really quickly.
When I first arrived, Molly and Andy both expressed a concern to me that I’d know a lot of stuff that they’d go through throughout the day. This was not the case at all. Regardless of your experience level, you should consider attending one of this workshops. I learnt tons of stuff that I’d either skimmed over, couldn’t be bothered learning fully, or got by by other means. One of these examples was Molly’s examples of Relative and Absolute positioning. I’d sort of understood them for a while, but never used them because I’d always used floats. During the presentation a little light bulb went on in my head. ‘Hello there’, I said, ‘Now I get it. This looks really cool!’. In fact, that happened quite a few times throughout the day.
The personal highlight for me was when Andy was presenting a section and grid design and a slide of my site appeared. Well, if he hadn’t of forwarned me, you could’ve knocked me down with a feather. He even made me stand up, which was nice. I like to think I took this five minutes of fame in my stride to a rather bemused audience who, not surprisingly, had never heard of me.
If there’s one thing to be said about today’s workshop is that it was enlightening, both in terms of day’s presentations, but also in the pub afterwards (which is where most of the really useful stuff is normall discussed). Thank you to Ryan and Gillian for hosting a fantastic day. It was great to meet some new people, finally meet Molly and have more than five minutes to talk with Andy. Interesting to note how many people from the BBC were there also. Are we to expect big CSS things from the BBC designers in the future? Well, just maybe.
Well, that’s killed an hour. Right I’m off to the buffet car. Stella anyone?
– November 19th, 2005
I’ve just received my copy of Professional CSS - Cascading Style Sheets for Web Design so I’d thought I’d share my first thoughts after flicking through the book.
p>First off, this book looks like a technical book written for people who already have a good understanding of CSS and what that involves, this is not a beginners book.
p>There’s a foreword by Zeldman. I was quite looking forward to what Jeffrey would say about the book and the subject matter, but I guess he’s already said it all as the foreword is a little uninspiring (sorry Jeffrey). The first chapter deals with planning to design and build a website and touches on subjects such as Information Architecture, Scope and it’s really nice to see a good couple of pages on Personas and User Centred Design.
The second chapter outlines best practices in XHTML and CSS, giving a brief overview to semantic markup, box model, cascade and inheritance, etc. Again, if you’ve read a few CSS books before this one, a lot of this won’t come as a surprise.
Then comes the bulk of books content, chapter after chapter of case studies with interviews from the designers and the techniques used to build the sites. They are:
I’m sure they’ll be some really good stuff in all of these chapters.
Anyhow, the upshot is, on first glance, it looks good. It’s good to see a book aimed at the professional whose been using CSS for a while and understands the benefits etc, but needs a book to explain some more of the detail. Like I say, I haven’t read it yet, just thumbed through it, but from what I can see it’s certainly worth the money.
Who knows maybe next Geekend I can get Dunstan to autograph it for me. What do you reckon I could get for that on ebay?
– August 8th, 2005
It’s amazing how productive an afternoon watching a gig can be.
So, if you click on ‘Accessibility options’ on the top left you’ll go to a page where you can set a cookie for the new layout.
Just to summarise Joe’s points from his presentation in creating a ‘zoom’ layout (please correct me if this is wrong):
I will of course be addressing the point Joe raised in his presentation that low-vision people generally prefer a high contrast (light text on a dark background), which is the version I’ve added here, but people with certain learning difficulties prefer dark type on a pale background. I will be adding a version of this soon.
Doug Bowman of Stopdesign recently added these two different styles to his site. The zoom layout is available for use and was used as the basis for my high contrast stylesheet.
Also, thanks to Roger Johansson for prompting me to get this done and also providing the code for the cookie.
Like I said, this is very much a ‘beta’ layout at the moment. There are problems with it and there are problems with the content ordering and stuff, but it’s a start and hopefully I’ll begin trimming it down over the next few weeks.
– July 2nd, 2005Next