is starting to look at HTML and CSS for Mobiles. If you’re been following the discourse over the use of CSS and standard, mostly-table-less XHTML for any amount of time, you’ve certainly bumped into the argument – one of the strongest, in theory – that future non-laptop/desktop computers accessing sites will benefit from such techniques. Griffiths is putting the proposition to the test.
Many people
have weighed in on the question of CSS now that the issue has become a “live” one in the weblog world. A representative opinion on one “side” of the thing (if sides here makes sense, which I don’t actually think it does) is that of Matt Bridges in CounterProductive. He wrote, “When a designer uses CSS to mimic what can be done with tables, separating content into different boxes that are placed at specific parts of the screen, they tie that content to that layout. This completely defeats the purpose of separation of style from content.”
It’s a perfectly reasonable statement, and having worked on some CSS layouts I do see the drawbacks alongside the advantages. The problem is, however, that most people seem to have the foundational principles wrong. And their error leads in ugly directions.
CSS is about style. But there’s something much more important than that. Implementing CSS also returns structure to HTML. And that is where the value is – it’s not about separating content from style – that’s what a CMS is for. Rather, it’s to return the third variable – structure – to its rightful place in the mix. So that not only do you have the flexibility to do anything you want with the content (in the CMS), and to redesign that site as you like, but there’s also a fully degradeable version at the heart of the human-readable, “published” version that any device can read, as long as it can interpret HTML in some rudimentary way.
The question on the table
: Are tables really evil? Well, no they’re not. But they were never intended to be used to format web pages, and so now that there’s a better solution (CSS), they should no longer be used that way. Tables are still completely viable in HTML – but for displaying tabular data.
Why? Why, really, should anyone change? The best answer is this: for the same reason Userland developed Radio. Radio solves (as do other systems) a big problem: separating content from style. Trouble is, there are three variables, not just two.
Content – we know about that. Style – we know about that too. But there’s also structure to consider. Using CSS allows us to separate structure from style. This is as powerful, in its own way, as separating content from style, and just as important.
By using CSS to format my pages (though I do have one table still kicking around, unfortunately), I get to present items that any device can understand. If some bit of text is a very important heading on the page, I don’t obscure the fact by coding it with font tags and hiding it in a table that’s purely there to place it in a prominent position on the page. I call it what it is: h1. Simple, clean.
Most importantly, though, suddenly it no longer matters what device is trying to “display” or render my page. Anything at all will see that and display that bit of text as the most important thing on that page.
Why is that important? Well, because as Dave Winer says, the web should be a great writing environment – which implies that it should equally be a great reading environment. When I’m writing, I’m only concerned about me – my ability to write well and have it appear. To make it a great reading environment – and thus support the other side of the coin – I can’t just care about me, I have to care about everyone else as well. And the fewer assumptions I make about them the better. Who am I to insist that they use a certain device to look at my page? They read, their choice. Why should I make them track down an alternate version which may or may not work on their particular device?
If you want the web to be a great writing environment, you also want it to be a great reading environment. And that means using CSS to provide the style, HTML (or XHTML) deployed in templates to provide the structure, and a CMS to feed the content. It’s quite simple, actually.
Earlier today
Ed quoted a post by Christina Wodtke referring to JJG‘s article:
I’ve always held that information architecture is architecture in the information space, and must embrace content architecture (a.k.a. little or narrow IA), interaction design and information/interface design, and the architects are those who practice and excel in those arts.
Christina goes on to say that, “a lack of thoughful […] architecture results in sites that are difficult to navigate, difficult to use, unprofitable, unrealized and generally stinky.”
I agree that is often the case, but I don’t think the solution either begins or ends with IA, whether referring to the practitioner or the discipline. I think it starts much earlier, which is what I was getting at earlier today.
Ed suggested that a web designer should be a part of the solution, and on that we agree, though I would underline that a web designer is not simply a graphic designer working in Photoshop. A web designer (I prefer “developer”) works with the graphics and the code, realizing the graphical concept she or he has come up with in working HTML/XHTML/CSS etc.
For me there are four equally important tasks to complete once a web project has been given the go-ahead. Design, IA, content (or editorial) definition, and application/DB development. Further, none of those tasks can be completed in a vacuum – the job of each relies on the work of the others. Hence, for instance, the person doing the content definition must know what happens in the code, at least superficially, and the apps people have to know about what the IA is going on about.
All of the tasks have to be completed to a high level of quality, of course, whether it is one person trying to do it or a team of 10.
There’s one other person that needs to be in the mix: the project manager, or as I say sometimes, the product manager. This person has to know the web, they have to have lived in it, and has probably filled at least one of the other roles at some point in their career. This person is the one who figures out (and documents) the initial strategy (in consultation with “the business”), and who works with whomever is necessary to research things before high-priced specialists are brought in to make it happen for real. The project manager, to me, isn’t just a process person, it’s fundamentally a bridge position between the business needs that form the reason for doing a project in the first place and the more techie folks who will develop the specific elements that become the finished product.
It seems to me that the heady days of the dot-com bubble introduced a lot of inefficient processes to the web world. Most importantly, maybe, was the introduction of the idea that the “boss” didn’t have to know what the “web folks” are actually doing day to day. For me, that’s the foundational problem behind why there are so many “generally stinky” sites out there. IA is important, for sure. As are the other roles in a web project (don’t get me started about how important it is to have a real “jack of all codes” technical lead when a project has moved into a more quotidian integration or maintenance phases). But those disparate tasks, usually completed by people who quite literally speak different languages, need to be brought together by a skilled and experienced person who has a good idea of what each of them is doing. It might be Information Architects who often get pulled into that role, but it’s not strictly an IA role that they’re filling. It’s a layer away from what I understand IAs (the required tasks) to do: it starts earlier, and it ends long after. Maybe never, as long as a site is alive.
Luckily for the field of IA, it’s just that kind of project manager who knows the value of IA people, and would only consent to developing a site without one under great pain!
So I’ve mostly
installed my new design here at mikel dot org. There are still some nails and debris hanging around, but it’s OK now. And although there is still a table or two, it’s CSS and HTML 4.01 compliant. Or at least the templates were when I tested them immediately before adapting them to the various Blogger formats.
- 1
- 2
- 3
- …
- 6
- Next Page »
