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

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

The user starts from a list of articles:

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

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:

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

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?


Category: usability Time: 2016-07-28 Views: 0

Related post

iOS development

Android development

Python development

JAVA development

Development language

PHP development

Ruby development


Front-end development


development tools

Open Platform

Javascript development

.NET development

cloud computing


Copyright (C), All Rights Reserved.

processed in 0.200 (s). 12 q(s)