Cykod Web Development and Consulting Blog

I am not a designer now I will never be a designer. I don't have the talent or the patience for it. Unfortunately my very close proximity to a designer for the past 10+ years has led me to tend to place a higher value on how things look than I did previously (or would probably prefer).

This becomes an issue early in the development process when a web project is in it's beginning stage and tends to look like the illegitimate offspring of some jurassic-era reptiles. Sometimes we'll work from some nicely designed mockups, but for larger development projects, designing screens first and functionality later ends up being too constraining for the inevitable iterative spec changes that come down the line (see: Specs: The Consultant's MacGuffin ).

I would rather have some flexibility in developing the specific interface elements rather than be limited to an initial design mockup. Likewise, designers usually prefer or should prefer to have a good  idea of all the elements that will needed to be in a site before really spending the time to generate a find-tuned design, so developing first and (graphically) designing later is a win-win.

... spending 8 hours a day working with something that looks like absolute garbage is incredibly demotivating.

Except that spending 8 hours a day working with something that looks like absolute garbage is incredibly demotivating. The default styles of most web browsers make simple markup look terrible. The good news is that the amount of effort it takes to make a HTML web application look half-way decent is pretty easy, more or less transferable from project to project, and doesn't add complexity that you'll regret later.

Simply applying a simple header and footer along with a couple of class names to your elements along with a basic CSS file will go a long way towards making your application output prettier and easier on the eyes. I'm going to take three examples of non-styled output and go through a couple of easy steps to make them look a lot nicer: a piece of content, a form and a table. If you're already pretty comfortable with CSS there's not a lot new here, other than the idea of getting some styles in earlier in the process than might be usual (click each image for the html version)

We're going for 4 basic rules to do this:

1. No defaults - just like most people still surf with IE because it's pre-installed there's a lot of websites that don't override the default styles. These are usually the websites that look like a 4-year-old's refrigerator drawing so when I see nothing but Times New Roman it looks like they didn't even try - unless they are doing it on purpose.

2. Differentiation - different elements should look different, so give elements like table cells one look and table headers a very different look - don't just make it bold or one point bigger - give it a background and make it way bigger. When two elements look too similar it ends up looking like either a mistake or just bad design.

3. Grouping - related elements should be grouped together as it makes it easier to tell what's connected on a page. That means adding extra padding between your paragraphs and columns. Pull up a well designed site in your browser and notice how easy it is for your eyes to scan around the different components of the page. Now look at your page - same thing?

4. Whitespace - in general the more the better. Properly spacing elements is the easiest way to improve the look of a site and make it look more professional - remember - when in doubt, pad it out. This is very connected to grouping but worth mentioning separately. White space invites the eye into to read the content.

We're also going to apply 1 meta rule to consider the entire time: apply the rules above but stay consistent throughout the whole site - nothing looks worse than a mishmash of 60 different colors, fonts, sizes and spacing. So - apply the rules above, but do it in a consistent way - using just a couple different fonts, font sizes, colors, and background colors will make everything a lot easier on the eyes.

My designer gives me 1 baseline guideline: pick two fonts and three sizes and unless you know what you're doing stick to that or the site may start to look messy.

Getting a blank slate

First things first - give yourself a decent doctype to make sure you are turning on "strict" mode so that you have some sort consistency across browsers:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Next pull in some sane defaults into your CSS file:

/* Reset all white-space to 0 for consistency across browsers */
* { margin:0px; padding:0px; }

/* Default to some sans-serif font at a specific size */
body { font-family: Verdana, Arial, sans-serif; font-size:12px;  }

/* Get some padding between paragraphs and some line spacing */
p { padding-bottom:5px; line-height:1.4em; }

/* Put some padding back onto our list elements */
ul, ol { margin-left: 10px; }
li  { margin-left:10px; padding-left:10px; }

/* Bye bye ugly blue border */
a img { border:0px; }

/* No dots around clicked links */
a, a:active { outline: none; } 

/* Class to any floated elements */
.clear { clear:both; }

Now you can do some more involved resets, but I've found these 8 lines of CSS are a good start.

Giving the page some structure

Next lets wrap the each of our pages in some sort of template - unstick stuff from the top left of your browser. If you have an idea what target width your website is going to be (many websites these days are fixed width as it's easier to control how stuff looks, but there are plenty of exceptions) you might as well put something in there so that you can get an idea of how much content will fit on the screen at once pretty early in the process. If you are going to have a sidebar (or think you might) put one is as well so that you're working with a realistic sized canvas for your dynamic data. Some sort of dummy navigation that you can swap out as new things are added in will help as well. Depending on how you're developing you might have a layout template or a separate header and footer templates:

<div id='container'>
<div id='header'>
  <div id='logo'><a href='/'><img src='images/logo.png'/></a></div>
  <div id='tagline'>Lorem Ipsum, dolor sic Amet!</div>
</div> <!-- end #header -->
<div id='main_menu'>
 <ul class=menu'>
  <li><a href='#'>Item 1</a></li>
  <li><a href='#'>Item 2</a></li>
  <li><a href='#'>Item 3</a></li>
  <li><a href='#'>Item 4</a></li>
 </ul>
</div> <!-- end #main_menu -->
<div id='content_container'>
  <div id='sidebar'>
     <div class='sidebar_heading'>Some Heading!</div>
     <div class='sidebar_body'>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>

     <div class='sidebar_heading'>Second Heading!</div>
     <div class='sidebar_body'>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
  </div> <!-- end #sidebar -->
  <div id='content'>
     <!-- Content Goes Here! -->
  </div>        
  <div class='clear'></div>
</div> <!-- end #content_container -->
<div id='footer'>
 <div id='copyright'>&copy; 2009 Acme Co</div>
</div> <!-- end#footer -->
</div> <!--end #container -->

Now lets drop in a few lines of CSS to center and pad our page out and give it a little structure:

/* Set the width to 900 pixels, centered on the page with a little padding on top */
#container { width:900px; margin:0 auto; padding-top:10px; }

/* 90 pixels to work with at the top - positioned relative so that we can absolutely position our header elements easily */
#header { height:60px; position:relative; }
  #logo { position:absolute; left:0px; top:0px; }
  #tagline { position:absolute; right:0px; top:5px; color:#666666; font-size:14px; font-weight:bold; }

/* Quick right-aligned tab-looking text menu */
/* Make sure to be explicit with the padding and margin on our ul and li elements so we can change the defaults later on as necessary */
#main_menu { height:26px; border-bottom:3px solid #000000; margin-bottom:30px; }
  #main_menu ul { display:block; float:right; list-style-type:none; padding:0px; margin:0px;  }
  #main_menu li { display:block; float:left; margin:0 5px; padding:0px;  }
  #main_menu a {
    display:block;
    float:left; /* Needed for IE */
    padding:5px 20px;
    color:white;
    background-color: #000000;
    text-decoration:none;
  }
  #main_menu a:hover { color: #000000; background-color:#666666; }


#content_container {
   padding:10px 0px;
   border-bottom: 1px solid #CCCCCC;
   /* Do the IE hack to get a minimum content container height */
   height:auto !important;
   height:500px;
   min-height:500px;
}

  /* Floating left and then right means that we can play with the widths of the sidebar and content separately and not worry about explicitly setting the space between */
    #sidebar { float:left; width:200px; }
      .sidebar_heading { font-weight:bold; padding-bottom:2px; border-bottom:1px solid #CCCCCC; margin-bottom: 5px;}
      .sidebar_content { padding-bottom:10px; }
    #content { float:right; width:650px; }

#footer { height:20px; position:relative; }
  #copyright { position:absolute; top:5px; right:0px; font-size:10px; color:#999999; }

Here's our three pages with the defaults CSS file and a little bit of structure added to them - already slightly better - they are starting to feel like a website and not something months away from being usable (click to go to the actual html files)

Ok, now let's go through each page one at a time and try to make them look a little nicer, starting with the piece of content.

Reworking content page

Let's attack the CSS for the content:
First, make the header stand out with a color,  some padding and a larger size.
Second, fix the information line closer to the header, make it smaller and lighten it up a little.
Third give our image some padding so the content isn't stuck to it.

/* Content Styles */

h1 { color: #333333; padding-bottom:15px; font-size:26px; }
.content .info { position:relative; top:-17px; font-size:11px; color:#999999; font-style:italic; }
.content img { float:left; padding:0px 14px 10px 0px; }
p { color:#444444; }

That was easy, no? Content already looks significantly better and will be nicer to work with as it continues to get developed:

Reworking the form

Next onto our form. With forms, grouping is the most important rule to follow, so that's it easy to tell what's related to what. Now there are different styles of markup your can use to create your forms - for simplicity's sake lets assume you're using a div's and not a table, but either way works. You might have a form markup that looks something like:

<form action='...' method='post'>
<div class='horizontal_form'>
  <div class='header'>Basic Information</div>
  <div class='item'>
   <div class='label'><label for='first_name'>First Name:</label></div>
   <div class='data'>   
    <input name='frm[first_name]' type='text' id='first_name' class='text_field' size='30/>
   </div>
   <div class='description'>Enter your first name</div>
  </div>
  ...More Items and headers...
</div>
</form>

Note - Some people have taken some serious issues with the use of divs, especially in the form elements (I even have a disease), so take a look at Prettier Accessible Forms for an alternative. I'm not a huge fan of that layout style, and I generally avoid fieldsets and legends like the plague because of the difficulty in styling them. I don't mind some extra divs around as it makes flexibly modifying forms via css simpler and cleaner and is easier to generate via code (I come from a cms background where we don't know what content is going where so a bunch of carefully crafted "#footer p img { position:absolute .. }" styles are worthless to me), but take a look the A List Apart post as a start and find what works for your project.

If you're targeting ie6 you'll need to add that extra classname to your input elements somewhere to tell you what input type your dealing with, otherwise you can use input[type=text]

Let's take quick stab at some css for a horiztontal (labels next to elements) form. Here's what we're going to do:

1. right align the labels and  put the description stuck below the field (grouping)
2. padding out the elements a little (whitespace)
3. separate out the headers (differentiation, grouping and whitespace)
4. give the whole form some padding all around (whitespace)
5. get rid of the default border and add in a psudeo-class when the field is focused. (no defaults)
6. Align and  Pad out the button a little bit - make it easier to click and a little less default-looking.

a few lines of CSS should do the trick:

 /* Form Styles */
.horizontal_form .item { margin:10px 4px; }
.horizontal_form .item .label {
   width:150px;
   text-align:right;
   float:left;
   padding-right:10px;
   vertical-align:baseline;
   padding-top:3px;
   color:#666666;
 }
.horizontal_form .item .description {
   clear:both;
   padding-left: 160px;
   font-size:11px;
   color:#aaaaaa;
   font-style:italic;
}
.horizontal_form .item .text_field {
  border:1px solid #999999;
  padding:2px 2px;
  color:#666666;
}
.horizontal_form .item .text_field:focus {
  background-color:#eeeeee;
}
.horizontal_form .header {
  margin:15px 0px 10px 0px;
  padding-left:0px;
  font-size:16px;
  border-bottom:1px solid #CCCCCC;
  font-weight:bold;
  color: #666666;
}
.horizontal_form .button { margin-left:200px; padding-top:10px; }
.horizontal_form .button input { padding:4px 10px; }

And we're done:

 

Already much better, and what's nice is because this was all done with CSS a couple of rule changes and the form can look completely different.

Reworking the table

Finally let's take care of the table, here's what we're going to do:

1. Get rid of cellspacing and cellpadding
2. Highlight the headers and pad them out a little bit
3. Give the table cells a consistent padding on the left and right as well as top and bottom.
4. Add in some sort of separation - either a thin border between rows or a striping effect (or both) looks nice.

 /* Table Styles */

table.account_table {   border-collapse: collapse; }
table.account_table th {
  padding: 10px 10px;
  color:white;
  font-size:14px;
  background-color: #7caaff;
  font-weight:bold;
}
table.account_table td {
  padding: 6px 10px;  
  border-bottom:1px solid #999999;
}
table.account_table tr.odd td {
 background-color:#eeeeee;
}
table.account_table td.currency { text-align:right; }

And we're done:

Now, you're not going to replace your designer in your organization (nor should you want to, programmers are much better paid) - but at least your work-in-progress will look a lot nicer. The point of this tutorial, and of creating a very basic, black and white site was to show you how little design knowledge and creativity is necessary to make something look halfway decent. Your not going to win any awards, but I bet you get a better reaction from the client with a couple minutes of simple CSS styling than you do from the entire week you spent getting getting that complex javascript validation to work correctly.

There's one thing that you need to be careful about making things look too finished too early - your client was often assume that the better something looks the closer it is to being done. So, for parts of the project that aren't anywhere near being done, make sure there is a stark contrast with the parts that are approaching completion - put a big X through them or give them a grayed out background. (See: Joel on Software's post  The Iceberg Secret which talks the issues with having something look "done" when it's not).

Side note: Some people have mentioned the use of CSS frameworks, such as 960 Grid System. I'm don't like those from a developer's perspective as they leak a lot of information about your layout and design into the HTML of your site, where I don't think it belongs (this is especially true if a designer is going to come in and rework the design: you don't want to rewrite all your HTML to support a new design). They are also "heavy" in that you need a lot of css to set up the grid and what you can change by only modifying the CSS is more limited.  I like the css Zen Garden philosophy a lot better - separate your content as completely as possible from the design and layout - but to each his own (aka "Flame On!")

The pieces are already here - Projected keyboard , Mini-projector , Voice Commands , Body Recognition - someone just needs to miniturize and stitch it all together. (Click for full size)

 

So let's say you want to join all the cool kids and use gemcutter but you're Debian Lenny and it's still got a 1.3.4 version of rubygems (gemcutter apparently needs 1.3.5)? Well you could go install a local copy and screw up your dependencies, or you could just pull the version out of debian unstable as it doesn't seem to mess up anything else:

First, make sure you have the stable repopsitory pinned and create or edit:

/etc/apt/preferences

Package: *
Pin: release a=stable
Pin-Priority: 700

Then to add the unstable repository to your sources edit:

/etc/apt/sources.list

 deb http://http.us.debian.org/debian/ unstable main contrib non-free

Finall update your packages and install the new version of ruby gems:

$ sudo apt-get update
$ sudo apt-get -t unstable install rubygems

And you should be good to go (we had to get starling installed on a production server and it requires gemcutter, so that's to motiviation)

If you want to be safe - I would recommend opening up your sources.list and remove unstable.

 

 

 

Roll-your-own or Not-built-here syndrome is a mentality that rightly takes a fair amount of abuse. After all, with more than half a century of software development under our belt as a species do we really need yet another XYZ? Chances are it's been built before, and with a little bit of research you could find an existing workable alternative.

For a now-fairly-large ecosystem like Ruby/Rails, there's generally a plugin or a gem that gets close to what you need it to do, and with ruby's infinite flexbility, it's easy to make a couple of modifications and get what you need. Contrast `gem install XYZ` and `ri XYZ` with taking the time to really learn the problem domain of what your trying to solve, come up with a workable architecture and interface and implement.So we roll-our-own, throwing together some half-assed implementation that'll get the job done but will probably end being more trouble than it's worth.

It should be a no brainer - but often we take the latter path because we fear what we don't understand, and integrating a whole bunch of code, the pedigree of which isn't known is an understandly scary task. So we roll-our-own, throwing together some half-assed implementation that'll get the job done but will probably end being more trouble than it's worth.

That's not the time to RYO. If there's an available library that looks like it does the job, your time would be much better spent going through the code, online docs, tutorials and blog posts about it then jumping the gun and trying to write your own. However, don't necessarily just will-nilly throw the library into your project without giving it a solid once over, both at the API and at the code level.

We spend hours and hours coding, but when's the last time you took a couple of hours to read through the actual code of an auxiliary library that will perform an important function in your app? I'm getting better, but oftentimes the first time I look at the code is when something doesn't work right. It think that's a problem that should be fixed.

So, let's say you've looked at the library and it looks like a winner that's going to meet most of your needs. There's still now one more question that you need to ask yourself:

"Am I completely, overly and 100% happy with the interface that this library provides?"

You might be, but there are a number of example of circumstance where you could have a reason for not being completely thrilled. If the library provides more features than you need, you might not want your code to have to worry about overly complicated method calls. If the library provides too few features, and you need to call some other library's methods to get the output you need, you also have a reason for trepidation. Even something as basic as an unhappyness with the naming convention could cause some doubt - take fpdf for example - a 100% Ruby port of PHP's FPDF that keeps the same not-ruby-friendly name convention and a php method style.

Whatever it is, if you're not 100% happy with the interface or have some doubts about the library itself (is it being maintained, is it well written?), it's a great time to layer something between your code and the library. Technically it's called the Adapter pattern, but putting a layer of interfacing code is something that developers write all the time so you don't have feel like a pattern-snob.

Doing so actually a great way to figure out exactly what parts of the XYZ library you actually need and now much effort it is to make them work. If you're unit testing, you could even stub out calls to the adapter for the time being to make sure the interface you think you want to use makes sense.

(Brief interlude: I know what your thinking - "Who the $#@%@ is this guy, he titles his blog post 'When it's ok to RYO' and now is talking about the complete opposite - integrating libraries and the adapter pattern. What a jerk." That's ok, I've been called worse)

Just bear with me for one more second. Let's say you've got the XYZ library integrated behind a nice clean interface and your project is chugging along for a couple months. As we all know, change happens. Invariably something will pop up that make the XYZ library less of a perfect match than it used to be. Maybe the project is getting more advanced and you need to do more than the library was intended for. Maybe your realize that you don't need full XYZ support, just X+Z and the library is bloating your codebase for no reason.

Whatever the reason. Now's the time to RYO.

What's changed from way back when you originally need the functionality implemented in the XZY library? Well, three things:

1. You know more about the XYZ problem domain - being forced to examine different options and actually integrate the library forced you to learn about it.
2. You know a lot more about your application's needs for XYZ's functionality, not just from the requirements but from actual use.
3. You having a working implementation of XYZ and have an idea of what they've done right and what they haven't. You are effectively building the second version of something without have had to build the first one.

For me, all three of these are big wins. We've now done this a number of times inside of Webiva. The rails file_column plugin is a great example - it was easy to get installed and working, but a couple of years down the road we need both less and more functionality and it wasn't being maintained. Luckily, since the Webiva codebase didn't have file_column's everywhere but instead had abstracted them in the DomainFile class - changing out that plugin for some custom code ended up not being too big of a deal. Authorization is another example - we used a great authorization plugin that we determined did a lot more than we needed, and a couple years down the line were able to easily extract the core functions we needed and roll-our-own very simply with a nice clean syntax (the main class SiteAuthorizationEngine clocks in under 200 loc)

Now sometimes the right library just isn't out there and you don't have a choice, but for the other 95% of the time, it's worth taking a look at the library that fulfills 96% of your requirements and writing the other 4% than the other way around. After all, you can always come back and write those 96% later on and you'll have whole lot of a better idea of what you're doing.