Nested edit states. What to do when edits are save-able at local and global level?

Question

We are making a solution where a user is supposed to evaluate a number of requirements and laws. These evaluations all happen on one page, and the requirement/law is evaluated one at at time - all the information on the page is piled up and saved with a click on Save Changes, both per client request and by analogy with a previous system.

The law/requirement is shown to the left and the evaluation (how the law is followed, etc) is filled in on the right. Each have a few pieces of data, which for the evaluation means a few input fields.

^{download bmml source – Wireframes created with Balsamiq Mockups}

However, while laws are predetermined, requirements can also be added by this same user, along with its evaluation, and the requirement can be edited. Leaving aside issues of data integrity (there will be an audit trail), we have a problem with the appearance of "nested edit states".

It is our client's inclination to show the requirement as non-editable text, similar to the way laws are presented, both for consistency and readability (not having to scroll in a text box). This invites adding an edit button to toggle edit mode just for the requirement box, and show input fields at that point. However, this comes with a bunch of undesirable consequences.

^{download bmml source}

^{download bmml source}

The rest of the page is already perpetually in edit mode, and being able to commit a certain part of it may mistakenly convey that any changes are immediately saved to the database (they aren't).

We have looked into inline edit/click to edit, but it seems to invite being able to do so for the laws, too, which you can't, and also asks the question why all of the forms on the rest of the page (the actual evaluation fields) are not designed in the same way. Additionally, it takes extra work to make tabbing work. Click to edit makes sense for single, seldom changed fields, but we are talking about three or four fields, and it would be pedagogical to show them all as editable at once.

The biggest problem is that it just seems off to have nested states with different lifetimes, where you can commit or discard some changes in a way that has no parallel in the rest of the page.

My best hunch right now is to hoist the edit requirement functionality into a modal, which although it may seem clunky, is at least more explicit about the nested states. But this seems like a bit of a frankenpattern in general. Is there a clearer solution that I am missing, or would things work out just fine if I just relaxed some part of this? The earlier system just had all fields editable at all time, which avoided this problem - is that still the best way to go?

Update: We've gotten great answers and the wide variety of the solutions has also told us something about the difficulty of picking one that feels reasonably natural to everyone. As it stands, our current thinking is:

1. If at all palatable, just break up the entering of new requirements into another page. Requirements and laws will still be visible on this page (since it is necessary to evaluate them), but editing or entering new ones will not be possible.

2. If not, we will push for making the requirements editable in situ, without a trigger, to avoid the extra state.

3. If not even that is workable, we will promote the editing of the requirement to a modal, with "update" and "discard" as the actions, to make the state clearly ephemeral.

Many people pointed out the ambiguity of what the Call To Action was, and how it makes the page more involved (and creates these sorts of questions). Some other people questioned the apparent influence of our client's inclination. The client is asking us to solve their problem for them and it is incumbent on us to find the right solution, so the natural order is for things to sometimes take a different situation. However, the situation and understanding is not always that pure and this site is filled with people who manage this tension daily.

I don't know where we'll end up but all answers have been very helpful. The first option wasn't proposed as an answer but is in a way the natural conclusion of demanding that the Call To Action be clear - give them separate pages, where they can be clear. Permissions will likely demand that only some people can enter requirements, so it would be completely necessary from this point.

The bounty and the accepted answer goes to Assimiz's answer, which was the first answer to propose our second option. For anyone who finds themselves in this sort of situation, I think the take-away is that while there are ways to solve this problem neatly, it is a sign of a cognitive burden, of being able to mess with things that you really shouldn't be able to mess with at that point in time.

Update 2: After some discussion, the client agreed to the first option above - to split the page into two pages, where one is to manage requirements and one is to evaluate laws and requirements.

Answer 1

"The earlier system just had all fields editable at all time, which avoided this problem - is that still the best way to go?"

Yes.

What is the difference between the fields of a requirement to the fields of its evaluation? - None. The evaluation fields are also "saved" locally and you do not have 'Save' and 'Discard' buttons for them, and that's because all fields are saved locally by nature.

So, it looks you are trying to solve a problem which could have been avoided in the first place. There should be single meaning to 'Save', as you suggest: I have done with my work for now, please compile it all and make my changes permanent. All other changes, between 'Save'-s are assumed to be local/temporary. I would not mess with this legacy, simple and straight forward method.

Finally, the clearer solution which you have (not) missed is: Discard the Requirements 'Edit' mode. Make its fields editable at all time, just like the evaluation fields.

Answer 2

I think you can get close with just a couple of changes from where you are now.

Have a different and informative CTA for the requirements

Currently you have 'Save' (local) and 'Save all changes' (global). This seems potentially confusing.

If you changed the CTA to something like the following, the user would be made aware that this change is local, not global.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Replicate the 'must complete' functionality of a modal, without switching modes

The main point of moving things into the modal is that the user is forced to interact before moving on, but it should be possible to replicate this process without the switch in modes.

Once the user has clicked to Edit something, carrying out any other action on the page (browser back, use of nav, click to edit else where, click to Save All) results in a browser warning. Something like:

^{download bmml source}

Having written the copy in this wireframe, it's seems clear that a little more work is needed on the verbs (Save, Edit, Change, Update) for clarity and consistency, but I think the point is there.

A frequent user should only need to receive this warning a small number of times before they understand the 'once started much be finished' nature of the interaction.

Answer 3

I think modal could be an overkill, as it will take the focus away from the page - and moreover its not justified for something like an edit function in the context of the application. Take a look at the below suggested flow:

1) Initially, the user is visually shown which are the editable vs non editable categories. As seen, Reqs are shown to be editable, in the left most column. This will ensure good onboarding of the user in terms of what he/she could expect.

2) Next, note how the LawA preview clearly mentions that this category is non editable.

3) Now, see how the UI may look for the Editable categories, like Reqs - note how it clearly says "click to edit req a", and hence maintaining consistency of UI with the law items.

4) Now, say user opts to edit req a - then there are clear option to "Save edits" or "Undo Edits" which clearly shows that these actions apply to the editable fields only and are local to that window/section.

5) Undo helps in giving more user control to the edit section.

6) Save All Changes - as obvious, saves the entire information.

Answer 4

What is the ultimate goal for the user?

• Evaluate the Law?

• Edit the Requirement?

• Edit and Evaluate?

I suspect the ultimate goal is to just Evaluate, and if so this should be the primary Call to Action trigger.

I also suspect that Editing the Requirement is an occasional supplementary activity so it's trigger needs to be very different to the primary trigger to ensure there is no confusion between the two tasks.

Answer 5

The solution I would use here is fairly simple- pull out the nested edit unto a modal window. I've also made some modifications to try and address some of the slight UX issues in the original mockups.

^{download bmml source – Wireframes created with Balsamiq Mockups}

(Pretend that the above mockup is presented beneath the grey overlay)

^{download bmml source}

If you're already dealing with multiple windows and feel like this is overkill, another option would be to have individual edit pencils next to each of the headers in the Requirement group box. When clicked, the corresponding field becomes editable, and when they hit enter/click out/make a selection the field reverts back to being uneditable.

Answer 6

This is a more common problem than the number of questions that have been asked about it, so I think it is a good place to summarize a couple of key points that may help you to determine what the best combination of strategies might be:

• Labelling of the call-to-action: the wording that you use can play a small part to address this issue. I know that people don't like long label on buttons or links, but it is an easy way to indicate what people are saving and whether it is a local or global save (e.g. save/edit versus a submit action).
• Notification or response from action: again this is using text appropriate (i.e. at the right time and context) that is used to let the users know exactly what is saved and where. Combined with the right labelling of the call-to-action buttons/triggers will reinforce this fact.
• Layout and presentation of content: I think this one is slightly more difficult to do well as you may have more constraints from the business rules or technical requirements, but again if done well it will allow you to implement the labelling of call-to-action and notifications in an easy-to-understand manner. The groupings will allow people to easily associate specific content with the action, so it enhances the effect of other strategies.
• Visual and interaction design of content: This is probably the riskier of the strategies, but can potentially work well independently of other strategies or be combined for greater effect. An example might be to encode the state of the data with different tags or status flags, so that users have a visual indication of the interaction and states of the information. It might take a little bit getting used to at first because it is not a common strategy or implementation decision, but it can be learned easily if you can reinforce the behaviour with other design elements.

Answer 7

I see only three valid options here which are listed below in order of preference :

1. Enable/Disable fields. When the user clicks on a requirement enable the description fields, make them editable. When the user clicks on a law, disable them. The requirement changes will be saved when the "Save all changes" is clicked.

I know that your client said :

It is our client's inclination to show the requirement as non-editable text, similar to the way laws are presented, both for consistency and readability (not having to scroll in a text box).

but I will disagree (users are not always right). There is no issue of consistency since requirements are editable and laws are not. The readability argument is not correct either, if you design your editable text box correctly.

^{download bmml source – Wireframes created with Balsamiq Mockups}

2. Edit mode toggle. When the user clicks on a requirement, a toggle will appear allowing the user to switch between edit/display mode. The default value of the togle will be "OFF"(display mode). The toggle will not save anything, changes will be saved when the "save all changes" is clicked.

^{download bmml source}

3. Use Modal Window. Place a button in requirements with label "Edit Requirement". When the button is clicked show a modal window with relevant information and a button with label "Update Requirement Details". When the button is pressed close modal and refresh details in the parent window. Also, change the label "save all changes" to "save all valuations".