Good point.  Under no circumstances whatsoever should the user be expected
to do data entry for 50 items on a single web page unless they items all
happen to be simple checkboxes.  This is a known principal in
user-experience architecture and Web site usability. If you need some lab
data or something that backs this up, I can probably find something if I
dig around.

Data entry is a cumbersome process. Users must be incented through the
process by parsing the process itself into manageable chunks and giving
users motivation throughout.

Consider a "wizard"-based data entry metaphor to correct this issue.
Also, make sure that you give appropriate feedback to the user after each
wizard step.
Consider also adding a motivator and possibly even a "step-map" that shows
location in the overall data entry process.
If you really want to be aggresive, consider also allowing automatic save
of the current state so that the user can always pick up where they left
off on new sessions.

- Cody





"Galbreath, Mark" <[EMAIL PROTECTED]> on 02/06/2002 07:14:57 AM

Please respond to Struts Users Mailing List
      <[EMAIL PROTECTED]>
To:   'Struts Users Mailing List' <[EMAIL PROTECTED]>
cc:
Subject:  RE: speed of struts


50 fields in a form???  Me thinks the bug is in the design.

Cheers!
Mark

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 6:02 AM
To: [EMAIL PROTECTED]
Subject: RE: speed of struts


I had a form with lots of custom tags. When run under the Sun 1.3 JDK it
was
slow as molasses. Sun 1.2 JDK or IBM 1.3 was instantaneous. A few mailing
list posts pointed me to a bug in Sun's 1.3 having to do with nested
try/catch blocks in the compiled JSP.

Try your page under Sun 1.2 or the IBM JDK and see if it makes a
difference.

Lee


-----Original Message-----
From: Christopher Cheng [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 3:50 AM
To: Struts Users Mailing List
Subject: RE: speed of struts


My form does not have a lot of tag processing (acutally none) The time it
takes to load the page is proportional to the number of instances of form
objects appeared on the JSP.

For instance, outputting a radio set is A LOT slower than outputting a drop
down list since you just have to pass a collection to the "iterate", but
you
have to actually put all the <html:radio/> options on the JSP.

<html:select property="factors[4].rating">
<html:options collection="ratings" property="value" labelProperty="label"/>
</html:select>

<html:radio ...../>Option A
<html:radio ...../>Option A
<html:radio ...../>Option A
<html:radio ...../>Option A

-----Original Message-----
From: Pete Carapetyan [mailto:[EMAIL PROTECTED]]
Posted At: Wednesday, February 06, 2002 12:10 PM
Posted To: Struts
Conversation: speed of struts
Subject: Re: speed of struts


I have had the same problem on one very large form with lots of back end
tag
processing. Would be interested to know if anyone had performed any
profiling on similar situations to identify where the bottlenecks were.

Struts wrote:

> I found out that if I include a lot of html form fields in a form (over
50). The jsp pages seems to be awfully slow to load (almost 10 seconds). I
made it a little bit faster when I converted all radio button sets to drop
down list, still it is very slow. The speed to load up seems to
exponentially related to the number of form fields.
>
> Has anybody got the same problem?
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
Pete Carapetyan
http://datafundamentals.com
Java Development Services

Open standards technology for commercial profitability



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>




----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to