WizardDesignContest

This page is for working on the goals, applications of, requirements for, and implementation issues of a wizard infrastructure.

What's the difference? A goal is from the user's perspective: what a user would want to see in a wizard they're using.

Applications are examples of wizards that could be built using the infrastructure.

Requirements deal with the external interface of the wizard infrastructure, what the API would need to do for wizard authors in order to meet the goals and enable the applications. While goals are from the user's perspective, requirements are focused on the needs of wizard authors.

Implementation issues considers whether base technologies (such as hidden form fields, server-side sessions, etc.) are capable of supporting the requirements.

Goals

• A user should be able to use a wizard to edit an object, as well as add one.
• Information the user enters should be validated right away. Error messages should be specific to the field.
• When creating an object, the object shouldn't be installed and published on the web "for real" until the end of the wizard process. If the user cancels or stops using the wizard in the middle, an incomplete or broken object should not be left published on the web. And when editing an object, the updated object should not be published until the final step.
• The user should be able to enter things like the title last.
• Creating something should be "simple".
• Provide a description of what something is before someone starts creating it.
• A wizard should be able to add different kinds of objects when useful... or to add multiple objects at the same time.
• Provide an "advanced" mode for people that would like to be more productive, e.g. all steps on one page.
• Promote consistency in look-and-feel across wizards.
• A user should be able to run a wizard more than once at the same time.
• Provide appropriate context sensitive links into the Zope 2.2 help system.
• Wizard authors should be able to provide help information/tips (displayed) at each step.
• Permit a user to leave a wizard and come back to it later in the middle, if supported by portal policy.

Applications

• KnowledgeKit (ZWiki decided to make this a link, I don't know why :-) KnowledgeKit is a Wiki name prepend a ! like this KnowledgeKit
• squishdot site
• eCommerce app
• search and query: sql, catalog, databases, data mining
• custom management interface for content providers

Requirements

• Let wizards do field validation easily, with little effort from wizard authors. Allow the object (or a helper class) to validate field values for the wizard.
• Should be easily extensible to developers, providing just enough functionality at low enough pain that developers will adopt it.
• Stays in line with Dublin Core where appropriate. (See the Dublin Core Metadata Initiative )
• Permit the wizard state to be stored in the ZODB, if appropriate for the portal.
• Allow for arbitrary paths through pages, as the Wizard demands

Implementation

• Keeping wizard state in hidden form fields does not support large data, such as uploading images or MP3.