Running a Drupal project: Overview

Tags: 

Here are some general guidelines for running a Drupal project. This applies to small projects, mainly. 

I don't mean to imply a strict waterfall approach. For every project, use your judgment about what to do when. 

This stuff come from my own experience, as well as other people's project guides.

Big tasks

Here are some big tasks, or, really, categories of tasks.

  • Learn about the client
  • Understand site purpose
  • Understand site requirements and structure
  • Design deets
  • Implement and test
  • Train
  • Party

You'll iterate over these tasks as the project proceeds. Sometimes the tasks are merged into one. Do what makes sense for you.

Learn about the client

Omit this step at your peril! It gives you the context the site is going to work in. You need to know.

Some questions to ask, where relevant. For nonprofits, replace "customer" with "stakeholder." (Buffy is always a stake holder.)

  1. What products/services does the client offer?
  2. How are the products/services created?
  3. Who uses the products/services?
  4. What are the main customer types?
  5. What problems do the products/services solve for customers? That is, what are the client's main value propositions?
  6. How do customers learn about the products/services?
  7. How do customers choose products/services?
  8. How are the products/services distributed?
  9. How do customers pay?
  10. What other interactions are there between customer and firm?
  11. How is the client firm organized?
  12. What IT expertise does the client have?
  13. What else is relevant?

The last one is important. Ask "What else do I need to know about you?" There's always something.

For a small project, it might take 1 to 3 hours for this conversation. This task and the next are often done in the same session.

Usually I just have a list of questions, and a free text response for each. Sometimes responses are lists, e.g., a list of customer types. Each one might have its own list of, e.g., relevant value propositions.

I often have drawings as well, e.g., a drawing of product distribution channels. A picture is worth N(780, 120) words. (Random value from a normal distribution with a mean of 780 and a standard deviation of 120. Never seen a picture worth exactly 1,000 words.)

Understand site purposes

This step is about site goals, expressed in stakeholder terms. Purposes often have the form:

The site will help [stakeholder] with [stakeholder goal] by [method].

For example:

The site will help humans kill zombies by helping them pick the right weapons.

I differentiate betwixt purposes and requirements. Requirements are just about the site, and are fairly specific. Purposes are about how the site serves stakeholder goals.

An example. A requirement might be:

A page with a list of weapons, sortable and filterable by attributes: price, weight, range, ...

Question: why is this a requirement? What is the purpose of having this page?

Ask this, and some clients will give you a blank you've-got-to-be-kidding look. But it makes sense to ask the question. In this case:

The weapons list helps customers find weapons they need.

That leads to other questions, like:

  • Are there customers who don't know what they need?
  • Are there customers who think they know what they need, but are wrong?
  • Can you help them find the weapons they need? How? A wizard? Online chat with reps? Common weapon usage scenarios?

Here's another way to think of the difference betwixt purposes and requirements:

Requirements are site features. Purposes explain the business reasons for those requirements.

A typical conversation with a client will rock back and forth between requirements and purposes. They aren't cleanly separable in practice. Sometimes you start with purposes and then figure out requirements. It's just as common to go the other way. 

Documents: Ye olde liste with divers drawings. The list is your friend.

Understand site requirements and structure

Everything above is expressed in business terms. Now we start talking about the site.

Some requirements are about specific pages or site sections, like the one above:

A page with a list of weapons, sortable and filterable by attributes: price, color, size, ...

Others are cross-cutting requirements. They apply across the entire site, or large chunks of it.

The site should be easy to use by people with disabilities.

People who have been injured by zombies often make good customers. 

Another:

The site should be mobile.

If you're on the run, then a mobile site is helpful.

I've found that as we start listing requirements, the site's structure starts to emerge. Features tend to clump together naturally. (Natural Clumps is a good band name.) 

Documents:

  • Tree diagram showing the main parts of the site.
  • List requirements for each node of the tree.

The deets

The detailed design work is here.

You can start with wireframes, if you like. Often, nested wireframes make sense. This site - the one you're looking at now - has the same logo and site name on every page. There's a standard menu, and some other stuff. Rather than repeat all this, make a global wireframe with the repeated elements, and a big "Stuff goes here" area in the middle.

You might need more than one global wireframe. Do whatever makes sense for you.

When you're doing wireframes, it makes sense to also write down functionality. You're thinking about the pages anyway, so you might as well do it now. Freeform text, a list of processing steps, notes on validation, whatever helps you.

You can keep lists of common objects of Drupalness (CODs) as you work on the wireframes. CODs apply to many site functions. Some CODs:

  • Content types
  • Roles
  • Blocks
  • Menus
  • Taxonomies
  • Views
  • Input formats
  • Custom modules

Many designers start detailed design with CODs, instead of wire frames. Again, if that makes sense to you, do it.

Themes. (Sigh)

A confession: themes are the bane of my existence. Well, one of the banes. A smaller one, now that I think about it. A banelet? A centibane? Centibane, that sounds right. 

Most clients want to talk about themes from the beginning of the project. It helps if you can pick an initial theme that's close to what they want, and convince them that it's better to delay finalizing the theme until the page structures are complete.

A warning: don't buy a theme that's packaged as a complete distribution. I did that once. It was a theme named for men's neckware. It was full of nonstandard weirdness. It was so inflexible that I ended up rebuilding the whole thing, creating a "normal" theme with the same colors, graphics, etc.

Implement and test

There are many tutorials on how to build Drupal sites. Google knows where they are. (Hmm, that sounds like "God knows where they are!" Is that significant?)

When building, I usually start with the CODs. The rest of the site depends on them. 

Another habit: I do the hard things before the easy things. For example, suppose I need to write a WYSIWYG editor plugin. Suppose it's the most difficult task in the project. It's the first task I do. I start out with TinyMCE, and find that Tiny's API is hard to understand. I try CKEditor, and succeed in writing the plugin. So, I adopt CKEditor for the rest of the project. Any editor work I do is done on CK.

Now, same situation, but I leave the plugin task until the end of the project. I start with Tiny as before, and keep working with it right up until the end. Then I try writing the plugin for Tiny, and, as before, I get confused by Tiny's API. But I've a lot of time invested in Tiny's configuration. Frak! It I switch to CK, I have to redo a lot of work.

Hence my advice: do the hard tasks first. The beginning of the project is when you'll have the most flexibility. 

Test with the client as you go, particularly the content creation and admin functions. If you can rope in some other people to act as users, that's good. 

Train

Make screen casts for content creators and administrators. It's quick and easy. Don't worry - too much - about editing out the umms and ahhs. 

It's better to make many short videos that a few long ones. If something changes, you might be able to replace a short video, without touching the rest.

Party

Pizza. 

Don't make too much noise. You'll attract zombies.