Fab Camp Fire
More tales of Fab Gear's modus operandi.

Technology Choices
Practical Applications
Getting a Project Off the Ground

Each project presents unique design challenges, and we work hard to avoid a one-size-fits-all design mentality. Having said that, for new small-to-medium sized projects we start with a standard approach that has proven successful for us in the past.

Start at the top: For web applications, workflow is the hardest thing to get right, and it'll have the largest impact on the quality of the application. Depending on where you are in the business cycle, the ability to quickly prototype and demonstrate your workflow might also be important.

Focus on it. Get out a pen and start sketching the site, on paper or on a whiteboard. No details, yet, just boxes connected by arrows. Once your first cut is done, start editing:

  • Eliminate "dead" pages, ones that just display a short message and invite you to continue.
  • Combine pages where it will improve efficiency, and split pages when it makes the process less confusing.
  • Think about destinations - when you're done with a process, where do you end up? Hint: content-free "home" pages are a crutch.
  • Think about which actions are important to the system, as opposed to the user - things like logging in. Try to focus the workflow on the what the user wants to get done, and integrate the system-required actions into those processes naturally.
  • At each stage in the process, try to provide the user one obvious next step.

Without a good workflow and data model, you're lost.

Let me give you an example: We built a real estate application that included the ability to add new property listings. Property listings have hundreds of attributes, and we ended up with a workflow of about eight pages.

We realized that completing such a process would take quite a while, which opens the door to phone calls, lunch and other interruptions, and may even require the efforts of multiple people. Therefore we had to be able to save partial listings, and later pick up where they left off.

So we had to make that work. We adjusted our constraints, and added appropriate status indicators. We made sure that those few attributes we simply couldn't live without were collected in the first step of the process. We ensured that other parts of the system could easily determine whether to include or exclude listings, based on the their level of completeness. We made sure that the workflow and the user interface elements led naturally to the save points.

Before you started sketching the site, you probably had a general idea of the data you'll need to collect and retain. Use the workflow sketch to refine that understanding - get a feel for the dynamics of the site, when information becomes available, when it needs to be stored, and what the transactional boundaries look like from the user's point of view.

Transactional boundaries are critical in any non-trivial application. Users need to know when their work has been saved, and if it's not yet complete, how to get back to it. Ideally, an action should be an all-or-nothing proposition - either it is complete and saved, or nothing has been changed. Complex tasks might not have such obvious behavior - they may require a series of steps, some of them optional. In such cases, it must be clear when changes are preserved, and how to return to previous steps.

Armed with a deeper understanding of your information needs, dive to the bottom: design your database. Go directly to the database, do not pass go, do not design a code-based object model. You can create much richer relationships in code than you can on the database, so if you start with code you'll waste all your effort trying to shoehorn objects into the database, or fighting an uphill battle to get decent performance (have you ever looked at the abominations generated by one of those automated model-to-schema tools? Yeesh).

So now, with a workflow and a schema, you're in a great position to design an object model that not only supports your site, but can also actually be stored efficiently. In fact, you could even use something like DbForms to create and use your new data model without any intermediate code.

history   contact
shim Fab Gear Interactive
Case Studies
The Process
The People

The Menu
Here's what we serve up:

Architecture Consulting
Software Consulting
Database Consulting
Web Site Construction
Need A Map?
We have one for you. Our development roadmap directs you destination by destination to your web presence.