This is why people freak out about user experience design, or UxD, these days. We can define and justify and normalize everything we do during the course of a web project by referring to the user experience, and we can keep this experience in mind as a theoretical model to help us make decisions along the way.

But the user experience is only just that — a theoretical model — until you get real users. This is why we can’t begin a project with all the answers.  The answers to many important questions are provided by the users.  But the users don’t come until we’ve actually designed and built something.

Oh, the Catch-22!

The way out, of course, is by agreeing to launch with something that’s in some important way unfinished.  Knowing that our users will provide us with feedback that will shape the future site — that we plan and build the site in phases, and that these phases are informed by an ongoing engagement with the user experience.

As an agency, you need to go to great lengths to get your clients to understand this.  They can’t provide a spec, like a blueprint for a shed, and get a quote and schedule based solely on the blueprint, and then expect the actual shed to look exactly like the blueprint.  This is what they’ll want, because it’s easier to plan, and easier to budget for, and just generally easier to think about.  But it doesn’t comport with reality, so you’ll have to make a strong case for agility throughout the process.

And as a client, you need to go to equally great lengths to factor this fluidity into your own plans.  Remember the great triangle of software development: one side is budget; the second side is functionality; and the third is schedule.  You can’t fix all of these sides, because you’ll end in horrendous failure (the great triangle of pain and disappointment).  If you must, try to fix two; but leave the third one agile.

Say you’ve got a project with some fairly well-defined requirements, and pegged to a particular real-world date.  You’ve got your functionality and schedule fixed.  This means you must remain agile with your budget.  In practical terms, you’ll need to provide the agency with a budget range that is acceptable, and trust them (Trust them! Seriously!) to keep their costs down.

(Side note: if you can’t trust your agency to keep their costs down, you should find another agency.  This shouldn’t be an antagonistic process, but one where both sides share common goals.)

A second example, one that we see very often at HM: Say you’re a not-for-profit institution that secured funding for a particular project proposal from a big foundation.  You may see all three sides of the triangle as fixed: you promised a set of functionality in your proposal.  You also received a fixed amount of funding, and have a delivery date as part of the funding timeline.

In truth, though, one side of the triangle has to be flexible in this situation.  Chances are the foundation won’t increase the budget, so one of the other sides needs to be subject to change.  This may require some advocacy on your part to get the flexibility you need from the funder, but the big selling point here is the main goal: a beautiful, functional, memorable web experience that users will visit again and again because it was built around their needs.  If you can’t get it all done in the budget and timeline provided, consider this a first phase.  Phases are good!

This matrix exists in a Platonic form where all of the requirements and conditions map neatly to available functionality and structures. It’s only when I populate it with the real-world facts of a project that gaps emerge. Those gaps identify the responsibilities and data structures that we’ll need to delegate to our own modules. Once we group these by logical or functional affinity, we have our module strategy.

For instance, while scoping a recent project it became clear that the client was asking for functionality resembling part of an e-commerce application.  Part, but not all: the client wouldn’t specify the order, but would rather be supplied with a template of an order, and given the option to alter details of the order before submitting.  And instead of processing payment, our application would submit to the client’s fulfillment department, who would then issue an invoice and process the order through existing systems.

We could have scoped this by documenting order flow, architecting the process, and writing a technical brief that would summarize business requirements and accompanying functional requirements.  Instead, we built a Drupal prototype to explore how far existing modules would get us.

You can see a very basic iteration of this prototype here:

http://d1.helen-marie.com/

Barebones indeed.  But that’s the point: this took fifteen minutes, and supplied us with much more accurate information regarding how we could work around the assumptions of the UberCart module.  Those assumptions form the core of our module strategy.  On top of that, we build in time and budget to cover theme development, and we have our basic scope and requirements.  We also know a lot more about our upgrade path than we would from an abstract scoping document, because we can cite UberCart’s support and upgrade history (as well as Drupal’s, of course).

And on top of that, we could show the client a working example of a portion of the proposed functionality.  That’s exciting for everyone involved, and comes at a very small internal cost.

The customization strategy becomes clear:

• A user of type A (or, in Drupal “role A”) can create an order for a user of type B.
• Type B user receives email notification and link when order is created.
• Order is considered “paid” by UberCart when submitted.
• Type A user receives email notification with order details when it is submitted.

That wasn’t so hard, was it?

One of the reservations underlying this approach is this: “What if I pick the wrong modules the first time around?  What if my scope is affected because I change my mind about my module strategy after the client accepts the budget?”

This is a risk you run whenever you pair a scope and a budget.  It doesn’t matter what platform you use, or how specifically you set your scope.  This is a problem you solve by setting a budget that allows for a certain degree of agility (i.e., making useful mistakes, learning from them, and correcting) during development.

Happy 2009!  OK, back to work.

Note to developers and designers: you still can’t layer HTML over Flash, and you still need to design around it.  Sad, but true.  For instance, this page on change.gov has the classic problem: a Flash video player at the top of the page, and a menu that draws a layer on rollover.  The two are not friends.

In its natural state:

On mouse over — whoops!  The video’s “play” icon shows through the menu:

It’s a problem on standards-compliant browsers and elsewhere.  There are two ways around it: hide the Flash player when the menu layer appears, or design around it.  We recommend the latter, as it enables you to avoid hacks or sleight-of-hand.

If you need the video right there, though, you’ll have to figure out a better way.  And if you have to resort to trickery, you might as well entertain yourself.

Fixing change.gov’s problem

This page uses the uber-popular Media Player from Jeroen Wijering, which unlike the QuickTime player is fairly scriptable.  But instead of making any calls on the Flash player or its helper scripts, we’re just going to destroy it entirely.

The goal is to replace the video player with some kind of flat HTML whenever the mouse is over the menu.  Then we can guarantee that the menu layers will always layer properly over boring HTML elements instead of being invaded by underlying Flash goobers.  When the mouse leaves the menu, we can restore the original video player.

You’ll need two main entities: a listener, to respond to the menu rollover event; and a Flash player handler, to hide and show (or destroy and re-create) the player.  Luckily, change.gov already has the former; it’s in this JavaScript file.  Our modified version, available here, has two additional method calls at lines 95 and 106.  These refer to a nav handler object defined in this additional JS file.

I made one substantial change to change.gov’s original HTML: I gave a class of “wrapper-video” to the div that contains the video player.  The nav handler will work on the assumption that every video player that might be affected is classed with “wrapper-video”.

When the handler’s setOver() method is invoked, it loops through “wrapper-video” divs.  For each div, it caches the original HTML and the calculated width and height.  Next, it sets the div’s background to an image: in this case, an exact still of the video player.  E.g.:

Looks convincing.  The image file name contains the dimensions, and setOver() takes advantage of this by constructing the file name dynamically.  This way, if you had more than one video player size, you’d be covered.  For good measure, we also explicitly set the div’s width and height, so it doesn’t collapse when we erase its contents.

Once all of this is done, we call jQuery.html(”") on the div, erasing its contents.  Now it just shows the background image, and will play nicely with the menu layers.

When the mouse leaves the menu area, navHandler.setOut() restores the original HTML contents of each video wrapper div.

You can see a working example here.

The files are also available for downoad as a ZIP.

The better solution clearly would be to design around this issue, but all too often we don’t have a lot of choice.  If video is the featured page content, there’s rarely a good way to push it safely towards the fold.

(Caveats: browser testing, your mileage may vary, etc.)