Planning

The first thing I do is think of the purpose of the piece. All art has a purpose (even if the purpose is solely to be aesthetic), and commercial illustration usually has quite specific purposes in what they need to communicate. In this case I’d like to do a character illustration celebrating Christmas to post on my blog and send to people as Christmas cards. The purpose is to wish people happy holidays as well as indirectly promoting my skills as an illustrator.

Next I think about constraints. In this case I don’t have a huge amount of time to spend on this picture, so it will have to be something simple and quick to draw rather than a complex and involved painting.

With all these things in mind I decided to draw a simple vector illustration of an abominable snowman. With a candy cane.

Sketching

Even though I’m planning to create this picture in a vector program on the computer, I like to start out with pencil and paper. Generally I find it much easier to quickly sketch out ideas on paper as I tend to not get as caught up in details as I would on the computer. First thing to do are some thumbnail sketches.

Thumbnail sketches are small, fast, loose sketches to figure out where you want to go with the final product. The idea is to experiment and get all your ideas onto paper as quickly as possible, without bothering about details, rather than jumping right into it and realising at the end that your composition doesn’t work. I apply the same concept to logos, website designs and even crafts, and have found that I always get a better result with proper planning and sketching.

Here’s what I came up with:

Some people like to do heaps of sketches, but since this is quite a simple idea I just did the four on the left. I had a vague idea of how the snowman would look, but felt that even in sketch form it wasn’t really working (again, this is why sketches are important!). The fifth sketch you can see there is a further stylised look, which I decided I was more happy with. For the actual pose I decided to go with the first one, which is nice and dynamic.

With a pose and style in mind, I did a fairly clean and larger sketch to work with, and messed around with it until I was happy. It doesn’t have to be perfect at this stage, just clear enough so that you can recreate the shapes on the computer.

Vectoring

Armed with a relatively clean sketch, I then scanned it in and brought it into Adobe Illustrator. I usually start by bringing down the transparency of the sketch so it’s visible but not so distracting, then lock that layer so it doesn’t get in the way.

I don’t want to go into the vectoring process too much as I’m still learning the best way to do things myself, but I basically create the basic shapes using the pen tool, add colour and then add shadows and details.

Small details like shadows and speculars on the eyes can really bring a character to life, even with a character as simple as this one.

Finished!

Here he is, all ready to go!

HTML (and its cousins/siblings/bastard children such as XHTML) is a markup language that is interpreted by the web browser to render a web page. A large amount of the actual code in HTML is taken up with closing off tags and general housekeeping. Having to repeatedly type “</p> and </div>” gets to be annoying. And large amounts of grief can be caused, particularly when you’re trying to debug an error in your code because the page isn’t working as intended.

RubyOnRails and Templating Languages

RubyOnRails is based on the MVC programming pattern. Basically this means that the various functional parts of the website are contained within designated parts (Model = Business logic, View = Presentation of data, Controller = Making it all work together). RubyOnRails has a templating language, ERb, which is used to embed programmatic functionality within an HTML template. Basically this means that you can include Rails code in a familiar environment, and have Rails generate your HTML for you.

Here’s an example.

  
  <div id="user_list">
    <ul>

      <% @users.each do |user|%>
        <li><%= user.name %></li>
      <%end %>
    </ul>

  </div>
  

OK, that’s a pretty basic example, but effectively what’s happening is that the Rails engine loops over a collection of users, and generates the HTML code to display a list of users. Doesn’t look too bad, but when you start getting a complicated page, it can start getting really difficult to work out what’s going on where.

Surely we could do better? (AKA why do I have to type so much crap?)

Thankfully, there’s a better way. Hampton Caitlin is a developer who also got annoyed at having to write necessary, but pointless code all the time. He felt that it could be done much better by a computer. So, he created Haml.

Haml allows you to write legible, even beautiful, templates for your websites, and takes care of most of the heavy lifting for you.

Crash Course in Haml

The easiest way to explain Haml is to use an example. Here’s the code from above, rewritten in HAML

  
  #user_list
    %ul
      -@users.each do |user|
        %li= user.name
  

Not too bad. 5 lines to replace 7. And not an angle bracket to be seen! Of course, it’s a pretty simplistic example, but should give you an idea of what can be achieved.

So, how does it work? Haml makes great use of whitespace, and tabs. The indenting in your template code is used to determine the hierarchy of your code. For example:

  
  #container
    %h1 Inside the container
    #box
      %h3 Inside the box
  

will generate

  
  <div id="container">
    <h1>Inside the container</h1>

    <div id="box">
      <h3>Inside the box</h3>
    </div>
  </div>
  

If you change the indenting like so

  
  #container
    %h1 Inside the container
  #box
    %h3 Inside the box
  

you get

  
  <div id="container">
    <h1>Inside the container</h1>
  </div>

  <div id="box">
    <h3>Inside the box</h3>
  </div>
  

This illustrates the power of Haml (and a potential source of bugs!). With the change of nothing more than an indent, it’s possible to greatly influence the generated code. The use of indenting also makes for legible, and beautiful code.

Haml Shortcuts

Haml also has some wonderful timesaving shortcuts that means you don’t need to sweat the details as much.

  
  !!! XML
  !!!
  %html{html_attrs}
  

will generate

  
  <?xml version='1.0' encoding='utf-8' ?>

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html lang='en-US' xml:lang='en-US' xmlns='http://www.w3.org/1999/xhtml'>

  

Nice.

Crash Course in Sass

Not long after the initial versions of Haml were released, it became obvious that CSS needed some Haml-ification. Sass to the rescue.

Sass takes the approach of Haml, and applies it to the world of CSS selectors and attributes. It makes the creation of large stylesheets, with complex parent/child relationships, and makes it a simple thing.

Nothing like an example. To create the following:

  

    #container{
      width : 100px;
      margin : 10px 2px 5px 0px;
      border : 1px solid #fff;
    }
    #container p{
      font-family : Helvetica, Arial, sans-serif;
      font-size : 1em;
      color : #000;
    }
  

you would write

  
    #container
      :width 100px
      :margin 10px 2px 5px 0px
      :border 1px solid #fff
      p
        :font-family Helvetica, Arial sans-serif
        :font-size 1em
        :color #000
  

Once again, you can see the power of indenting being used to create parent/children relationships. And the Sass example is eminently more “readable”, which helps with debugging and maintenance of code.

So, it’s only a Rails thing right?

Well, sort of. It’s really a Ruby thing, as Haml has been included, or been made to work with, Merb and Sinatra, two other web development frameworks based on Ruby. I’m not aware of any attempts to get it working with other languages.

But all is not lost! Hampton has got a Haml Lab up and running, so you can test it all out, and see how much time it could save you.

In Conclusion

Go Team “Haml and Sass”!

1. Write for your audience

When writing web content the most important thing to know is who your audience is. Spend some time researching who they are, what they like and dislike and what they’re looking for - you can then tailor your content to suit. Read what your visitors read - i.e. trade related publications and websites. Look at competitor’s sites to see what they do (or don’t do) well. Familiarise yourself with industry specific terminology to help with your credibility. Constantly revisit who it is you’re writing for to get the tone and style right.

2. Have a purpose

Not only is good web writing concise and to the point but it also gives clear direction as to what a visitor should do next. If a website is sales oriented, the copy should aim to bring visitors further along the sales cycle. If it’s marketing based it needs to provide relevant answers to questions visitors may have. The minute your copy starts to lack clarity and direction your visitors will go elsewhere. Good web copy always keeps the needs of visitors in mind.

3. Don’t be wordy

Web content needs to be brief and punchy - it also needs to be at least 50% shorter than print. Shorten sentences to 20 words or less and get rid of unnecessary words. Wordiness puts visitors off so say what you need to say quickly.

4. Write scannable text

79% of visitors only quickly scan content which means unless they find what they’re after quickly, they’re gone. Organise content into chunks, separating each with sub-headings or using lists helps to make content more scannable. Front-loading - where important or goal oriented info is placed at the beginning of a sentence - is another useful tool for helping people find what they need quickly.

5. Watch your language

Neutral language has no place on the web. The only way to quickly attract and hold the user’s attention is through active language. For example the following passive sentence, Daily updates can be found on the news page has less impact than the active, Find daily updates on the news page. Active language is generally shorter and takes less thought to process which is what you need to aim for.

6. Always proofread

Don’t ever let any content onto the web before it’s been proofread. There’s no excuse for typos, grammatical errors or general sloppiness. Any mistakes will damage your credibility so be vigilant.

7. Team up with a designer

The design of a site, and the content that appears on it, rely on each other to convey messages to visitors. Neither can exist or thrive without the other so it’s handy to sit down with a designer and plan out how things should flow. A designer might suggest that some text would be better represented as an image or a downloadable document, while you might have some ideas on pull quote placement and formatting. Working with a designer will invariably help the end product so be open to the experience.

Krissy Bradfield (the brains behind wordish.com) is a freelance writer focusing on productivity issues, psychology and corporate communications.

Bad wireframing on websites can resemble these 80’s string atrocities. Points placed all over the website in no order create an absolute chaos of pathways to follow. Pathways going everywhere can leave a user thinking “Of course the first place I would check on a website for repairs is to go into accessories. Probably just as logical as finding the contact page as a tiny link under products.” On a number of occassions I used to want to rip down those gastly string arts because they made my brain hurt. Imagine how a user feels upon entering a website with the same schematics.

def: Website wireframes are a visual guide to suggest the layout of elements in the website interface.

So once we have chaos, how do we create order from it. Wireframing from concept is a lot easier than being given a board of nails and a kalaidescope of string going nowhere. Or is it?

The Horror Website

We have been given the epitomy of all nightmares website. Navigating around it makes you cringe. We think they are missing many parts of a formal website structure, only to find them in the bowels of some obscure category. So what do we do? We strip the aesthetics and get the website down to raw html with no formatting, flash or javascript. Have it set up live, but obviously not the existing website (not if you want to retian your client anyway!).

We need to know what they “do” have, not what they “think” they have. I have seen websites totally consisting of images, and the clients swore black and blue that they had lots of text to copy and paste into the new website. The majority of clients don’t know what their website consists of. The last thing we want to do is to include a whole section in the wireframe of what the client wants off the existing website, only to find out that we can’t access it, and that it’s going to add considerable charges to their website. Clients can quickly blow out budgets by presuming they have more than what they have.

Starting Afresh

We now have a better idea of what we are working with. Now to extract the required elements from the old rotting corpse. Sometimes even on the most abominable website we can still tear shreds from it. Don’t just throw them all in one folder to rummage through later. Bring your planning into your folder system. Thoughts of how it might be set up in its new live environment, should be adopted on testservers so crucial items aren’t ommitted. Don’t be confined by attrified sectioning on the old website. In each folder we decide on what photo or images we will be using again, and keep a spare folder for discarded items. Planning how we dismantle is equally as important as it is to plan our construction.

Creating the New Wire Frame

Usabilty

One of the advantages of reconstructing an existing website, is that we come to the party already aware of how various sections have performed until now. We have an idea of how many people hit the front page and run away at lightening speeds. We are in a position to ask for error logs so we are aware of what parts of the website aren’t working to specs.

Optimisation

Where budgets permit, it is a good idea to consult a SEM (search engine marketer) to retain any PR or organic ranking that pages may have amassed. Because we are recycling content, we have to be careful not to kill pre-existing layouts that worked. Even the worst website can have pages that just simply worked. They may have age factor, or just happen to hit on that x-factor. So it’s important to recognize and accomodate these successes and check the ego at the door.

From forum software, allowing you to constantly argue about the latest episode of “Heroes”, to blog software where you bag out the declining writing of “Heroes” and even content management systems, allowing you to build a whole site about how much you hate “Heroes”, you are not limited in your choices of software.

But it is important to ask yourself the following questions when looking at any freely available open-source web software before downloading it and using it for your own projects, and doing so may save you a lot of stress and frustration.

Does it do what I need it to do?

All too often, people will download a piece of open-source software that comes highly recommended by peers or experts, and will spend large amounts of time trying to get the software to do what they needed it to do, and usually fail in doing so.

When on the hunt for software, grab a piece of paper (or open up a Notepad document if you don’t believe in writing) and just jot down the major pieces of functionality that you require. Then shop around Google, read review sites and compare software to each other to find the best software which covers all of the functionality that you require and nothing more.

It is always best to go for the software that does everything that you require ‘out-of-the-box’, instead of the software that does half of what you want and then requires add-ons or modules to do the rest. That way, you can be sure that the functionality you require is constantly supported by patches and updates.

Is it well-supported?

Support for open-source software usually comes in the form of a community. A core group of developers will create the software, then release it to the community to test for bugs and security errors.

In most cases, the software with large communities of developers and testers will mature quickly, bugs are squashed quicker and more people are on hand to help out with any issues you have, whereas a smaller community may mean bugs and issues are left undiscovered or un-patched for longer and questions you have may remain un-answered for longer.

Is it safe to use?

One of the disadvantages of open-source software is that because it is freely available to everyone, there will be those out there that would read each line of code thoroughly for vulnerabilities.

Before using any open-source software, it is always recommended to make sure you are using the latest version and check that there are no reported security issues. Some developers tend to hide discovered security issues to prevent malicious users from exploiting the vulnerabilities, so it is also recommended to check out 3rd-party security advisories such as ]Secunia for any vulnerabilities which may not have yet been revealed.

Is it easily customisable?

Open-source software is great for branching out in to new areas, like adding a gallery to your blog or a music player (please, no auto-playing music!). Most open-source software is built for extendibility, provided in the form of ‘add-ons’ or ‘modules’ that you simply download, install and use immediately.

If you must create your own new functionality, it is always good to check if the software developer provides good documentation on the functionality. This can come in the form of well-written comments in the code, or a ‘developers area’ on the software developers website.

Conclusion

If you are very careful in selecting open-source software for use on your website, then you can set up a site fast and without hassle. There’s a lot of good and bad software out there, so always read up about the software and the community behind it and always test out the software before committing to it.

A few caveats first. This process only really works if you are not being hemmed in by a restrictive wireframe. Mind you it can also be used to create and document a formal wireframe. It’s also really only any good I have found when you are totally against the clock and have to find that design, like yesterday.

You know what is the hardest thing for me design wise; the blank canvas. I’m sure it just stares back at me mocking me. So how do I overcome this? Well I make a list.

Often I will have a design of the logo and the corporate colour palette for the site already. If you think about it you will also have the defined content areas, title types, number and types of menus you want to use, you will have got this from your client and user research. These all go on that list.

I’ll assume that you have the content or an idea of the content. If you don’t, really I think you should stop and go bake some fruit mince pies or something, as design without knowing the content is a very bad idea, trust me it will end in tears.

From a blank canvas we now have the logo, colours, content type areas, menus, titles, forms, buttons and the like. Now we are ready. I usually go grind a few beans (coffee that is), make a nice cuppa and sit down with a large sketchpad and pencils.

What NO computer! Yes that’s right, step away from the computer.

Okay now the blank canvas of the sketchpad is laughing at me.

But not for long, draw up a series of rectangles about the same ratio as a screen, say 9 to 15 a page. These are basic frames, thumbnails of a screen design. You can list the elements you need to put in design on the sketchpad page too if you wish, it does help you to remember them all.

Now you just drawn the basic outline of the content areas, menus , logos etc in the small frames. Nothing detailed, as seen in figure 1, keep it simple it’s like you are drawing thumbnails of quick wireframe. However remember you can use curves and shading.

Go on go crazy, break all those conventions, put stuff where you know its not allowed in the sensible design world. These thumbnails are your experimentation area. Nothing you do here is wrong. You can’t make a mistake. Even the things that are a little too wild may inspire that one killer design.

When I’m doing this I will often complete 20 to 30 of these thumbnails. I usually stop when I feel that I’m starting to repeat myself.

Allowing ourselves to step away from the computer to the old medium of paper for me is liberating and using a sketchpad is even more so, as it makes me want to experiment and just play around.

Now I find that the grey lines of the lead pencil are a little restrictive on the design choice so I will photocopy the sketches. Then I get out the coloured pencils and set to work colouring them in as close to the corporate colours as I can get (see figure 2).

The result is you can quickly see the major contrast and colour balance issues, and with your keen eye for design you can select a few of the choice thumbnails. From here I usually sketch up a few larger, half page to full page wireframes (figure 3), these are more detailed with an base grid pattern. If you like you can colour them in, as sometimes it helps. Just stick to rendering the colour in blocks, nothing to high-resolution, at this point.

Now with these few rough full sized wireframes we can now goto the client and let them select the main direction of the site design. Of course from here we have a little user testing and maybe some prototyping, before we slide into the high-resolution designs and the final product.

How are the mince pies coming by the way, nearly ready?

Opacity

• Supported by Firefox 2+, Safari 2+, Chrome, Opera 8+, IE8
• Hack for IE5.5, 6 & 7
• Inheritance (opacity is not inherited, but it effects all children of the element)
• If the property is not supported by the browser the opacity of the element is 100% (solid)

RGBA

• Supported by Firefox 3, Safari 3, Chrome
• Not inherited, no effects on child elements
• Can not be applied to images
• If RGBA is not supported by the browser, uses previous colour values or defaults

In detail

opacity: 0.5

Will make that element and all children of the element 50% opaque. To get the same results in IE:

filter:alpha(opacity=50);

This of course is not valid CSS, so use it and ignore the validator or hide it behind conditional comments (up to you, but you get the desired results). Also it looks like the element needs to HasLayout for the filter to work.

The biggest problem is that opacity is affects the display of all children of the element (except for IE). So you have to be very cautious with it’s use. For example, you wanted to have a white translucent box over the bottom of an image with some opaque text.

<div style="background-color: #fff; opacity: 0.30;"><p style="color: #000;"…

Will result in a white translucent background of 30%, and equally translucent black text. Trying to rest opacity has no effect, and trying to set the transparency of the child to 70%, makes it even more transparent (30% * 70% = 21%). So you need to take the child element out of the flow, by example using position: absolute.

If opacity property is not supported by the browser, it render the element with an opacity of 100%.

RGBA is far simpler to apply

<div style="background-color: rgba(255,255,255,0.3);">

Delivers a white background with a 30% opacity without having to worry about the effects on it’s children.

For browsers that don’t support RGBA.

<div style="background-color: #fff; background-color: rgba(255,255,255,0.3);">

Supplies an opaque background, if that is your preference. Or

<div style="background-color: transparent; background-color: rgba(255,255,255,0.3);">

A transparent background, as transparent is the default you can leave it out.

So which on to use?

Well it depends: on what browsers you want to target and what you want browsers which do not support which method you choose. Lets go back to the example of wanting to put a translucent white section at the bottom of a slide show, with opaque buttons and caption and you need to get it to work in IE6 & IE7.

Using opacity

The background element opacity is set to be translucent, the buttons and caption are taken out the flow by using position: absolute. Conditional comments feeds a stylesheet with filter:alpha(opacity=X) to IE7 and below.

Advantages

• Works in most common browsers

Disadvantages

• Painful to code and maintain

Using RGBA

The background element RGBA is set to be translucent, uses straight forward HTML. Conditional comments feeds a stylesheet to IE7 and below with filter:alpha(opacity=X) for the background element and to correct it’s children.

Advantages

• Easy to code and maintain
• Forward compability

Disadvantages

• Does not work in Opera, Firefox 2 or Safari

Using 24bit PNG as background image

A translucent 24bit PNG is used as an background image. 24 bit PNGs are not supported by IE 6, so you can use conditional comments to feed a stylesheet to IE6 and below, with a new background image and filter:alpha(opacity=X) to get the right level of transparency and correct it’s children opacity with filter:alpha(opacity=X).

Advantages

• Easy to code and maintain
• Works in most common browsers

Disadvantages

• Requires a background image
• IE6 support is painful

Conclusion

I have been using the 24bit PNG background image, method for a few years now, however, I would consider using the RGBA method now, with or without IE support depending on the task and whether it is a progressive enhancement or a required feature. The opacity property is just too difficult for complex project, but great for single element.

Web Analytics sadly plays a backseat role to flashy things like… well, Flash… and latest .NET platforms, and stylish and exotic designs and other wow-y items sure to help seal a sale, but wouldn’t you love to design and build a site, and then be able to tell that client that you kicked so much backside at it that you’re making them heaps of money?

Get some analytics tools.

If you’re small, start small. StatCounter is great for small. And it’s FREE. You slap it in your code and you can point to it and yell excitedly at your client, “SEE? That guy that came in on that search term went here and here and here and then filled out the contact form and became a client… Score.” Details on a per-visitor level can sometimes tell you more about the mindset of your users than all the buzzwords like “Conversion Rates” and “KPIs” ever could.

If you’re bigger, Google Analytics. Its great for bigger companies/sites but its great for small ones too and did I mention it’s FREE!. Slap it in your code, figure out what you think you want to know (and please “boofhead”, not just “hits”, there’s so much more to analytics and actually working out how your site is going than “hits”) - customise a report, get it sent to you daily and point to it and yell excitedly at your client, “SEE? All those people that came in from that one place went here and here and here and filled out the contact form and 87.3% of them became clients… Mad Score.” Reporting on what you actually want to know (“How many people clicked on that new button I insisted we make for the home page, and out of them, how many did magical and wondrous things on the website?”) can help determine your next steps in the website’s evolution.

If you’re Global Dominationally Huge, the Googs still does pretty good, but by that point you’ll spend so much time figuring it all out that you won’t be able to count all the money you’re making, so you’ll have to hire someone to explain how much your website rocks.

So go get some FREE analytics tools, there’s plenty out there, and learn how to use them, it’s not hard. Find out what you’re doing right, then go tell everybody how awesome you are. Don’t be afraid to learn a little at first and just go with that, we can’t all be experts, but there’s surely enough free information out there to make you sound a bit like one.