Would you Like to Redesign Notification in Firefox? Yes. Not Now. Never.


Recently I’ve been thinking a lot about the way Firefox interacts with the user when it needs to ask a question, or provide a piece of information. These interactions involve topics like:

-RSS detection
-Password manager messages
-Download manager messages
-Installing updates
-Installing extensions
-Pop-up blocking
-Phishing protection
-A range of other features that are still in the design stage (microformat detection, inspecting security information, etc.)

What’s Wrong with the Current Approach?

The biggest problem with notifications in Firefox 2 is that some of them force the user to answer a question using a modal dialog box. These modal dialog boxes interrupt the user’s flow, and (while at least they are not anthropomorphized) these kinds of repetitive interruptions can get annoying:


There has been a considerable amount of research into the effects of notifications. People have studied the negative effects of interruptions in terms of task performance and emotional state, and have even created models to predict the cost of interruptions. It turns out, interrupting the user is bad.


So the challenge is to interrupt the user, without interrupting them. Notifications have to be noticeable, but not annoying. It’s a fine line. Here are some ideas I’ve had for redesigning notification in Firefox. First I’ll go through the basic idea, then I’ll iterate through a few variations. This design is still pretty rough, please feel free to propose new ideas in the comments.

First, I think we should create a centralized area in the browser chrome that provides notification UI. This could be anywhere, but the first mockups show it next to the throbber. There are a couple of reasons why this may be a good place to put notification icons: outside of the status bar this is the only area of the chrome that displays status, and the user’s gaze may already be near the throbber while the page is loading, since it animates. Also, I personally want to get rid of the status bar. But that’s a different issue that has already been heavily debated.

Some notifications are more important than others. Because of this, the design supports four increasing levels of notification:

Level 1: Icon
Level 2: Message
Level 3: UI Controls
Level 4: Modal Warning Dialog

Here is what these four different levels look like. [If you are wondering about my switch to crayons, it’s an attempt to convey that these are just conceptual mockups, not final designs].

Level 1: Icon


From left to right, RSS feed on page, file is downloading, and a new version of Firefox is available. These icons only appear when they are relevant. If this looks overly cluttered, keep in mind that this is a rather extreme example (normally not all of these things are relevant at the same time). Note that this is a rough sketch, the last two icons are likely to change.

Level 2: Message (non-modal)


Level 3: UI Controls


Level 4: Modal Warning Dialog


Unlike the previous levels, this type of notification is modal. The content area is blacked out, and the user must make a decision before continuing to use Firefox.

Each type of notification is assigned an appropriate default level. This isn’t a complete list, but it provides a sense of what types of notifications appear at each level:


These levels determine how the notification is initially displayed, however the user can also drill down on their own. For instance, clicking on a notification that is a icon (level 1) or message (level 2) will display the relevant UI controls (level 3):


Messages (level 2) and UI controls (level 3) are non-modal. This means that clicking anywhere outside of the notification will cause these notifications to disappear, however the icon will remain while the notification is relevant.

One problem with this design is the occasional situation where the user clicks right after a notification appears. This will cause the user to accidently dismiss the notification, and then wonder what it said. There are a couple of ways to help mitigate this problem. First, messages (level 2) and UI controls (level 3) should always contain larger versions of the same icon that appears in level 1. If the user catches a glimpse of the icon, this will help them know which icon to click on to get the notification back. Secondly, the notification should fade out, so if the user does a visual scan quickly enough they will be able to see which icon the message originated from. And finally, we can use cognitive performance modeling to calculate the average time it will take the user to view the notification and process what it said (probably a fraction of a second). Any clicks under this threshold should not dismiss the notification, because it is unlikely that the user was clicking to get rid of it.


Here are some different variations of the same general idea.

Status Bar
Everything is the same, except icons appear in the status bar instead of next to the throbber:


Location Bar / Throbber

Some notifications only apply to the current tab, and other notifications apply to the entire browsing session. The designs above don’t make a distinction between these two types of notifications, but perhaps we should. The way we currently create this distinction is to have tab specific notifications like RSS feeds and microformat detection appear inside the location bar (because they are associated with the current page). We could have global notifications like downloads and browser updates remain outside the location bar field, next to the throbber:


If this looks too cluttered, one way to reduce visual complexity is to make all of the notification icons monochrome, matching the throbber. Kind of like the upper right corner of OS X. Also keep in mind that these icons only appear when they are contextually relevant, usually there won’t be this many at the same time.

Javascript Popups
[Update: Benjamin Smedberg explains in comment #6 why this would break the Web]
While we are on the topic of page-level notification, a javascript popup window should be modal to the tab that invoked it, and not the browser. This makes it clearer to the user that the Web site is addressing them (and not Firefox), and the modal popup doesn’t lock the entire browser.

As I mentioned earlier, all of these ideas are up for debate. How do you think we should improve notification in Firefox?

Technorati Tags: ,


  1. New application versions should be modal IMO.

  2. love it, that is definitely the way forward. I also really like the idea of javascript popups being attached to the the page / tab somehow, rather than just a dialog

  3. It seems like your proposal is coming with the price of permanent “notification” icons in the chrome.
    We’ve looked at this before and that’s something we did not want to do.
    It would be good to make the notifications more uniform/streamlined. I don’t know if there’s been an audit of all the notifications, but would be good to have.

  4. Magnús Örn Gylfason

    Allow me to say, YES YES YES! :)
    All dialog boxes (especially modal ones) should burn in the lower planes.
    For me, the Firefox Find bar was the best ui-improvement of the last five years or so…

    cheers and keep up the good work!

  5. Wow!!! Its really cool!!! I need all of that in Firefox 3!!! =))

  6. Unfortunately, javascript popups cannot be tab-modal without breaking the web. There is a concept called run-to-completion where DOM scripts are not interrupted (changes cannot occur from “under” them). And since tabs can hold references to eachother, you’d have to make a set of tabs modal, which is either Very Hard or Impossible (TM).

  7. Nice proposal. But I would personally prefer these notifications be put within some kind of an information/notification bar within the browser canvas.

    This has couple of advantages:

    1. Not cluttering either the toolbar/status bar
    2. Grabs the attention of the user, if it is non-modal, it can be collapsed manually or with a timeout
    3. Web browsers unite, I’ve noticed Firefox already uses these kind of information bars in some cases, IE does it, so this can be a uniform way of representing user-interactions

    PS. I vaguely remember an old post with a mockup on password dialog too.

  8. bsmedberg already said one thing I was going to (much more clearly than I could), about some of the things you call “page-level” – actually one site might be in several tabs, interacting with each other, so those things should really be “site level”, although that’s not a concept that really exists (yet).

    I have a personal hatred for the “remember this password” dialogue. On my work computer, I want to remember passwords for a lot of work sites. I don’t want to remember any personal passwords. I also don’t want to have Firefox keeping a list of all the personal sites that I don’t want it to remember passwords for (no, I’m not looking at porn at work, I’m just paranoid :P )

    I also wonder if the “icon” level is too subtle for many people to even notice (but maybe the things being indicated like that are things where it doesn’t matter if they never notice or understand them).

  9. This looks great. While at it, are there any plans to make the dialog appear-post-validation?

    I was pretty poor password memory so I generally have to try multiple passwords before I remember the one I need to login. So in an indeal world firefox would only ask me to save the password AFTER the website has let me login.
    Perhaps changing it to a non-modal dialog would work, such that it pops up before the page is done loading, but remains there even when the next page loads.

    Otherwise I tend to tell firefox to remember incorrect passwords and that’s inconvenient.

  10. Definitely YES. It’s a good ideea and I don’t mind a bit of space estate for the icons.

  11. I agree with comment 9.

    And I really, really want the password dialog functionality to change! The blocking it does now is really terribly annoying, especially since it blocks all tabs, not just the one you’re logging in on.

    I’m not sure if your mockups are the way to go or not, but I like the direction of your thinking quite a bit. I do think we need to distiguish between page level and “universal” type prompts.

    I haven’t applied rigorous mental checks to your ideas, as I’m sure they have a ways to mutate before they near final valuation (and others are much more qualified to provide some of that initial checking). But I definitely agree notifications overhaul is needed, and I really like the idea of lowering the interruption level without making them unnoticeable.

    I’ll be keeping an eye out and thinking more about this myself. Cheers!

  12. This looks great. While at it, are there any plans to make the dialog appear-post-validation?

    Yeah, I didn’t want to go into too much detail about each type of notification, but I agree that displaying a password manager notification post-validation is more useful. I also have been thinking about a “auto-login” option. A notification would appear after the automatic login, in case the user wanted to go back and login with a different account.

  13. There’s an alternative way to present non-modal UI in context. I explore this in reference to OpenID login UI:

    It may be possible to apply a similar in-context design to other alerts.

  14. This is great research. We’ve been playing around with a lot of this in the latest version of Flock (codenamed Cormorant, a developer preview is due out later this week but the hourlies are always at tinderbox.flock.com). Mind you, we haven’t looked much at reworking the underlying FF notifications, but simply handling all the NEW notifications that Flock’s service-integration has created. The best case we’ve done so far has been to support simple one-click bookmarking, where the notification bar provides a button to open up the properties dialog and change things such as tags, whether or not the bookmark is saved to an online social site, etc.

    I really like your approach to hanging non-modal dialogs off the icons, but a technical issue comes up with that (we’ve run into it in the search flyout as well) – if the flyout ever ends up over top of a playing Flash video, the video gets drawn over top. We’re working on a fix for that one, and if we nail it we’ll push it back upstream.

    Anyway, great work, and I’ll be using your references in our work. Thanks again.

  15. I am flabbergasted(!).

    I’m eager to see these dialogs in Firefox.

    Question: Will this refresh also improve all JavaScript Alerts()!.

  16. Very interesting work. One particular pet peeve of mine is that if the master password is required in a loading web page, even if Firefox is minimised, it will pop up it’s dialog, it should only do this upon Firefox regaining focus.

    I particularly like your mockups for the notifications, sort of coming out in a speech bubble manner from the main Firefox UI. This separates Firefox generated dialogs from the Javascript ones that spammers and malware authors use sometimes, that still get through the pop-up blocker.

    Would very much like to see progress on this. Keep up the good work.

  17. I like the idea and mock ups. However, wasn’t a similar notification of updates to firefox used in Firefox 1.5 or an earlier version, and there were discoverability issues with users not realizing an update was available? Perhaps there could be some higher level of discovery associated with each level, like animated icons, color icons, or as I believe you mentioned larger icons. My concern would be that users inadvertantly miss important information. At the same time, using Firefox should not be like this I’maMacI’maPC ad.

  18. It is actually worse than bsmedberg implies in comment 6. Not only can other tabs change data, extensions can do as well. You could make alerts modal to all tabs from one site since the other can’t influence it anyway but you can’t do anything like this for extensions – they always have full access. So there is no other way but to make alerts modal to the entire browser UI. It is really a pity.

  19. wasn’t a similar notification of updates to firefox used in Firefox 1.5 or an earlier version, and there were discoverability issues with users not realizing an update was available?

    Yes, that little green up arrow that no one noticed. Displaying just an icon is (in terms of my proposal) level 1, and right now I am suggesting we use an icon + non-modal dialog with UI controls (level 3). But if we find that this is still not discoverable, we can make Firefox updates modal (level 4), as suggested in the first comment. Probably drop the red dialog since it isn’t a warning, but still black out the page since the dialog is modal.

  20. This is a very neat idea, I like it and makes the program seem slick.

  21. It also could fade out (a little )the entire page, to get the attention of the user.

    A problem that could arise would be sites that try to mockup the notification in an image so that the user would click there (but if it would fade out the page, it would a lot more dificult to fool the user.

  22. It is actually worse than bsmedberg implies in comment 6. Not only can other tabs change data, extensions can do as well. You could make alerts modal to all tabs from one site since the other can’t influence it anyway but you can’t do anything like this for extensions – they always have full access. So there is no other way but to make alerts modal to the entire browser UI. It is really a pity.

    If a page throws up a dialog, other windows (even from the same site) aren’t blocked, and web pages don’t know about the distinction between tabs and windows. So there’s no need for other tabs to be blocked for run-to-completion to work.

    If chrome JavaScript in an extension throws up a dialog, sure, that can be modal to the entire window. Extensions just shouldn’t do that ;)

  23. Yeah good idea! Think that would be nice.

  24. I like how currently clicking “Subscribe to this page” allows me to see the headlines of a feed before I subscribe. I’d like to be able to do so in future versions of Firefox too.

  25. A sincere plea from an online shopping addict: PLEASE MAKE A WAY TO OVERWRITE YOUR SAVED PASSWORDS. I have no idea how many incorrect passwords are saved in Firefox; I have two passwords I use for nearly everything, depending on the site’s handling of special characters (why is $ a special character?), and there are dozens of times I enter the wrong password when logging into a rarely-used site. I see the dialog, think “ok, save the password” – and it’s the wrong password. Sometimes the “change this password” dialog catches it on the re-login, but that utterly fails when I’m redirected to a separate “catch” script server-side where I re-enter the correct password. This is absolutely intolerable; unless there’s a gaping security hole I’m missing here, there should be a separate handling for user-misinformation cases like this.

    That said, a question to Benjamin Smedberg (#6) – I think I see what you’re saying; wouldn’t it be easy in XUL to display the tab-linked array of Javascript popups as a -moz-stack (or similar)? Then you’d be able to set the display of the popup corresponding to the selected tab to “inline”, “inline-stack”, etc., or else just set the display of all the other popups to “none”. Seems pretty intuitive, and keeps the desired interface.

  26. I almost completely agree with comment 7. Just use the already-existing notification bar for the password manager, or where else it may fit. For Update, Download and Feed notifications, I don’t see the problem that you want to solve. They aren’t unified, yeah, but nonetheless they work very well.

    The point where I disagree with comment 7 is the timeout, because that wouldn’t be accessible.

  27. Wow, this looks excellent! I really hope this innovation is included in Fx3. I hope that this is put in the status bar (unless the status bar is removed). The status bar definitely has more open space for this (although I see that only a couple of these icons would show at a time). I also hope the status bar stays unless a new, innovative approach that still shows full link destination URL is implemented.

    Also, as few have mentioned, this is somewhat similiar to the notifications Fx1 used, which I have missed in recent Fx versions (it is definitely NOT a good system to have to go to run the addons manager to update add-ons). This unified approach will greatly simplify Fx use across all levels :)

  28. One more thing, with this feature implemented, would it be possible to wait and see if a logon goes through successfully before having to choose whether or not to remember the password? If so this is another welcome improvement this feature would make

  29. I don’t like the way these notifications cover part of the content area and tab bar. Having a pop-up-blocked notification obscure the page and interfere with closing the tab would be about as annoying as having a pop-up.

  30. Just looking at the pictures I got the feeling that this new solution you are presenting has a much better feeling attached to it than the old modals. I hope this will be reality :)

  31. I think this would be an excellent idea! Looking forward to seeing it implemented.

  32. Will “level 2” and “level 3” notifications take focus when they appear?

  33. How do you expose these dialogues to screen readers and make them keyboard-operable?

  34. Nickolay Ponomarev

    Nice proposal. As a user I would certainly appreciate the modal dialogs go away. Is it something that may happen for Fx3?

  35. Before this, I would like to have these model dialogs limiting their scope to the tab they are intended for.
    Nothing is worst that having entire browser locked due to one javascript alert.

  36. That’s an interesting take on it all, my only problem with it is when you have XYZ extensions applied to Firefox. These spaces can be cluttered at the moment. Myself, I’ve got 3 icons on the right of my status bar, and two on the left. I also have one by the throbber.

    However I do use all of these, so I do look at them – but only when I need them. Not as a general notification.

    If it were the default firefox with no clutter then I think this would be great.

  37. 33, Joe: How do you expose these dialogues to screen readers and make them keyboard-operable?

    I’m unfortunately not familiar with how applications can proactively send text to screen readers, and what the non-modal dialogs would need to do to get the user’s attention. I’ll be attending the CSUN accessibility conference next week, and I hope to find out more there. We will make sure that any design we go with is accessible.

  38. These would probably be exposed to screen readers the same way Firefox’s yellow information bar is exposed to screen readers.

  39. Maybe it’s an idea to make a some sort of notification icon (always visible) which has lightens just like the tab dropdown. This would give you a fixed place for browser notifications and also a way of storing allerts. For really important stuff it should just popup (yellow bar style or proposed style) for the others it just flashes. Maybe add some kind of indicator to report the number of message.
    To reduce mouse-clicks it could fly-out on mouse-over.

  40. “a notification about plugins, updates, blocked popups inside the document window. The problem? Oh yeah, since that happens inside the window controlled by the document, a malicious page can spoof them with 100% realism.”

  41. My biggest concern would be the security one. Notifications which overlap the content area have a high spoofing potential. What happens if a page puts up a grey notification in the top right corner (so it matches the toolbar colour, and it’s not obvious that it’s not linked to an icon) which says:


    Firefox needs to install an important
    security update. Please click this link
    and then click “Yes” to the security warning.


    Then restart Firefox to complete the update.

    What measures do you plan to take to mitigate this problem?

    In my view, the only way to have trusted communication with the user is to have a strong visual separation between content and chrome, and to keep notifications restricted to the chrome side of the line. Yes, we don’t have much space and so this is a UI challenge. :-)


  42. I think we should at least consider that when a user is using tabs, these notification icons can go on the tab head and not by the location bar.

  43. Oh! I love it! It is a different design. thanks!

  44. This looks awesome and would better my browsing experience!

  45. I agree with both posts 7 and 9. I really have always liked the feel of the yellow notification bar, and have no problems with that becoming a larger part of the UI.

    In fact, due to security reasons (the yellow bar is spoofable), perhaps the notification bar should be always on, displayed so that it appears flush with the tab. This would not only provide a permanent space for notifications, but would also be a prime location for site specific controls. From that bar, the user could theoretically control font size, cookies, pop-ups, passwords, scripts, adds, etc., while also being readily notified by icons and color changes of page related notifications. This could also be a starting point in the UI for accessing microformats.

    As for browser related alerts, has anyone ever considered utilizing tabs for more than just websites? If the download manager opened as a tab, then it would be immediately visible and the tab itself would notify the user that downloads had finished. If the update manager appeared as a tab when updates were available, it would be noticed, but could be dealt with at the users leisure. And if Places ever gets off the ground, I would seriously consider having that be an always on tab to the far left of the tab bar.

  46. Yes, please make tab-specific dialogs tab-modal. I don’t understand how implementing this for tabs could “break the web” when it’s already normal behavior for windows:

    1 Open two Firefox tabs in the same window
    2. Type javascript:alert('test') into the first tab’s location bar
    3. The dialog that pops up is modal to the entire browser, even though it only applies to the first tab.

    Now, try something different:
    1. Open two Firefox windows
    2. Type javascript:alert('test') into the first window’s location bar
    3. The dialog that pops up is modal only to the window that called it. The other window can still be worked with.



    for a related bug, and


    for a mock-up of how I think these dialogs should be implemented.

  47. These all sound great, but you don’t go back to the initial example – password remembering – and specify what this would look like under the new system. Would it still be modal?

    Right now that box is my most hated feature. 90% of the time I’m entering a password for a site I don’t visit often, and I’m not sure if I’ve got it right. Almost every time that dialogue pops up, I’m unable to confidently answer it. In a matter of microseconds, I will know whether the password works, and if it does, of course I want to remember it. If it doesn’t, of course I don’t. But I can’t get to that microsecond without making the decision it will inform, and once I have, I can’t easily go back and change my answer.

    A level-3 interruption is fine, but the vital thing is that I need to be able to answer /after/ submitting my password. Whether that means keeping it up for a few seconds after leaving the page that raised it, or leaving the icon present while you stay at the resulting page, I don’t know.

  48. I like these ideas. I would give you an other: just make it possible to ignore plain alert() messages until the next reload of the page, or something like that. I there’s an annoying site that gives hundreds of alerts “for fun”, or if I made a mistake during debugging my application with alert, I usually would like to turn of alert() dialogs for the time I can leave/reload the page.

  49. The idea is great, but i don’t feel that comfortable with taking the space next to the throbber.
    Personally, i use that area to place *my* desired icons, i currently have Web Developer, Firebug, ImageBot, and both del.icio.us buttons next to my throbber.
    To any extent, modal messages shouldn’t even take space as an icon, they are modal dialogs and as such they need to be *centered* on your screen, they must say “hey dude, i have something really important to tell you”, showing them at the top-left corner of the screen will just annoy people’s eyes and mouse pointer moving to an uncomfortable location.

  50. erm, make that “top-left” to be “top-right” ^_^


    I talked with my friend Lutzky (http://yasmin.technion.ac.il/ohad) about my earlier post in huminized(http://www.humanized.com/weblog/2007/06/19/humanized_puzzler_2_firefox_tabs/index.php#comment-29729) , and i think we came up with a good solution

    use the suggested “expanding tab” mouse-over like the apple dock does, but also add the following twist, if the mouse-wheel is scrolling outside the browser window, while Firefox is the chosen application, the tabs will “mouse-over” one by one startng from the current tab

    by using the third wheel you gain maximum control over the mouse-over without having to physically mouse over the tab-bar

    and because all you need to do is go to this “tab-browsing” state is move the mouse violently to the edge of your screen, you can move between “choosing tab” to “reading content” with practicly no thought involved

    those that like the new 2.0 version still get the benifits, as well as those that like the old 1.5

  52. I think that the variations and designs you provided are much clear and interact with the user in a more friendly way than the actual notifications.

    Another advantage of your proposal is that it is a centralized system. Which means that the notifications have similiar/same appearance and appear at a fixed point(top right in this case).

    So, in a matter of days or weeks the user gets used to the point of income and knows where the notification will appear. This is much better than the actual notifications.

    Also keep in mind and i hope that if this gets accepted, that you make a guideline that the Extension developers will follow. So that they don’t make an extension that will display notifications in another way, and therefore breaking the “centralized system”.

    On another note, if this doesn’t get accepted, what do you think about making Growl for Mac the default notification system for Firefox and for the Pc using Snarl which can be found here: http://fullphat.net ?

    Finally my answer is YES, use the system you’ve suggested. :)

  53. Please make the icons show in the status bar because the bottom right is seldom used and is non-intrusive. In the top right it just seems to cause too much hassle and mess. The search box is already tight for space.

    I used to use the BT Yahoo browser, and although I hardly miss it I do think the pop-up notification was better. If a pop-up was blocked a small notification (roughly 100×70 at the most) popped up at the bottom right of the screen for ~5 seconds. It informed me that a pop-up had been blocked from ‘http://…’ and a small one word link was provided to ‘view’ the pop-up.

    If you ignored the notification it would soon disappear, no harm done because I don’t remember it blocking any useful info on a site.

    Other notifications haven’t been bothering me too much, the yellow pop-up bar is the one that I find overly intrusive.

    Thanks mate,


  54. At first look it looks fine. great ideas combined in the UI. Although I strongly suggest you use the notify bar that’s currently used. Or create an alternative notify bar that comes from the top of the page.
    I agree with Rafael, he didn’t want to see permanent “notification” icons in the chrome. I also believe this will infect the security level breaches for inexperienced users.

  55. Hmm, a bit late maybe, but however. I think those are interesting proposals and while I don’t use FF as my main browser those are (imho) clearly steps in the right direction. I’ve written about a specific modal dialog and its problems (at least those I perceived) a few weeks ago: http://hypftier.de/en/usability-nightmares-part-3

    I think it may be a challenge to position those notification icons where the user notices them. Things like RSS may be subtly, as long as the user knows where to look (and I doubt most users use it anyway, they are content with what they know).

    Making Phishing alerts modal might hinder usability again, though. Might need some testing but I suspect users (i. e. non-developers or tech geeks) will still be able to miss it, especially as the dialog is probably not in the exact spot they’re looking. Maybe having a kind of “sandbox” model for this case might work where forms on suspected phishing sites can’t be submitted before deactivating security for that site explicitly. Might be challenging to make that discoverable, though.

    Well, just my little opinion, albeit pretty late :)

  56. love it, that is definitely the way forward. ı have followed your writing for a long time.really you have given very successful information.
    In spite of my english trouale,I am trying to read and understand your writing.
    And ı am following frequently.I hope that you will be with us together with much more scharings.
    I hope that your success will go on.

  57. Don’t repeat the mistake of making something more modal than it needs to be. The web-forgery warning you gave as an example should be tab-modal, not application-modal, for example.