Open, close, save

[AlexanderPico]

While playing with the edit in situ I think we will need another state. I'm hoping this isn't too challenging...

With the current buttons:

1. "^ Quick Edit" -- opens editor
2. "X" -- closes editor
3. checkmark -- saves AND CLOSES

Maybe, (3) should ONLY save and then you'd return the button to (2). This would allow multiple edits to be individually saved and perhaps help reassure the user that changes are being saved.

Alternative button ideas:

1. same as above
2. chevron-down + "Close" -- closes editor; keeps familiar styling and is obvious
3. checkmark + "Save" -- saves; keeps familiar styling and is obvious

[khanspers]

I agree that a save-without-closing is necessary. How about if the "X" (close) button stays the same, and if something is changed, a green checkmark "Save" (but don't close) button appears in the actual editor? To the right of the set of input boxes.

[AlexanderPico]

When we tried this earlier, we only had a single tab. We'd have to add this button to every tab, which isn't ideal. It would also create new conditions: closing without saving and closing with partial save, that I'm not sure we are ready to accommodate. I'm not entirely against the idea of separate parallel save and close options, but I think we'd have to go back to the drawing board and rework a lot of things to make it work. So, maybe not for this first version?

Or, maybe now is the time to do it? Anders, what do you think?

[ariutta]

It could be difficult to implement a save-without-closing button right away, because we decided against that earlier. It would definitely be possible in a later version.

With regard to closing and discarding changes, currently both the pvjson and the SVG are changing when the user makes edits. The GPML is only updated and saved to the backend when the user clicks the green checkmark-to-save-and-close button. If we want an X-to-close-and-discard-any-changes button visible at all times when the editor is open, we can easily allow the user to close the editor without updating the GPML/saving it to the backend. But at present, the pvjson and the SVG would still reflect the edits.

Here's a two-part proposal for how we can enable an X-to-close-and-discard-any-changes button:

1. MVP solution (quickest): when the user clicks the X, pvjs closes the editor and triggers a page reload, which will ensure the GPML, pvjson and SVG all return to the state before the user opened the editor.
2. Later, when we implement "undo" functionality, clicking the X can return the GPML, pvjson and SVG back to the state before the user opened the editor, without requiring a page reload.

[AlexanderPico]

We might have to go with page reload for other reasons in addition to this one... But on this point it is even more complicated. We need to consider when someone saves one change, then makes another change, then closes without saving. AND, we have to consider all the messaging we want to prompt users with, e.g., Do you really want to close without saving?

I don't see a quick solution here (that includes close without saving), but if it's a show-stopper, then we'll have to put the time in now to design for these cases.

I think the quick MVP solution is to not support close without saving until we develop undo and review. Even still, we might have to reload pages...

[AlexanderPico]

Checked in changes to styling of close and save&close buttons (to match the open btn a bit better). These should be critiqued; we can easily return to unlabeled symbols.

Orthogonally, Anders will also prototype a separation of these functions so that a user can save multiple times before closing. If awkward or buggy, we will simply ship with save&close.

[ariutta]

I'm OK with keeping the current UX for now. Any other input?