How to nice corporate background webpage


Ever wonder how some websites get that nice, subtle background going? I did. Turns out it’s really easy.

Just make an image (say 4 pixels high with a single dark pixel at top and three light ones below)

And repeat it as a background image over your page.


body {
    background-image: url(../images/background.gif);


    <title>Repeated background</title>
    <link href="css/repeatedBackground.css" media="screen" rel="stylesheet" type="text/css" />


And voila.

It’s subtle, but nice for corporate style look and feel work or in any enterprise as a background to a table or TPS report.

Another approach is to apply the same idea with a gradient. Take a longer gradient image (say 1×500 pixels) and repeat it along the x-axis with a darker background color for where the gradient runs out :


body {
    background-color: #091A3A;
    background-image: url("../images/background-darkblue-1x500.gif");
    background-repeat: repeat-x;

and you get something like this:

Cool eh? These are just a web design tips I am picking up no my current project. Thanks to Jonas Claesson for point these out.


CSS Hack for making your own drop shadows


Jonas Claesson showed me this cool hack for simulating a drop shadow effect on a document in css.

Basically it takes drop shadow images, and repeats them around the border of your display image by placing in in north, south, east, west corners of your image.
You then plop them in using css ids and background images.

The result looks something like this:

And the code looks something like this:


<!DOCTYPE html> 
  <link href="css/classBackgroundImg.css" media="screen" rel="stylesheet" type="text/css" />

The following is an example of how you can use classes to place background images.

<table cellspacing="0" cellpadding="0" id="previewTable">
    <td id="nw"></td>
    <td id="n"></td>
    <td id="ne"></td>
    <td id="w"></td>
    <td id="previewContent">

    <div id="previewForm">

        <table style="margin-top:15px">
            <tr >
                <td><span class="headerBold">Summary:</span></td>
                <td><div  class="header">Do your stuff here</div></td>


    <td id="e"></td>
    <td id="sw"></td>
    <td id="s"></td>
    <td id="se"></td>



    margin: 20px auto;
    width: 900px

#previewForm *
    font-family: verdana, serif

/* This is for the drop-shadow effect around the document*/
#nw, #ne, #sw, #se
    height: 15px;
    width: 15px;

#nw {background-image: url('../images/nw.png');}

#n {background-image: url('../images/n.png');}

#ne {background-image: url('../images/ne.png');}

#w {background-image: url('../images/left.png');}

#e {background-image: url('../images/right.png');}

#sw {background: url('../images/sw.png') repeat-x;}

#s {background: url('../images/s.png') repeat-x;}

#se {background: url('../images/se.png') repeat-x;}

You can download the code and check it out here:

How to design stuff that matters fast – Eewei Chen


Great session this afternoon with Eewei Chen as he walked us through some great rapid prototyping techniques for ideation.

Step 1: Create an empathy map / persona

Fill in the various sections creating a persona for the person you are building the app for.

The categories are:
– Behavior
– See (motivations)
– Do (features)
– Say
– Feel

Step 2: Map features – what do I want to do?

Take the features you mapped from step 1, and start flushing them out down here.

Step 3: Can I use it?

Now walk the use through using your app made up of your highest priority most valuable features.

Step 4: Elevator pitch

Step 5: Pitch it!

Special thanks to Eewei Chen for hosting such a great session. Eewei was prepared, he had the materials, all the personas were nicely laid our around the room, and you even pre-filled in our elevator pitch butcher paper.

Great session.

Thanks to Ariadna Font and Adrian Smith for being awesome partners.

I am already thinking about how we are going to spend our millions once we build it 🙂

Sharpen your saw with newsgroups


Today, in the agile community, there are dozens of newsgroups spanning many topics. Here are a few interesting ones I regularly track and follow:

Extreme Programming:

Domain Driven Design

Lean agile

Lean development

Agile testing

Agile usability

Do a favorite newsgroup? Do share.

Create great looking mock-ups with Balsamiq

1 Comment

Several people have asked me what tool I used to create the screen shots used in the YAGNI vs Usability post.

The tool is called Balsamiq. And if you are looking for a simple, quick, easy way to create great looking screen mockups, it is a tool I highly recommend.

Dead easy to use

One of the things I like most about the tool is how easy it is to use.

With its easy drag-and-drop interface, designers could learn a lot from just studying how Balsamiq was built and designed.


Good plugin community

And because Balsamiq is so open and configurable, there is a decent plugin community for Outlook, Facebook, and iPhone apps.


Making mock-ups is just fun

For no other reason, I like this tool because it’s funky, fun, and actually makes the creation of paper based looking mock-ups really cool and fun.

So if you are in the market for a tool like this, check out Balsamiq. It is well work the low price of $79.

YAGNI vs Usability

Leave a comment

YAGNI (You Aint Gonna Need It) is a reminder to all who write software not to over engineer your designs, keep things simple, and add complexity only when necessary.

Usability, on the other hand, is about improving the users’ experience with the software—additional architectural complexity be damned!

YAGNI vs. usability are two forces that sometimes bump on agile projects.

This post looks at a simple example of how these forces can conflict, and how teams can help find the right balance for their project.

Keeping it simple

My last project was a web based application that showed users at a construction site which roads were closed on any given day.

One of the stories was called display road closures and the first version of the story looked something like this.


With a simple date based search at the top of the screen, the user simply enters the day they are interested in seeing road closures. They hit the search button, and the map refreshes showing which roads are closed, along with the search results at the bottom.

Delighting your customer

During development, my partner came up with a better way to visualize which roads were associated with which permits. Instead of simply displaying road closures in red, why not give each road closure a different color. And while we are at it, why not make the search results selectable—so that when the user clicks on a road closure at the bottom of the page, the associated road on the map becomes more bold and visible to the user?


I thought his idea was great. It required a fair bit of custom JavaScript, which would add some complexity to the UI. When asked how long he thought it would take, he said about an hour. Thirty minutes later it was done and integrated into the code base much to the delight of our customer.

Playing the YAGNI card

Deciding whether or not to implement this feature was a no-brainer. My partner had the necessary JavaScript chops, the cost was minimal, and our customers loved it.

But what if the trade-off wasn’t quite so black and white?

What if we didn’t know JavaScript?
What if the improvement, compelling as it was, was expensive to implement?
What if making the necessary change did require some heavy architectural lifting?

How should teams balance the desire of keeping things architecturally simple, with a desire to delight their customers?

See how you are tracking

Before getting all hot and bothered about whether to invest in an enhancement, or add a new feature, check and see how your project is tracking.


If your team is struggling to deliver stripped down, spartan versions of your customer stories as is, spending additional time on UI improvements is a luxury your project can’t afford.

On the other hand, if the team is on track, and the customer is happy with what they are getting, there may be a little wiggle room to make a few usability enhancements here or there.

And if your team is delivering ahead of schedule, all options are open. Go ahead and try the 13 shades of blue.

Know your project context


Every project is different. And not all have the same requirements around things like usability.

For some projects, a few fields and a submit button are more than enough. For others, nothing less than an aspirational experience will do.

Knowing ahead of time what your project requires, and how your customers feel about stories being ‘good enough’ will tell you whether you need to spend more or less on usability and the experience of the user. Putting working software into your customers’ hands sooner rather than later will serve you well.

Don’t be dogmatic

While YAGNI is certainly a sound architectural principle, like any sound principle it can be taken too far. When YAGNI is repeatedly used as a trump card to prevent improvements to user experience, it can upset team members, and cost the team an opportunity to better serve their customers. Not all usability enhancements need to be expensive, and sometimes the smallest of changes can make the biggest of impacts.

Like most things in life, it comes down to striking the right balance. The only way you’ll find out is if you build something, show your customers, and get some good solid feedback along the way.

Until then, you’re just guessing.

%d bloggers like this: