Mailing List Archive

[Zope-PTK] CHALLENGE: PTK wizards
Howdy folks. Wizards are a strength of the PTK, but we need some better
ideas, plus proposals on how to implement them. I'm looking for some
folks to write some requirements and a proposed implementation.

I'll start the ball rolling with some proposed goals for wizards and
wizard infrastructure:

1) Make the process of creating something simpler.

2) Provide a description of what something is _before_ someone starts
creating it.

3) Help cut down on "pollution" of the add list.

4) Provide an "advanced" mode for people that would like to be more
productive, e.g. all steps on one page.

5) Promote consistency in look-and-feel across wizards.

6) Add more "brains" to the creation process, such as field validation,
select lists conditioned on previous choices, etc.

7) Have the wizard run the "edit" as well as the "add" for an object.

8) Provide appropriate context sensitive links into the Zope 2.2 help
system

9) Should be easily extensible to developers, providing just enough
functionality at low enough pain that developers will adopt it.

10) Stays in line with Dublin Core where appropriate.

I'll start the ball rolling with a proposed change to the
infrastructure. I think the first step for all wizards should be one
that:

o collects minimum necessary

o collects the same information for every kind of object

o collects Dublin Core information

o collects a mandatory ID and optional Title, Description, etc.

o the button says "Add"

o from there forward, it runs the "edit wizard" for the new instance

Other thoughts?

--Paul
Re: [Zope-PTK] CHALLENGE: PTK wizards [ In reply to ]
At 09:48 AM 2/22/00 -0500, Paul Everitt wrote:
>
>I'll start the ball rolling with a proposed change to the
>infrastructure. I think the first step for all wizards should be one
>that:
>
> o collects minimum necessary
>
> o collects the same information for every kind of object
>
> o collects Dublin Core information
>
> o collects a mandatory ID and optional Title, Description, etc.
>
> o the button says "Add"
>
> o from there forward, it runs the "edit wizard" for the new instance
>
>Other thoughts?

I think the first screen should be one which asks you more detail about
what you want to create, so as to select an appropriate product and/or
template. For example, in my apps, I would probably have a "Gather
Information" wizard which would select among products and templates for
surveys, polls, votes, discussions, etc., and a "Publish Information"
wizard which would ask about Files, Documents, etc. (And a
"Projects/Administration" wizard which would deal with project folders,
schedules, job descriptions/positions, etc. Just to name a few.)

The second screen could be like your first screen, but the first screen
would need to permit selection from a list, since otherwise the kind of
object wouldn't be known and thus couldn't be added.

In other words, I think there should not be assumed to be a 1:1 mapping
between Wizards and Products/Classes. Otherwise, all we've done is
replaced the cluttered dropdown with a cluttered page of wizards. Wizards
should provide a functionally-oriented grouping of object types and
templates, IMHO.

The idea of asking the same basic information for add, and then doing an
edit, makes a lot of sense from a programming efficiency POV, and it's also
great if the object would let you re-run the "edit wizard" at any time,
with your selections still in place. However, unless the Dublin Core stuff
can be mostly filled in automatically, it does seem that putting it first
is an annoying interference. As a user, I'd much rather fill in stuff like
the title *last*. I want to get my result, not fill out forms. Also, if
I'm exploring the Wizard's options, I don't want to have it actually *make*
something before I've gone through the whole process. How do I know I
really want that object until I've seen the screens that are type-specific?
Re: [Zope-PTK] CHALLENGE: PTK wizards [ In reply to ]
Phillip wrote:
> The idea of asking the same basic information for add, and then doing an
> edit, makes a lot of sense from a programming efficiency POV, and it's also
> great if the object would let you re-run the "edit wizard" at any time,
> with your selections still in place. However, unless the Dublin Core stuff
> can be mostly filled in automatically, it does seem that putting it first
> is an annoying interference. As a user, I'd much rather fill in stuff like
> the title *last*. I want to get my result, not fill out forms. Also, if
> I'm exploring the Wizard's options, I don't want to have it actually *make*
> something before I've gone through the whole process. How do I know I
> really want that object until I've seen the screens that are type-specific?

We originally had the wizard wait until the end, but there was one very
important case that blew a hole in it: file uploads. Some things, like
images, depend on it.

Anyway, I was just making one proposal to fulfill the requirements.
Let's argue about the requirements, then have interested parties
implement some proposals. Again, this is a challenge, so get those
cards and letters comin' in!

--Paul