Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

My company has a history of making pages which start out un-editable, and then only become editable after the user clicks an "Edit" button. On the first such page like this that made a lot of sense, because the non-editable version of the page also hid all of the un-filled parts of the form. On subsequent pages however, we don't have any such hiding, so the whole "edit button" paradigm seems pointless to me.

As far as I can tell, the only advantage of this style (vs. just starting with an editable form) is that it prevents the following scenario:

  1. user arrives at form
  2. user accidentally changes some information without realizing it
  3. user accidentally clicks save

and it seems to me that that scenario is rare enough that we shouldn't have to make every other user go through an extra button click (and the extra cognitive effort to find that button on the page).

Am I missing something? Is there a case to be made for the "edit button" that I don't see? Or if not, is there any chance anyone can point me to arguments against such a button (that I can then share with my co-workers)?

share|improve this question
    
How often is the form referenced versus how often is it edited? –  Jeremy T Nov 5 '13 at 19:26
    
Well there are multiple such forms, so it depends. That seems like half an answer already though; I could see a rule like "If a form is referenced at least twice as often as it is edited it should require a user action to be editable". –  machineghost Nov 5 '13 at 19:52
    
I think Jeremy's question is important because if these forms are opened to be presented or printed, having elements related to editing the data are usually not desired, so separating the view/present mode from the edit mode makes more sense. –  Kip Nov 5 '13 at 20:10
    
Apart from "accidental saves" there is a future trap if you ever implement auto-saving. –  Erics Nov 8 '13 at 11:32
add comment

2 Answers

up vote 6 down vote accepted

The proper way to go about this is to list out your use cases in priority order and then make your interface functionality fit the use cases.

If 90% of the visits to this page are for reference only, and the primary use case is "I want to see the information on this form". In such case, the edit fields just get in the way.

Accidental edits need to be factored in, but you already stated that those are negligible.

But if it's more like 50/50, then you have to decide which one you're going to prioritize; And that answers your question.

I might add, however, that there are some cases where you have a very low frequency use case, but it's very important. Maybe you have users that have to do this action over and over again (but the number of actions is small compared with the total number of user actions), and adding the extra click is going to slow them down substantially.

share|improve this answer
    
And in the case where it's more like 50/50, could you possibly use the path the user took to determine the default step? –  Leslie M Nov 5 '13 at 20:12
    
@LeslieM I try to avoid making pages look different depending on how the user got there. It all goes to predictability. If you must, I would prefer just segregating users and having different user groups get different versions. –  Jeremy T Nov 5 '13 at 20:24
3  
Was merely thinking that the path might determine whether a form was editable by default based how the user arrive. Say they had to Add a new account vs reviewing an existing account. Or different permissions exist based on the role. Having elements disabled/ enabled because of such predecessors can be smart design. Editable and non-editable forms can and should look slightly different, if only via disabled/enabled controls. And if you know this, then you don't have to annoy users who primary purpose is to edit, and you don't leave "reviewing" users at risk of inadvertent changes. –  Leslie M Nov 6 '13 at 0:10
add comment

Yes, there is a case for an edit button but it is quite specific, however, I have hit this case.

An interface I have developed uses a map as a way of entering a location point as part of a form. The map marked the point by allowing the map to be moved while a cross hair is used to mark the centre (and the map point to save). This was a better interface and easier development build than point and click point dropping.

We noticed that the central point on the map was quite specifically set and while we required a draggable feature to allow the map to be centred (alongside postcode search etc.) we had to stop this being accidentally moved and saved, as the process of setting a location could be fairly tricky, not to mention that another user may accidentally drag without knowing where the centre point was in the first place. They may also drag, realise, but have made many other edits that they want to lose with a refresh.

So, an activate button was implemented, which activated the draggable feature (though postcode etc. would still function).

What I think you can take from this example is that a form may have fields, particularly those accessed and edited by mice, which may well require an uneditable default state to avoid accidental editing and saving. I would ask the question field by field rather than for a whole form and also consider the likelihood of editing, both purposeful and accidental.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.