Last week, I bought myself a new laptop. Or notebook. Or whatever you want to call these things nowadays. I went for the Asus N51 because it was compliant with the specs I had in mind and because laptopshop.be had a bit of a special deal (it came with a mouse and a carrying case).

The notebook had Windows Vista Home Premium pre—installed. My previous laptop has Linux installed. Kubuntu to be more precise.

I originally installed Ubuntu on my old laptop (an Acer Aspire 1561WLMi) because Windows XP was, in the end, slow and unstable and was generally getting on my nerves. Vista was readily available but off course too heavy for my system. So I felt adventurous and formatted the disk and went ahead and installed Ubuntu. Radical move! Windows was gone! What a relief!

And although I felt “liberated”, using Ubuntu was plain difficult at times. How do you fix this or that problem, how do you install this or that driver, etc… Most of the times, the answer was (and is): open a shell and bash this or sudo that — not easy for Windows folk. But I got used to it and stopped wondering where certain files were located on the file system (really, most of the time, you don’t need to know). So, finally, using Ubuntu wasn’t that bad after all. And in january this year I did the thing all over again and installed Kubuntu — I like that interface better.

But doing all of that on a brand new laptop or notebook ? I’m hesitant — a pre-installed notebook usually integrates well with the OS (Vista in my case). And I’m not sure how well Kubuntu will handle my machine and it’s components (sound, webcam, special functions, etc…).

What would you do ?

Webdesign Issues ? CSS Frameworks to the Rescue ?

Building websites has to do with a lot of things:

• building HTML pages
• styling your pages with CSS
• dealing with layout and browser issues
• choosing the right fonts and colours
• content, off course!
• dynamic aspects (client or server—side code)

I’m not a designer, I’ve been a software developer. Designing for me has a lot to do with making choices concerning layout, typography, colours and backgrounds. I usually stick to HTML and CSS but, in the near future, I will probably pick up some scriptaculous or mootools or jQuery along the way to make things more functional, appealing and more lively.

You probably know that a lot can be done with CSS when it comes to styling and positioning of elements on you website, and certainly when you look at the possibilities CSS2 and CSS3 (grid positioning ?) give us.

But one thing that keeps bugging most of us is the bunch of issues regarding correctly positioning elements and correctly rendering stuff in the browser(s). In the past year or so, I’ve seen designers/builders take more of a “DTP” approach to layout and positioning. I mean, website bakers have started using grid—systems to layout websites and fixed width is no longer frowned upon. Using grids in DTP has proven more than useful and applying it to web design isn’t all that far fetched. Nettuts has a good introductory article on grids.

Things we hear out there:

Using grids/frameworks is a good thing because:

• it’s easy to use (requires you to link in some style sheets and that’s it)
• it allows you to quickly and easily position some elements by placing them on a grid
• you can start from scratch, with a blank (reset) canvas — no quirks!

Using grids/frameworks is a bad thing because:

• it’s “un—semantic”, it doesn’t mark up with meaning. The markup used conveys position and layout, and that’s a bad thing.
• semantics change for each and every project, so there cannot be “a framework”
• you should use CSS and style for a particular, semantic, reason and not because you just need to position something
• frameworks are bloated and you won’t need most of the styles in those sheets

Good thing — bad thing: that’s not the point of this post, really. CSS frameworks give you some stylesheets. Mostly they’ll be based on some good practices (like resetting stuff and some basic typography). Most frameworks will also include a stylesheet that will make IE behave. You’ll have to see for yourself if you like these frameworks or not.

There are a couple of those out there: Blueprint, Tripoli, YAML, YUI, etc.

I decided to use Blueprint because I too believe that having some basics is a good idea and that a CSS framework shouldn’t become too bloated. And Blueprint gives me reset and grid (and some other stuff that I won’t use and don’t have to use because it’s in a separate stylesheet — I can choose not to include it). Not sure about the grid though. Isn’t that like using tables? And yes, it mixes layout with semantics, so, that’s a bad thing, right ? Well, I wanted to give it a try anyway to see if there are any advantages of using such a grid. I also want to see if I will be overriding a lot of styles or not.

Real World Example: Two Trees

About a year ago, my girlfriend needed a presence on the web… fast. She quickly sketched out a simple design which I implemented in straightforward HTML+CSS. And so her company, Two Trees bvba, was indeed present but it mostly showed pictures of previous projects.

The site itself had a peculiar layout. It didn’t sport the typical masthead on top and menu to the left (or below the masthead) but had the main menu at the bottom and had the secondary navigation (thumbnail photo’s) placed vertically almost in the middle. The major piece of content was the larger photo in front. There’s also some comment per photo to the right of the thumbnail.

This is what it looked like:

Current twotrees.be layout

The HTML that makes up this page is rather straightforward and looks something like this:

<div id="container">
  <div id="innercontainer">
    <div id="bigimage">
      <img id="big" name="big" src="img/twotreesbig.jpg" />
    </div>
    <div id="verticalbar">
      <!-- thumbnails can go in here -->
    </div>
    <div id="textblock">
      <!-- additional text or comments or announcements go here -->
    </div>
    <div style="clear: both">
      <!-- stop the floating already -->
    </div>
    <div id="horizontalbar">
      <div id="menu">
        <!-- menu anchors/items go here -->
      </div>
    </div>
    <div id="logo"><img src="img/twotrees.jpg"/></div>
    <div id="horizontalbartail"><!-- empty --></div>
    <div style="clear: both"></div>
    <div id="bottomspacer"><!-- empty space --></div>
    <div id="contact">
      <!-- contact info goes here -->
    </div>
  </div>
</div>

Simple enough and, I think, readable enough. And no, it’s not liquid, not really.

Here’s some of the CSS-styling that goes with it:

#container {text-align: center;
   }

#innercontainer {text-align: left;
   width: 900px;
   margin-left: auto;
   margin-right: auto;
   }

#bigimage {float: left;
   width: 580px;
   }

#verticalbar {float: left;
   width: 111px;
   text-align: center;
   border-left: 2px solid rgb(221, 221, 222);
   border-right: 2px solid rgb(221, 221, 222);
   }

#textblock{float: left;
   }  

#horizontalbar {float: left;
   background: rgb(221, 221, 222);
   min-height: 115px;
   height: 115px;
   width: 1082px;
   margin-left: -500px;
   }

#logo {float: left;
   }

#horizontalbartail {float: left;
   background: rgb(221, 221, 222);
   min-height: 115px;
   height: 115px;
   width: 500px;
   margin-right: -500px;
   }

#bottomspacer {float: left;
   }

#contact {float: left;
   text-align: center;
   border-left: 2px solid rgb(221, 221, 222);
   border-right: 2px solid rgb(221, 221, 222);
   background-color: transparent;
   width: 111px;
   min-height: 50px
   }

As you can see, the layout is achieved by floating most of the stuff left and stopping the float with a div that clears floating on both sides.

However, some oddities might occur now and then (with badly sized photo’s or to large a text on the right side) and those occurrences might be related to differences between browsers. And I really hate  catering for different browsers.

So, I thought I’d use a grid and see if this would make my life easier.

Using any grid layout (and in our case: Blueprint), I propose the following layout be put on top of that grid:

We’ll use:

• at least three columns — the left one being the widest, the one in the middle (the “vertical bar”) might be fixed width
• three “rows” — the middle one being grey and holding the menu and logo
• the vertical bar will probably determine the size of a column
• the biggest photo will span more than one column (because all columns in a grid system have to have equal widths)
• the horizontal bar with the menu will conveniently span all of the columns

Note that “row height” as such doesn’t exist in this grid system — height will be determined by the tallest block (div) in the row.

Using the default stylesheets provided by Blueprint, it was pretty easy making a layout that closely resembles the original layout of the website. And using Blueprint, you have the option of showing the grid by adding the class "showgrid" to your container block as follows:

<div style="container showgrid">
  <!-- content goes here -->
</div>

That container block is a required block if you’re going to use Blueprint – it contains all your content.

The result, using the default grid and using the class "showgrid", can be seen in the image below:

twotrees.be layed out on top of grid

The default Blueprint grid provides 24 columns. Each column spans 30 pixels and there’s a gap of 10 pixels between columns. The total width of your page will thus be 950 pixels. That’s fixed width off course.

How did I get there ? Well, first I included the necessary stylesheets (I opted to use reset.css and grid.css) like so:

<link rel="stylesheet" href="css/blueprint/screen.css"
  type="text/css" media="screen, projection">
<link rel="stylesheet" href="css/blueprint/print.css"
  type="text/css" media="print">
<link rel="stylesheet" href="css/standard.css"
  type="text/css" media="screen, projection">

The content of reset.css and grid.css are made available by using screen.css. I had to make some adjustments in my original stylesheet (standard.css, which I am still using), because of the reset properties.

I figured I’d keep the default 24 columns, provided by Blueprint, and started mapping my layout on top of the grid. Remember, you can use a different number of columns for your grid if you want to, but then you’ll have to re—create the grid.css file by using a tool that does just that. Note: more resources are available on Blueprint’s website.

Mapping went as follows:

• Most of the big photo’s are fixed at 400 pixels in height. Using an aspect ratio of about 4:3, the maximum width of the photo’s will be fixed at 600 pixels. This means I’ll need about 15 columns for displaying the photo (15 x 40 = 600).
• The vertical bar in the middle will contain some kind of widget or thumbnail in the middle, so I’ll use one column for that and provide a leading and trailing column to give me some extra space to the left and to the right. So that makes three columns for this bit.
• The remainder of the columns will be used by the right-hand-side part of the layout.
• As for the rows: as mentioned earlier, there is no notion of “rows” – so we don’t have to deal with that.

So, finally, our page looks something like this:

<html>
  <head>
    ...
    <link rel="stylesheet" href="css/blueprint/screen.css"
      type="text/css" media="screen, projection">
    <link rel="stylesheet" href="css/blueprint/print.css"
      type="text/css" media="print">
    <link rel="stylesheet" href="css/standard.css"
      type="text/css" media="screen, projection">
    <!--[if IE]>
    <link rel="stylesheet" href="css/blueprint/ie.css"
      type="text/css" media="screen, projection">
    <![endif]-->
  </head>
  <body>
    <div class="container showgrid">
      <div id="content">
        <div class="span-15 border" style="min-height: 400px">
          <div id="bigimage">
            ...
          </div>
        </div>
        <div class="span-3 border" style="min-height: 400px;">
          <div class="verticalbar" style="min-height: 400px;"></div>
        </div>
        <div class="span-6 last">
            ...
        </div>

        <br class="clear">

        <div id="horizontalbar" class="span-24">
            <div id="menu" class="span-15">
              ...
            </div><!-- end menu -->
            <div id="logo" class="span-3 last">...</div>
          </div><!-- end horizontal bar -->

        <br class="clear">

        <div class="span-15 border" style="min-height: 50px">&nbsp;</div>
        <div class="span-3 border last">
            ...
        </div>

        <br class="clear">

      </div><!-- end content -->
      <div id="footer" class="span-24">
        ...
      </div>
    </div><!-- end container -->
  </body>
</html>

Note the following classes:

• border: will draw a 1 pixel wide border on the right—hand side of the block, right in the middle of the gap between two columns
• last: will tell the grid that it is the last element in a row — this means that the gap on it’s right won’t be necessary (so there will be no 10 pixel right margin)

And here’s a piece of advice: use your blocks, marked up with "span-xx" (xx being the number of columns), only for layout and don’t combine a "span-xx" class with another class (e.g. "span-xx contactinfo"). This will ensure that all div ‘s in the same “row” have the same “height”. I had this problem when I first constructed the vertical bar: it wasn’t tall enough (as I could see by looking at the length of it’s left and right border). I used "span-3 verticalbar" as the class. Better do this:

 <div class="span-3">
  <div class="verticalbar">
    ...
  </div>
</div>

Conclusion

As you can see, it wasn’t all that difficult to change the original layout into a grid—based layout using Blueprint. But I wonder: was it, in this case, necessary ? Well, the answer is: no. Not in this case. But it’s an easy way of positioning elements on a “page”. And it’s also easier for my girlfriend to add pieces of content (she can use a printed version of the page with the grid in the background).
If you read the older version and compare that to the gridded version, you’ll notice that the HTML of the older version is more readable. But I don’t think I’ve really lost a lot of the semantics in the new version. The information is still there – it’s just been encapsulated in blocks that span a number of columns.

Were there any advantages in using Blueprint on this case ? Nope, not really. And did I have to override a lot of style ? Some, yes, because I chose to use the reset.css stylesheet – and that means you have to override, or at least, add, some style if you don’t want to run with the bare basics.

The whole debate about whether or not using these CSS frameworks is a good thing, is not one I wish to have here. I wanted to convert twotrees.be to a grid and I found this an easy task using Blueprint.

You could argue, though, that this case is too simple to really find out how easy these grid systems are. And you’re right. Grids are probably better suited for really complex layouts (think print magazine needs publishing on the web) but even then, anything is possible with CSS and without grids (just read some of Eric Meyers’ work and you’ll get the idea).

So, has this been easy, migrating the old Two Trees site to a layou using Blueprint ? Yes. Was it really necessary ? No. It might save most of us a heck of a lot of time on those more complex designs though.

If you ever have a complex layout problem, and it seems no one out there can help you, maybe you can use one of the CSS/grid frameworks out there. Good luck!

We all know about good design, don’t we ?

January 2009, a new year, and a typical time of year to publish lists of all kinds. I recently came across a list about webdesign trends and I sighed. I don’t think most sites even went with whatever has been proposed as a trend for 2008. Here’s another good article — but does it really hold up for the majority of the sites out there ?

Really, even today some articles talk about age old soars that webdesigners have to deal with. Don’t use tables for layout, lay out the front-end using CSS, don’t mix formatting with content, … etc. It’s all “old news”. Isn’t it ?

On the other hand, if you look at most of the sites you’re visiting today, you’ll probably notice that those sites really don’t follow those predictions or trends or guidelines. And what’s more: a lot of sites don’t even follow basic guidelines (but then again, what are the basic guidelines anyway ?).

Yes, but still… in practise ?

So, whatever good webdesign is or should be (in theory), I think that actual websites (the practice of it all) lag behind… a lot. What we’re still seeing today is:

• cluttered top menu’s or multiple mastheads
• too much animation (apart from flash ads)
• lots of 3–column layouts about — this is supposedly changing. Still, I think more and more people will be using widescreen monitors, so there will be enough room for 3 columns…
• really small fontsizes
• layout problems when using your browser’s built-in features to make fontsizes larger (e.g. Ctrl+’+’ on Firefox)
• not enough whitespace
• bad colour schemes (although this is rather personal, I think)
• and, on a side note, lack of style sheet for printing

Just go and take a look at the site of you local/national newspaper or network, the sites you visit daily or the site you use for you research. Or even sites of famous brands or big companies.

Those of us who are interested in webdesign and frequently read about it know about the current “best practices”. However, in practice, you won’t see enough applied knowledge.

And that even goes for the way this blog looks – I really should move to my own hosted solution and get another template. And maybe templates are in part to blame for the fact that real sites are lagging behind when it comes to good design.

If templates and template—makers don’t respect good design guidelines, then a lot of sites will keep on looking and feeling the way they do.

Beauty on the internet

I think I’m going to respond to bad–looking small–font over–crowded websites by contacting them and asking them to re—think the way their site looks and feels. Let’s make the internet a more beautiful place!

Hello World! Here I am.

I’ve been on the internet for a long time now, just like many other people out there. And I’ve built small websites, static and dynamic, and even crafted a simple web application or two. But it isn’t until recently that I really started using some of those must—have online tools or services like Facebook or Ning, Backpack or Vitalist. And I love them all.

But using those tools to write down some of my ideas or griefs or excitement just didn’t work out. I fumbled with Joomla! in the past (still have that site on software development and stuff, although it’s obsolete) and have a really really old blog with Blogger, but that didn’t work out well either.

So I decided to go for a tool that is better suited for jotting down short messages or articles – and here we are.

Why WordPress ?  Don’t know really, I haven’t thoroughly researched this, I’ve seen a couple of blogs out there, and WordPress looks right for me.

And that’s that.