You will more than likely recognize this first site, kjvandfamily.com, as I used the same WordPress template, with a few minor modifications.

I really enjoyed creating the second site, villageofsecor.com, as it is entirely managed via WordPress. This is the first time I've used WordPress to manage an entire site. Doing it this way makes me want to make this site managed entirely in WordPress. But that will have to wait. As my free time is at a premium these days.

With this site, I had my client pick a template from WordPress.org. Once picked, I then modified it slightly to work better with the theme of the site.

Since I had the themes for both sites nearly built for me, I was able to develop them in a short period of time, and get them rolled out quickly. I must say, when looking at the time spent on each, I'm very happy with how they turned out.

At immediate glance, there doesn't seem to be too much wrong with this site.

What are your thoughts now?

Warning! You won't see this unless you scroll to the bottom.

If you are going to have a warning message that's this important, why are you putting it at the bottom of the page, after the fold (1024 x 768)?

Use Tables For Tables Only!
First things first, if your page is using tables for layout, then stop reading. This solution is for people who only use tables for their intended purpose. So, make sure you are using tables correctly before continuing on.

The Table Markup
The actual XHTML code for the tables themselves is extremely simple, and because of this is, it is nice and legible.

<table>
    <thead>
        <tr>
            <th>Column Head</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Column Value</td>
        </tr>
    </tbody>
</table>

Give It a Little Style
Now that you have the HTML down, it's time to give this table it's looks.

table {
    border-collapse: collapse; /* removes unwanted
cellspacing garbage */
    border-top: 1px solid #999;
    border-left: 1px solid #999;
    margin-bottom: 20px;
}

table thead {
    background: #ccc;
	text-transform: uppercase;
}

table thead th {
    border-bottom: 2px solid #333;
}

table thead th, table tbody td {
    padding: 5px 10px;
    border-right: 1px solid #999;
}

table tbody td {
    border-bottom: 1px solid #999;
}

Here's what you get:

Looks nice, eh? We're not done yet. Now we want to make each row alternate color and make each row change to a different color when you mouse over it. To do this, we need a little JavaScript.

function niceTables(evenclass,oddclass,hiliteclass) {
    if(document.getElementsByTagName('table')) {
		var tables =
document.getElementsByTagName('table');
		for (var nn = 0; nn < tables.length; nn++) {
		  var rows = tables[nn].tBodies[0].rows;
            for(var ii = 0; ii < rows.length; ii++) {
		    	var row = rows[ii];
		    	row.onmouseover = function () {
                        this.className=hiliteclass;
                    };
		    	if(ii % 2) {
		    		row.className = evenclass;
		    		row.onmouseout = function () {
		    		        this.className=evenclass;
		    		    };
		    	} else {
		    		row.className = oddclass;
		    		row.onmouseout = function () {
		    		        this.className=oddclass;
		    		    };
		    	}
		    }
		}
	}
}

This will set the class of all rows that are divisible by 2 to the variable evenclass and all other rows to the variable oddclass. It will also set a mouse over event on the row and when moused over change the class to the hiliteclass. So this is great and all, but how do I get this function to run? Simple... We're going to add an onload event to the window with javascript like this:

window.onload=function(){
    niceTables('light', 'dark',
'hilite');
}

So, if this javascript included in the head of all your html files, then every table that exists in the page will obtain this style when the page loads. Notice that calling this function set the evenclass to 'light', the oddclass to 'dark', and the hilite class to 'hilite'. What this means, is that we have to add these classes to our stylesheet:

.light {
    background: #fff;
}

.dark {
    background: #DFEEFF;
}

.hilite {
    background: #9FCDFF;
}

...and you end up with:

There you have it, nice, sleek looking tables with very little markup. See it in action.

Thanks to a great article by Paul Stamatiou, and some research I did on tons of other sites, I was able to find some really great applications. Here is a list of some of applications I've downloaded since last week:

• Adium A chat program that allows you to use your AIM, MSN IM, yahoo IM, Google IM and much more all in one slick application. It also comes with a cool little software package called "Growl", which is a notification system that can be used with many other software apps.
• Cyberduck A great FTP application that integrates nicely with many file editors, including TextWrangler.
• Quicksilver This application is SWEET. Talk about Getting Things Done. This application makes doing anything on your Mac a piece of cake. I can't do it justice, but a ton of other people have already tried, so I'll let you take t heir word for it.
• Twitteri fic Clever little app that lets you send twits, and receive the latest twits from all your friends.
• TextWrangler Relatively simple text editor that does just what I need it to do when I'm writing any PHP, xhtml, or CSS code.
• Firefox This should come as no surprise to anyone. Great browser.
• mySQL Although somewhat of a PITA to install and get working, this is a great free database software that allows me to create sample databases for all my projects.
• CocoaMySQL This is nice GUI front-end for mySQL. It allows you to connect to a database, and via a GUI, easily run queries and manipulate data however you see fit.

I've only had my Mac for about a week now, so I'm still getting accustomed to it. However, I am enjoying every minute of it, and can't wait to learn more! If you have any suggestions as to other applications I should be using, I'd love to hear from you.

Working with Matt was a pleasure. He was very receptive to my ideas from the very beginning. In our first meeting, he came prepared, and gave me all his thoughts and ideas of what the site should contain. Based on this information, and the fact that this was a site for an attorney, I wanted to convey a strong sense of professionalism, with a minimum amount of images, and a sizable amount of textual content. This was not at all a problem for Matt. He was able to come up with some excellent quality content that made it easy to incorporate into the final draft.

For this site, I used XHTML, CSS, Magpie RSS, sIFR (for all headers), and a minimal amount of JavaScript and PHP.

Have a Look: www.mattalbrechtlaw.co m

• How many days out of the 30 can be dedicated to design and usability testing?
• How can you possibly design a usable interface in such a short time frame?
• How can you execute usability tests in such a short time frame?
• How can you make modifications based on the UAT results in such a short time frame?

As you can see, a pattern was developing here: "How can (fill in the blank) be accomplished in such a short timeframe?" When I approached anyone with these questions, the responses were not good. The reason: usability design wasn't necessarily thought about when this methodology was created.

Agile’s iterative development cycle is one of the method’s strengths, but it also makes for some tight deadlines. As the now infamous interview between Alan Cooper and Kent Beck [2] shows, the timeline is perhaps the most controversial aspect of agile methods. In such a high-speed development cycle, do we have time to fully understand users’ needs? The short answer is no. The long answer: If we’re defining users’ needs during development—even in an agile development process—something has gone horribly wrong. -- Clash of the Titans: Agile and UCD

If at this moment, you are feeling a bit uncertain, never fear, if you look closely, you can see a shiny silver lining around this dark and dreary cloud. Never fear, there is a way to incorporate usability design (UX Design) into the agile development process. I'm pleased to report that we have been able to execute a very successful sprint cycle that involved iterative design processes and usability tests to create a well received deliverable.

Start Small

I cannot stress enough just how important starting small is. In our first attempt at a design based sprint, we failed. And we failed miserably. Why? The reason was because we tried to tackle a task that was way too big. Being the awesome designers that we knew we were, we decided to try and fix the system wide navigation. We knew there were some workflow issues, and we were going to fix them. Ummmm. BAD IDEA!. This task was way too large to try and take on in 30 days. Needless to say, the deliverable for that sprint was a rather useless Visio document showing everyone everything they already knew.

So, in the next sprint planning meeting, we realized that we had our priorities a bit out of whack. We decided to take a look at the product backlog a bit more closely, and found one task that was rather high up in priority on the list that jumped out at us: "Display more information on this page." So, we took a closer look at the page, and realized that the story itself "Display more information on this page", wasn't exactly a desirable solution. In actuality what was needed for this page, was a complete redesign. So instead of adding more results to this page, we decided to make this page much more user friendly.

The key here, is to try and understand the reasoning behind a requirement. Don't hesitate to challenge the original story/requirement. It often times helps to ask questions about each requirement, so that you end up getting the entire story. Once you have this, you can begin to understand what is truly desired, and you can begin adding tasks based on this information.

Stay A Sprint Ahead

In order to create a usable interface, you'll need at least 30 days. If you want to deliver a great product that will impress your users and upper management, you will need enough time to brainstorm, plan, design, and prototype. So, give yourself a 30 day head start. Then, when your 30 days are up, you can hand off your prototype to the engineers, who can in turn add the task of completing the code to roll out to production.

It's okay to be 2 or 3 sprints ahead, however, any longer, and your prototype sits on the shelf for too long, and by that point will more than likely be considered obsolete.

Get A Room

When you are ready to get started, I highly, highly recommend commandeering a room. In this room you will need:

• a whiteboard
• dry erase markers (not having these will render the whiteboard useless)
• post-it notes
• writing utensils

Brainstorm and Whiteboard

At this point, you should know the problems and issues that are the reason that have you pent up in this room. Take these problems, and flesh them out. Brainstorm on what can be done to alleviate these problems. Write your answers on the whiteboard or on post-its, and leave them there. When you are doing this, be bold, be creative. Pretend as though there are no limitations, and any idea you come up with can be accomplished. You can dismiss these at a later date. This is the time where there is no such thing as a bad idea.

Prototype. Test. Repeat.

Once you've got your ideas squared away, the next thing to do is begin prototyping. So, start on the whiteboard. Draw out in rudimentary fashion the design ideas you have for your page. Once you feel like you got the idea down, start putting it down in digital form. We used Photoshop, and created a pretty extensive design. Now, you may hear from others that you do not want to make your designs / mockups too detailed because the people you are showing them to will begin picking apart things that you really don't want them focusing on. Let me say that I have had plenty of experience with this, and I agree - to an extent. The problem, however, is that with SCRUM or any agile methodology, you don't have that kind of luxury. By day 30, you want to be able to deliver something to your engineers that they can begin developing (i.e. you need to be done). That being said, create your mockups, and try and get the major details ironed out. Once you feel satisfied with the design, begin creating the prototype you'll be using for testing.

For our prototypes, we used PHP with mySQL, and created a quick and dirty test database with one table and the necessary columns that we were able to import a small portion of data into. Then we began work on the XHTML, Javascript, and CSS work. Once the development of this was done, we incorporated the PHP code. At this point, we had a working prototype that we could begin testing with actual users. All in all, it took about a week to get to this point, and I must say, we loved what we had. It was eons better than the page that currently existed in the application. We were ready to roll it out at this point. We couldn't imagine how our users could see much wrong with this new design. and that, my friends, is why you need to test with users.

So, in order to keep a consistent testing environment, we created a set of real life scenarios that a user would run into when using this page of the application. Then we ran each user through these scenarios. In our first round, we put three users to the test. Overall, the new design was extremely well received, however, there were quite a few of the smaller things we missed, that without testing, we would have never realized. When all was said and done we tested with 12 users, and based on our findings, changed the prototype seven different times. Prototype. Test. Repeat.

Involve Your Supporting Cast

When you feel like you have your prototype to a point where the changes you'll be making are minimal, bring in the engineers, QA, and the tech writers. Keep them updated as to what is on the horizon. Make sure your engineers know what you're planning, and that what you are proposing is possible. If you can, give QA a copy of your prototype so that they can begin to write automated test scripts. And finally, involve your tech writers. Give them the ability to begin writing the documentation in the early stages. Let them know that it isn't complete, but the meat of the design won't change.

Show It Off

When you're done, show off what you've got. Make sure you get buy in from everyone in the company, not just the product manager, and not just the users of the application, but you also want the developers to be happy with what you've created. You want everyone to anticipate what is coming up. With this project, the most common question we received from everyone was: "When will this be available?" Not a bad question to be asked.

To sum it all up in a couple of bullet points, here are the things to remember:

• You only have short timeframe, so start small, and get stuff done
• Make sure you have a workspace that accommodates for group collaboration
• Brainstorm and ignore any constraints
• Design quick, create working prototypes
• Test, take notes, modify prototype, test new prototype, take more notes, modify new prototype, etc. etc. etc.
• Involve the people that will be working to get this new design into the production application
• Show off what you've got, and get buy in company-wide

Next, I plan on explaining just how to get buy in from upper management to allow for these usability sprints. I also plan on writing about what was involved in our user acceptance tests, from setup, to scenarios, to post testing documentation.

Let me first start by saying, that I in no way came up with the code necessary to do this. All the hard work was done by Mike Davidson of mikeindustries.com . Mr. Davidson actually took the time to figure out how to make the crappy back-end code of myspace work for you:

Several weeks ago, I finally signed up for an account, and within seconds I was instantly put-off by what had been created for me: a hastily-designed “profile page” with uninspired colors, misaligned tables, and a mish-mash of extraneous cruft and design elements which made this feel more like a halfway house than a “home”. Now, granted, I am a designer by trade so my tolerance for this stuff is orders of magnitude lower than most of the population, but clearly, this was not a place I even felt comfortable having my name on.

So with the default home page this underwhelming, what is a MySpacer to do? Customize, of course. One of MySpace’s greatest features is its ability to let you skin your own home page. Unfortunately, 99% of the customizations I’ve seen are chalkboard-screechingly awful, but what could a MySpace home page look like if some actual design thought went into it? That is the question I sought to answer. -- Mike Davidson

So, if you are looking for this code, here is a link to his awesome blog entry explaining all about it: "Hacking A More Tasteful MySpace.

So, armed with this code, I was able to create a few decent looking pages:

• My personal myspace page
  
• My wife's page
  
• my brother in-law's page
  
]]> http://www.patmullin.com/weblog/2007/04/17/myspace-can-look-decent/feed/ 2 http://www.patmullin.com/weblog/2007/04/02/web-design-and-web-building/ http://www.patmullin.com/weblog/2007/04/02/web-design-and-web-building/#comments Mon, 02 Apr 2007 18:09:49 +0000 Patrick http://www.patmullin.com/weblog/2007/04/02/web-design-and-web-building/ Here's an interesting take on web design and building:

]]> http://www.patmullin.com/weblog/2007/04/02/web-design-and-web-building/feed/ 0 http://www.patmullin.com/weblog/2007/03/19/finishing-touches/ http://www.patmullin.com/weblog/2007/03/19/finishing-touches/#comments Tue, 20 Mar 2007 01:59:16 +0000 Patrick http://www.patmullin.com/weblog/2007/03/19/finishing-touches/ I put the finishing touches on my new design this past weekend, and I'm pretty happy with the results. It still maintains that clean look, but I've added a bit of pop to it with the addition of the background, a few footer additions, some font fixes, and other miscellaneous modifications.

The first thing I added was a new background, that fills the left and right sides of the content with a bit of color. The beauty of this implementation, is that the diagonal lines, are actually a repeating transparent PNG. This allows for me to change the background color to anything I please.

Along with the new background change, I also decided to keep a piece of the old design. My wife commented that she really like the image of the leaf cradling the droplet of water, and I agree with her. It's a nice image, and I feel it has become a sort of staple of the site. Because of this, I decided to put right back where it was. Because I'm using transparent PNGs for this, the background color, and the leaf don't appear for IE6 users, and I'm okay with this. I don't want to bend over backwards for a browser that doesn't support transparent PNGs.

I also added a bit more to the footer. I feel that this adds a nice touch, that remains consistent throughout the site. So, from any page on the site, the visitor always has the ability to my latest posts and the most recent comments.

The comments on the site were a bit bland, so I spruced them up with a background and a border, and reimplemented the gravatar. I really like the concept of the gravatar as it adds more personality to the comment author, and helps provide recognition if they've made more than 1 comment on the site.

The last thing I did was make the logo, and the navigation into images. This guarantees that all visitors will see the same thing. Before, I was only using a font in the style sheet, which meant that if a visitor didn't have that font on their computer, then they wouldn't see it the way I wanted them to. Plus it provides for smoother looking letters.

Overall, I really like the new look and feel. It's much less busy than the old site, but still has some nice features. Hopefully you'll enjoy it as well.

]]> http://www.patmullin.com/weblog/2007/03/19/finishing-touches/feed/ 1