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
