IxDA - Comments for "Error Handling Best Practices?"http://www.ixda.org/node/22380
Comments for "Error Handling Best Practices?"enError Handling Best Practices?http://www.ixda.org/node/22380#comment-74426
<p>Hi Mark,<br />
I found a mail you wrote a while ago, and have a very specific question<br />
regarding the solution you presented.<br />
I'll be happy to receive other thoughts of course...</p>
<p>We have a few complex forms as well in our app and I was happy to discover<br />
we use some of the same principles.</p>
<p>I wanted to ask regarding the position of the error message (for field<br />
validation).<br />
We present the message after clicking Submit but without refreshing the<br />
page. The submit button is obviously at the bottom of the page, so the<br />
message appears under the form. Still in most sites messages are at the top<br />
(but after refresh) so I'm not sure.<br />
Another problem we have with it is that the Print button is at the top. It<br />
is possible to print the form before submitting, with all the information<br />
filled in, but we check validation for the Print button and if there are<br />
problems we present the error message... and yes we do so at the bottom :(</p>
<p>Solutions can be<br />
- not to check validation before printing<br />
- take the user to the bottom of the page automatically<br />
- show some indication at the top of the form.</p>
<p>Love to hear what you do or what you think.</p>
<p>Thanks,<br />
Nurit</p>
<p>Nurit Peres</p>
<p>:<i> : <A href="http://lists.interactiondesigners.com/listinfo.cgi/discuss-interactiondesigners.com">nurit.peres at ams-sys.com</a><br />
</i>:<i> : <a href="http://www.ams-sys.com" title="www.ams-sys.com">www.ams-sys.com</a><br />
</i></p>
<p>&lt;partial&gt;<br />
-------------------</p>
<p>Subject: RE: [ID Discuss] Error Handling Best Practices?</p>
<p>....</p>
<p>We've got several apps that are complex-form based, all contain branching<br />
and skip logic to account for users only being able to complete certain<br />
aspects, based on how much time that have to work on this particular form,<br />
the availability of information that needs to be input, as well as to<br />
account for process interruptions. (these are primarily agents filling out<br />
life insurance applications online). We offer a non-linear path through the<br />
content, allowing partial input on form *chunks*, but require complete field<br />
entries. </p>
<p>When the user navigates to the form component that has the high-level alert,<br />
they will see a summary message, as well as detailed information at the<br />
field level indicating the issue (error or information message) that is<br />
triggering the high-level alert.</p>
<p>We allow users to *save* their work, but do not allow them to *submit* until<br />
all errors have been corrected (obvious perhaps).</p>
<p>-Mark</p>
Mon, 06 Feb 2006 13:47:23 +0000nuritpscomment 74426 at http://www.ixda.orgError Handling Best Practices?http://www.ixda.org/node/22380#comment-72306
<p>&gt;<i> -----Original Message-----<br />
</i>&gt;<i> From: Dan Brown<br />
</i>&gt;<i> The kind of form we're working on is sort of like a tax<br />
</i>&gt;<i> form: lots of internal dependencies and skip logic. It's also got some<br />
</i>&gt;<i> funny business rules about &quot;errors.&quot; Due to the nature of the form, we<br />
</i>&gt;<i> can't validate all the inputted information, though we can warn users<br />
</i>&gt;<i> about possible bad input.<br />
</i><br />
Dan,</p>
<p>Couple things, we've recently gone through several areas of our apps and implemented a more robust messaging scheme. We're differentiating between true *error* messages, and information messages. This isn't implemented in stone, that is, the guidelines we've set up align system or data integrity issues w/ errors, and most other messaging to the user (notifications, alerts, etc.) as information messages. Prior to this effort our users only, ever, saw *error* messages, even when they should have been simply *notified*.</p>
<p>We've got several apps that are complex-form based, all contain branching and skip logic to account for users only being able to complete certain aspects, based on how much time that have to work on this particular form, the availability of information that needs to be input, as well as to account for process interruptions. (these are primarily agents filling out life insurance applications online). We offer a non-linear path through the content, allowing partial input on form *chunks*, but require complete field entries. </p>
<p>We've devised a messaging scheme that logs and visually indicates; which form components are completed and are valid, which are incomplete, and which components have invalid data entered. This is a high-level alert system.</p>
<p>When the user navigates to the form component that has the high-level alert, they will see a summary message, as well as detailed information at the field level indicating the issue (error or information message) that is triggering the high-level alert.</p>
<p>We allow users to *save* their work, but do not allow them to *submit* until all errors have been corrected (obvious perhaps).</p>
<p>We list the form components in column that is ever-present and acts as the navigation component for the user to access the form contents. We also assign validity icons to indicate which components need to be looked at.</p>
<p>I wish I could share a visual, it would be much easier. If this sounds like it could work, contact me off-list and I'll see what I can do about visualizing this for you.</p>
<p>-Mark</p>
Thu, 05 May 2005 14:50:24 +0000FelcanSmith, Markcomment 72306 at http://www.ixda.orgError Handling Best Practices?http://www.ixda.org/node/22380#comment-72305
<p>Dan,</p>
<p>Have you tried &quot;Defensive Design for the Web&quot;<br />
(<A href="http://www.amazon.com/exec/obidos/ASIN/073571410X/37signals/103-1667543-4203060">http://www.amazon.com/exec/obidos/ASIN/073571410X/37signals/103-1667543-4203060</a>)?</p>
<p>I remember that the information used to be available freely on the<br />
37signals site. I don't know how &quot;meaty&quot; it all is, but it might be worth a<br />
glance.</p>
<p>Best,</p>
<p>Cheryl Garabet<br />
Bilingual Website Technical Writer<br />
Ontario Teachers' Pension Plan<br />
Email: <A href="http://lists.interactiondesigners.com/listinfo.cgi/discuss-interactiondesigners.com">Cheryl_Garabet at otpp.com</a><br />
Telephone: 416-730-3730</p>
Thu, 05 May 2005 12:41:12 +0000Cheryl Garabetcomment 72305 at http://www.ixda.orgError Handling Best Practices?http://www.ixda.org/node/22380#comment-72304
<p>Thanks for the book suggestion, but I was literally looking for<br />
examples. I need to show other people on my team how other sites do<br />
the same things we're trying to do.</p>
<p>Any ideas? The kind of form we're working on is sort of like a tax<br />
form: lots of internal dependencies and skip logic. It's also got some<br />
funny business rules about &quot;errors.&quot; Due to the nature of the form, we<br />
can't validate all the inputted information, though we can warn users<br />
about possible bad input.</p>
<p>I haven't seen many (any?) examples of this kind of error handling:<br />
where errors come in several flavors of severity and the interface<br />
treats them differently.</p>
<p>Thanks,<br />
-- Dan</p>
<p>On 5/4/05, Gerard Torenvliet &lt;<A href="http://lists.interactiondesigners.com/listinfo.cgi/discuss-interactiondesigners.com">g.torenvliet at gmail.com</a>&gt; wrote:<br />
&gt;<i> Dan,<br />
</i>&gt;<i><br />
</i>&gt;<i> A handy little book you might want to refer to is &quot;Defensive design<br />
</i>&gt;<i> for the Web: How to improve error messages, help, forms, and other<br />
</i>&gt;<i> crisis points&quot;.<br />
</i>&gt;<i><br />
</i>&gt;<i> <A href="http://www.amazon.com/exec/obidos/tg/detail/-/073571410X/qid=1115240607/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-1673605-6504016?v=glance&amp;s=books&amp;n=507846">http://www.amazon.com/exec/obidos/tg/detail/-/073571410X/qid=1115240607/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-1673605-6504016?v=glance&amp;s=books&amp;n=507846</a><br />
</i>&gt;<i><br />
</i>&gt;<i> You probably know everything it says already, but it just organizes a<br />
</i>&gt;<i> lot of that common sense into one place.<br />
</i>&gt;<i><br />
</i>&gt;<i> Regards,<br />
</i>&gt;<i> -Gerard<br />
</i>&gt;<i><br />
</i>&gt;<i> --<br />
</i>&gt;<i> Gerard Torenvliet<br />
</i>&gt;<i> <A href="http://lists.interactiondesigners.com/listinfo.cgi/discuss-interactiondesigners.com">g.torenvliet at gmail.com</a><br />
</i>&gt;<i><br />
</i></p>
<p>--<br />
<a href="http://www.greenonions.com" title="www.greenonions.com">www.greenonions.com</a> ~ <A href="http://lists.interactiondesigners.com/listinfo.cgi/discuss-interactiondesigners.com">brownorama at gmail.com</a> ~ (301) 801-4850 ~ Murray RIP</p>
Thu, 05 May 2005 12:01:55 +0000Dan Browncomment 72304 at http://www.ixda.orgError Handling Best Practices?http://www.ixda.org/node/22380#comment-72300
<p>Dan,</p>
<p>A handy little book you might want to refer to is &quot;Defensive design<br />
for the Web: How to improve error messages, help, forms, and other<br />
crisis points&quot;.</p>
<p><A href="http://www.amazon.com/exec/obidos/tg/detail/-/073571410X/qid=1115240607/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-1673605-6504016?v=glance&amp;s=books&amp;n=507846">http://www.amazon.com/exec/obidos/tg/detail/-/073571410X/qid=1115240607/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-1673605-6504016?v=glance&amp;s=books&amp;n=507846</a></p>
<p>You probably know everything it says already, but it just organizes a<br />
lot of that common sense into one place.</p>
<p>Regards,<br />
-Gerard</p>
<p>--<br />
Gerard Torenvliet<br />
<A href="http://lists.interactiondesigners.com/listinfo.cgi/discuss-interactiondesigners.com">g.torenvliet at gmail.com</a></p>
Wed, 04 May 2005 21:05:29 +0000Gerard Torenvlietcomment 72300 at http://www.ixda.org