4

I keep going back and forth on this issue and wanted to get some other opinions.

We have a series of pages within a settings control panel. There are multiple modules within the pages, and each module can be saved independently.

Should the "SAVE" button on each module appear:

  1. Always appear enabled (right side of image)
  2. Only appear enabled when a change has been made (left + right images)
  3. Some other variant, such as not appearing until there is a change made (walked away from this idea)

enter image description here

enter image description here

Ben Brocka
  • 40,865
  • 10
  • 112
  • 183
Ramsey
  • 61
  • 1
  • 4
  • why not combine them? Development push backs? – Jung Lee Nov 01 '15 at 21:13
  • I tried to simplify this example—there are additional pages which have way too much varied content, so they were turned into individual modules to help 'chunk' relevant pieces of info. – Ramsey Nov 01 '15 at 21:55
  • Even if there were only 1 module — what would you recommend for the save button state? – Ramsey Nov 01 '15 at 22:10
  • Left is better because it provides 'some' type of feedback that a form has been saved through the disabled button. But it's an implicit feedback, and not everyone will know what the disabled button means. You can make it more explicit by displaying "Saved!" message either at the top, or in the button itself. You might find this thread relevant. http://ux.stackexchange.com/questions/15798/should-i-provide-feedback-from-a-save-button/ – Jung Lee Nov 01 '15 at 22:27
  • Hey! Thanks Jung. This actually isn't the full sequence. There is an animation that occurs to provide feedback.

    The root of the question I'm trying to ask:

    Should the SAVE button be disabled if the information has not been changed, or does it cause more confusion? (Let the user hit "SAVE" on a form that has not changed)

     – Ramsey Nov 02 '15 at 13:23
  • Disabled state is more informative, so I would side with that. Otherwise you can have users clicking Save when they aren't really necessary due to uncertainty in the UI. I would also make sure the system prompts the user to save if she tries to leave without saving. – Jung Lee Nov 02 '15 at 20:19

4 Answers4

2

Consider just getting rid of save button. Whenever user makes a change, just remember that change and update it. And then give user a non-modal receipt like a toast. It's a common modern way of GUI implementation for Settings changes, especially for web based products.

If you really want to have the save button, having one button makes more sense in your case, but make sure it's discoverable to users.

Also since your settings have multiple pages(sections), you can consider adding a navigation, most likely based on your section titles. So users can get an overview of settings and can easily drill down to a specific section at the same time.

Chris
  • 21
  • 2
  • Google Docs is a good example of this pattern--for a while they had a placebo save button but eventually they removed it. Though Google Docs is a single-entry sort of deal, can't think of immediate examples of multi-section autosaves, but I'm sure I've seen them. – Ben Brocka Jan 01 '16 at 19:32
0

I would suggest using multiple tabs per group and target each group while clicking on each tab. enter image description here Thus, your updated details can be saved in one go, SAVE button appears only if you change or update something.

Sknny
  • 1,332
  • 3
  • 13
  • 23
0

A different approach is to display the content plainly on the page as non-editable content (no dropdowns and textfields, just text) and add an 'edit' button to each section. If the user clicks this button you show all the textareas, dropdowns etc along with the 'Save' button and a 'Cancel' button.

This whole approach makes the user feel more at ease, you can view the page without being afraid of changing something accidentally. You only work on one section at a time and can even decide not to apply the changes.

I actually like the fact that you have little chunks of information, it's easier to digest that way.

Martyn
  • 2,348
  • 10
  • 22
0

If you want a user to get a perception that only one block will be saved, I would suggest Option 2. Keep "Save" button disabled unless a change is made.

If you keep all buttons active (Option 1), a user may make changes to both sections, 1 and 2, then expect to click "Save" inside one of the sections to save changes in both areas. If you choose to go the route of Option 1 then you need to make sure "Save" buttons save changes on the entire page, rather within only one section.

Additional UX improvements:

  1. Right now your design pattern for an actionable item looks identical to the group block heading, you may want to consider using an alternate design pattern for your CTA
  2. I've seen a few tools do auto-save when a user leaves a field. Such approach will allow you to eliminate the need of a "Save" button
Igorek
  • 1,813
  • 13
  • 21
  • Thanks, Igorek! The original concept leveraged a more async 'auto-save' approach as the user exits the field—but the dev effort + logic around sensitive areas like credit cards caused us to walk away from that idea.

    Definitely agreed about the CTA + the section header. With the limited color palette, perhaps we can explore a different shape to help differentiate.

     – Ramsey Nov 02 '15 at 13:26