Is history-dependent navigation after save/cancel actions good practice?

Question

I'm working on the content editor for a CMS.

The user starts from a list of articles:

From here they can navigate to two different screens - the pencil button takes them to the actual content editor, and the gear button takes them to a property sheet (for document meta-data) with management functions like publish, delete, etc.

The property sheet isn't that interesting, but note that it also has the edit-button - so the user can navigate to the content editor either from the list of articles, or from the property sheet.

The content editor itself takes a "distaction-free" approach, with the editable content taking up the entire screen, and the only interface being a toolbar at the top:

This interface doesn't have "save" or "cancel" buttons yet, but the plan is to put those in the top-right corner next to the undo/redo buttons.

The question is, what should happen when you press the save or cancel button?

Would the user expect to go back from where they came? That is, when you save or cancel, would you expect to go back to either the article list or the property sheet, depending on where you came from?

Or would you expect to always go to the same place after editing, for example always going to the property sheet?

I can see problems with both.

If the navigation is history-dependent, and I'm on the edit page for a long time, say, editing an article for 20 minutes, I'm most likely not going to remember whether I came here from the list or from the property sheet - since this will vary depending on how I got there, I could be surprised by ending up in either place, which seems bad.

On the other hand, if the destination after save/cancel is always the same, say, always the property-sheet, I might get annoyed by the extra click to get from the property-sheet back to the article list.

Adding more buttons isn't really an option, as we would need too many buttons - at least four, "save and go to list", "cancel and go to list", "save and go to properties", "cancel and to go properties".

Is there a "right answer" to this question?

Answer 1

I think both the content editor and property sheet pages should return to the article list since that's the user's point of entry for those pages. With this, I would also remove the ability to navigate to the content editor page from the property sheet.

This keeps each page's functionality separate. By only being able to navigate to the content editor and property sheet pages via the article list page, the expectation of returning to the article list page after a "Cancel" action is a bit more natural.

I understand your concern of requiring an extra click to navigate between the property sheet and content editor pages. In this case, I think the benefit of having a clearer navigation flow (and a more intuitive experience for the user!) outweighs the extra click.

Answer 2

I guess the "right" anwser would depend on your User's Context of using the application but from what I understood of your explanation:

Save Button: Is there really a necessity for a 'Save Button'? As seen in other platforms such as Evernote or Google Drive there has been an increased practice of using Auto-Save and displaying a 'Document Saved' message on the top each time it does save. If you find that the Save Button is really necesseray I would suggest that it didn't close the Editor's view when clicked. You could display a message aswell('Document saved.').

Cancel Button: The terminology 'Cancel' might be confusing to the user because imagine a case where the user just finished editing a document. He clicks 'Save' an then there is a 'Cancel' button. He might get confused if he clicks 'Cancel' it would cancel all of his work. I suggest using 'Close' and also that the Close button send the user to different screens depending from where he came. If he came directly from the List view send him back to the list and If he came from the properties send him back to the properties.

Hope it helps somehow...

Answer 3

So when the user clicks the save button, he or she isn't just saving, but is also creating a historical copy - but labeling the button "save" doesn't tell them this. It also seems like the cancel functionality, historical copies, and undo button are a bit redundant. If I make a bunch of changes that I decide I don't want to keep, I can undo until I get back to the document's original state (would be good to support keyboard shortcut here) or I can revert to a previous saved version. So, I agree that the cancel button is unnecessary. However, you could use a back button or arrow instead of "close" so then it is clear you are taking the user back to the previous screen he or she was on. Close could make sense if the editor shows up in a modal over top of the previous screen, but it doesn't seem like it does.

Answer 4

For me a simple approach is to display a notification in a pop-up to let the user know the operation is complete and the informations are saved and ask him if he want to see the article or go in the list to the next article (the options can vary). Anyway you display the success message, so I don't think this extra step is time-consuming.