1

I am working on designing a standard for how overwrites should be handled on our software. I have come up with a couple different options for when a user needs to make changes to values that they have already entered previously. Please let me know what you think, or if you know of best practices for handling this.

enter image description here

  • The first field in each option is just showing what will happen if the user selects the checkbox. So yes the user is allowed to change any fields. Something I also want to mention is if the user were to check the update checkbox then clear out the field they will be changing the value to null. Same goes for the Radio Set example if they were to click the second option and leave the option blank it would make the value null. – L. Lemmer Jun 12 '17 at 15:45
1

Allow for actual in-line editing

There may be some technical constraints that are not obvious from your question, but all these options seem over-engineered.

You used the 'in-line' editing tag, but then describe examples one step removed from in-line editing.

Drop Down Value (Left Example Below)

  • Show value in a drop down selector
  • Allow user to select a new value.
  • When value differs from stored value, show "Update"button and "Cancel" link.

Text Input (Right Example Below)

  • Allow for direct editing (deletion/addition) of values
  • When value differs from stored value, show "Update"button and "Cancel" link.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

1

All of your options seem unnecessarily complex and widget-heavy: some of them wind up displaying the same field as many as four times on the same screen. I'm not at all sure what purpose is served by duplicating the form in two columns in all the designs.

(Edit: On second look, I see that the "Building" field consistently has different information in each column, while the others don't -- so unless that's just an artifact in the mockup, maybe there's some purpose to this that isn't being effectively communicated by the design.)

I'd suggest radically simplifying this: display all the fields as editable inputs from the very beginning, or if edits are a much less common task than simply viewing the data, use a single toggle to switch between read-only and editable for the entire form at once. Individual edit toggles for each field just unnecessarily requires lots of extra clicks for the user.

That, alone, would be sufficient for most cases. Some nice-to-have frills might be

  • Highlight individual fields that the user has edited (triggered by the fact that the user changed the contents of that field; no additional interaction needs to be demanded of the user here.)
  • Include a 'revert' (or 'cancel' or 'undo') button once a field has been changed (this reinforces the indication of which fields were changed and which were not, and allows the user to easily undo a mistake without reverting the entire form. As above, just show this button automatically if the field changes, no extra clicks required from the user.)

So in this example, the user has changed the "assignment type" field, but left the others at their original values:

enter image description here

If there's some reason why in your particular application it would be useful for the user to be able to easily compare before-and-after values before committing their changes, then your two-column layout might be useful: left column would be the original values (as readonly text), right column the input fields allowing changes. In this case, too, either show both columns all the time, or make that second column visible based on a single 'edit' toggle for the entire form, not for individual fields.

(In all of this, I'm assuming that there's a "save" button somewhere down below that will commit the user's changes. If instead you're capturing and storing new user input on a field-by-field basis, then use the same general approach as in my little screenshot sample, but with paired "save" and "cancel" buttons automatically appearing as each edit is made. Or if the changes are low-stakes -- meaning it's acceptable for the user to accidentally publish the wrong info into the system for a moment before they realize their mistake and correct it -- skip the 'save' button and just commit changes automatically on field blur (with a transient indicator to inform the user that you've done so.)

1

There have been some good answers already, though if it's important to see what fields will be updated, I've seen another pattern work well also.

Allow "object" to enter an edit mode, then distinguish which fields will be updated by showing the field bold and with an (optional) asterisk to indicate unsaved changes.

Additionally, you could include the old value nearby, styled in an "expired" kind of look (lower contrast, strikethrough).

mockup

download bmml source – Wireframes created with Balsamiq Mockups

0

Why does the user need to tell which fields were updated? Can't the software compare to the previous values and tell which one were updated? If it's good for the user to clearly have control over what is being updated or not, I suggest the interface shows only an input text field to the (optional) new value and next to it, a static label showing the previous value. This label can be shown only next to values that were changed, so user can easly tell what editions are being done.

I also suggest to include in the standard a reminder to handle the empty values. When the user erases an existing value, will the software replace the previous value with empty or will it ignore the change? And will the software display correctly the empty value? What about a value that has only blank spaces? Programmers not always bear this in mind and that affects the user experience.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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