New instance of form different from editable form / avoid labels

24 Jul 2013 - 11:25pm
51 weeks ago
7 replies
3119 reads
Petra Liverani
2008

Hi Everyone,

I'm designing an "ideal" transport incident management form and it occurred to me to make the "New Incident" form quite different from the "Editable Incident" form.

1. The Editable Incident form would display information entered into the New Incident form summarised in text format (rather than in the field format of the New Incident form) and thus use less space, allowing for more information to be displayed.

2. The Editable form would allow editing of single sections of the form and/or the entire form.

3. Labels, to a large degree would be dispensed with because the label information could entered into a field in grey and once information is entered it would generally be obvious what needs to be entered into the field.

I know this has been done but I can't think of any examples. I'd be grateful if people could advise me of special design terminology for this, literature on it, and examples.

Thanks in advance,
Petra

Comments

24 Jul 2013 - 11:55pm
Haskell
2013

Gmail has a nice take on this with their email composition panel (desktop site). It uses many of the methods you describe - grey labels within fields that disappear upon text entry, area controls that are hidden when the field group loses focus - to nice effect.

In a form group (e.g. the To, CC and BCC fields), the control are only visible when the group has focus. When blurred, the field is reduced to contact names and optional labels. In the Subject area, the label is grey and disappears when text is entered. It's a pretty cool little form, and there are some clever nuances.

5 Aug 2013 - 11:11pm
Petra Liverani
2008

Thanks for your reply, Michael, and sorry for the delay in replying. I saw your email but didn't make it back to the site until now. I guess it does have some clever nuances which I will keep in mind while also following Tyler's salutary advice below.

Regards,
Petra

25 Jul 2013 - 12:40am
Tyler Goelz
2013

I believe you're referring to watermark or placeholder (which can be found in the Twitter Bootstrap framework)

Labels in forms are generally important in order to keep the "communication" of the form going. If a user is editing something, removing the labels could lead to confusion. I can't tell you how many times I've been on a form that used placeholders, didn't have labels and prefilled my info. I end up having to cut and re-paste my info to realize what the input is asking.

The form losees context when it's prefilled with no labels. Here's and article that talks about placeholders and labels. http://www.pardot.com/faqs/forms/placeholders-and-labels/

My recommendation would be to forgo the placeholder all together and just use the labels to describe the input. (and of course prepop info on edits).

I hope this answers the question you were asking.

-TFoTG

5 Aug 2013 - 11:06pm
Petra Liverani
2008

Sorry for delay in thanking you, Tyler, for your salutary advice and link to article - I saw your email but didn't make it back to the site until now. I think I'll dispense with the placeholder idea unless I know there's no way the user could be confused.

Regards,
Petra

25 Jul 2013 - 6:31am
Jack L. Moffett
2005

Hi Petra,

Luke Wroblewski's book, Web Form Design: Filling in the Blanks, is a great source for guidance, best practices, and examples. In your case, I'd especially suggest the following chapters: 

4. Labels

5. Input Fields

11. Additional Inputs

25 Jul 2013 - 10:33am
Juan Lanus
2005

Hi Petra,

IMO the "update form same as new-item form" is a convenience for the developers and frequently an inconvenience for the users, sauf for the usually-very-simple input forms in the web. 
It might well happen that the update was quite a different transaction than the new item insertion. 

For example, certain changes in an existing item might trigger the need to undo things, like when (guessing without any background) a transport incident involved notifying the authorities of two different locations, and the user changes the second location, then the authorities of that second location need to be un-notified somehow. 

Any data that was stored in the database and has undergone further processing has to be pulled back. 

There is an inmutable principle of systems accessed by humans that states that each and every action on the UI needs a procedure to revert it (not necessarily by the original user; this is not the undo feature only available before submitting). You are entering this area.

My suggestion is to forget about the new-item form and to find out what are the things the users need to change. After, provide one or more forms so they can fulfill those goals. If this sounds much like UCD, it's bacause it is it.

If your system is complex, like an "enterprise" application, then also get Carolyne Jarrett's book "Forms that work" written after her multi-year experience moving online the UK administration UI.I think she is from Australia. 

--

Juan Lanus

25 Jul 2013 - 6:50pm
Petra Liverani
2008

Thanks very much Jack and Juan.

I went to Luke Wrobleski's book on amazon and among the comments on the Most Helpful Favorable Review there was a link to a very helpful article by Luke http://www.alistapart.com/articles/testing-accordion-forms on accordion forms - so now I know the terminology. There are many articles on accordion forms (quite a few on ixda even!) including this one:  http://www.ixda.org/node/31080.

Regards,
Petra

 

Syndicate content Get the feed