Breaking down complex processes

Question

I'm currently developing a CMS for a booking agency that puts together multi-day music festivals. Rather than posting news or articles, the bulk of the content being managed are just these festivals & shows. However, there's a lot of data input involved in posting these shows to the site, and the process to create a new festival is somewhat involved:

• Create a festival
  • Input festival name, start date, description
  • Upload and attach any flyers
• Attach events (e.g. Rock night, Metal night, Hip-Hop, etc.)
  • Input event name/description, date, lineup, headliner
  • Attach any flyers
  • Input set times (on multiple stages)
  • Select venue (or create a new one)

The current implementation model simply has the user go to the Festivals, Events, Flyers, Venues, and Set Times sections of the site and fill out individual forms to add/edit or delete this data. But this doesn't seem very intuitive. So I'm trying to convert these conventional forms into AJAX interfaces and consolidate them into a single screen to streamline the process.

However, this is a lot of data, and I'm wondering, at which point do you need to break a process down into multiple steps (e.g. a wizard)? How many input fields do you try to limit each screen to?

I hesitate to create a wizard-type UI since I personally dislike using them, as most workflows aren't so linear (e.g. each event's set-times aren't decided until the night before the show). I'm hoping that by grouping the input fields into collapsable forms and using a modal dialog for uploading the flyers, I can limit the number of input fields on screen at a given time, reducing the clutter. Is this a reasonable design, or does the average user prefer a wizard-type interface?

Answer 1

In such cases, I use group tabs to organize the forms (so the user can directly access the page he needs), but also provide Next: xyz (xyz being the name of the next form) buttons on each page so a user who prefers the wizard-like approach can click through the pages.

Answer 2

What makes the process complex is not that there's so much data but the assumption that it has to be entered all at once. Creating a festival should be a three step process:

1. Create a blank festival.
2. Edit the festival until it's complete.
3. Publish the festival.

The trick is getting the user to understand that the form doesn't need to be completed the first time. It's okay to edit just one field and hit the save button. The festival can remain in an incomplete draft state -- possibly not even having a date -- right up until the moment it's published.

Answer 3

I'm curious, Lèse majesté, why you don't like wizards? Is it something you've developed a personal distaste for or do you have something more concrete in terms of research that proves wizards create problems for users in completing particular tasks? I'm currently working on a re-architecture of a very complex application and have some similar considerations and concerns as yours, though it has nothing to do with Festivals. I was looking for non-traditional wizards and really liked the uploader that Flick'r uses. I think it also depends on the amount of steps in a particular process. The thing I liked about the Flick'r implementation was its transparency and vertical visualization, both gave me the feeling that it was going to be easy.