Form values turning to edit mode on click

7 Jan 2012 - 4:25am
2 years ago
6 replies
1491 reads
Shivanand R Yerva
2009

Hello,
I have a form with labels displayed on left hand side and values displayed on right hand side. When the user clicks on a value field it turns into an editable field. I would like to know the pros and cons of the usage of this design pattern? Attaching the screenshots for reference.

-Shivanand

 

form-field-view.png

form-field-edit.png

Comments

7 Jan 2012 - 2:39pm
briandils
2010

The pros are

  • Simplicity. No additional UI needed because you are double-loading a page element
  • Consistency. If every field behaves this way, then its easy to impliment this pattern over and over without thinking of unique solutions.

 

The cons are

  • Discoverability. This particular application of the pattern isn't common because the field doesn't look like it can be edited.
  • Lack of Contextual Design. Maybe this design pattern doesn't make sense for every field. Wouldn't you rather see a calendar widget for a date field rather than a simple click and edit field? It makes more sense to the task.

 

Its you're call here, but I think the cons far outweigh the pros and you should look to creating contexual solutions for each field type...

8 Jan 2012 - 9:37am
darkejon
2012

This is pretty unconventional, lIke te person above states, user will not realise this is editable. You would need to use some form of additional instructional device such as a 'edit' link on cell rollover appearing. But this is still a little hidden and the simplest solution by far will be to either have an Edit' button on the page to make ALL fields editable at once with a submit/cancel. Or all fields are always editable regardless, with a permanent submit/cancel control, and perhaps a browser notification if they modify a field and try to leave the page without saving changes.

This type of individual row editing functionality can be useful in some contexts, but I dont believe its the right choice in this particular example. This is much better suited to single title like fields, good example of which might be Google docs - changing the title of a document by clicking upon it.

Also you should always ask fo the password field to be repeated. As the user canopy see what tehy are typing, typos could easily occur locking the user out fo their own account.

8 Jan 2012 - 10:36am
Kivi Shapiro
2007

Alan Cooper promotes this pattern in About Face, as "Allow input wherever you have output" (http://www.google.ca/search?q=%22Allow+input+wherever+you+have+output%22).  You do have to make it very clear that the fields are editable though.

9 Jan 2012 - 9:01am
Kivi Shapiro
2007

About always repeating the password field:  that also is the subject of discussion.  On the IPhone, for instance, when you're typing into a password field, your most recent character is briefly visible but the rest are masked.  Another alternative approach is to include a checkbox to allow the user to determine whether they want the password field to be masked or not.  With patterns like these, it might not be necessary to repeat the password field.

For some of the previous discussion on the topic here on this list, see http://www.ixda.org/search/apachesolr_search/password.

9 Jan 2012 - 10:02am
AlokJain
2006

Shivanand,

I have extensively used this approach in one of my products - http://insightify.com - it's an online survey tool. Since surveys can be very long we wanted to provide a simple one page model where user can interact with the whole survey and inline editing is a great solution.

A few things on discoverability as (which is your biggest challenge):

a) If possible keep the focus on a field when the page loads, this tells the user that it is a form

b) On mouse over change the cursor to the text cursor (just tryuing doing a mouse over on any text field). Also add another visual indication like a light color outline on the field

c) For text areas, you'll ideally want an auto-expanding text area, other wise the view and edit transition would not be smooth.

d) Be very consistent across the app.

The other potential issue such a design beings is clarity on when is the data saved ? As the user moves away from the field, the field would go away and you'll display the text only. this indicates that the state is changed which could be read (by the user) as the data is also saved.  In Insightify we did auto-save. This I think is less relevant if you have small forms but if you have a workspace model as I have in Insightify, then auto-save pattern is very useful. Auto-save also has other considerations around undo etc , so expect to spend time on it. 

In another product that I am designing, which is not released yet, I am using a slightlightly different version of this. I am using the UI closer to how iOS works. Try out the mail app for instance in any iOS device. 

Hope this helps

Alok Jain

http://twitter.com/alokjain

10 Jan 2012 - 8:37am
Shivanand R Yerva
2009

Thank you all for your feedback!

Syndicate content Get the feed