TV version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer


Weblog Entry

Methodology

November 14, 2003

From an e-mail exchange last night:

I think there’s an important relationship here: if content is the focus (as it should be), usability means structuring that content appropriately.

Structuring that content appropriately means designing it properly, but you can’t design until the content is in front of you.

Once you’ve designed it, it’s easy to look at the comp and figure out how to break down the content into structured markup (or, it is for me these days anyway — I build XHTML before I touch CSS). And then once the markup is done, you style it with CSS.

Really, in the end, CSS is the last step in the chain, and the least important. BUT. You have to consider it as early as the structuring.

If you can’t build it, well then you can’t design it. So even though CSS is the least important step, it’s still absolutely critical to the design process as a whole.

It’s the designer’s job to know the strengths and limitations of the technology, and how to make best use of it. That is why CSS is important to the designer; no more, no less.


Reader Comments

Eric says:
November 14, 01h

“you can’t design until the content is in front of you”

This thought is a legacy of the print design world, and illustrates one of the main problems that designers have when moving from print to online, that being thinking abstractly about content.

Dave S. says:
November 14, 01h

And any reversal of that thought is an artifact of a programmer-cum-designer mindset, one who views content as nothing more than something a database spews out.

Designing without considering content isn’t designing. It’s “skinning”.

Jeremy says:
November 14, 01h

One of my biggest peves is to not know what kind of content a client intends to put on his site.

They say to come up with something, so I design using Lorem Ipsum and have nice content design, then have to shoehorn some crap into the layout, or worse yet, they do not have the content to fill the layout as i have designed it, which usually means they want some meaningless image collage or something.

Content is king.

Especially when designing a site. Always helps to know about that first.

November 14, 02h

In my experience, you can’t *re*design until the content is in front of you :)

The design process (for me, at least) requires many iterations. Separating structure from presentation just means a designer can iterate faster.

But the designer must sometimes go back and adjust the structure to facilitate the presentation. Eric Meyer wrote an excellent analysis of this:

“The Incomplete Divorce” http://www.meyerweb.com/eric/thoughts/200310.html#t200310015

Jon Hicks says:
November 14, 02h

Same feelings as Jeremy.

Many sites I have designed have suffered from not seeing any real content until it was too lateto do anything about it. There needs to be a bit ‘back and forth’ before the final design.

Marc says:
November 14, 04h

Chicken. Egg?

Keith says:
November 14, 04h

Exactly Marc. I have noticed lately that while working on the redesign of my own site that I am giving much more thought to what content is going to appear on that page. It has definitely made the process easier.

I have yet to find the perfect process (for me) when it comes to designing.

Jim Amos says:
November 14, 05h

I have to agree that designing a page is a much less frustrating task if you already have at least some of the content in front of you. Designing without content at all is like driving blind: you know how to get there but you can’t exactly see where you’re going. Or something like that lol

Coincidentally (or not) this conversation corresponds to an entry I just read at mikepick.com:

"As you go through marking up the content, you can then think about how it will lay out and assign style blocks, class wrappers and ids as needed"

Mike says:
November 14, 07h

Hey, I was just thinking about this myself!

It’s not 100% applicable - it really depends on the nature of the project. And as the latest at StopDesign says, you sometimes have to break away from the XHTML/CSS trap and think visually, instead of in blocks.

And of course everyone knows that getting content from clients is like pulling teeth.

Still, if you can get your assets assembled ahead of time - it can pay off to concentrate solely on markup and only move on to style rules after the HTML files are written. This is where you get the tightest code IMO.

November 15, 07h

Perhaps this is one of the reasons why the CSS Zen Garden is so successful. Designers already have their content, so they are free to create without fear that different content will spoil it.

In fact, that raises an important question. Should there be an alternative version of the CSS Zen Garden that handles different content? Perhaps Dave could come up with a version that includes some dynamic content. I’ll wager that the designs won’t be quite as dramatic under those circumstances.

11
Chris M. Cooper says:
November 15, 10h

I think this issue becomes very prevalent in education also. Now that institutions of higher education are offering courses in “web design”, students are having to learn how to build web sites without understanding how important content management is. A person designing for a dynamic medium must know how to design for dynamic content.

I’m only a second year design student, however, I’ve been playing with web sites since late 1994, and though I have published very few web sites for paying clients, I understand how the web works pretty well. Consequently, I’m the only one in the department who really knows this stuff, even the teachers don’t know the web yet. So I have been asked to help teach the upper division classes about web design, but I’m pulling my hair out trying to get them to understand simple concepts like image rollovers and block elements that expand to fit content, let alone enabling a page to handle content that will actually be changing.

I’m very frustrated, to say the least.

If this was off topic, I apologize.

Dave S. says:
November 15, 10h

Simon – in fact, many have proposed just that. I’ve had people approach me about dynamic content, web applications, and e-commerce variants of the same core concept. One person even went so far as to throw down the challenge - http://www.nosightatnight.co.uk/challenge/ - but since July I don’t think there have been any entries.

I’ve never been opposed to the ideas, and have encouraged anyone who can build a better mousetrap to do so. But I don’t think they’re necessary for a few reasons. Any talented designer will look at what the Zen Garden does and see that the content itself is largely irrelevant, it’s the principle of the thing that’s important. And the barrier for entry on the Garden is lower because you’re not trying to hit a moving target; while a certain time investment is necessary to build a great design, people aren’t spending the next three years tweaking for every possibility and contingency.

The Garden worked on a lot of different levels, but those two are rather important, and reasons why I couldn’t see much in the way of dynamic content catching on for a similar project. If the types of people that make decisions on these things absolutely can’t see the forest for the trees, maybe they’ll be necessary at some point; but in cases like that, I think referring them on to Wired and ESPN and their ilk will be far more effective anyway.

Those are just my own thoughts, based on running a similar project. If someone wants to prove me wrong, best of luck. I’d welcome it as much as everyone else.

13
Emperor Zelnox says:
November 15, 12h

I come from the Software Engineering world and an important concept stressed is iterative development. The bane of all software processes (building software is partly a creative process) is the waterfall model, where one complete steps in a sequence, from requirements to design to implementation and so on (no backtracking).

A better approach is to work iteratively and incrementally. Artifacts produced from one iteration is reused or refined in the next. So CSS cannot be the last step. It is part of a larger group of inter-related activities.

Most processes start with requirements elicitation and indeed this is important activity. In a waterfall model, mistakes or confusion here can lead towards the wrong path (usually discovered too late). On the other hand, if the website is developed iteratively, mistakes can be caught much earlier and confusion reduced. Nevertheless it does not eliminate the problem of changing requirements.

There are developers who pratice user-centered design, because it helps them “freeze” the requirements that matter early in the process. An example of such a process is the Fusebox Methodology.

Finally, when I was still studying Software Specification, it was funny how we were taught that most clients ( and stakeholders) do not know what they really want. You have to pry it out of them. There are various techniques for that and maybe they can help web site designers too.

Hope this helps and thanks for reading.

P.S. 1 degree Celcius in Montreal, and no snow yet!

Sian says:
November 16, 04h

I’ve just gone through a period of several months where I helped out with a website with hardly any content. My opinion before going through this process was ‘use Lorem Ipsum and everything will be fine’. Not now, content is king.

Same said website wanted it originally designed in Powerpoint and was puzzled why it wouldn’t work on the web. ‘Nuff said really.

Eric says:
November 16, 04h

“And any reversal of that thought is an artifact of a programmer-cum-designer mindset, one who views content as nothing more than something a database spews out.”

That is fairly accurate, but I submit that content is, in fact, nothing more than something a database spews out. Consider the Zen Garden, as mentioned above. They are designs based on pre-existing content, and at least half of the designs wouldn’t stand up to being dynamically generated. The most obvious example of this is the one’s that use image replacement.

Maybe it’s just semantics, but it’s my opinion that if it can’t come out of a database, it isn’t content, it’s design. Obviously you need to have some limitations, typically defined as “content types”. If you are doing a news site, you will design for headlines, subheadlines, article text, author citations, related links, etc. If some totally new _type_ of content comes along, then some design tweaking is needed and everyone in the process should realize that. However when a design fails because of changes in the content itself, that’s a problem. I’ve seen way too many comps where the designer cheats by putting in fake content that is too brief, and then complains when the text wraps in the real site.

Now, there are people here, like Dave S, that have intimate knowledge of page development, and these are the designers that typically cause the least problems, but they also happen to be the rarest kind of designers. If there is a cause for this, I think it’s because up until the last year or two, the designers that are willing and able to reach this familiarity found it was more profitable to just become HTML programmers. Now that HTML programming is a pretty hard line of work to get or keep a job in, those people will hopefully make their way back into design.

16
Hero A says:
November 16, 05h

“Maybe it’s just semantics, but it’s my opinion that if it can’t come out of a database, it isn’t content, it’s design.”

Perhaps it is just a matter of semantics, Eric, but we need to clarify our common terms in order to continue a meaningful discussion. Otherwise, web IT personnel and web designers will continue to view each other as condescending adversaries.

Let’s first take a larger view and agree that the web, with all its supporting technologies, processes, and workflows, is merely another medium alongside print and traditional broadcast media: technological conduits and protocols to pass along messages. In the scope of this discussion, the medium is *not* the message (apologies to the societal insights of H. Marshall McLuhan).

From a designer’s perspective, the statement quoted above is about neither content nor design; rather, the statement refers to data and stylistic presentation.

What is missing is context and meaning: data without context or meaning is *not* content, and stylistic presentation without context or meaning is *not* design. In isolation, neither data nor presentation communicates anything. It is context and meaning that provides the purpose, scope, and direction.

That’s where designers come in.

The job of the designer (any designer in any field or medium) is to facilitate and enhance communication for one’s client. In contrast, an artist creates works of personal expression (unless they are a technical or production artist– aren’t semantics fun?).

When I use the term designer, I’m not talking about stylistic desktop publishers who fancy themselves as “designers” because they consider themselves artistic, happen to know how to use the tools of design (such as HTML tags or Adobe or Macromedia software), read some technical “Be-A-Designer-in-24hrs” book, and think that they know everything about “design.” Unfortunately, most remain satisfied with their unrefined stylistic level of work and never understand the larger scope of design.

Truly effective designers (and I make no claims about being one), whether classroom- or self-taught, allocate a large portion of their effort to understanding the context and meaning of the message a client is trying to express. When designers say “getting content from clients is like pulling teeth,” they are talking about context and meaning: purpose, scope, and direction. Stylistic treatment is placed on the back burner until the content is sorted out and prioritized; otherwise, style will distract from the content rather than enhance it.

Have you ever noticed that effective, straight-forward design is often accused of being “so simple that anyone could have done it”? That’s usually (though admittedly, not always) because the designer or design team expended a great deal of thought and effort sorting through and leaving out less significant data while trying to balance the most effective amount of informational detail with client expectations.

Whether the client is big or small, this is an organic process that requires more interpersonal communication than it requires personal computing. Understanding the content is *the* crucial requisite initial phase upon which the rest of the process stands or falls. Mentioning iterative development is all well and good, but design has been an iterative, organic, flexible process long before IT departments existed. (Kelly Goto and Emily Cotler’s book, Web Redesign: Workflow that Works, is an amazing resource that covers a combined design process and web workflow.)

When setting up processes and workflows, then content *classification* should be conceptualized in abstract terms. However, for *specific* content to have practical effect as communication, it must stop being considered an abstract puzzle piece and given appropriate value and attention.

To say that content is not a requirement of the media process is to completely miss the point that content is *the* reason these media and processes exist. Ultimately, isn’t content what human beings communicate to other human beings?

Ergo, concordantly, vis-a-vis: Content is king.
;)

(Yes, that’s my real name below. Non-western parents– ’nuff said.)

November 16, 07h

for me, it’s a feedback loop, at least in the initial stages: xhtml structure -> css -> real content comes in -> tweak xhtml -> tweak css…rinse and repeat.

18
Gabe says:
November 17, 08h

That is a great clarification of the issue Hero.

I think content is necessary to optimize a design, but often times the abstract content is enough. If you can discover the purposes of a web site and the pieces of information it will contain, then you can do an awful lot of design work without the actual copy. Certainly having the exact content allows the design to be considered that much more closely, but in the real world we may not have the budget (or the talent) to devote such attention to detail. Obviously cramming whatever content you have into some unsuitable stylistic framework is not going to yield optimal results, but it’s not a black and white issue. All media entail some design compromises. The idea is to make the acceptable compromises to avoid the unacceptable ones.

19
april says:
November 24, 10h

I think one thing missing from this discussion (and maybe from design in general) is the old print methodology that distinguished between design and production. While its true that you can’t produce a site without content its not necessarily true that you can’t design one without content. In fact, whenever I have designed with detailed content already in hand the ideas are usually not as creative or as interesting and unique as they could be.

20
Mark says:
November 29, 06h

This is a tough one. I’m building my first full site in CSS and xhtml at the moment.

This is a personal project so i guess that makes it different. I know the content maybe a little better than in a client relationship.

I usually just produce a template in Photoshop. This is the design, this is the navigation, and this is the content. Then I make it into HTML and type the content in. Is that so wrong? It’s hard to think about the content before you have a site that actually looks like it is alive.

I guess the good thing is with CSS it will make it allot easier to refine designs once the content is starting to take more shape.

But interesting about redesigns. Should we design a very quick design, like a hybrid and then work on the content, seeing how it fits in with the design. Then once it’s all done, make a final design from that?

Hmm confusing what should be done about this issue, it’s making me think about this site. I don’t really know the content apart from the different sections and the design is pretty much done. I will fit the content into that, but are you saying this is wrong?

May 12, 05h

Coming from a creative background I work in a really close relationship with someone who is supremely technical in their approach for designing for the web, and during the design process we’ll both be actively considering how one element of a design should fit with other elements of functionality.

I think the interesting arguement here is when do you put form before function and vice versa, in an ideal world (creatively speaking) we would all live in the gloriously forgiving visual world where you can get away with all of the usual things that designers anywhere other than the internet usually take for granted, but we don’t live in that world so we have to actively push the barriers of the constraints that are laid out by the medium.

Obviously these goalposts have changed through the years with the emergance of visually capable browsers and ever evolving technologies that enable the designer/artist to have liberties that previously they may not have had. However while we have been evolving there have been other “evolutions” that have constrained the designer and made everyone (creative and technical alike) sit down and reconsider their view point… I am of course talking of accessibility: Depending on who you ask it’s either an exciting buzz word that’s enabling content architects to deliver new content in clever new ways, or it’s an unregulated behemoth that threatens the very creativity of the web itself.

I would put myself somewhere in between, but I think that this has made me a better designer, before I may have just brain-dumped my creativity onto the page with little thought for function, whereas now I’m forced to think about the ramifications of what I do. Of course there are times when I grumble, WAI could of course update their specs sometimes, it would make life easier, but we don’t live in the perfect world.

Coming full circle (as I’m rambling!) I beleive that you simply can’t seperate function from form, and I’m glad that the advances in the way content is delivered online have made designers and programmers alike sit down and plan the way they work so that form and function have symbiosis where as previously they simply seemed to repel each other.