where to go next (after submit)

[Dan Allen <da...@gmail.com>]

Every single time I sit down to develop an application in Struts
(though the I am going to present is certainly not unique to Struts) I
find myself stuck on the same question:

"Where to go next?"

Dynamic applications are all about forms and those forms send data to
be saved.  However, once the data is saved, the instructions are
unclear from the point of view of the controller.  The user asked the
controller to save the data, but the user never said what the
controller should do after that.  Many developers make very large
assumptions here, perhaps forwarding on to a generic page, tacking on
any message necessary to inform the user that the object was saved
successfully.  In Struts Resume, Matt forwards to the "Main Menu" page
after each submit.

The problem with automatically dumping the user somewhere is that
often times, it isn't where the user wanted to go.

To answer this question, I thought about how desktop applications
handle this problem.  Usually a sidemenu is accessible at all times. 
Saving data is done without progression by hitting the "apply" method.
 This leaves the next step entirely up to the user.  Unfortuately, it
doesn't translate well to the web since web users tend to expect some
sort of page flow (or else they may think it is broken).

My solution:

I think I have a solution, and I am sharing it just to think aloud and
formalize my idea a bit.  Whenever a form is presented to the user to
edit some object, the form should submit to a readonly version of the
page where a summary of the saved object can be presented along with
any messages.  This way, the user gets the feel of the desktop app's
"Apply" but at the same time senses that the flow was advanced (but
without any assumptions since technically the are still viewing the
same information).  At this point the user can either click to reedit
the object, choose from a set of links provided under the summary, or
select a link from the sidebar menu (if present) to continue.

This workflow seems to make the most sense.  Others may disagree, but
if it provides a solution to keep me from beating my head against the
moniter all afternoon, I'll take it.

Dan

-- 
Open Source Advocacy
http://www.mojavelinux.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: where to go next (after submit)

[Langdon Stevenson <ls...@objectpositive.com>]

Hi Dan

I agree entirely with you on this front.  I follow the same sort of 
process myself when saving data from forms.

My personal preference is to be able to see the data that I have saved, 
and (if necessary) be able to edit any silly mistakes that I may have 
made.  This is especially true of order taking systems.  Its nice to be 
able to see a summary of what you ordered, where it's being sent, and 
what it will cost.

Regards,
Langdon


> My solution:
> 
> I think I have a solution, and I am sharing it just to think aloud and
> formalize my idea a bit.  Whenever a form is presented to the user to
> edit some object, the form should submit to a readonly version of the
> page where a summary of the saved object can be presented along with
> any messages.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: where to go next (after submit)

[Michael McGrady <mi...@michaelmcgrady.com>]

Dan Allen wrote:

>Every single time I sit down to develop an application in Struts
>(though the I am going to present is certainly not unique to Struts) I
>find myself stuck on the same question:
>
>"Where to go next?"
>
>Dynamic applications are all about forms and those forms send data to
>be saved.  However, once the data is saved, the instructions are
>unclear from the point of view of the controller.  The user asked the
>controller to save the data, but the user never said what the
>controller should do after that.  Many developers make very large
>assumptions here, perhaps forwarding on to a generic page, tacking on
>any message necessary to inform the user that the object was saved
>successfully.  In Struts Resume, Matt forwards to the "Main Menu" page
>after each submit.
>
>The problem with automatically dumping the user somewhere is that
>often times, it isn't where the user wanted to go.
>
>To answer this question, I thought about how desktop applications
>handle this problem.  Usually a sidemenu is accessible at all times. 
>Saving data is done without progression by hitting the "apply" method.
> This leaves the next step entirely up to the user.  Unfortuately, it
>doesn't translate well to the web since web users tend to expect some
>sort of page flow (or else they may think it is broken).
>
>My solution:
>
>I think I have a solution, and I am sharing it just to think aloud and
>formalize my idea a bit.  Whenever a form is presented to the user to
>edit some object, the form should submit to a readonly version of the
>page where a summary of the saved object can be presented along with
>any messages.  This way, the user gets the feel of the desktop app's
>"Apply" but at the same time senses that the flow was advanced (but
>without any assumptions since technically the are still viewing the
>same information).  At this point the user can either click to reedit
>the object, choose from a set of links provided under the summary, or
>select a link from the sidebar menu (if present) to continue.
>
>This workflow seems to make the most sense.  Others may disagree, but
>if it provides a solution to keep me from beating my head against the
>moniter all afternoon, I'll take it.
>
>Dan
>

I don't see the problem.  Just do what you need to do in the individual 
case.  That surely will change depending on circumstances. 

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: where to go next (after submit)

[Rick Reumann <st...@reumann.net>]

Langdon Stevenson wrote:

> How about this: In the case of deleting an object, would it make sense 
> to display the list of objects that it used to be part of (obviously 
> with the deleted item missing)?  This would allow the user to visually 
> confirm that the object has in fact been deleted.

That's the approach I always use and is the one most commonly seen when 
editing records in other web applications. Makes the most sense to me. I 
usually add an ActionMessage which displays in green on the top of the 
new list of records "You successfully deleted/removed FooBar" (errors 
show up in red).

-- 
Rick

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: where to go next (after submit)

[Langdon Stevenson <ls...@objectpositive.com>]

David Stevenson wrote:

> On 4/9/04 8:26, "Dan Allen" <da...@gmail.com> wrote:
> 
> 
>>This workflow seems to make the most sense.

  <snip>

> Doesn't work in all cases - after deleting something, I'd rarely want to
> have a screen that says "this is what you deleted", in that case I would go
> to the index page.

This is an interesting point in case.  When adding, or editing an object 
  the solution is fairly obvious.  However it's cases like you have 
mentioned (where their isn't an obvious place to go) that I think Dan's 
musing add value to.

How about this: In the case of deleting an object, would it make sense 
to display the list of objects that it used to be part of (obviously 
with the deleted item missing)?  This would allow the user to visually 
confirm that the object has in fact been deleted.

This would seem like a more logical end point to me that gives the user 
direct feedback about the outcome of their action.

Regards,
Langdon

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: where to go next (after submit)

[David Stevenson <ho...@ytfc.com>]

On 4/9/04 8:26, "Dan Allen" <da...@gmail.com> wrote:

> This workflow seems to make the most sense.

It certainly does in some cases.  In my messageboard for instance, after
submitting a new message I go directly to the page that views the message,
rather than back to the index.  As people often want to check what it looks
like, and maybe amend it.

Doesn't work in all cases - after deleting something, I'd rarely want to
have a screen that says "this is what you deleted", in that case I would go
to the index page.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org