Done Page and re-usable forms

[Leon Torres-2]

Hi all,

I'd like to get to the bottom of this issue:  Suppose you have a re-usable form
such as editcontactmech that is called from various screens.  To get back to the
screen the user came from, there is a [Go Back] and [Save] link generated from a
DONE_PAGE parameter that is passed to editcontactmech.

However, suppose instead of having [Go Back] and [Save], the requirement is that
the user is taken back to the originating screen upon submitting the form.
Currently, the only way I was able to implement this was to have a special java
event method called donePageRequestHelper as follows,

     <!-- call this request when you have a donePage that you want to go to
after finishing a service -->
     <request-map uri="donePageRequestHelper">
         <security https="true" auth="true"/>
         <event type="java" path="path.to.java" invoke="donePageRequestHelper"/>
         <response name="viewContact" type="request-redirect" value="viewContact"/>
         <response name="viewAccount" type="request-redirect" value="viewAccount"/>
         <response name="viewLead" type="request-redirect" value="viewLead"/>
         ...
     </request-map>


     public static String donePageRequestHelper(HttpServletRequest request,
      HttpServletResponse response) {
         String donePage = (String) request.getParameter("donePage");
         if (donePage == null) {
             donePage = "error";
         }
         return donePage;
     }

The problem with this is that the request-redirect will end up adding all the
form parameters to the URL.  I see no way to resolve this with the current
RequestHandler, except maybe with a flag to prevent the form POST data from
being added to the GET parameter data.  That is, it is only desired to pass
along GET parameters to the redirect URL from the original request.

Any ideas?

- Leon

[BJ Freeman]

have you thought of using the lookup type of form.
this also allows the data created to be inserted into a field.


Leon Torres sent the following on 7/13/2006 1:57 PM:

> Hi all,
>
> I'd like to get to the bottom of this issue:  Suppose you have a
> re-usable form such as editcontactmech that is called from various
> screens.  To get back to the screen the user came from, there is a [Go
> Back] and [Save] link generated from a DONE_PAGE parameter that is
> passed to editcontactmech.
>
> However, suppose instead of having [Go Back] and [Save], the requirement
> is that the user is taken back to the originating screen upon submitting
> the form. Currently, the only way I was able to implement this was to
> have a special java event method called donePageRequestHelper as follows,
>
>     <!-- call this request when you have a donePage that you want to go
> to after finishing a service -->
>     <request-map uri="donePageRequestHelper">
>         <security https="true" auth="true"/>
>         <event type="java" path="path.to.java"
> invoke="donePageRequestHelper"/>
>         <response name="viewContact" type="request-redirect"
> value="viewContact"/>
>         <response name="viewAccount" type="request-redirect"
> value="viewAccount"/>
>         <response name="viewLead" type="request-redirect"
> value="viewLead"/>
>         ...
>     </request-map>
>
>
>     public static String donePageRequestHelper(HttpServletRequest
> request,      HttpServletResponse response) {
>         String donePage = (String) request.getParameter("donePage");
>         if (donePage == null) {
>             donePage = "error";
>         }
>         return donePage;
>     }
>
> The problem with this is that the request-redirect will end up adding
> all the form parameters to the URL.  I see no way to resolve this with
> the current RequestHandler, except maybe with a flag to prevent the form
> POST data from being added to the GET parameter data.  That is, it is
> only desired to pass along GET parameters to the redirect URL from the
> original request.
>
> Any ideas?
>
> - Leon
>

[David E Jones-2]

Why use a redirect at all? Why not just change the form target?

Or if you do want to use a redirect, use the more common (and generally successful) approach of saving the parameters in the user's session and then send down a redirect with minimal information. This can be done using a Control Servlet request event written in Java that uses the response object to send the desired redirect.

-David


Leon Torres wrote:

> Hi all,
>
> I'd like to get to the bottom of this issue:  Suppose you have a
> re-usable form such as editcontactmech that is called from various
> screens.  To get back to the screen the user came from, there is a [Go
> Back] and [Save] link generated from a DONE_PAGE parameter that is
> passed to editcontactmech.
>
> However, suppose instead of having [Go Back] and [Save], the requirement
> is that the user is taken back to the originating screen upon submitting
> the form. Currently, the only way I was able to implement this was to
> have a special java event method called donePageRequestHelper as follows,
>
>     <!-- call this request when you have a donePage that you want to go
> to after finishing a service -->
>     <request-map uri="donePageRequestHelper">
>         <security https="true" auth="true"/>
>         <event type="java" path="path.to.java"
> invoke="donePageRequestHelper"/>
>         <response name="viewContact" type="request-redirect"
> value="viewContact"/>
>         <response name="viewAccount" type="request-redirect"
> value="viewAccount"/>
>         <response name="viewLead" type="request-redirect"
> value="viewLead"/>
>         ...
>     </request-map>
>
>
>     public static String donePageRequestHelper(HttpServletRequest
> request,      HttpServletResponse response) {
>         String donePage = (String) request.getParameter("donePage");
>         if (donePage == null) {
>             donePage = "error";
>         }
>         return donePage;
>     }
>
> The problem with this is that the request-redirect will end up adding
> all the form parameters to the URL.  I see no way to resolve this with
> the current RequestHandler, except maybe with a flag to prevent the form
> POST data from being added to the GET parameter data.  That is, it is
> only desired to pass along GET parameters to the redirect URL from the
> original request.
>
> Any ideas?
>
> - Leon

[Leon Torres-2]

Hi David,

David E. Jones wrote:
>
> Why use a redirect at all? Why not just change the form target?

Originally we wanted to avoid issues with refreshing the target page with POST
data.  But since we designed the target pages to be free of this issue, we found
using "view" instead of "request-redirect" works fine.

> Or if you do want to use a redirect, use the more common (and generally
> successful) approach of saving the parameters in the user's session and
> then send down a redirect with minimal information. This can be done
> using a Control Servlet request event written in Java that uses the
> response object to send the desired redirect.
>
> -David

Hm, not a bad idea.  I'll look into it if this comes up again.

- Leon

[Ray Barlow]

I have certainly found users are confused by this particular interface
especially on the ecommerce side, where you don't get to train the user
when creating addresses or card details. It does not progress the user
to the next stage and often they press save again thinking it didn't
work the first time and they are not sure they want to press "Go Back".
People are generally taught not to press the "Back" button and here we
are saying "Go Back", they don't want to go backwards in the checkout
process they are itching to give you their money!

I think the rational is that 99% of forms/dialog act with an "OK" and
"Cancel" button style of interface which the mind naturally applies to
these screens and the user does not want to "Cancel" or "Go Back" which
they see as heading the wrong way in the process and possibly undoing
what they have just done.

Personally I would like to see the save button automatically step the
user onto the next screen, if there are no errors, and for the forms
that require or offer additional information after the first save, such
as contact mech purposes, these should be offered on the first screen so
I can choose and submit in one screen that this is the primary phone
number I'm creating. Much quicker than entering the number clicking
save, next screen select purpose click add and then click go back to finish.

I did once change the ecommerce process but it was 3 years ago which I'd
need to look at to recall the solution I used. I see David has made a
suggestion anyway so really this reply is a call for possible change to
the standard currently used in OFBiz. Would people prefer the save to
move to the next screen?

Ray

Leon Torres wrote:

> Hi all,
>
> I'd like to get to the bottom of this issue:  Suppose you have a
> re-usable form such as editcontactmech that is called from various
> screens.  To get back to the screen the user came from, there is a [Go
> Back] and [Save] link generated from a DONE_PAGE parameter that is
> passed to editcontactmech.
>
> However, suppose instead of having [Go Back] and [Save], the
> requirement is that the user is taken back to the originating screen
> upon submitting the form. Currently, the only way I was able to
> implement this was to have a special java event method called
> donePageRequestHelper as follows,
>
>     <!-- call this request when you have a donePage that you want to
> go to after finishing a service -->
>     <request-map uri="donePageRequestHelper">
>         <security https="true" auth="true"/>
>         <event type="java" path="path.to.java"
> invoke="donePageRequestHelper"/>
>         <response name="viewContact" type="request-redirect"
> value="viewContact"/>
>         <response name="viewAccount" type="request-redirect"
> value="viewAccount"/>
>         <response name="viewLead" type="request-redirect"
> value="viewLead"/>
>         ...
>     </request-map>
>
>
>     public static String donePageRequestHelper(HttpServletRequest
> request,      HttpServletResponse response) {
>         String donePage = (String) request.getParameter("donePage");
>         if (donePage == null) {
>             donePage = "error";
>         }
>         return donePage;
>     }
>
> The problem with this is that the request-redirect will end up adding
> all the form parameters to the URL.  I see no way to resolve this with
> the current RequestHandler, except maybe with a flag to prevent the
> form POST data from being added to the GET parameter data.  That is,
> it is only desired to pass along GET parameters to the redirect URL
> from the original request.
>
> Any ideas?
>
> - Leon
>

[David E Jones-2]

Yes, this is certainly one of the not so golden oldies that needs revisiting...

In a web application I don't think the OK/Cancel paradigm is sufficient so I've been opposed to that from the beginning.

Having the Save button automatically do a "Go Back" as well also seems confusing and I don't like it for 2 reasons:

1. the context of the operation is lost unless the following screen has clear indication of success and well as results of the operation done (like showing a ContactMech summary, etc)

2. as you mentioned with the follow-on operations: even including those in the original form... I don't know that this would be sufficient; in the contact mech purpose example it is somewhat common (and encouraged...) to want to add multiple purposes to a single contact mech, necessitation going back to the same screen repeatedly

In previous discussions on this one pattern that I've heard that looks good is:

1. a button that saves and comes back to the same screen
2. a save that goes back to the previous screen,
3. a cancel that goes back to the previous screen.

The trick is that all of these are needed (and in current Save/Go Back pattern #2 is missing), but the labels to use on them are tricky... So, maybe we can center our discussion on that, ie the labels to use for numbers 1, 2, and 3.

Here is one proposal:

1: "Save"
2: "Save and Continue"
3: "Cancel"

I'm not totally sure about those... would they be confusing?

-David


Ray Barlow wrote:

> I have certainly found users are confused by this particular interface
> especially on the ecommerce side, where you don't get to train the user
> when creating addresses or card details. It does not progress the user
> to the next stage and often they press save again thinking it didn't
> work the first time and they are not sure they want to press "Go Back".
> People are generally taught not to press the "Back" button and here we
> are saying "Go Back", they don't want to go backwards in the checkout
> process they are itching to give you their money!
>
> I think the rational is that 99% of forms/dialog act with an "OK" and
> "Cancel" button style of interface which the mind naturally applies to
> these screens and the user does not want to "Cancel" or "Go Back" which
> they see as heading the wrong way in the process and possibly undoing
> what they have just done.
>
> Personally I would like to see the save button automatically step the
> user onto the next screen, if there are no errors, and for the forms
> that require or offer additional information after the first save, such
> as contact mech purposes, these should be offered on the first screen so
> I can choose and submit in one screen that this is the primary phone
> number I'm creating. Much quicker than entering the number clicking
> save, next screen select purpose click add and then click go back to
> finish.
>
> I did once change the ecommerce process but it was 3 years ago which I'd
> need to look at to recall the solution I used. I see David has made a
> suggestion anyway so really this reply is a call for possible change to
> the standard currently used in OFBiz. Would people prefer the save to
> move to the next screen?
>
> Ray
>
> Leon Torres wrote:
>> Hi all,
>>
>> I'd like to get to the bottom of this issue:  Suppose you have a
>> re-usable form such as editcontactmech that is called from various
>> screens.  To get back to the screen the user came from, there is a [Go
>> Back] and [Save] link generated from a DONE_PAGE parameter that is
>> passed to editcontactmech.
>>
>> However, suppose instead of having [Go Back] and [Save], the
>> requirement is that the user is taken back to the originating screen
>> upon submitting the form. Currently, the only way I was able to
>> implement this was to have a special java event method called
>> donePageRequestHelper as follows,
>>
>>     <!-- call this request when you have a donePage that you want to
>> go to after finishing a service -->
>>     <request-map uri="donePageRequestHelper">
>>         <security https="true" auth="true"/>
>>         <event type="java" path="path.to.java"
>> invoke="donePageRequestHelper"/>
>>         <response name="viewContact" type="request-redirect"
>> value="viewContact"/>
>>         <response name="viewAccount" type="request-redirect"
>> value="viewAccount"/>
>>         <response name="viewLead" type="request-redirect"
>> value="viewLead"/>
>>         ...
>>     </request-map>
>>
>>
>>     public static String donePageRequestHelper(HttpServletRequest
>> request,      HttpServletResponse response) {
>>         String donePage = (String) request.getParameter("donePage");
>>         if (donePage == null) {
>>             donePage = "error";
>>         }
>>         return donePage;
>>     }
>>
>> The problem with this is that the request-redirect will end up adding
>> all the form parameters to the URL.  I see no way to resolve this with
>> the current RequestHandler, except maybe with a flag to prevent the
>> form POST data from being added to the GET parameter data.  That is,
>> it is only desired to pass along GET parameters to the redirect URL
>> from the original request.
>>
>> Any ideas?
>>
>> - Leon
>>

[Leon Torres-2]

It's worth to consider that Ajax will add a few extra options and render most of
the old-school methods of form flow with static web pages moot.

I've been working on these possibilities, and the one that stands out with the
most promise are in-page "formletts".  Imagine you want to edit an address
listed anywhere, say in select shipment method for an order.  You could click
the edit button and it will present a form to edit the contact mech directly
within the same page.  On completion, the form will go away.

- Leon



David E. Jones wrote:

>
> Yes, this is certainly one of the not so golden oldies that needs
> revisiting...
>
> In a web application I don't think the OK/Cancel paradigm is sufficient
> so I've been opposed to that from the beginning.
>
> Having the Save button automatically do a "Go Back" as well also seems
> confusing and I don't like it for 2 reasons:
>
> 1. the context of the operation is lost unless the following screen has
> clear indication of success and well as results of the operation done
> (like showing a ContactMech summary, etc)
>
> 2. as you mentioned with the follow-on operations: even including those
> in the original form... I don't know that this would be sufficient; in
> the contact mech purpose example it is somewhat common (and
> encouraged...) to want to add multiple purposes to a single contact
> mech, necessitation going back to the same screen repeatedly
>
> In previous discussions on this one pattern that I've heard that looks
> good is:
>
> 1. a button that saves and comes back to the same screen
> 2. a save that goes back to the previous screen, 3. a cancel that goes
> back to the previous screen.
>
> The trick is that all of these are needed (and in current Save/Go Back
> pattern #2 is missing), but the labels to use on them are tricky... So,
> maybe we can center our discussion on that, ie the labels to use for
> numbers 1, 2, and 3.
>
> Here is one proposal:
>
> 1: "Save"
> 2: "Save and Continue"
> 3: "Cancel"
>
> I'm not totally sure about those... would they be confusing?
>
> -David
>
> Ray Barlow wrote:
>> I have certainly found users are confused by this particular interface
>> especially on the ecommerce side, where you don't get to train the
>> user when creating addresses or card details. It does not progress the
>> user to the next stage and often they press save again thinking it
>> didn't work the first time and they are not sure they want to press
>> "Go Back". People are generally taught not to press the "Back" button
>> and here we are saying "Go Back", they don't want to go backwards in
>> the checkout process they are itching to give you their money!
>>
>> I think the rational is that 99% of forms/dialog act with an "OK" and
>> "Cancel" button style of interface which the mind naturally applies to
>> these screens and the user does not want to "Cancel" or "Go Back"
>> which they see as heading the wrong way in the process and possibly
>> undoing what they have just done.
>>
>> Personally I would like to see the save button automatically step the
>> user onto the next screen, if there are no errors, and for the forms
>> that require or offer additional information after the first save,
>> such as contact mech purposes, these should be offered on the first
>> screen so I can choose and submit in one screen that this is the
>> primary phone number I'm creating. Much quicker than entering the
>> number clicking save, next screen select purpose click add and then
>> click go back to finish.
>>
>> I did once change the ecommerce process but it was 3 years ago which
>> I'd need to look at to recall the solution I used. I see David has
>> made a suggestion anyway so really this reply is a call for possible
>> change to the standard currently used in OFBiz. Would people prefer
>> the save to move to the next screen?
>>
>> Ray
>>
>> Leon Torres wrote:
>>> Hi all,
>>>
>>> I'd like to get to the bottom of this issue:  Suppose you have a
>>> re-usable form such as editcontactmech that is called from various
>>> screens.  To get back to the screen the user came from, there is a
>>> [Go Back] and [Save] link generated from a DONE_PAGE parameter that
>>> is passed to editcontactmech.
>>>
>>> However, suppose instead of having [Go Back] and [Save], the
>>> requirement is that the user is taken back to the originating screen
>>> upon submitting the form. Currently, the only way I was able to
>>> implement this was to have a special java event method called
>>> donePageRequestHelper as follows,
>>>
>>>     <!-- call this request when you have a donePage that you want to
>>> go to after finishing a service -->
>>>     <request-map uri="donePageRequestHelper">
>>>         <security https="true" auth="true"/>
>>>         <event type="java" path="path.to.java"
>>> invoke="donePageRequestHelper"/>
>>>         <response name="viewContact" type="request-redirect"
>>> value="viewContact"/>
>>>         <response name="viewAccount" type="request-redirect"
>>> value="viewAccount"/>
>>>         <response name="viewLead" type="request-redirect"
>>> value="viewLead"/>
>>>         ...
>>>     </request-map>
>>>
>>>
>>>     public static String donePageRequestHelper(HttpServletRequest
>>> request,      HttpServletResponse response) {
>>>         String donePage = (String) request.getParameter("donePage");
>>>         if (donePage == null) {
>>>             donePage = "error";
>>>         }
>>>         return donePage;
>>>     }
>>>
>>> The problem with this is that the request-redirect will end up adding
>>> all the form parameters to the URL.  I see no way to resolve this
>>> with the current RequestHandler, except maybe with a flag to prevent
>>> the form POST data from being added to the GET parameter data.  That
>>> is, it is only desired to pass along GET parameters to the redirect
>>> URL from the original request.
>>>
>>> Any ideas?
>>>
>>> - Leon
>>>

[Daniel Kunkel]

Hi

I've heard from numerous customers who report having real difficulties
(read lost sales) with the off the shelf checkout procedure in OFBiz.

Rather than just changing the button labels we may be far better off
integrating the credit card information into the checkout screens.

Leon's formlettes could also be the answer.

Another possibility is a revolutionary change to the quick-checkout
procedure.

It could be simplified to handle the just the basic checkout information
used  for 95 (or more) percent of customers, only 1 shipping/billing
address, not a gift, pay with credit card etc.

Links can direct the user to the various stages of the normal checkout
process, or even the existing quick checkout screen that would handle
the more unusual needs of separate shipping/billing, other methods of
payment, etc.

Thanks

Daniel



On Sat, 2006-07-15 at 01:08 -0700, Leon Torres wrote:

> It's worth to consider that Ajax will add a few extra options and render most of
> the old-school methods of form flow with static web pages moot.
>
> I've been working on these possibilities, and the one that stands out with the
> most promise are in-page "formletts".  Imagine you want to edit an address
> listed anywhere, say in select shipment method for an order.  You could click
> the edit button and it will present a form to edit the contact mech directly
> within the same page.  On completion, the form will go away.
>
> - Leon
>
>
>
> David E. Jones wrote:
> >
> > Yes, this is certainly one of the not so golden oldies that needs
> > revisiting...
> >
> > In a web application I don't think the OK/Cancel paradigm is sufficient
> > so I've been opposed to that from the beginning.
> >
> > Having the Save button automatically do a "Go Back" as well also seems
> > confusing and I don't like it for 2 reasons:
> >
> > 1. the context of the operation is lost unless the following screen has
> > clear indication of success and well as results of the operation done
> > (like showing a ContactMech summary, etc)
> >
> > 2. as you mentioned with the follow-on operations: even including those
> > in the original form... I don't know that this would be sufficient; in
> > the contact mech purpose example it is somewhat common (and
> > encouraged...) to want to add multiple purposes to a single contact
> > mech, necessitation going back to the same screen repeatedly
> >
> > In previous discussions on this one pattern that I've heard that looks
> > good is:
> >
> > 1. a button that saves and comes back to the same screen
> > 2. a save that goes back to the previous screen, 3. a cancel that goes
> > back to the previous screen.
> >
> > The trick is that all of these are needed (and in current Save/Go Back
> > pattern #2 is missing), but the labels to use on them are tricky... So,
> > maybe we can center our discussion on that, ie the labels to use for
> > numbers 1, 2, and 3.
> >
> > Here is one proposal:
> >
> > 1: "Save"
> > 2: "Save and Continue"
> > 3: "Cancel"
> >
> > I'm not totally sure about those... would they be confusing?
> >
> > -David
> >
> > Ray Barlow wrote:
> >> I have certainly found users are confused by this particular interface
> >> especially on the ecommerce side, where you don't get to train the
> >> user when creating addresses or card details. It does not progress the
> >> user to the next stage and often they press save again thinking it
> >> didn't work the first time and they are not sure they want to press
> >> "Go Back". People are generally taught not to press the "Back" button
> >> and here we are saying "Go Back", they don't want to go backwards in
> >> the checkout process they are itching to give you their money!
> >>
> >> I think the rational is that 99% of forms/dialog act with an "OK" and
> >> "Cancel" button style of interface which the mind naturally applies to
> >> these screens and the user does not want to "Cancel" or "Go Back"
> >> which they see as heading the wrong way in the process and possibly
> >> undoing what they have just done.
> >>
> >> Personally I would like to see the save button automatically step the
> >> user onto the next screen, if there are no errors, and for the forms
> >> that require or offer additional information after the first save,
> >> such as contact mech purposes, these should be offered on the first
> >> screen so I can choose and submit in one screen that this is the
> >> primary phone number I'm creating. Much quicker than entering the
> >> number clicking save, next screen select purpose click add and then
> >> click go back to finish.
> >>
> >> I did once change the ecommerce process but it was 3 years ago which
> >> I'd need to look at to recall the solution I used. I see David has
> >> made a suggestion anyway so really this reply is a call for possible
> >> change to the standard currently used in OFBiz. Would people prefer
> >> the save to move to the next screen?
> >>
> >> Ray
> >>
> >> Leon Torres wrote:
> >>> Hi all,
> >>>
> >>> I'd like to get to the bottom of this issue:  Suppose you have a
> >>> re-usable form such as editcontactmech that is called from various
> >>> screens.  To get back to the screen the user came from, there is a
> >>> [Go Back] and [Save] link generated from a DONE_PAGE parameter that
> >>> is passed to editcontactmech.
> >>>
> >>> However, suppose instead of having [Go Back] and [Save], the
> >>> requirement is that the user is taken back to the originating screen
> >>> upon submitting the form. Currently, the only way I was able to
> >>> implement this was to have a special java event method called
> >>> donePageRequestHelper as follows,
> >>>
> >>>     <!-- call this request when you have a donePage that you want to
> >>> go to after finishing a service -->
> >>>     <request-map uri="donePageRequestHelper">
> >>>         <security https="true" auth="true"/>
> >>>         <event type="java" path="path.to.java"
> >>> invoke="donePageRequestHelper"/>
> >>>         <response name="viewContact" type="request-redirect"
> >>> value="viewContact"/>
> >>>         <response name="viewAccount" type="request-redirect"
> >>> value="viewAccount"/>
> >>>         <response name="viewLead" type="request-redirect"
> >>> value="viewLead"/>
> >>>         ...
> >>>     </request-map>
> >>>
> >>>
> >>>     public static String donePageRequestHelper(HttpServletRequest
> >>> request,      HttpServletResponse response) {
> >>>         String donePage = (String) request.getParameter("donePage");
> >>>         if (donePage == null) {
> >>>             donePage = "error";
> >>>         }
> >>>         return donePage;
> >>>     }
> >>>
> >>> The problem with this is that the request-redirect will end up adding
> >>> all the form parameters to the URL.  I see no way to resolve this
> >>> with the current RequestHandler, except maybe with a flag to prevent
> >>> the form POST data from being added to the GET parameter data.  That
> >>> is, it is only desired to pass along GET parameters to the redirect
> >>> URL from the original request.
> >>>
> >>> Any ideas?
> >>>
> >>> - Leon
> >>>

--
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           [hidden email]
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.SatelliteRadioZone.com
http://www.Cards-Visa.com       http://www.ColorGlasses.com
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

[Leon Torres-4]

Daniel Kunkel wrote:
>
> Another possibility is a revolutionary change to the quick-checkout
> procedure.


It was my understanding that the stock ecommerce checkout was more of a demo of
the flexibility of ofbiz and starting point for customization.

In any case, I think you're right:  We could re-organize the customer checkout
so that only the simplest common-denominator checkout steps are present.  Then
we can provide a way to activate the more advanced options.

For instance:  Google search.  The basic input box will be used 99% of the time
and the advanced search options are just one click away.

We could use some fancy Javascript UI here to keep the user in the same page
when exposing advanced functionality.  If the user wants to split the shipment,
she clicks on something and a form "unfolds" where the user can enter her split
preferences.  (Note that Ajax isn't necessary in this case, but we'd be using
one of the handy advanced UI tools that come with such frameworks.)

- Leon

[davidnwelton]

> In any case, I think you're right:  We could re-organize the customer checkout
> so that only the simplest common-denominator checkout steps are present.  Then
> we can provide a way to activate the more advanced options.

Talking very generically, I like that pattern a lot (as long as it's
clear that the advanced options really aren't used that often).
Present the simple thing as the easiest thing, and then give the user
a way to configure it or modify it if they need, but don't make
everyone look at all the options.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[BJ Freeman]

As a general input, The Store owners I work with, usually opt of single
page format.
this is the cart on the top, Billing and shipping side by side under the
cart. Shipping and special functions like coupons side by side under that.
Seems the Customers like it also, since the conversion rate seems to go up.

As a note the actual page is controlled by CSS for placement and visibility.

like on Downloadables, the Shipping does not show.

Shipping is filled in from the Billing if the customer checks it after
filling in the Billing.

with this, there is only changing the CSS.


Leon Torres sent the following on 7/17/2006 5:07 PM:

> Daniel Kunkel wrote:
>>
>> Another possibility is a revolutionary change to the quick-checkout
>> procedure.
>
>
> It was my understanding that the stock ecommerce checkout was more of a
> demo of
> the flexibility of ofbiz and starting point for customization.
>
> In any case, I think you're right:  We could re-organize the customer
> checkout
> so that only the simplest common-denominator checkout steps are
> present.  Then
> we can provide a way to activate the more advanced options.
>
> For instance:  Google search.  The basic input box will be used 99% of
> the time
> and the advanced search options are just one click away.
>
> We could use some fancy Javascript UI here to keep the user in the same
> page
> when exposing advanced functionality.  If the user wants to split the
> shipment,
> she clicks on something and a form "unfolds" where the user can enter
> her split
> preferences.  (Note that Ajax isn't necessary in this case, but we'd be
> using
> one of the handy advanced UI tools that come with such frameworks.)
>
> - Leon
>
>