Error Handling Best Practices?

4 May 2005 - 3:07pm
8 years ago
5 replies
908 reads
Dan Brown
2004

IxD,
Can anyone point me to good examples of error handling in online
applications? We're looking to redesign some applications and would
like to see what others have done. The kinds of applications we're
working with are very complex and have a lot of skip logic.

Thanks,
-- Dan

--
www.greenonions.com ~ brownorama at gmail.com ~ (301) 801-4850 ~ Murray RIP

Comments

4 May 2005 - 4:05pm
Gerard Torenvliet
2004

Dan,

A handy little book you might want to refer to is "Defensive design
for the Web: How to improve error messages, help, forms, and other
crisis points".

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&s=books&n=507846

You probably know everything it says already, but it just organizes a
lot of that common sense into one place.

Regards,
-Gerard

--
Gerard Torenvliet
g.torenvliet at gmail.com

5 May 2005 - 7:01am
Dan Brown
2004

Thanks for the book suggestion, but I was literally looking for
examples. I need to show other people on my team how other sites do
the same things we're trying to do.

Any ideas? The kind of form we're working on is sort of like a tax
form: lots of internal dependencies and skip logic. It's also got some
funny business rules about "errors." Due to the nature of the form, we
can't validate all the inputted information, though we can warn users
about possible bad input.

I haven't seen many (any?) examples of this kind of error handling:
where errors come in several flavors of severity and the interface
treats them differently.

Thanks,
-- Dan

On 5/4/05, Gerard Torenvliet <g.torenvliet at gmail.com> wrote:
> Dan,
>
> A handy little book you might want to refer to is "Defensive design
> for the Web: How to improve error messages, help, forms, and other
> crisis points".
>
> 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&s=books&n=507846
>
> You probably know everything it says already, but it just organizes a
> lot of that common sense into one place.
>
> Regards,
> -Gerard
>
> --
> Gerard Torenvliet
> g.torenvliet at gmail.com
>

--
www.greenonions.com ~ brownorama at gmail.com ~ (301) 801-4850 ~ Murray RIP

5 May 2005 - 7:41am
Cheryl Garabet
2004

Dan,

Have you tried "Defensive Design for the Web"
(http://www.amazon.com/exec/obidos/ASIN/073571410X/37signals/103-1667543-4203060)?

I remember that the information used to be available freely on the
37signals site. I don't know how "meaty" it all is, but it might be worth a
glance.

Best,

Cheryl Garabet
Bilingual Website Technical Writer
Ontario Teachers' Pension Plan
Email: Cheryl_Garabet at otpp.com
Telephone: 416-730-3730

5 May 2005 - 9:50am
FelcanSmith, Mark
2004

> -----Original Message-----
> From: Dan Brown
> The kind of form we're working on is sort of like a tax
> form: lots of internal dependencies and skip logic. It's also got some
> funny business rules about "errors." Due to the nature of the form, we
> can't validate all the inputted information, though we can warn users
> about possible bad input.

Dan,

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*.

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.

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.

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.

We allow users to *save* their work, but do not allow them to *submit* until all errors have been corrected (obvious perhaps).

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.

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.

-Mark

6 Feb 2006 - 8:47am
nuritps
2010

Hi Mark,
I found a mail you wrote a while ago, and have a very specific question
regarding the solution you presented.
I'll be happy to receive other thoughts of course...

We have a few complex forms as well in our app and I was happy to discover
we use some of the same principles.

I wanted to ask regarding the position of the error message (for field
validation).
We present the message after clicking Submit but without refreshing the
page. The submit button is obviously at the bottom of the page, so the
message appears under the form. Still in most sites messages are at the top
(but after refresh) so I'm not sure.
Another problem we have with it is that the Print button is at the top. It
is possible to print the form before submitting, with all the information
filled in, but we check validation for the Print button and if there are
problems we present the error message... and yes we do so at the bottom :(

Solutions can be
- not to check validation before printing
- take the user to the bottom of the page automatically
- show some indication at the top of the form.

Love to hear what you do or what you think.

Thanks,
Nurit

Nurit Peres

: : nurit.peres at ams-sys.com
: : www.ams-sys.com

<partial>
-------------------

Subject: RE: [ID Discuss] Error Handling Best Practices?

....

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.

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.

We allow users to *save* their work, but do not allow them to *submit* until
all errors have been corrected (obvious perhaps).

-Mark

Syndicate content Get the feed