So far we’ve had:
- The Brewing Process: Part 1 – the early seeds of the design
- The Brewing Process: Part 2 – the movement and refinement stage
So if you’ve missed those, you might want to have a quick browse around to catch up a bit.
This time I’m going to be talking about the more practical parts of the design. Not particularly the nuts-and-bolts XHTML and CSS, but the more general areas and why I made certain design decisions.
The Old Fixed V Liquid Debate
You’ll have noticed this is a fixed design. Part of me is a bit disappointed with that, the other bit is quite happy.
It was never meant to be a fixed design. You can’t really tell from the screen shots, but all of the mockups – bar the very last one – were designed to be liquid.
It wasn’t until I started messing around with a grid that things really slotted into place and felt right. From that moment on, the ideas flowed a lot more freely.
I am fully committed to liquid designs, and all of their advantages, but I’m not a zealot about them. They have their place. Like for council websites. They are brilliant for presenting web based information in certain ways, and in certain situations.
One situation they aren’t so great in is when you’re trying to achieve a certain look using a lot of graphics and illustrations. I’m not saying you can’t make liquid sites look nice – but you do have to make sacrifices and plan very carefully for the compromise of graphical control and movement.
This is a blog aimed mostly at people like me. Web savvy types with big screens and the latest browsers. (And ideally with a Mac because it looks even nicer on a Mac.)
It is funny that I feel I almost have to apologise for a fairly simple design decision!
I have to say that I will miss the traffic that
CSS Liquid No Resolution brought, as it was one of the very few showcase style sites that ever gave me a steady stream of new visits. (Thank you Christian Montoya!).
Screen Res-ident Evil
I took the decision to fix the design at something approaching 1024 pixels – it’s actually a bit smaller – for the same sort of reasons.
Again I’m really aiming for the site to be visited by people with decent kit and screen resolutions of four figures. At less than 1000 pixels wide the design fits quite nicely in all but the smallest non-maxed windows. (An interesting point, however, is that the percentage of visitors with sub-1000 pixel widths to our main council site is at a surprisingly low level and is decreasing steadily and I take that as a fairly good representation of the general surfing public…)
Though it’s also a bit ironic that the very people the site is aimed at are also the people most likely to never see it because of their feed readers…
At the end of the day I wanted the control and space that the fixed 1000 pixel space gave me. I think it was the right choice.
I’m happy to say that WordPress is still powering the site along it’s merry way.
Every platform has their own champions and supporters. I can’t even begin to pretend have tried all of the different systems, but WordPress is the platform I have always felt most comfortable working with.
I have a degree in something called Applied Computer Technology. It was a bit of an odd course, and we were the student guinea pigs to take it’s course virginity. It had us take modules in everything from Engineering Maths (seriously, and I hadn’t even done A level…), to how to electronic circuit building. But also brief modules with programming languages like VB and C++.
What I’m trying to say is that I understand programming languages – I get the whole loop thing, arrays, and all that – but I’ve never become anything like fluent in any particular language.
However, it does mean I can generally hack my way around most languages once they’re already up and running, and from that point of view WordPress is perfect. It provides enough hooks and entry points to let someone like me concoct fixes for things, while it still hiding most of the important and scary stuff away.
I know it has it’s detractors, and that it can be a bit cludgy and bandwidth heavy, and that if Digg or whatever gets a sniff then it can be brought to it’s knees pretty sharpish… but it’s still the base for me.
I will have to try Expression Engine at some point though.
Another reason for favouring WordPress is the incredibly adaptable templating system. Officially these are called Themes, but I really see a theme as something you create for other people to use and change. I wouldn’t call what I do a Theme, it’s certainly just for me… no one else could find a use for this!
Once you’ve got the theory of the WordPress Loop sorted in your head it’s pretty straightforward to create the template.
I aim to one day try and write up a really good guide for putting together templates, but that’s certainly for another time. What I would say is:
- Start with your graphical mock ups
- Slice and dice your mock up into a fully functioning (but static) XHTML and CSS prototype
- Make a copy of the default theme folder, and give it a name
- The bulk of the code for your design will be going in header.php, index.php, sidebar.php, footer.php, plus a couple of others (for comments etc)
- Start with header.php and start fitting your code around the WordPress hooks, deleting the stock design code already there.
- As you get to the end of a pageyou will see the hook for the next template e.g. index.php… so move on to that.
- Keep going like that, filling in the gaps as you go along.
Plugins are another massive strength of WordPress. Generally, if you can think of something you want to change about (or integrate into) WordPress, someone else will have already done all the hard work for you.
Just head to the official source, or Goolge “*your problem/idea* wordpress plugin”, and you’ll find a handy little file to drop into your plugin folder. Even if it doesn’t do exactly what you want, you’ll probably be able to bend it to your will.
Plugins will be the subject of the next post, but here’s the props to the devs of the ones harmed in the making of this design…
- WP Audioscrobbler, by Marc Hodges (who has now washed his hands of it completely, which is a shame) for the ‘New on the Jukebox’ Last.FM widget
- Xbox 360 Gamercard by Oliver Baty for the ‘Trophy Fish’ in the footer
- Smart Archives by Justin Blanton for the… well… smart archives page!
- Exec-PHP by Sören Weber which allows Smart Archives to work by letting you paste PHP into a page
- SimplePie Plugin for WordPress by Ryan Parman and Geoffrey Sneddon which is the RSS parser thing that powers the Brain Tumblr Ale poster in the footer… which in turn grabs things from my Tumblr blogette
- FlickrRSS by Dave Kellam which powers my natty Fave Photo Frames in the footer.
That’s actually quite a few looking at it, many hearty thanks chaps!
Most of them needed some sort of adaptation… but that sounds like something to talk about in the next post!