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?

3 Answers 3


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.

  • Hrmm... I've never used group tabs before, but they look promising. Do you have any recommendation on how many input fields to limit each form to? Commented Dec 31, 2010 at 16:20
  • 1
    @Lèse majesté: The pages should break the whole form down into logical sections, so it's not "page 1", "page 2" etc., each with (say) 20 fields; instead, using your example, grous could be ("festival", "attached flyers"), ("events", "attached flyers", "input set times", "venue")
    – ammoQ
    Commented Dec 31, 2010 at 17:29

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.


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.

  • Super late reply, but it's probably a personal prejudice due to having been subjected to a lot of wizards in various applications that hide advanced functionality that I've needed. Conventional wizards tend to make a lot of assumptions about the user's needs and intent, which is bound to lead to negative experiences among more advanced users that may not fit into the majority use case. Wizards force a particular workflow and also add additional clicks compared to traditional interfaces. Commented Oct 24, 2015 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.