598786 - Need visual design for tab-modal prompts

Status: RESOLVED FIXED

(Toolkit :: Themes, defect)

Description

[Justin Dolske [:Dolske]]

Bug 59314 is implementing tab-modal prompts, will soon need a final visual design and icons. I'm currently prototyping with some styling stolen from the crashed-plugin UI (see attachment 477312 [details]).

From previous discussions, I think we're generally aiming for:

* Dialog "box" floating over the page. Centered, but perhaps at a fixed offset from the top so it's always easy to find.
* Some effect applied over the page (eg blur, desaturate, darken) to help indicate the page can't be interacted with, and make the dialog clearly visible.
* Dialogs triggered by page JS [alert(), confirm(), prompt()] shouldn't use the /!\ icon, but rather a (?) icon. Probably something more page-neutral, but maybe still somewhat platform-specific?
* Dialog shouldn't look just like a OS prompt (want to emphasize it's a different creature, and part of the page), but also shouldn't so radically different that the user doesn't recognize it as a prompt. [And normal prompt interactions, like location and order of OK and Cancel buttons.]

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

I think for alert we should use the information icon, and for confirm and prompt we should use the question icon.

Comment 2

[Stephen Horlander [:shorlander]]

Attachment: Tab-Modal Design v01

First pass at styling for the tab-modal prompts.

Went with something neutral and dialog-esque. A is completely neutral and B has colored icons.

The goal was to make it recognizable as a dialog but not a system dialog. It should come across more as the webpage is talking to you.

Comment 3

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #2)
> Created attachment 479267 [details]
> Tab-Modal Design v01

I have two comments: first, this is spoofable... second, you don't really see it's tab-modal.

I have then two suggestions:

  1. place the dialog upper in the viewport with a triangular zone connected
     to the tab when the tab is visible in the viewport
             /\
     +------/  \------+
     |     dialog     +
     +----------------+

     Making it go beyond the html viewport's limit will solve the spoofability
     issue.

  2. have a visible indicator in the tab itself showing a tab-modal dialog
     is waiting or input when the tab is NOT currently visible in the viewport

Comment 4

[Jonathan Haas]

> I have two comments: first, this is spoofable... 

Does it matter? At least for alerts, confirms and similar stuff, I think it doesn't because the alert doesn't do security-relevant things and the website could easily implement their own alert/confirm mechanism.

> second, you don't really see it's tab-modal.

Does it matter again? At least it doesn't look like a native dialog and this way I think it already looks tab modal. And the user will see that it is tab modal by trying to switch tabs.

(In reply to comment #2)
> Created attachment 479267 [details]
> Tab-Modal Design v01

I think the icons are way too large. When a website is displaing an alert it is usually not very harmful, but this huge exclamation mark, especially in the colored case would be more appropiate to a critical system failure or a virus infection detected by anti virus software. Providing such a big warning icon by default could make spoofing error messages actually easier.

Comment 5

[Josh Tumath]

If I may add, I think the icons are fine at the size they are, personally. However, for Windows at least, the question mark icon shouldn't be used, in my opinion, because the UX guidelines say that it should only be used for Help related stuff, rather than when you're asking the user a general question.

Comment 6

[Stephen Horlander [:shorlander]]

Attachment: Tab-Modal Design v02

Version 02:
- Using the default 64x64 notification icons
- Removed blur effect

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

These look good, quick feedback:

-We should avoid the default system icons so that there is no confusion as to who is talking (the page versus the operating system).
-The diagonal lines at the top of the dialog are too strong in the direction of being a warning/danger.  These are usually informative or simple questions.

>for Windows at least, the question mark icon shouldn't be used, in my
>opinion, because the UX guidelines say that it should only be used for Help
>related stuff

It's true that the guidelines say this, but their solution is to use a danger sign for every single question, regardless of if the question is of any consequence.  I think the Windows guidelines could use to add a question icon, constantly using warning icons is too dramatic.

Comment 8

[Justin Dolske [:Dolske]]

(In reply to comment #7)

> -We should avoid the default system icons so that there is no confusion as to
> who is talking (the page versus the operating system).

Agreed, though as I noted in comment 0 I think they should at least be be somewhat familiar looking, just different.

> -The diagonal lines at the top of the dialog are too strong in the direction of
> being a warning/danger.  These are usually informative or simple questions.

Yeah, I noticed the same. They're muted enough that I'm not too worried about it, but it is at least mixing messages.

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

>I think they should at least be be
>somewhat familiar looking, just different.

yeah, same glyph (i) or (?), I would just avoid using the system color/texture.  I like the colorless inset design here: https://bug598786.bugzilla.mozilla.org/attachment.cgi?id=479267 or some other type of white/grey treatment seems generic enough not to conflict with the design of the site itself.

Comment 10

[Ethan Sisson]

The noise in the background is too strong. I would actually opt for doing away with it entirely in favor of a smooth gradient lighter at the top, darker at the bottom, and a bit more opaque than in Stephen's mockups. If I don't get slammed at work tomorrow I'll see about doing a mockup.

Using noise in this way seems arbitrary and alien to the Firefox UI, and doesn't work particularly well with the overlay being translucent. I think it is more suited to something with a matte texture such as Stephen's In-Content UI mocks (http://blog.stephenhorlander.com/2010/06/01/in-content-ui-visual-unification/).

Comment 11

[Stephen Horlander [:shorlander]]

Attachment: Tab-Modal Design i03

Comment 12

[Ethan Sisson]

(In reply to comment #11)
> Created attachment 480008 [details]
> Tab-Modal Design i03

This is very nice.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

Looks great

Comment 14

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

(This patch relies on some updates to earlier patches in the dependencies, which I'll update soon)

Comment 15

[Justin Dolske [:Dolske]]

Attachment: Screenshot of patch v.1

Should probably lighten the background color over the overlay, it's rather dark. Probably made worse as a result of the SVG filter desaturating the page.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

I think we should lighten instead of darken.  We use a dark page for malware and phishing protection, so even though the user will very rarely see that page, I would like us to use a consistent visual language that a dark content area might be dangerous.  Also lightening the page just seems happier :)

Comment 17

[Paul [pwd]]

Any chance we can wrap some glass around them on Windows 7 as per the doorhangers?

Comment 18

[Josh Tumath]

(In reply to comment #17)
> Any chance we can wrap some glass around them on Windows 7 as per the
> doorhangers?

If we do, it might be better to sort that out in a follow-up bug.

Comment 19

[Jonathan Haas]

(In reply to comment #17)
> Any chance we can wrap some glass around them on Windows 7 as per the
> doorhangers?

Why? This will make them even more native/systemish looking, apart from the obvious sillyness of using it just to be cool. On the other hand, we probably shouldn't use this mac-like design on Windows.

Btw. I miss the text "The pageat www.example.com says:" from the last screenshot. Is this because it's been caused by the urlbar? Else this would be probably a security issue.

Comment 20

[Paul [pwd]]

(In reply to comment #19)
> Why? This will make them even more native/systemish looking, apart from the
> obvious sillyness of using it just to be cool. On the other hand, we probably
> shouldn't use this mac-like design on Windows.

For those very reasons. I think it's important that we keep this inline with the current theme of both the operating system and that of Firefox 4. The doorhangers have more of less laid the groundwork for that. And the current look just doesn't appear to fit the Windows 7 theme.

Comment 21

[Justin Dolske [:Dolske]]

(In reply to comment #19)

> Btw. I miss the text "The pageat www.example.com says:" from the last
> screenshot. Is this because it's been caused by the urlbar? Else this would be
> probably a security issue.

The prompts are essentially part of the page now, so the "The page at..." text is redundant. There's no spoofing concern, because the prompt UI could just as well be implemented by the page itself.

(In reply to comment #20)

> The
> doorhangers have more of less laid the groundwork for that. And the current
> look just doesn't appear to fit the Windows 7 theme.

As noted in comment 0, we deliberately do not want these to look like native prompts. Doorhangers serve a different purpose, and can look different.

Comment 22

[Justin Dolske [:Dolske]]

Attachment: Screenshot (bright variation)

Here's a variation, with Faaborg's suggestion of brightening instead of darkening. [Single line change to use background-color: hsla(0,0%,100%,.8)] Suggested, and I agree, that if we do this the prompt shadow should probably be inset, to further reinforce it's embedded in the page (ala crashed-plugin), and not a floating/draggable entity. Not sure what to do with the now-invisible spotlight behind the dialog.

Shorlander, want to play around with this and see if a brighter design works better?

Comment 23

[Alex Faaborg [:faaborg] (Firefox UX)]

An inset shadow will help to visually establish that these are in fact tab modal (and can't be moved outside of the tab, have to be answered before switching to another tab, etc.)

This is the same reason why we don't want to use a glass border, if the user believe that these are application modal (even though they aren't) then we went to a lot of work for less benefit, since their behavior won't change and they will feel that they must answer the dialog before switching tabs.

Comment 24

[Paul [pwd]]

(In reply to comment #23)
> An inset shadow will help to visually establish that these are in fact tab
> modal (and can't be moved outside of the tab, have to be answered before
> switching to another tab, etc.)
> 
> This is the same reason why we don't want to use a glass border, if the user
> believe that these are application modal (even though they aren't) then we went
> to a lot of work for less benefit, since their behavior won't change and they
> will feel that they must answer the dialog before switching tabs.

If the user feels the need to interact, that's up to the user. This is ultimately about making users' life easier rather than attempting to change the way they interact with the browser. We want these to feel application modal but without hindering the users browsing experience in other tabs. These should look like they are from the application. We most certainly don't want something that looks replicable at the page level so as that some sites attempt to mimic these. Harmless as it was, look at the yellow box at the top of the browser that IE created. A bunch of forums employed HTML/CSS in order to replicate them as sign up invites. We want nothing of the sort here.

Comment 25

[Alex Faaborg [:faaborg] (Firefox UX)]

>If the user feels the need to interact, that's up to the user

It's up to us to correctly set their feelings and expectations.

>rather than attempting to change the way they interact with the browser.

we are very much attempting to change the way users interact with the browser.

>so as that some sites attempt to mimic these

I would be happy for sites to mimic/change these.  These don't contain any form of sensitive information or questions, and if the site implements their own they can have it perfectly match the rest of their design.  Basically we are giving them a lightbox style UI for free, but they are certainly welcome to make their own.

>yellow box at the top of the browser that IE created.
>A bunch of forums employed HTML/CSS in order to replicate them
>as sign up invites.

All of our sensitive dialogs and permission based notifications are being transitioned to a non-spoofable UI over in bug 588240

Comment 26

[Ethan Sisson]

Just another quip here that might be helpful, since it seems the purpose of these prompts isn't quite clear to all:

(In reply to comment #24)
> These should look like they are from the application.

Quite the opposite – they shouldn't look like they are from the application, because they aren't. These prompts are generated by the page (JavaScript), and should identify with the page, not the application, thus they shall have a generic aesthetic like we see here.

In fact, I think the best thing that could happen is for the average user, upon seeing one of these prompts for the first time, to assume that the site has a clever and polished notification/question box built in. In every way we want people to understand that this is something the page is doing, not the application. As Alex pointed out, those who want a more customized solution to prompts can even develop their own implementation and match it visually to their site/application.

Comment 27

[Yann Brelière]

I like the idea of lightening instead of darkening the page (because "we use a dark page for malware and phishing protection"), but it shouldn't look either like a windows vista's or seven's whitened frozen window (http://attachments.techguy.org/attachments/133002d1212665899/ie-crash.jpg).

Comment 28

[Alex Faaborg [:faaborg] (Firefox UX)]

>but it shouldn't look either
>like a windows vista's or seven's whitened frozen window

Interesting point.  It would be generally bad if users felt a small tinge of fear every time a tab modal prompt appeared, thinking that the application might have just crashed.  Unfortunately I can't off the top of my head think of a solution that isn't either darkening or lightening the page.  We could just do the blur, but that doesn't really draw the user's attention to the dialog (unless the blur is really strong, and the dialog does a better job of capturing attention).  I'll give it some more thought.  We might want to land the lightening with blur now and see what feedback we get (and also note if we ourselves experience a quick moment of fear when these panels show up).

Comment 29

[Jonathan Haas]

Attachment: Mockup grey tint

> Unfortunately I can't off the top of my head think of
> a solution that isn't either darkening or lightening the page.

Tint it in grey? In this example I used #aaa with 50% opacity. I think it looks dark enough to not look like a frozen app, and it looks bright enough to not look dangerous.

Comment 30

[[Baboo]]

(In reply to comment #21)
> The prompts are essentially part of the page now, so the "The page at..." text
> is redundant.

The text helps in determining where an alert/confirm box window is coming from, for example when a site embeds HTML content from other domains through iframes.

> There's no spoofing concern, because the prompt UI could just as
> well be implemented by the page itself.

Take the previous example, JS alerts give "iframed" sites an opportunity for deploying a message outside their frame.

Comment 31

[oddMLan]

(In reply to comment #29)
> Created attachment 483765 [details]
> Mockup grey tint
> 
> Tint it in grey? In this example I used #aaa with 50% opacity. I think it looks
> dark enough to not look like a frozen app, and it looks bright enough to not
> look dangerous.

That looks great! Maybe a little bit darker (try using #7F7F7F or #7A7A7A) and less blurry (25% less!) IMHO.

Comment 32

[Justin Dolske [:Dolske]]

Random observation: I'm not really aware of any common convention (visually) for sites doing their own dialog type things, but I _have_ noticed that for sites with "click to view larger photo" features, it's quite common to darken the background around the zoomed image.

EG:

http://www.sparkfun.com/commerce/product_info.php?products_id=9017

A Google Images search also does roughly the same thing (when clicking on a specific image, the site loads grayed out underneath).

So, I'm not sure we can count on reserving darkening the page for "bad" things, because users are already seeing the effect in normal websites. We should probably just go with light/dark/gray/pink based on other factors. I don't really feel strongly either way, though I would note that I like how the contrast of light-dialog on dark-background makes it stand out. [As would dark-on-light, but that seems like it might be a bit weird. I guess it works for the bookmark panel on OS X, though!]

Comment 33

[Alex Faaborg [:faaborg] (Firefox UX)]

>We should probably just go with light/dark/gray/pink based on other factors.

yeah, I think it is worth considering the other situations (phishing, windows crashes), but ultimately I agree we should just go with what works best overall.

Comment 34

[Justin Dolske [:Dolske]]

Attachment: Patch v.2

Updated CSS style from shorlander (lighter tint, button styles, other tweaks) and some cleanup/fixes from me.

Comment 35

[Justin Dolske [:Dolske]]

Attachment: Screenshot of patch v.2

Comment 36

[Dão Gottwald [:dao]]

Comment on attachment 491108 [details] [diff] [review]
Patch v.2

>--- a/toolkit/themes/winstripe/global/tabprompts.css
>+++ b/toolkit/themes/winstripe/global/tabprompts.css

Is this going to be used for gnomestripe? If so, the custom button styling won't fit there. They won't fit XP or, say, classic on Win 7.

> .mainContainer {
>+    padding: 20px;
>+    background-image: -moz-linear-gradient(hsla(0,0%,97%,.9), hsla(0,0%,87%,.9));
>+    border-radius: 8px;
>+    box-shadow: 0 0 0 1px hsla(0,0%,0%,.25) inset,
>+                0 1px 1px hsla(0,0%,0%,.2) inset,
>+                0 1px 2px hsla(0,0%,0%,.1) inset,
>+                0 1px 0 hsla(0,0%,100%,.4);
> }

This seems to lack a text color.

Please use two-space indentation.

Comment 37

[Justin Dolske [:Dolske]]

Attachment: Patch v.3

Fix previous comments. Let's just push the button styling off to a followup, need to get this in soon and we don't need to block on the buttons.

Comment 38

[Dão Gottwald [:dao]]

Comment on attachment 491143 [details] [diff] [review]
Patch v.3

>+++ b/browser/base/content/effects.svg

Shouldn't this be in themes?

>+++ b/toolkit/components/prompts/content/tabprompts.css
>@@ -0,0 +1,30 @@
>+/* Tab Modal Prompt boxes */
>+tabmodalprompt {
>+    width: 100%;
>+    height: 100%;
>+    -moz-box-pack: center;
>+    -moz-box-orient: vertical;
>+}
[...]

nit: indentation again

Comment 39

[Justin Dolske [:Dolske]]

Attachment: Patch v.4

Updated with final review comments.

Comment 40

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/mozilla-central/rev/b1f6e5f93eb8

Filed bug 613704 for the button styles (deferred in comment 37 here).

Comment 41

[barryvan]

Will this styling and interaction change also be applied to the onBeforeUnload dialogs, or does comment 0 mean that only alert(), prompt(), and confirm() will be the only affected dialogs?

Comment 42

[Justin Dolske [:Dolske]]

(In reply to comment #41)
> Will this styling and interaction change also be applied to the onBeforeUnload
> dialogs

From bug 59314 comment 158:

"The only prompts this affects are the window.alert() / .confirm() /
.prompt() calls triggered by pages. Things like HTTP Authentication,
onbeforeunload messages, quit dialogs, etc are unchanged (ie, window-modal
prompts). We'll look at fixing those later, probably after Firefox 4 to
minimize risk."

Comment 43

[Alex Faaborg [:faaborg] (Firefox UX)]

>things like HTTP Authentication,
>onbeforeunload messages, quit dialogs, etc are unchanged (ie, window-modal
>prompts). We'll look at fixing those later, probably after Firefox 4 to
>minimize risk."

Also some of those will use our site identity based arrowpanels, instead of being modal dialog boxes (or in tab modal prompts).