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 [EMAIL PROTECTED]
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
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
