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?

  • 3
    What is the use of tabs if the user can't keep unsaved changes around while working on something else? What is your objective in forcing the user to save changes before switching to another tab?
    – ADTC
    Commented Oct 18, 2014 at 20:13

7 Answers 7


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:

Modified tab is 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?

  • 19
    I find most programs use a * to indicate pending changes. Changing the color would be a surprise for me, although if I saw it change from black to blue when it changed I would probably get the hint.
    – corsiKa
    Commented Oct 17, 2014 at 17:02
  • 4
    Some programs (e.g. Notepad++) do use a red/blue color scheme for "unsaved changes," but I've always seen it used in conjunction with an asterisk.
    – apnorton
    Commented Oct 17, 2014 at 19:25
  • 4
    Color changing, asterisks, or any other indicator works, as long as it works well with the rest of your app. Commented Oct 17, 2014 at 19:29
  • @corsiKa Probably most use * due to color blindness. Going from dark to light or vice-versa would get around that, but might clash with the rest of your design.
    – Izkata
    Commented Oct 19, 2014 at 22:18

One should never irrevocably discard unsaved changes without warning the user. There are two possible solutions to this:

  • When a user tries to change tabs, pop up a warning dialog that there are unsaved changes. Give them a choice to discard the changes or not at this point (there should be an option to continue and discard the changes, as well as an option to return to the tab they are working on. There could also be an option to save and continue).
  • Remember unsaved changes from all tabs, and save content from any modified tabs when they choose to save changes. This would require some kind of persistent indication on the page that there are unsaved changes--otherwise, the behavior when switching tabs would be ambiguous.

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.

  • 1
    "One should never discard unsaved changes without warning the user." I disagree. Under many circumstances it's much more reasonable to discard the changes and offer an "undo". Remember that most of the time the user knows what he is doing and would be heavily annoyed by random "do you really wanna" popups
    – Lovis
    Commented Oct 17, 2014 at 6:55
  • 1
    @L.Möller, yes you are right--if there is a way to get the changes back. I will soften the first sentence. I do hate "do you really want to do this?" popups. But they are necessary if the alternative is losing work. In this case, I'm not sure how an "undo" feature would work.
    – user31143
    Commented Oct 17, 2014 at 7:07
  • Yes, I agree with the rest of your post. I just wanted to say that the sentence was to "ultimate".
    – Lovis
    Commented Oct 17, 2014 at 7:09
  • 2
    I'm not sure that I agree with the first option. When I'm changing tabs, in a browser or another application, I'm probably in the middle of doing something which a pop up will undoubtedly distract me from. Another point is that the situation may arise where I'm editing data in the first tab while referencing data in the second. It would be annoying if jumping between them meant that I kept getting prompted to save my changes (I've actually run into this issue before). I think that your second option is a good one however, as it seems like it would fit in pretty seamlessly. Commented Oct 17, 2014 at 8:14
  • 1
    @MattChampion, I prefer the second option, too, but there may be implementation challenges that make it infeasible. Also, how much it matters depends on the use case of the application. If changing between tabs is likely to be rare, it probably isn't worth the more complex implementation.
    – user31143
    Commented Oct 17, 2014 at 8:25

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.

  • Expectations about tabs are not so clear when the context is a website. Often on websites (especially historically) tab-like visual designs have behaved more like individual web pages, making it unclear whether changes will be remembered. I do agree that remembering the changes is best, but there probably needs to be a visual indicator of this.
    – user31143
    Commented Oct 17, 2014 at 7:46
  • 4
    "Normal" end user expectation is pretty clear that website tabs should work like application tabs. Among us developers, understanding the underlying technology, we don't have the same expectation. You have to know your audience for this one. Commented Oct 17, 2014 at 17:13
  • "wether" -> "whether" (ref. <en.wiktionary.org/wiki/whether>)). "Wether" is: 1) A castrated male goat, 2) a castrated male sheep, 3) a misspelling of weather or 4) a misspelling of whether (see en.wikipedia.org/wiki/Wether) Commented Nov 3, 2014 at 22:25

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:

  • Pasively when leaving the tab and
  • Actively when leaving the page

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):


  • a) When leaving the tab
  • b) When leaving/changing the page


  • 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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