Homepage Design MindJolt

Had a couple of revelations on web design today. Gotta love tangential learning (another argument for a well-designed hypertext document).

I was reading Margaret Baschelet’s “Learning to Love the Code: HTML as a Tool in the Writing Classroom” today. At the heart of her article is a discussion of why we should teach students HTML rather than just setting them down in front of a WYSIWYG authoring program like FrontPage. My own experience with web writing thus far offers the following answer: by learning the code, you learn how the web works, how display works, what “reading” means online and in browsers, and how to manage the “medium” or the interface of the browser window. Her article goes on to discuss the problems authoring programs offer due to their reliance on print metaphors and thinking processes, rather than offering an opportunity to understand the nature of the web and what it’s driven by (hint: code).

Anyway, when I got to her section on Structure and Presentation, I decided to link over to a piece by Owen Briggs: “Design Rant.” Enter mindjolt. On page four of his rant, Briggs writes:

So how to see your page? Look at the content. Before you decide you want “a three column layout”, ask your data what it says it is. What are the general groupings there?

On this page, I came out with four. There’s all this rant, so that would be Content. There would be navigation or at least supplemental explanation, so that’s Menu. I knew I’d want a fancy logo or some such across the top, so Head. And I wanted Lance Arthur’s brilliant WaSP banner ad somewhere. It didn’t really fit with the other groups, and it’s optional, so I made a Tail div. Almost by itself this formed into two columns, one wide, with top and bottom boxes. I could try other things, but this worked so I stopped there.

My point is I didn’t view this page as a layout first. I let the content inform the structure. I looked to the message to decide what the enhancement should be for visual layout. That’s the trick: let your message inform each enhancement. And as each enhancement relates back to the core it’s fairly easy to not lock out any browser type, because your message doesn’t end up in an enhancement layer — it stays in the core.

So, for example, you can have fun with javascript, without making the common mistake of requiring it for the navigation to work.

Hold it right there.

When designing my homepage, what did I think about first? Content or the “page”? Thinking about my design process, I completely understand why the print metaphor pages is problematic. My header would be an excellent example: I had been so stuck on the notion of having things “centered” on the page that i was allowing it to break I’m wanting to do with my CONTENT, and screwing up my main content column design. Basically, my paper-trained eyes saw “weird-looking” margins; this made me set up a minimum width for my center content. Could someone on an iPhone look at something like that? No idea, because I’ve never played with one, but I doubt it… Sure, I learned a LOT about CSS and HTML code from futzing around with that stupid header, but from Briggs’ point of view, it’s entirely possible that I’ve messed up the readability of my content by thinking of enhancement first. I’d been thinking about layout before content. Idiot. đŸ™‚

Here’s an interesting bit on this from part 3 of his rant:

Perhaps the main method people lay out their page is to see it as done and then try to build a structure to support this. That’s natural, since you see a lot of pages before you try to build one, and it’s reinforced by a brilliant and out of date hack that let us create an underlying layout table in any shape whatsoever.

But if you view a table-hack page in any browser other than what’s common to PC and Mac, you’ll find the content is scattered to the wind. Like I said, it’s a hack, and it’s out of date. The web isn’t just 15″ CRT monitors anymore, so no more table tricks.

However. If you visualize your ‘page’ as a page and start tossing CSS boxes around to make your site look like CNN, you’re in for a lot of angst, and that’s so 1990’s.

There’s reasons for this. Two of them. First being that CSS boxes do not react the same as rigid table cells. They’re much more complex because they do more. So you have to take some time to learn what the different box types do and when to use them.

I’d been swimming in angst over the design of my boxes and where I’d tossed them; yeah, I’d learned a lot about how CSS works, but now I needed to think about how it should be used. After reading his article, I tried to get out of the enhancement end of the pool and think in terms of content…. What do I need? I came up with the following list:

  • Main content columns for the stuff that people will read/watch/see (#centercontent in my css)
  • Navigation to get to different content (#leftmenu in my css, could be on the right, though)
  • Fancy thing to look at up top (#topmenu in my css)
  • That’s about it. At one point this week I’d considered adding a “contact me” footer, but decided not to. I’ll probably just have a link to the contact page at the bottom of the menu

This all comes back to Baschelet’s reasons for teaching HTML: the code was designed to be used as code, to “build outward” (as Briggs writes) so that any browser can access the content, can get the message while displaying the enhancements it can use.

It’s not just code, dammit. It’s also not just coming up with a layout to put “stuff” in. It’s a content-driven design language.

Now to go back and fix a few things. First up: decenter that header.

Advertisements

4 thoughts on “Homepage Design MindJolt

  1. Chris, This is so true that one should let the content drive the design, as opposed to trying to fit something awkwardly into a preformed hole. I think most great page designers at newspapers and magazines (maybe all of them) start with their dominant artwork and build their pages around the contours and colors and movement of the image. I don’t see why web designers would want to work any differently on a static page. On a page that artwork scrolls or changes frequently, I think this would be a problem. But maybe that could be part of the design process, too, or the dynamics of the page. For example, we might know we want to have four main entry points on this page, but the configuration of how people get through those points could change completely depending on what’s driving the look of the page. A new piece of dominant art should dictate a total redesign of the page, just like it would in print. Instead, what I see most often, is that a new piece of art gets put in place, and it’s so much easier to leave the page the way it is otherwise, it often remains unchanged. And then a new button is added here. And a new feature over there, and pretty soon the original design, which might have looked really good, suddenly is a cobbled together mess. As for the coding versus WYSIWYG issue, I wonder if it’s better to have a page that looks great on most machines, not all, or a page that looks the same on all machines but is clearly limited in design and beauty by the skills of the programmer.

  2. I guess that's where javascript and css come in, both of which allow for design to work on multiple platforms, even cutting out elements for specific platforms to retain usability. DrRice asked the other day how my splash page & design might look on an iPhone, and I'm wanting to find out, so I can see if I need to work in some alternate code for alternate browsing methods.Thanks for the comment, Brett. Good thoughts.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s