Error messages for edit-in-place forms

6 Nov 2008 - 9:53am
6 years ago
8 replies
844 reads
R Sengers
2008

I'm working on an Ajax app that will have edit-in-place forms (a.k.a. inline
editing). Page has read-only data; parts of the data are editable. User
chooses to edit a part; that part turns into an editable form. When user
saves changes, the form converts back to read-only data (this happens
without a page reload).

The fields in the forms are required. So if user leaves any blank, they need
to be challenged, and we need to let them know which fields are in question.
What's the best way to handle this?

We are reluctant to show an error message right above the form, because it
will push the form & other content on the page downward, creating a visual
"jumping" effect. (unless we overlay the error message over top of other
content on the page)

What are best practices for this? Good examples?

Thanks,
Rachel

Comments

6 Nov 2008 - 2:06pm
Loren Baxter
2007

If you don't want your content to shift around, your error messages really
can't take up any space. It would help to see the interface in question.
However, you can use effects like highlighting the fields in question
(change their border to red, background to light pink or something
similar). And overlays may not be too bad - especially if they are very
small and point to the correct form fields.

Be sure that you provide an explanation that there was an error somewhere on
the screen, preferably near the "submit" button that they pressed.

Loren

-----
http://acleandesign.com

On Thu, Nov 6, 2008 at 7:53 AM, Rachel <rachseng at gmail.com> wrote:

> I'm working on an Ajax app that will have edit-in-place forms (a.k.a.
> inline
> editing). Page has read-only data; parts of the data are editable. User
> chooses to edit a part; that part turns into an editable form. When user
> saves changes, the form converts back to read-only data (this happens
> without a page reload).
>
> The fields in the forms are required. So if user leaves any blank, they
> need
> to be challenged, and we need to let them know which fields are in
> question.
> What's the best way to handle this?
>
> We are reluctant to show an error message right above the form, because it
> will push the form & other content on the page downward, creating a visual
> "jumping" effect. (unless we overlay the error message over top of other
> content on the page)
>
> What are best practices for this? Good examples?
>
> Thanks,
> Rachel
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

6 Nov 2008 - 8:34pm
cfmdesigns
2004

I have seen cases where a space is allotted for where an error message
will go if it occurs. Designed well, users with no error never notice
that the space is there, it just integrates into the design. (I've
also seen this done poorly, of course where there's a big obvious
blank space.)

-- Jim
Via my iPhone

On Nov 6, 2008, at 7:53 AM, Rachel <rachseng at gmail.com> wrote:

> I'm working on an Ajax app that will have edit-in-place forms
> (a.k.a. inline
> editing). Page has read-only data; parts of the data are editable.
> User
> chooses to edit a part; that part turns into an editable form. When
> user
> saves changes, the form converts back to read-only data (this happens
> without a page reload).
>
> The fields in the forms are required. So if user leaves any blank,
> they need
> to be challenged, and we need to let them know which fields are in
> question.
> What's the best way to handle this?
>
> We are reluctant to show an error message right above the form,
> because it
> will push the form & other content on the page downward, creating a
> visual
> "jumping" effect. (unless we overlay the error message over top of
> other
> content on the page)
>
> What are best practices for this? Good examples?
>
> Thanks,
> Rachel
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

6 Nov 2008 - 2:17pm
Casey Edgeton
2008

On Thu, Nov 6, 2008 at 12:06 PM, Loren Baxter <loren.baxter at gmail.com>wrote:

> If you don't want your content to shift around, your error messages really
> can't take up any space. It would help to see the interface in question.
> However, you can use effects like highlighting the fields in question
> (change their border to red, background to light pink or something
> similar). And overlays may not be too bad - especially if they are very
> small and point to the correct form fields.
>
> Be sure that you provide an explanation that there was an error somewhere
> on
> the screen, preferably near the "submit" button that they pressed.
>
> Loren

A short message explaining what the error was could also be placed next to
the field in addition to highlighting it (depending on how much space you
have).

7 Nov 2008 - 7:04am
pyces
2007

The best way that several books (e.g., 37 Signals, and I believe Luke
Wroblewski's Web Form Design book has it as well) have shown to display
an error message is to use an error icon, such as an X or a ! (often
surrounded by a circle or triangle or diamond), and to the right of that
error icon, display a message above the incorrect field. If there is no
room to display it above the incorrect field, you could put it the the
right if there are no formatting hints in the way. You could also
surround the entire error message and field with a red outline to make
it really stand out.

To help avoid an error, have a forgiving format, (for example, allow
phone numbers with no spaces, spaces, hyphens, parentheses) or if that
is not possible given your database or the code, then provide a
formatting hint (e.g., xxx-xxx-xxxx) to the right in gray text or
underneath, depending on space constraints.

Highlighting the fields is good, but color shouldn't be the only way
that you convey information to your users. Red-green color-blind people
might miss the highlighting distinction (they see red and pink as shades
of brown).

Also, make sure that you indicate required fields (a standard is with
bold and asterisks) to highlight that distinction, to help avoid errors
occurring in the first place.

Hope that helps.

Courtney
Senior Usability Analyst

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Rachel
Sent: Thursday, November 06, 2008 10:53 AM
To: discuss at ixda.org
Subject: [IxDA Discuss] Error messages for edit-in-place forms

I'm working on an Ajax app that will have edit-in-place forms (a.k.a.
inline
editing). Page has read-only data; parts of the data are editable. User
chooses to edit a part; that part turns into an editable form. When user
saves changes, the form converts back to read-only data (this happens
without a page reload).

The fields in the forms are required. So if user leaves any blank, they
need
to be challenged, and we need to let them know which fields are in
question.
What's the best way to handle this?

We are reluctant to show an error message right above the form, because
it
will push the form & other content on the page downward, creating a
visual
"jumping" effect. (unless we overlay the error message over top of other
content on the page)

What are best practices for this? Good examples?

Thanks,
Rachel
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

6 Nov 2008 - 11:06am
enelson
2008

I recommend Luke Wroblewski's book
http://www.rosenfeldmedia.com/books/webforms/
as a source of best practices and examples. I find it a valuable
reference in my work.

Luke is giving an online course Nov. 13 that includes a copy of the
book. The course is described on the above web page.

Esther

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=35328

6 Nov 2008 - 8:40pm
R Sengers
2008

Thanks to everyone for your ideas so far. More ideas are welcome, too!

Space is really tight, so I'm not sure we can allot room for a message
(unless the message appears in an overlay)

Olga, when you say inline field validation, do you mean a popup overlay
message right above the field, which would appear as soon as they leave
focus on a field, after leaving it blank?

Thanks
Rachel

On Thu, Nov 6, 2008 at 9:34 PM, Jim Drew wrote:

> I have seen cases where a space is allotted for where an error message will
> go if it occurs. Designed well, users with no error never notice that the
> space is there, it just integrates into the design. (I've also seen this
> done poorly, of course where there's a big obvious blank space.)
>
>
>

7 Nov 2008 - 9:34am
Gregory McClendon
2008

Without seeing your interface this is tough, but one suggestion would
be to use the field itself to display the error message. Your note
leads me to believe that your only validation is for a required
field. If that is the case, this idea would work, otherwise I would
explore some type of overlay.

Typically edit-in-pace has a simple action to invoke, like clicking
on a section of text. Then that text is encapsulated in a textbox
allowing the user to type. The change is committed by either a loss
of focus on the textbox or with a dedicated save button (that only
becomes visible once the "edit-in-place" is invoked). So... if you
absolutely have no space at all, use your textbox to display your
error message. You probably have enough space for the editable text
to have a "This field is required" etc...I would set a different
color for this message and have it go away when the user returns
focus to the textbox (similar to a hint textbox, that would contain
light colored instructions like "Enter your name" that go away once
the user put focus on the textbox).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=35328

7 Nov 2008 - 8:14pm
Oleh Kovalchuke
2006

There is the first time for everything: no one has called me Olga before.

Yes, by "inline" I meant validation on field blur. The "Required!" message
can be delivered in many ways. I think Gregory's idea of placing suggestion
inside the field itself is worth testing.

--
Oleh Kovalchuke
Interaction Design is design of time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On Thu, Nov 6, 2008 at 8:40 PM, Rachel <rachseng at gmail.com> wrote:

> Thanks to everyone for your ideas so far. More ideas are welcome, too!
>
> Space is really tight, so I'm not sure we can allot room for a message
> (unless the message appears in an overlay)
>
> Olga, when you say inline field validation, do you mean a popup overlay
> message right above the field, which would appear as soon as they leave
> focus on a field, after leaving it blank?
>
> Thanks
> Rachel
>
>
> On Thu, Nov 6, 2008 at 9:34 PM, Jim Drew wrote:
>
> > I have seen cases where a space is allotted for where an error message
> will
> > go if it occurs. Designed well, users with no error never notice that the
> > space is there, it just integrates into the design. (I've also seen this
> > done poorly, of course where there's a big obvious blank space.)
> >
> >
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

Syndicate content Get the feed