We have a web application with tabs that have read only content. Some users have permission to edit the content; when edit is pressed, the tab's content can be edited.
On an edited tab that has unsaved changes, if the user switches to another tab, all the changes are discarded.
Is this good user experience? What heuristic principals does it disobey?
It depends on your application structure, but in general tabs are precisely made to have more than one opened at a time.
Therefore, it would be pretty annoying to always notify the user when he switches tabs.
A common solution would be to keep the status of each tab and display a "modified" indicator inside the tab headline. E.g. in IntelliJ a modified document's headline becomes blue:
Offer a global "save all" and a "save" for each tab.
The "do you really want to discard your changes" popup might now open when the user decides to close the whole "document" (e.g. when he decides to close/leave the page).
Alternatively, you could save the modifications as draft and load them when the user enters again. This would move the necessity of the Popup to the time when the draft would be overridden.
Like I mentioned in the first sentence: in the end it depends on the structure and the context. How often will users switch tabs? Can your webpage design/technology handle the different states of the tabs?
One should never irrevocably discard unsaved changes without warning the user. There are two possible solutions to this:
As L. Möller mentions, often allowing an action, but giving an undo option, is preferable to asking the user "are you sure?". I don't think an undo action would make sense in this case, but the second suggestion offers an implementation that avoids annoying pop-up dialogs.
Tabs are meant to keep the state whether they are shown or not, meaning that the things you have in tab A should look exactly the same even if you switch to tab B and then back to A.
Try to start to write an email in a tab using a web browser. Open another tab and then switch back to the mail composer tab. You would be surprised if what you had written in the mail was gone.
When I design a flow and structure I try my best to not put the user in a such a position to make the switch between two tabs within one operation / transaction / action / goal. If I put address into a tab I try to put a save button in the tab. If not I work in collapsible and / or one long screen depending on the technical capabilities, the medium, the user, the data roaming etc...
If you have to work in tabs and you have the technical abilities; you can at least try to give the user the feedback about which info is changed. For example make the "saved" info and the "unsaved" info in different visuals. (e.g. saved dark gray and regular, unsaved light gray and bold) That is the kind of thing we use in banking applications sometimes.
Short answer:
99% of the time, it won't be a good UX.
My choice would be to notify the user:
Unnecesary long answer:
Why? Here some thoughts and recommendations that come to my mind:
What does the user expect? You must think in what kind of programs the users of the application could be familiarized with, and follow a similar a approach or try something that may be better (easier, clearer, more intuitive,etc).
For sure and as mentioned in previous answers, what you should not do is to make implicit non-intuitive actions that tend to get the user mad or disoriented. Unnecessarily undoing actions that the user may want to preserve for later saving/confirmation is definitely a thing to avoid.
Some possible solutions:
1) Inform about the app behavior (before users' action): The behavior should tend to be intuitive and without a need of notes of use, but in some cases it is necessary or at least an aggregate that has more benefits than drawbacks on the UX. Something like "The edited content will be discarded when leaving tabs without saving"
In this case, I don't find it appropiate at all.
2) Notify them that there's unsaved modified content (after users' action):
When?:
How?
a) Actively: Leaving no choice but to choose in the moment they are leaving the tab/page.
b) Pasively: With some warning that tells the users about it "constanstly" but without a demand of a instant response. Depending on your UI design and application there are several things you could do: changing some style of the unsaved tab (btw I dont't think that an * is always enough by itself for non-developers users) for example, some colour or any more reconigzable sign would be beneficial aggregate, even more if you have a "reference bar" with that saids "Unsaved tabs" with a reference of the unsaved-tab-color (this last things, if the amount of editable tabs is considerable, not just one or two).
Other things that may help in some particular cases:
Is the current criteria for dividing the content in tabs appropiate? How each tab is related?:
As a user, if I'm editing something in a tab, I wouldn't like to need to go to another tab to find some information to complete my action (like keeping coherence between two settings which are placed in different tabs). So the less coupled the tabs are, the better. By doing that, the existence of unsaved content could be reduced. The user's tendency to move between tabs in order to complete an action may be a good reason to reanalyze the information distribution within them.
"Ok I did my best, but what if it is wrong?
Test it, learn from it and improve it. You can track the user behavior to try to find a clue about what they tend to do, and modify your application based on that.
First off, there is always something wrong in simply discarding changes (i.e. without notice).
Secondly, preventing a user to switch tab unless they either save or loose change is not very good. If you have several tabs, it is to be able to switch from one to the other. Or you need to change the design so the tab being edited becomes the top element (e.g. as a popup on a dimmed bg)
Lastly, having modified tabs while being able to go to another one can be dangerous. You can notify the user (a * is always good, different color on the tab header...), and also, to loop with the first point, you should not let the input be lost if the user close the application. Either use an alert (see gmail for instance), save the draft in background, or both.
It is not a good user experience if the user's changes just vanish on changing tabs. Github for e.g. has settings in many tabs, and the changes just get autosaved. It is the same for Slack preferences as well.
Another option is to have an edit option for each sub-section of the settings, with Save cancel controls.
