User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on a screen where the user can see the same information in 2 modes: graphic mode, and table mode (there's a toggle to switch between them). In the graphic mode, there's a graph and a details pane (which shows the details on what's selected in the graph), in which the user can edit some fields. In the table view, the user can edit the same fields directly in the table. Both views have "save" and "cancel" buttons.

My question is - what are the users most likely to expect in the following scenario: The user edited some fields in the graphical view and did not save the changes. The he switches the view to table. Should the changed he made but did not save persist in the table view, or should the view switch action discard unsaved changes (and therefore the user should receive a message on whether he wants to save the changes)?

share|improve this question
Not prompting can lead to the most dangerous possible assumption; that your app auto-saves when it doesn't – Ben Brocka Jul 8 '12 at 17:18

I realize this isn't one of the two options you proposed, but I would expect the changes to reflect on the other screen automatically and yet not actually save in the sense of persistence (read: written to disk, network, database, etc.).

Think of a WYSIWYG editor for web pages. When switching between the graphical interface and the code view, changes in one view should update the other without any prompt and without saving the file. The changes shouldn't really be saved until the save button is clicked or until the edited is closed and the user is prompted to save/discard the edits. This way, you can make edits in one view, preview them in the other, and change you mind by closing the editor (e.g., going "back" to the previous screen) and choosing to discard the changes.

In other words, changes should persist between views but in memory only. The save/discard decision need only happen when the user leaves the editor altogether.

share|improve this answer
This is especially true, when the user is likely to do a lot of quick iterations like "edit the table - view graphical representation". – SkyDan Jul 8 '12 at 14:35
Thanks for the useful reply. What would you say should happen when editing is possible in only one of the views? say only the table, while the graphical view shows different kind of information about the entities? Say, only the relations between entities but not their textual properties. – Olgaarsh Jul 9 '12 at 11:00
Okay, so a read-only graphical overview and an editable tabular detail page, accessible through tabs or a toggle button or some such mechanism? I would still expect the same behavior. In other words, you should still delay the "There are unsaved changes. Do you want to save?" decision until the user exits the activity with the tabs/toggle (or attempts to load new data, like File > Open, if that's possible in your scenario). – user113215 Jul 11 '12 at 0:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.