Category Archives: Website

Quick Book Review: Steve Krug’s Don’t Make Me Think

sk_dmmt

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.

Subversion Install Swankiness Part I

Here we go with the newly decided first part of my Subversion install series.  I decided to break it up into smaller chunks of articles as the first part really is the installation/setup part and the second is the integration/deploying part.  So with this first part we’re gonna talk about downloading, verification, repository setup, and Apache integration.  I’ll make it short and sweet as possible but grab a cup of joe so we can get started.

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?

Continue reading Subversion Install Swankiness Part I

Aligning Myself With Subversion Behavior

After working through the development environment portability debacle and relaunching the website, it was time to figure out how to control the customizations I have planned.  There are big plans coming for the site and I want to template the changes for future identity management and blogging prospects.  I really didn’t set much time on setting up a system by myself.  Time for me to re-introduce myself to revision control.

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.