Book Review: Designing Web Navigation

Designing Web Navigation: Optimizing the User Experience by James Kalbach, published by O'Reilly.  ISBN:0596528108.

This is a book about design, not implementation.  You may have grokked that from the title...  The book's beautifully laid out with lots of shots of real websites scattered across full color pages to help illustrate important points.

This book's really targeted to make you think about how to make your site's visitors best able to easily and repeatedly find content you deem important.  You won't find bits on CSS, Javascript, or Ajax.  Instead you'll find out things such as selecting appropriate navigation menu styles for given contexts, information architectures, the impact of tagging systems, and some of the complexities around search.

The first chapters are pretty academic and can be pretty dry, but they provide good information on content/information architecture.   The rest of the book is an easier read, but that doesn't mean you should skip the first chapters.  Lots of good sidebars call out specific topics -- accessibility is a hot topic throughout the book and gets a lot of sidebar treatment.

The book's full of gems such as how you should consider workflows in navigation (think shopping cart systems, e.g.), or the differences between "lingo" and vocabularies.  There are also a bunch of great references to other works, and each chapter has some nice exercises which are actually pertinent and helpful in making the reader more aware of that chapter's points.

I was surprised that globalization/localization didn't get more treatment in the book, but there are quite a few example screenshots and discussions around international websites.

Overall it's a very interesting, thought-provoking book.

Renaming NHibernate-Persisted Classes

If you rename classes that you're passing through NHibernate, keep in mind that you've got several places you need to do that rename at:

1. The business class itself, i.e. Schema -> Schematic.
2. Inside the Hibernate.cfg.xml file, where you'll have a mapping resource element pointing to the class and its assembly.
3. Rename the mapping file, i.e. Schema.hbm.xml -> Schematic.hbm.xml
4. Change the name of the class within the mapping file's class tag.

That last one's bitten me a couple times and I always lose more time than I should over it.

Forget any one of these and you'll run up against the infamous "Could Not Compile Mapping Document" error.

First CodeMash Podcasts Up!

Michael Kimsal of WebDev radio did an interview with me a week ago about CodeMash and has posted the ‘cast up on his site.

Chris Woodruff also did an interview with me about the history of CodeMash, my current role in CodeMash, and what attendees can expect to find at CodeMash this year.  That’s posted as the first ‘cast on the CodeMash website — Chris will be posting a series of podcasts interviewing speakers, attendees, and others around CodeMash.

I’m never pleased hearing myself speak in any media, so I’m definitely not a good judge on the quality of these.  I know I had waaaaay too many “uh”s in the interview with Chris.  That aside, we covered a lot of interesting topics so I think they’ll be useful and interesting to listeners.

Check ‘em out!

CodeMash Badge: Wear It!

For some stupid reason I’ve forgotten to put up my CodeMash badge on this blog.  Rectified now.

If you’re heading out to CodeMash, please add the badge to your blog or site.  You can find HTML for the badge at the CodeMash registration page.  Every bit of exposure for our community-driven event helps drive attendance!

Good Series on Collections in NHIbernate

Billy McCafferty has a nice series on collections in NHibernate.  I like his discussion of good places to put particular retrieval methods (FindAllByDateRange is his example).  His thoughts on separating out responsibilities between the data access layer and domain layer are thought provoking and well-reasoned. 

McCafferty walks through some various scenarios of where such methods could live and lays out good pros and cons along the way.  His article's really about how you can work solve problems around collections, but the general point of where and how to implement accessors is an important one too.

Nice Blog from O'Reilly's Publicity Folks

The publicity team at O’Reilly has a great blog talking about releases, conferences, and a lot of other good stuff relating to O’Reilly.  I just stumbled across it today and found it pretty interesting!

Another Reason CodeMash Rocks

Reason #152 why CodeMash and its crowd of homies is awesome: The CodeMash Song.

Read the rest of the thread for a great discussion on the pending jam session at CodeMash.

Ironing Out the CodeMash Schedule

I’m looking at the tentative schedule for the CodeMash sessions we’ve selected and it’s shaping up to be a pretty amazing lineup! 

Jason Gilmore and Dianne Marsh have done the really, REALLY difficult job of the initial session selection: 120 submissions were received, all of which were of high enough quality to be selected at any code camp or other regional conference, most of which were solid enough for national level conferences!  They had to cut out almost 80 selections to pare down to 42 sessions.  That was a hard, hard bit of work, particularly since we know all of the submitters and it’s tough to tell friends “Sorry, maybe next year.”

Now comes the next hard part: slotting those sessions into a schedule where we can try and build momentum at the start and avoid too many obvious conflicts.  Not an easy task, and I’m very glad that Jason and Dianne did all that initial work and then tossed the list over to me for a review!

Dianne, Jason, and a few other folks have confirmed two great keynoters (Brian Goetz and Scott Hanselman) and have a third nearly nailed down.  I’d love to tell you who it might be, but I don’t want to sink the process.  Trust me, you’ll agree it’s a cool catch if we get him!

CodeMash isn’t far away at all — 10 January’s not many squares out on the calendar.  Go register.  Now!

The Importance of Good Task Granularity

On Tuesday's DNR the guys read a letter of mine I'd sent them after hearing a comment on one of their shows about burnout due to a perceived lack of progress when working on vague, esoteric, or difficult features. 

Carl and Richard didn't read my whole letter, which is understandable since they've time limits.  (And no, it wasn't particularly long-winded, either!)  Unfortunately, they left out the main reason I wrote in: The importance of breaking those large or vague tasks into smaller, more concrete chunks, and a creative way to do that. 

My letter included my explanation of how I tried to keep some sanity around a poorly scoped, vague feature I had on my plate during a project.  The feature was estimated at three days and ended up taking three months.  Ouch.  There's a long story behind that, and the huge overrun was largely due to the client making some very sensible changes based on good business decisions for them.

Regardless, I had one feature card that remained on our working wall for three months without any visible sign of progress.  It was frustrating for me since my teammates were wracking up completed features, and I also felt it left upper management the impression that no progress was being made on the feature.

The right thing to do in these cases is go back to the drawing board and rework that feature into a number of smaller, more granular tasks.  You should bring in the client to ensure you're getting the right things broken out and aren't missing any necessary pieces of the larger part.  Those new decomposed tasks should then be broken out as their own features and tracked.

For a number of reasons that wasn't feasible (theory versus real world), so what I did was handle all that myself using one of the best technologies known to mankind: Post-It Notes.

I broke down the larger task into smaller parts and wrote those up on Post-Its.  Those stickies went up on a couple different sheets of paper to categorize their status (limbo, in the queue, working, complete).  I used these Post-Its to help keep me focused on specific tasks as well as reminding myself that I was indeed making some progress while the others on the team were wracking up a large number of feature completion dots each week. 

Small things like green lights on a test or completion dots on a feature chart may seem simplistic or silly, but they are much more significant than you might think.  We all crave satisfaction in some fashion, and these sorts of things help salve that need.

When the Feature From Hell finally got finished I decided a regular dot (we use the round labels) wasn't quite expressive enough of the effort I put in to the feature, therefore I got a marker and made a dot that indicated the significance of the event:

Two important things about this:

1) Break down a large or vague task into smaller chunks so you have better scope and can see better progress.

2) Use some form of BVC to help keep that progress visible.

Burnout due to a missing sense of accomplishment on long, esoteric,  or vague tasks is a real risk.  Help yourself out by doing something, anything to show progress on those tasks.