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
