GUI design for a long form

I have a long (10-page) paper form that I need to implement on screen.  Text
entry boxes, radio buttons, multi-selection lists, etc. will populate a
database through the model.  How would you suggest implementing the
screen(s) for this form?  

(a) Is there a way to make the window vertically scrollable?  The entire
form could go on one long screen.  I'm not sure how user-friendly this is,
though, since the user has to scroll up and down.

(b) Is there a way to put tabs across the top, as in manila folder tabs, so
the user can click on any tab and get to a particular section of the form?

(c) Break the form into screen-size chunks and daisy-chain them with a 'Next
Page' button at the bottom of each?  Is this best implemented as a sequence
of nested modal dialogs?  There would be a final 'Submit' button at the end
of the last screen that actually writes to the database, so the form is
entered into the database all-or-none.

I'd appreciate suggestions.

Thanks.

Ted Shen

Ted,

Short answers below.  We can give more detailed when you decide on the
method you want to use.

> (a) Is there a way to make the window vertically scrollable?  The
> entire form could go on one long screen.

Yes.  You design the view using a "Presenter.Scrolling container" resource
and you can then make the view any size you want, the scrolling is handled
automatically.

> (b) Is there a way to put tabs across the top, as in manila folder
> tabs, so the user can click on any tab and get to a particular
> section of the form?

Yes - #CardContainer. See the Dolphin class browser and package browser
(amongst others) for examples.  It's quite easy too use, you normally have
one underlying model with each tab, and it's associated subviews and
widgets, accessing different parts of that model.

> (c) Break the form into screen-size chunks and daisy-chain them with
> a 'Next Page' button at the bottom of each?

Yes - #WizardCardContainer. For an example see the Deployment wizard that
comes with Dolphin Pro.

(b) and (c) are very similar in use but you would use (b) if the user can
fill out the pages in any order and (c) if page 1 must be completed before
page 2 &etc.  You can then prevent the user continuing if the current page
is not correctly filled in.

The class comments for #CardContainer and #WizardCardContainer give a little
more detail about (b) and (c)

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian, Ted,

Incidentally, for an application like this I'd probably split the "form" into
small pieces using tabs, and then /also/ make each page scrollable.


> It's quite easy too use, you normally have
> one underlying model with each tab, and it's associated subviews and
> widgets, accessing different parts of that model.

I'm not sure what you mean here, Ian, do you mean that you'd split the form
data (conceptually 1 Model) into, say, 10 sub-models, one for each page ?  Or
do you mean that you'd have 1 model (in reality as well as conceptually) with
10 Presenter/View components that displayed different aspects of that model ?
(I'd probably do the second, myself, unless the data turned out to have a
natural breakdown into sub-objects).

    -- chris

Chris,

> I'm not sure what you mean here, Ian, do you mean that you'd split
> the form data (conceptually 1 Model) into, say, 10 sub-models, one
> for each page ?  Or do you mean that you'd have 1 model (in reality
> as well as conceptually) with 10 Presenter/View components that
> displayed different aspects of that model ? (I'd probably do the
> second, myself, unless the data turned out to have a natural
> breakdown into sub-objects).

Closer to the latter.  My original replay was badly worded but I was just
trying to point out that there would be no need to create a separate MVP
triad for each tab's view.  I would probably have one Model, one Presenter
(that referenced _all_ the widgets in it's #createComponents method) and a
series of tab views, each of which made a subset of the widgets available to
the user.  If that got too complicated, with too many widgets, then I would
consider creating separate Presenter/View components but would almost
certainly stick to a single Model to hold the state of the complete form.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ted Shen wrote:

> I have a long (10-page) paper form that I need to implement on screen.  Text
> entry boxes, radio buttons, multi-selection lists, etc. will populate a
> database through the model.  How would you suggest implementing the
> screen(s) for this form?

Hard to analyze without knowing the context, but as a general
principle, I would suggest changing the starting point before you
go about solving the problem.

Paper forms are often solving multiple problems, some of which
are inappropriate if directly translated to electronic form.

So, I would start by ignoring the form per se, and answer some
questions about the data that is on the form, such as:

1) Why is it all on one form - why is the form so big?
    [what problems are solved by this?]
2) What are the smallest subgroupings of data that would
    make "sense" in isolation?
3) How many different situations/opportunities to collect data
    are represented by this single form?
    [Is it *really* a single event that generates all the data at once,
     and is only changed by throwing away the form and replacing
     it with a completely different one, or are there independent
    events which update just certain parts of the data?]

Etc.

Once you've done this, (or if you already have done this, and)
if you still need a gigantic multipage transaction, so be it.
But you *never* want to design a GUI to match a form.
And you *never* want to design a model whose purpose
is to hold the data for a GUI.  That's backwards, and usually
produces the wrong solution.  Very often such solutions are
terribly wrong, but will not hurt at all when constructed.  The
pain comes later on, as the system continues to evolve.

You *always* want to model the collection/usage/calculation
events of the business/activity, and then design a set of GUIs
whose purpose is to gather/display the data for those
collection/usage/calculation events.


> (a) Is there a way to make the window vertically scrollable?

Sure.


> The entire form could go on one long screen.  I'm not sure how user-friendly
> this is,
> though, since the user has to scroll up and down.

Right - it could all go on one long screen.
But I am quite sure this is a user-hostile approach.


> (b) Is there a way to put tabs across the top, as in manila folder tabs, so
> the user can click on any tab and get to a particular section of the form?

Sure.  But even asking this question suggests that
the form data is not really monolithic - it was just organized
that way *on paper* for some reason.


> (c) Break the form into screen-size chunks and daisy-chain them with a 'Next
> Page' button at the bottom of each?  Is this best implemented as a sequence
> of nested modal dialogs?

One can do this too.  How is it best implemented?
Depends on the *reason* for the chunks, the *reason*
they get linked together, and the *reason* that the
data is related into a single whole.


>  There would be a final 'Submit' button at the end
> of the last screen that actually writes to the database, so the form is
> entered into the database all-or-none.

Right - you want an atomic transaction.

But - and this is important - is any part of the transaction
*reserving* some actual resource?  (So that only one requester
actually obtains it?)  Or is the transaction just ensuring that the
net result is either (oneBigCompleteRecord) or (nothing is recorded)?

In the latter case, one can simply hold all the data, and
allow the user to navigate forward/backward or jumpAround,
continually updating the data you're holding, *until* a SUBMIT
button gets pressed (if ever).  The only tricky part is detecting
that the user is gone (so you should throw away the uncommitted
data). If you can possibly organize things this way - DO IT.

If you cannot possibly get the correct result that way
(because of the need to *reserve* an actual resource),
then yes, you must control the entire navigation sequence
in some way, so that it always starts with a reserve, never repeats
the attempt to reserve, always ends in either a SUBMIT or a
CANCEL, and always ends by either confirming success or
reporting the failure to commit, so you may need a sequence
of modal dialogs.  But you should try *very* hard to make that
sequence as short as possible, with as little nesting as possible,
because otherwise the whole activity gets error prone,
both for the designer *and* for the user, and the chances of
user-friendliness diminishes rapidly for both reasons.


Sorry if all this is overkill/well understood.
You might actually be in a situation that demands
a multiple tab scrolling form single atomic transaction.
But they are pretty rare, and make for a poor solution
if not actually needed.  So it is worth extra effort to either
be certain of the neccessity, or design your way out of
the need altogether.

Regards,

-cstb

Ted, Ian,

> I would probably have one Model, one Presenter
> (that referenced _all_ the widgets in it's #createComponents method) and a
> series of tab views, each of which made a subset of the widgets available
to
> the user.

This is a very powerful feature of Dolphin's MVP framework, but it has
occaisionally made for some long debugging sessions for me, and for large
numbers of aspects, seems as though it is inefficient.  Of course, it is
Smalltalk objects, not win32 "objects" that are wasted, so perhaps the hit
isn't all that bad??

Either way, this reminds me of a suggest/request: an option to make missing
presenters cause an error.  Something as simple as
Presenter>>errorOnMissingSubpresenter that defaults to false (current
behavior) would do the job - once called from the framework, of course :)


> If that got too complicated, with too many widgets, then I would
> consider creating separate Presenter/View components but would almost
> certainly stick to a single Model to hold the state of the complete form.

This is my preferred approach, though I would let the data guide me on
whether the model is one object, or a composite.  I agree with Chris'
suggestion of tabs, with each tab being vertically scrollable.  I have been
doing this for a while, and it is what lead to ViewGenerator, CodeGenerator,
and friends.  The idea is to work from "meta data" (the source of which has
evolved over time) to create view resources and code to drive them.  Much of
my code is tied to things that I cannot release, but I have tried to create
and release reasonably concrete base classes that might be of use to you.
If you decide to use the packages, please let me know if you have any
suggestions or problems.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Thank you all.  I think the way to go in this instance will be tabs with
vertical scrolling under each tab, if necessary.  The questions on the form
are organized into several sections, some short, some longer. I'll also
look into ViewGenerator and CodeGenerator.

Ted