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.

When figuring out how I should download Subversion, I weighed many options.  I could either grab the source from their website at Tigris or install from Ubuntu's repository.  The hardcore geek in me wanted to compile from source, but I really wanted to roll out the software quick so I can focus on the blog code.  Also  updates trickle down from Ubuntu with relative automation, so I went with acquiring the binary from Ubuntu.  It really makes sense to knock out the binaries for tools surrounding a project and focus on source for project related code.  Why waste your time setting up a utility when it's the poject you should be working on?

After some research, I decided to follow the steps provided by How-To Geek.  I updated my repository and installed Subversion.  After the packages were downloaded, unpacked, and installed, I verified that it had indeed been setup on my system.  Here's how it happened:

hokey@tardis:~$ sudo apt-get install subversion
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libneon26 libsvn1
Suggested packages:
subversion-tools db4.4-util
The following NEW packages will be installed:
libneon26 libsvn1 subversion
0 upgraded, 3 newly installed, 0 to remove and 3 not upgraded.
Need to get 964kB of archives.
After unpacking 5128kB of additional disk space will be used.
Do you want to continue [Y/n]?

hokey@tardis:~$ svn --version
svn, version 1.4.4 (r25188)
compiled Sep 28 2007, 10:50:44

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme

So after verification it was time to decide on where to create my new repository and setup web access.  Now with anything Linux-wise, you are pretty much left to your own notions as to where to drop a directory for installs.  Companies like Adobe use /opt for their application installs and some programs use /var to store data separate from program files. I figured /var/svn was reasonable enough so I had at it, creating the directory and using the Subversion command create to setup the files:

hokey@tardis:/var$ sudo mkdir svn

hokey@tardis:/var$ sudo svnadmin create /var/svn/

hokey@tardis:/var$ cd svn
hokey@tardis:/var/svn$ ls -lat
total 36
drwxr-xr-x 7 root root 4096 2008-11-07 17:54 .
drwxr-xr-x 2 root root 4096 2008-11-07 17:54 conf
drwxr-xr-x 2 root root 4096 2008-11-07 17:54 dav
drwxr-sr-x 5 root root 4096 2008-11-07 17:54 db
-r--r--r-- 1 root root 2 2008-11-07 17:54 format
drwxr-xr-x 2 root root 4096 2008-11-07 17:54 hooks
drwxr-xr-x 2 root root 4096 2008-11-07 17:54 locks
-rw-r--r-- 1 root root 229 2008-11-07 17:54 README.txt
drwxr-xr-x 15 root root 4096 2008-11-07 17:47 ..

Now that the repository was created, I needed to figure out how to get web access up. Welp, thanks to the How-To Geek and the original coders of the module, there was one available to tie it all together. Using libapache2_svn, a client can connect via Apache to a Subversion repository and write to it using DAV. This was a perfect setup, even though the security isn't the greatest, for me to develop locally before deploying my sites to my host. So here's how I did it:

hokey@tardis:/etc/apache2/mods-available$ sudo apt-get install libapache2-svn
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
db4.4-util
The following NEW packages will be installed:
libapache2-svn
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 136kB of archives.
After unpacking 344kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com gutsy/main libapache2-svn 1.4.4dfsg1-1ubuntu3 [136kB]
Fetched 136kB in 1s (126kB/s)
Selecting previously deselected package libapache2-svn.
(Reading database ... 30761 files and directories currently installed.)
Unpacking libapache2-svn (from .../libapache2-svn_1.4.4dfsg1-1ubuntu3_i386.deb) ...
Setting up libapache2-svn (1.4.4dfsg1-1ubuntu3) ...
Enabling dav as a dependency
Module dav installed; run /etc/init.d/apache2 force-reload to enable.
Module dav_svn installed; run /etc/init.d/apache2 force-reload to enable.

After I installed the module, I had to edit the dav_svn.conf file to point to my settings. Following the instructions, I removed the comments for configuration which included:

• Setting the repository location:Location /var/svn
• Uncommenting DAV svn
• Setting the SVNPath: SVNPath /var/svn
• And ucommenting the authority settings:
  AuthType Basic
AuthName "Subversion Repository"
AuthUserFile XXXXXX
Require valid-user

I then setup the authentication:
hokey@tardis:/etc/apache2/mods-enabled$sudo htpasswd -cm /etc/apache2/dav_svn.passwd hokey
New password:
Re-type new password:
Adding password for user hokey

After doing a quick restart: hokey@tardis:/etc/apache2/mods-enabled$ sudo apache2ctl restart, I got this:

The wrong Location

What was wrong? I set the Location for Apache as /var/svn. What I was shooting for was to have /svn as the root. Doh!  The SVNPath already tells Apache where to look for the repository. The Location tag and attribute in the configuration tell Apache where to display it on the web server. So I made the change and restarted. After testing authentication, I was ready to rock. Stay tuned for Part 2 of my swankiness as I look to integrate Subversion with a project and deploy it back to my host.

Revision control is the de facto standard way to manage code changes and bug fixes in a project.  From a single developer to a collaborative work environment,  it's the best way to keep the evolution of a project in steady hands.  With a little effort in between building the project, you can roll back, trace history, and work on new features without affecting the production code.  For what I have planned, I need this kind of system to handle the changes heading toward this current deployment of the WordPress blogging software package.

My first exposure to revision control started way back in college.  My role as a student worker included modifying the content management portion of the college's in house online course delivery system.  We used CVS as the motor for our revision control.  CVS was by all means not perfect and we had workarounds or hacks to help push projects along, but it was way better than nothing.  A couple of years ago, I felt the need to retrain myself on that but ended up deciding on Subversion as it was an evolution of the CVS mindset.  What ended up happening was a huge distraction of data backups and an implementation of rsync at headquarters.

Before deciding on what software to use, I felt the need to research the topic of revision control to see what changes came about in the last couple of years.  Due diligence is always near and dear to my heart.   I looked at lists of many different types of software.  There was a CVS control system guideline for websites that cnetnews.com follows.  Git was another up and coming software package that Linus Torvalds built which I used on a project at work.  And a Django module strictly developed for website control and rollback also came up in my searches.

After looking over the choices Sunday evening,  I decided to go with Subversion.  The biggest factor that won me over the other methods was the WordPress development team's use of Subversion.  Another big factor was my previous desire to use Subversion.  What I hope to gain is learning how to use a web server to update and manage code remotely.  This also opens the door for me to try out different IDE's because of plugin or internal support for Subversion.  Finally, further down the road I want to bang out some code for Songbird and they use a documentation/wiki/code repository framework called TRAC, which uses Subversion for its repository portion.

So this week I'll start figuring out how to implement Subversion on the website.  I'm not sure how long it will take, but I will report or update on its progress when necessary.   Once I nail down the process for code management,  I'll finally get to work on updating WordPress for kccollegegameday.com.  Until then,  I'll pop in and out to pontificate when the urge fills me.