I just put down the second edition of Steve Krug's "Don't Make Me Think" so I'm putting down some quick thoughts about the book as a whole. For those of you that don't know, web usability is a big topic when designing, developing, and marketing a website. Steve Krug comes from a background of years of consulting in this field and put a condensed version of what he has learned in "Don't Make Me Think." The book is divided into 3 main sections, usability on the whole site, usability on the home page, and how to test for usability. All said Krug does a good job of summarizing what all it takes to increase website usability while leaving the door open for more exploration.

The title alone is what someone who reads this should walk away form this book. "Don't Make Me Think" is more of a command than just a title. When people blaze through websites, they move at a pace faster than normal conversation. Where you should choose your words wisely while talking with someone (especially someone important), you don't have the luxury of choosing words on the fly when presenting a web page to someone. It is the responsibility of the website to make it as easy as possible from the beginning to avoid any confusion. Confusion slows people down, which will lead them to other websites.

The first part of the book talks about website usability as whole. Krug breaks it down to about 6 different parts of the page where confusion can creep. Some of them made sense and some of them were gotchas I haven't thought of. I came away with two concepts. First, keep things simple and consistent across the whole site. Second, make the site look like some version of a tabbed catalog or book. This makes more sense when developing a business site, but the concept can be used for other purposes. Essentially, a crisp clean book with easy to search and indexed tabs will make the most of what your target audience wants.

We shoot on to the second part of the book where Krug throws that out of the window and talks about the home page. Krug says that the home page can have a different look from the rest of the site because of its welcome mat mentality. To me that meant it's the cover of the book or catalog to flip through, and then some. You need tell them what it is and how to dive deeper, but give just enough shine to lure them away from other books. Here Krug makes exceptions to the rules, making them good rules.

The last part of the book talks about how to perform duct tape usability testing. From his experience, he maps out the hardcore way to sample a user base and record interactions with a web page for top notch results. Then, much like this book, he runs over the quick and dirty way to get comparable results with just a camera and an office. All that's really needed is to openly discern what type of natural browsing behavior someone exhibits when hitting the website the first time. I haven't really thought about web usability testing before, so getting a glimpse of both sides of the spectrum really help in determining where I can apply usability testing to my projects.

Out of the whole book, the part where I most identify was the downright silly arguments bred from design suggestions or decisions. Believe or not, I have been privy to some absolutely ridiculous arguments. The classic examples he provides, including the 'technical issue' trump card, have all been played out in front of me. I may have even dealt some out myself. The point that's made here applies to my trials and meeting tribulations. The focus of the website should be geared toward the target audience and not one's own beliefs. The context and content should always aim for the target audience. This is where Krug uses usability test to figure out if the site works or not. Leave it up to strangers, not someone who's had a hand in the whole development process.

Steve Krug's "Don't Make Me Think" is a great read if you into making you website super user friendly and therefore super cool. If you have an afternoon pluck down and cull out the basics. The concepts within will help catch any low hanging fruit (which he suggests throughout the whole book) while not wasting any of your time building a site. Krug does gloss over some topics like Cascading Style Sheets, but that's a monster topic on its own. Regardless, pick up this book if you want exposure to solid design principles, amateur or professional alike.

Nothing Like A Fresh Subversion Import

Welcome back to part 2 of my Subversion install series.  What we are going to go over is developing the right structure for the repository, importing a website, updating a website, then testing and deploying the website using some of Subversion's command sets.  There were some road blocks along the way and I will talk about that as well as some other thoughts about the process.  After that I'll talk about what's next but first let's setup and deploy some code.

The first step in molding the fresh install of Subversion into something workable, was to decide on what kind of structure I wanted to keep.  Articles online discussed whether or not to keep multiple repositories for projects or maintain a single repository to house multiple projects.  In thinking of how I wanted it implemented, the simplicity of maintaining a single repository won over the cleanliness of revision management in multiple repositories.  Perhaps at a later date I can split it out or even incorporate Git, but for the purpose of getting started I'm going with one repository.

I decided to follow the svnbook's advice of a creating a temporary directory structure to setup the initial framework of the repository.  In my case, there are three major areas I will develop in:  websites, scripts, and home related projects.  I created the structure and imported them in to Subversion using the svn import command.  After which, I deleted the temp directories and verified the structure below.  Here's the output:

hokey@tardis:~/tempdir$ sudo svn import . file:///var/svn/ --message 'Initial Repository Layout'
[sudo] password for hokey:
Adding         scripts
Adding         headquarters
Adding         web
Adding         web/gonzoguys.com
Adding         web/gonzoguys.com/trunk
Adding         web/gonzoguys.com/branches
Adding         web/gonzoguys.com/tags
Adding         web/h0key.net
Adding         web/h0key.net/trunk
Adding         web/h0key.net/branches
Adding         web/h0key.net/tags
Adding         web/hoketronics.net
Adding         web/hoketronics.net/trunk
Adding         web/hoketronics.net/branches
Adding         web/hoketronics.net/tags
Adding         web/kccollegegameday.com
Adding         web/kccollegegameday.com/trunk
Adding         web/kccollegegameday.com/branches
Adding         web/kccollegegameday.com/tags

Committed revision 1.
hokey@tardis:~/tempdir$ svn list --verbose file:///var/svn
1 root                  Nov 18 08:44 headquarters/
1 root                  Nov 18 08:44 scripts/
1 root                  Nov 18 08:44 web/
hokey@tardis:~/tempdir$

It was time to work with local install of my website.  I copied the production code to my home folder on my local webserver.  After setting up the database and changing root path directives, I set about verifying the local page.   It looked good so I then downloaded the latest Wordpress package.  Following the directions, I copied the updated code and again verified the website.  The recent point releases didn't affect the database schema, so I was good on that end.

Now that I updated my code to the latest Wordpress point release, I imported the website into the Subversion repository.  Using svn add, I recursively added all of the new files from my website.  When it successfully added the file set, I committed the change using svn commit, complete with the initial import message.  Subversion pulls from CVS alot and these two commands reflect that.  It almost felt like I was greasing the code revision bicycle gears and getting back to the smooth ride of code management.

So now that I added the website files to the repository, I did it twice because of another point release in Wordpress, it was time to test and deploy the code.  Using the svn export command, I copied the code to the web docs directory on my local webserver.  I decided on doing that instead of checking out the repository on the live site because I'm on a shared hosting platform for production and I didn't want trailing '.svn' folders eating up space.  Plus it adds the benefit of greater security.

hokey@tardis:/var/www/hoketronics.net$ sudo svn export http://localhost/svn/web/hoketronics.net/trunk ./hoketronics.net

The code exported to the local server.  This is where I ran into some issues.  The code portion of the website works well in different directories, but I need to come up with a way to manage dev/test/prod databases for link resolution.  The logon screen for the local test install pointed to the local dev install.  Regardless of that little issue, the code tested out well.  Now it was time to deploy the website to my shared host, minus the config file.

The other issue I ran into was the process of updating my shared host with the new code.  I run Linux on the webserver locally but my workstation runs Windows XP.  The best way, I thought at the time, to copy the update was to compress the test folder, copy it to my workstation, and then use Filezilla to copy it up to my shared host.  This proved laborious and it ended up taking more time than I expected due to two reasons: remembering the correct compression one liner and not taking advantage of a command line ftp client on the local webserver.

That said, the production site on the shared host updated with no breaks.  I logged on, verified the version, and inspected both the UI and and the backend files for any issues.  The Subversion process was almost complete.  After I updated the code, I made note to change the initial work flow for updating my site to handle updates from the local webserver to the shared host.  Also, I'll take some time to flesh out different configs for my environments to avoid any path issues the next time around.  Lastly, I'm going to make sure I centralize my one liners for easier access, maybe even using the repository to keep track of additions.

Subversion seems like a great centralized source code management tool.  With my CVS experience under the belt, much of the commands feel familiar and comforting when I invoke them.  Now that I have the repository live, kccollegegameday.com is getting some work.  I'm looking forward to checking the 'diffs' when modifying pages and themes.  Chances are you'll see me talk about that on top of a couple of article ideas due to the roadblocks experienced with this project.