Drakenhart Studios

Welcome to Themes

Themes, also known among some as “skins”, consists of the html, css, and images that make a site look the way it does. Those UI (User Interface) designers who do not do a lot of back-end coding can, feasibly, work up a Theme. One doesn’t need a lot of design skill, not with all the tutorials and help sites out there today. But taking that Theme from Image Mock-up to final product requires a little bit more effort.

What it requires is the ability to understand a given CMS (Content Managemnt System) and how it outputs the data it manages. The level of difficulty in doing this depends entirely on what you are trying to accomplish.

Levels of Complexity and Difficulty

Making a skin using the defaults that come with a CMS is the easiet way of handling this. Because so many designers want something unique, the defaults are rarely seen as much as one might come to believe. But this doesn’t make the site look or feel unique even if the defaults aren’t used as much. It still seems like a re-colored clone.

The next level consists of designing an entire site the way you want it to look, while taking into consideration the “parts” that the CMS Outputs. For instance WordPress outputs a header, footer, content area, and sidebars (if they are enabled). Since this is automatic to any given CMS, you need to design with these sections in mind and determine what goes where as you work.

The next level consists of tweaking the existing code either by applying small hacks or re-arranging how things show up on a given page. You may wish to change the front page into a semi-static landing page with RSS feeds that show up in the sidebar, for example. This requires an understanding of how the CMS’s system handles such extras, if it does at all, and how outside code might effect the final output. Any good designer knows well that a small bit of stray code can cause havoc in how a site looks when it is viewed!

Beyond this is the Intermediate to Advanced coding techniques that can transform how a given CMS outputs entirely. This often requires an innate understanding of how the system handles data, and may well require a non-coding designer to learn more then their fair share of coding. The options here for most UI designers are to either learn how to code in depth, learn the basics and stay away from the more advanced coding tricks, or hire someone else to do it for you! What a designer chooses is entirely up to them and there is no “wrong way” of doing it, as long as the site looks good and does what you want it to do!

Wire Frame FIRST!

Even before the Mockup comes the Wire Frame. What this looks like is entirely up to the one doing the design. Personally I work out a flow chart first, and as I work on this I doodle ideas into the corner of my notes. From this flow chart and doodles I make a rough wireframe that gives me an idea of the general layout and feel of the site.

Wire frames helps you to see the flow of the site, and to get an idea of what you are going to need in what areas. It is essential for the final mockup in the same way an outline is essential for a good research paper!

Once you have your wireframe (and notes!) then you can get to working on the mock up itself!

Mockups

A mockup is a graphic representation of what you want to site to look like. This includes the base body design (the elements that won’t change), the look of the individual pages and their content (Lores Ipsum fills in text nicely in case you aren’t sure of what to write), and what images are being used for each! Each individual page should have a mock up. Layer them all properly and name them (if the graphics program you have allows you to name your layers). This will reduce the wasted time from searching for a particular element later.

Mock ups should be of the final size, and take into consideration the different browser sizes. Yes there are some people who still use older monitors whose max resolution for websites are 600×800. Thankfully they are in the minority now, but you need to keep in mind that they do exist and keep the important information in the center. Anything non-essential to your site (advertisements, links outside of the site, etc) can be on the “wings”, but the main product and content needs to be easily accessible.

Make the Mock Up into Code

So now that you’ve decided on what to do, and how far into the code you are going to go, what’s next? Take the mock-up and write the base markup and CSS. I cannot stress enough how important this step is for keeping organized and focused on the final goal! Do all of your mark up first, make sure it works, try to break it to find out what happens, test the css in different browsers, get friends to test it in other browsers, do what ever you need to make sure the design code itself is functional.

Why? When something goes wrong later you can be certain, at least, that it’s not something in the design code that is malfunctioning! Also, this framework gives you the foundation you need for making Themes look good. This is what the site is suposed to look like after all, right?

After this, then you can get into the nitty gritty of dividing up the sections of a site into the parts needed as per how the CMS handles outputting. This part can be a little bit tricky depending on what your overall scheme for a site is and how you are going to handle it. Generally many sites rely on PHP in order to output. Understanding how PHP works will be a great help to any designer who finds themselves working with it.

W3Cschools section on PHP is a great place to start! There is also PHP.net which is more of a walk-through tand explains a lot more in plain language (until you get into the more technical stuff). Tizag has a lot of beginner tutorials and explanations. I found them to be slow, mostly because I was too excited to start with the basics. But I have to enforce, baby steps, learn the basics first. When you are looking at the CMS output code you’ll at least be able to read it! That is the first key to successfully tweaking the PHP output code!

Once you get the repeating sections done (header, footer, and sometimes but not always the sidebar(s)) you can work on how the content in the main content section will output. This can change from page to page. So keep in mind what your intents for each page are, and always refer back to your wireframes and mockups! I relate this habit to checking my algerbra notes during a test! By checking your mockups and wireframes you keep focused on the end result rather then get lost in the code.

By the time you get all the sections coded, it’s time to test it. (If you have a Windows Vista Machine I highly suggest you DO NOT try to install a virtual server unless you KNOW exactly what you are doing!) Best way to do this live is to have a mock-site set up, with a live database, et al. This way you can test it in a live environment.

It is highly suggested that one does NOT just upload the site to it’s final home for testing. This can cause problems on a number of levels! It can interfere with user experience, as well as cause problems with the site’s database in case something in the code is messed up. The Search engine spiders and bots could crawl your site and come up with poor reactions, and you wouldn’t even know it until later when you check your statistics! You could even drive traffic away from your site as well.

It’s a messy process. Find a place or way to test it before setting the site live.

Generally most computer OS (Operating Systems) can’t or won’t parse PHP. Windows NT was the server version of Windows and will display PHP. There are virtual servers you can set up and configure on your machine, but in such cases you should always back up the computer you will be using to do this in case something bad happens.

Once things are tested and working, it’s go-time. You should have a functional site that looks good and works!

More in this Series:
(tba as posted)