Website Redesigns - IA vs. Functions

Any company these days will want to have a public website. In Signal vs. Noise, the blog from the folks at 37signals, we’re given a timely post around a site’s role in the company. Here’s a clipping from Site Persona:

Your site should be your best employee. It should be the most knowledgeable, most polite, friendliest, and most useful member of your team. It should have the best grasp of language and the ability to clearly explain who it is and why it’s there to help you. It should especially have good people skills.

I want to point out that the majority of these objectives are accomplished by design-dependent decisions, and less so functionally dependent pieces. Which leads me to the core of this message; reviewing a company site for effectiveness against the described objectives is very important, and it’s not an uncommon decision that a site redesign is required to address a few shortcomings.

While this sounds simple and straight forward. It is unfortunately common that the reasons that drove the decision aren’t carried down to the planning of the redesign. It bears mentioning how many times drivers such as “It’s unprofessional, it’s hard to navigate, not intuitive, hard for first-time visitors to get sense of how to do things through the site” is brought to a redesign team and they say… “Great! We’ll scope a project with A, B, and C bells, and X, Y and Z whistles – a store locator, website content management, calculators for service fees and taxes –all functional pieces, and of course we’ll do some polishing up of the site and re-branding while we’re putting all these up”…

Yeah No, not so great. Concentrating on functional widgets that will be slapped into a website where the information architecture (IA) and usability are treated as third-class deliverables will most often perpetuate the original problems; it may continue to be hard to navigate, it may still be less than intuitive for first-time visitors, and if these issues remain true then it is definitely still unprofessional. “Hold on” you say, “Just because we’re adding function doesn’t mean we’re not looking at IA”. This may be true – and it depends on the people you’re depending on to handle the redesign. IA is less specifically mentioned by a redesign team when a) it is so in grained that it is a given or b) its actually not specifically recognized as a deliverable. In case of the first team, you would see a lot of discussion on user goals and profiling, intended calls to action, existing business structure. In the case of the second, you’ll see a list of features – mostly functional. Watch out for ‘b’, avoid.

Why should this be a concern? Because both pieces (building widgets and addressing IA/branding design) as deliverables represent– okay, should represent – comparable costs. A redesign that considers design as a byproduct of functional additions is well on its way to failure. This approach implies that the information on the sight prior to the redesign is invalid, useless. But somehow, the additions of the widgets will some how make the invalid information already there somehow valid again.

In the arena of IA vs. Functionality, Comment Roundup includes a description of information architecture in 10 words or less:

IA is Skeleton, Muscle, Bone
Design is Skin, Face, Hairstyle
Development is Nervous System, Brain

The first step is to stop counting function points as a metric for the effectiveness of a website redesign proposal. Clients looking for this work need to acknowledge, understand, and act on this truth.

A better-proven approach is looking at the current limitations of the site from the criteria set at the top of this post, and address what you need to do for clients to perceive your site (and therefore your service) as professional and trustworthy. If you’re going to call it a redesign, then make design a true deliverable. This does not preclude the need for new functional features, but it does require that every functional piece is built to support the goals of the site structure and not stand as self-contained goals themselves.

GTD Update and Managing Time

Netcentrics has released GTD Outlook Addin update 2.1. GTD is the popular shorthand for "Getting Things Done", the work-life management sytem and book by David Allen. I adopted the GTD method just over a year ago and it's served me pretty well. YMMV.

The update itself installed with no problems, but I had installed the first so long ago that I forgot that I actually had made changes to the task views (color and filters etc), so when prompted whether to update the views my hair-trigger reaction foolishly clicked 'update all' before I thought about it. Small user-bug.

Having used for the whole day it's as polished as the previous version, a few comments:

• Like: but haven't yet used, the fact that sub-projects are now implicitly supported. There are subtle changes but for the most part I was able to use it without breaking stride.
• Like: being able to Send-and-File rather than having to create a task in order to file.
• Strange behavior: Send-and-Delegate or and-File usage breaks down when multiple email composition windows are open. If you've opened multiple reply-to's, when you signal to send the task-creation and filing dialogue (current users know what this is) does not open - the email is sent, but don't know where the email is filed to, but the waiting-for task is not created.
  

Along the time-management line, I love the PocketMod. I wish I'd seen this during the 3-4 months that I was PDA-less holding out for my Treo650 - during that time my 'ubiquitous idea capture tool' (GTD-ism) was a stack of business cards alligator-clipped and stuck in my pocket. On the right side of the sight is a customizable pocketmod template tool. Sweeet.

http://www.netcentrics.com/
http://gtdsupport.netcentrics.com/learn/productUpdates.php
http://davidco.com/what_is_gtd.php
http://www.pocketmod.com/

Perspective

It’s been a while, again, since the last post. It’s simply been a while since its felt appropriate to return to what is in perspective an excercise in self indulgence. A truly senseless tragedy touched one of our coworkers and that has, I think, hit very close to home for many of us. With utmost respect, and sympathy.

There is a sacredness in tears.
They are not the mark of weakness,
but of power.
They speak more eloquently
than ten thousand tongues.
They are the messengers
of overwhelming grief,
of deep contrition,
and of unspeakable love.
- Washington Irving

FitNesse, Persistence and Team Processes

Our group just did a project debrief of our latest release. We went through our ‘worked well’ / ‘needs improvement’ discussions and, as I mentioned a few times, one of our ‘needs improvements’ was the fact that our FitNesse tests were allowed to fall into disuse. We’ve resolved as a team to getting these back in place.

A brief thread on the yahoo FitNesse group goes into the subject of handling acceptance testing and integrating persistence. I found Craig Demyanovich’s post on how his group handles it very useful, so I’m posting it here with his permission.

I'm working with a couple guys from ObjectMentor (lucky me!), creators of FitNesse, and we're doing mostly the same [mocking out persistence]. What's different is that our Acceptance Tests (ATs) always run against a database unless we specifically tell FitNesse to run them against in-memory containers. We control this with a custom variable, containerType:

...
!define containerType { database }
...

It's values are either database or inmemory.

We decided to do it this way because we always want the ATs to reflect how the application will be used: with a database. Also, when we were running ATs with the in-memory containers, we found that we forgot to
implement some things in the database container classes. We'd rather not have that happen again during a demo or a release!

To test things like SQL statements, we use Unit Tests (UTs) for our database container classes. ATs verify higher-level behavior: tell the application to manipulate a thing, save it, recall it and verify it.

We maintain our own databases. Our DBA has given us one for integration, and we each have one on our own machines. We have full control over them in terms of schema and data. We work against our own machines (UTs and ATs) until we're ready to integrate. Then, we run the ATs against the integration database. We control to which database we connect via a settings file for our application (though NUnit helps us here with its NUnit project concept). Finally, we track our database schema in Subversion in both a master script (create a database from scratch) and upgrade scripts (to move a database from one version of our application to another). Doing so makes it easy for us to create a new database or upgrade our local, integration and production environments.

Andy Hunt has started a new podcast. Cool

Andy’s got 2 podcasts so far. One is an excerpt from the upcoming Pragmatic Bookshelf book Behind Closed Doors, Secrets of Great Management by Johanna Rothman and Esther Derby. The book is slotted for release on Sept. 15th, and I’m really looking forward to reading it.

The other podcast, "We the people" touches on the importance of the people in software development: being the raw material for a team's success, your ability to communicate well and learn quickly is key.

While I agree completely in both cases, I keyed specifically on the learning. This applies to any industry, field, or position.

listen to it here.

I know that I expect and depend on my ability to learn and adapt quickly above anything else. I was lucky to recognize this pretty early, and so had taken some time to look specifically at how I learn, and what techniques and methods work for me. That investment has serverd me very well so far - I’ll post a few resources in this area a little later.

I absolutely believe that your ability to learn translates directly into your ability not only to build on what you already have, but more importantly to begin anew if you had to. How many paths (or professions) have you walked down? If you really had to, could you leave the one you’re following now, and go to the beginning of another? How confident do you feel when you can honestly answer 'Yes'.

Blitzkrieg Testing and One Test Per Feature

UPDATE 9/22/05: Jared's posted a pointer to this entry as an example of the Blitzkrieg Testing method. I humbly welcome everyone, thanks for looking and as Jared says, Enjoy!

Jared Richardson points to Johanna Rothman's blog post on a method of jumpstarting what Jared coins Blitzkrieg Testing. In this post I describe our experience with the technique (though I was not aware of the formalized name).

Jared's Blitzkrieg Testing essentially proposes a process of installing critical automated testing coverage where none originally existed. Key points in this style of testing:

Aim for breadth, not depth. If you're testing a portal product that has ten main pages, write a test that logs in, visits a page, verifies the page, and then logs out. You've written the equivalent of a "Hello world!" program for that page. Next, add the same type of test for every page in your portal ... your preferences page, configurations, content pages, and so on. The point here is to run across the product and create a basic test for as many areas as you can.
Don't get stuck in any one area. You don't want to dig in; you want to roll across the country in a tank!

Johanna's post recommends a similar practice in incorporating one test for each feature in the smoke test.

Interestingly enough, not having read Jared's formalized description prior to tonight, our group still saw how effective the practice was during our latest release cycle: I had mentioned previously that we wrap our business logic into FitNesse acceptance tests. That needs clarification: we did manage to do this for a few cycles previous to this one, but this last release developed from an amalgamation of 3 concurrent initiatives, 1 of which was maintaining the FitNesse tests, the other 2 were not. New team members were unfamiliar with the FitNesse or the specific fixture code and various pressures didn't allow us to back-track into familiarizing them with it. The other risk factor during this release: was a decision I made to switch our UI testing tool from Selenium to Watir a very short time ago, yes in the middle of this release cycle. Now it may sound strange, making that decision while automated acceptance tests would be left broken. We were essentially compounding the issues by switching UI coverage tools mid-stream. Well let's just say that once it was clear our UI tests would be our product's "testing vice" I had ramped up my use of Selenium but ran into maintenance and simple implementation issues that left me very nervous about putting all my eggs in that basket. Luckily, this is also when I found out about Watir for Ruby. As a test of Watir, I recreated our base UI-driven test of logging into the system using every combination of User Type, Access Level, and User Origin (our web application customizes the features available to users according to these parameters) and tested that navigation to each of the feature pages was successful for each login. This is the standard hook-in test that we run to verify that access and page availability is there on our system, and sounds a lot like the process that Jared describes above.

I had that going so painlessly that I was sold on Watir, so I continued to build on that login code to account for major functional features (client CRUD functions and basic transactions) to cover at a very high level the critical existing pieces. And from there I added a test to cover each of the new features being added in the release.

From there I experienced what Jared describes as momentum: we made a mind-map of the application on whiteboards where we listed major components branching to features, then branching to nodes, then branching to business rules. We traced on it the branches where our blitz had provided coverage, and then prioritized which areas needed to be given coverage next, and which could not be covered with automation and would therefore require greater attention from our exploratory manual testing effort.



Now, would I recommend doing away with any existing tests just to go through this experience? Definitely not: I sorely missed the practice of writing FitNesse tests as specifications by example and not just as automated tests. Having these back in place is my current priority. I am also very aware that many of the tests now placed in the UI script would be better placed in the FitNesse framework as business rule validations. Not to mention I was wickedly stressed until the release went into production (cleanly I might add) last week.

All said and done, we had rebuilt basic coverage of the existing features and planned release features prior to the start of the testing cycle, and a good picture of what needed to be accomplished when the application was built into our test environment. Our testing cycle was still very short and effective because we knew where to focus our manual tests, integration bugs were found and resolved quickly, and we added automated tests to cover many of the bugs found manually to address bug regression. In the end it allowed 3 of the 5 main project members, including myself, to keep vacations this week that were booked out months in advance. Niice.

Read Jared Richardson's original post on Blitzkrieg Testing here
Read Johanna Rothman's post on One Automated Test per Feature here

This process captures a very effective way of implementing the practice of automated testing (in this case acceptance/integration testing) in an environment/project where none exists.

Haloscan Trackbacks

Haloscan commenting and trackback have been added to this blog.