395248 - Larry UI looks like two textboxes: needs to be a button, differentiable from URL in location bar

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Deb Richardson [:dria] (plz NEEDINFO)]

Current UI is confusing.

Comment 1

[Johnathan Nightingale [:johnath]]

I agree, I think.  The current UI makes the SSL domain (on non-EV) look a little too textboxy.  

mconnor suggested we try inverting the gold/white segments, so that the URL bar was always white, and only the larry section turned gold.

Then someone suggested making it look like the search button does (at least in winstripe) -- i.e. match the theme background so that it looks more... buttony.

Another thing I've wanted to do, and which Mossop just brought up again, was only showing the root of wildcard certs, so that, e.g. https://bugzilla.mozilla.org only showed "mozilla.org" in the identity section.  That, to me, just makes sense.  KaiE pointed out that X509 certs make this complicated, since there are potentially multiple places to find the domain information (the CN field is the usual place, but there is an extension that, when present, overrides CN) and that field can have a whole list of domains, so determining what to show is more complicated.  Complicated != impossible though, and this seems like a valuable fix, if only in terms of giving people back some locbar real-estate.

Copying dveditz, because he was worried at one point that I was talking about taking away the gold background (I wasn't), which implies he has an interest in such things.

Comment 2

[Rob Campbell [:rc] (:robcee)]

Attachment: locbarscreenie.png

extra text in the loc bar is offset by a pixel vertically. (Mac intel)

Comment 3

[Rob Campbell [:rc] (:robcee)]

as deb suggested maybe a simple checkmark or icon indicating the domain is recognized could be better. Maybe a ... padlock??

Comment 4

[Dave Townsend [:mossop]]

(In reply to comment #2)
> Created an attachment (id=279972) [details]
> locbarscreenie.png
> 
> extra text in the loc bar is offset by a pixel vertically. (Mac intel)

Johnathan, this matches the picel issue I was seeing when we spoke on IRC

Comment 5

[Johnathan Nightingale [:johnath]]

> Johnathan, this matches the picel issue I was seeing when we spoke on IRC

Actually, I think rob's comment has to do with the relative positioning of larry-text and locbar-text, larry-text being one pixel higher.  I don't think, unless I'm mistaken, that he was complaining about size changes for the location bar as a whole, which is how I understood your earlier comments.

Comment 6

[Dave Townsend [:mossop]]

Ok, but when the location bar was changing size, the url text position was changing relative to the larry text.

Comment 7

[Michael Clackler]

Attachment: Larry UI change mockups

Played around a little in Photoshop trying out some different things to improve the UI using some of the suggestions here.

The present UI is not very discoverable, and it seems a little odd the the UI element used to provide security info remains white while the URL bar changes color.  It would make more since that the Security UI element changes color.

Comment 8

[Robert Sayre]

It doesn't interact with location bar completion, either.

http://people.mozilla.com/~sayrer/2007/09/06/hmm.png

Comment 9

[Alfred Kayser]

Actually, the 'larry' status should be cleared as soon as one types a new address.
It is strange to keep showing the domain and the 'identified/verified' status when one is trying to open another site...

Comment 10

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

Attachment: Making larry look chrome-ish

I'm concerned that we are only using shape to create a distinction between chrome and content.  Everything above a certain line is chrome, everything below a certain line is content.  However, visually color is also a very strong cue.  It is easy to assume that everything that is white is content, and everything that is darker is chrome.  You could even argue that the location bar is content, because the Web site determines what goes in there (by creating a page that exists at that URL).

I've also spoken to users who believe the lock is simply something that the Web site requested that Firefox display (not something we verified, and then decided to display).

For all of these reasons, I think we need to make our identity button look like chrome, in addition to being located in chrome.  We should assume that white == content, even though that isn't entirely accurate.

Comment 11

[Robert Sayre]

Comment on attachment 280429 [details]
Making larry look chrome-ish

So, green means "safe" ?

Comment 12

[Michael Clackler]

Attachment: Larry UI change mockups ver 2

In an effort to centralize the UI discussion this has been moved from bug 395555 so that bug can be closed:

Put together another set of mock ups using the feedback from several bugs.

Done here:

1.  Larry UI box is used as the primary indicator for Identity and encryption
state.  The Larry box is the only box that changes color (white/gold/green),
the URL box remains constantly white (helps the "two text box" situation).  The URL box is kept a constant white in all states providing consistency and eliminating any contrast issues with URL bar places star and/or
livemark icons on colored backgrounds.

2.  Reduced text size in the Larry UI box with slight bold to further visually
remove the idea of typing in the box like the URL area.

3.  Added lock back to Larry UI on URL bar. I know this is something that was
consciously removed but there needs to be a differentiator other than color in
the URL bar UI and the Lock icon is so ingrained in users it would be difficult
to remove.  With the text size reduction in #2, the lock can be added without
taking up any more space in the bar.  Using the lock and gold background on the UI is also consistent with the current UI and povides familiarity.

3.  Changed background color of Info Popup to maintain consistency with the
color state of the URL bar indicator.

4.  Reworded "Identity" to "Owner" and "Location" to "Web Address" as has been
suggested in bug 395295.

5.  All UI states contain both Owner and Web Address validation states in the
same physical location to maintain consistency across all states. (also suggested in bug 395295)

6.  Larry icons changed:
    - Unknown state: Larry waiting with hands at side, ? mark indicating no
information.  Arm not outstretched or holding passport since there is nothing
from website.
    - Domain Verified:  Larry holding passport, but ? mark over passport
indicates something is missing (Owner Identity information not present)
    - Identified Site:  Larry holding passport, check mark above passport
indicating verified state. Check mark moved from agent to passport.

7. The lock icon in the UI popup is changed to the larger icon from the options panel.  The scale of the small icon seems out of place in the popup and it easily gets lost.


The visual confusion of the UI box being a text box is greatly reduced with the
color only in the Larry URL bar indicator, the text size change, and the lock
icon.

I thought about swapping the location of the lock icon and the favicon in the
UI box to keep the favicon next to the URL address as in the "unknown site"
state.  The favicon so far away from the URL looks a little strange.

Comment 13

[Michael Clackler]

Attachment: Larry UI w/ Favicon right justified

In an effort to centralize the UI discussion this has been moved from bug
395555 so that bug can be closed:

Continuing thoughts from comment 12, mockup of Larry URL bar UI with site Favicon right justified in UI box.

This really seems to further remove confusion of where to type a URL.  The
Favicon is a visual "anchor" where the URL is normally directly to the right. 
With the Larry "identity" information between the Favicon and URL, this
continuity is broken.  Placing the Favicon on the right of the Larry UI
directly next to the URL combined with the difference in text style and color between the UI and the URL box have greatly reduced the "two text box" confusion.  This also maintains consistency between all three Larry UI states with respect to the location of the URL in relation to the Favicon.

If the Lock icon is used, placing it on the left side of the UI seems to
reinforce the fact that the UI block is used for more detailed "security"
information.

Comment 15

[Michael Clackler]

Attachment: Favicon rright justified Visa

I played around with browser.css.  This is achieved by including:

#urlbar[level="high"] > .autocomplete-textbox-container,
#urlbar[level="low"] > .autocomplete-textbox-container {
  /*background-color: #F5F6BE;  #F7F898; */
  color: #000000;
}

#identity-box.verifiedDomain {
  background-color: #F5F6BE;
}

#identity-icon-label {
    padding: 1px 2px 2px;
    margin: 0;
    color: black;
    vertical-align: middle;
    font-size: 80%;
    font-weight: bold;
}

Comment 16

[Jesper Kristensen]

(In reply to comment #12)

Padlock and favicon bound even closer together and even easier to confuse.

A lot of words is used to show location/identity. Could it be made simpler?

Comment 17

[Jesper Kristensen]

Attachment: My proposal, ASCII format

- Favicon visually bound to the URL instead of identity ui

- Identity UI has an icon, which is always visible and changes together with the text and background color

- I have put "Unknown" in the UI for plain http sites. Maybe it is overkill. The icon may be enough.

- Encryption gets its own headline, so that there is a clear separation between identity and encryption.

Comment 18

[Jesper Kristensen]

Attachment: More simplified

Here the encryption information is left out. Instead the Identity Unknown dialog tells the user that communication is not secured.

I also added a link for users, who want to learn more about online security. It should probably link to some article on the upcoming Firefox Support website.

Comment 19

[Alfred Kayser]

What is precisely the semantic difference between Identity Verified and Domain Verified? What does it really mean?

For me, all current secure sites, like paypay.com, postbank.com, etc only have Domain Verified (because they don't yet support the latest verification protocols?). But does this mean that they are not secure?

As for the 'Unknown' and the 'Unknown Larry' (used to be Broken Lock), people really didn't want to have this in the URL bar.

I think the new 'larry' box in the URL bar just need to be the 'visual confirmation' of the domain name itself (when it is verified and/or identified) to show that I am really on the postbank.nl and not some phisher site...

Comment 20

[Jesper Kristensen]

(In reply to comment #19)
> What is precisely the semantic difference between Identity Verified and Domain
> Verified? What does it really mean?

Identity Verified means that both the owner and the location of the web site is verified. Domain Verified means that the location is verified, but the owner is not verified.

Example: If the owner is verified to be eBay, you know that it is eBay you are communicating with. If the domain is verified to be ebay-online.com, you have to figure out yourself if that address belongs to eBay or not. Both cases corresponds to the closed lock.

Comment 21

[Jonathan Haas]

Are there plans to change the larry guy icon? IMO it looks very out of place in Windows XP. There may localization aspects, too. (It should look like a policemen, should it? Not recognizeabe for me as a german...)

And the popup should IMHO get a simple 1px border like the menus and the history popup on Windows XP. The 3D-look looks ugly.

Comment 22

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

Attachment: Vista styling idea, SLL and EV Larry

Playing around with more of a button/chrome appearance for the identity button using Vista widgetry

Comment 23

[AndrewM]

(In reply to comment #22)
> Created an attachment (id=281273) [details]
> Vista styling idea, SLL and EV Larry
> 
> Playing around with more of a button/chrome appearance for the identity button
> using Vista widgetry

I really like the colours and styling of the Larry UI part and the places star icon, but I think the location bar and search box should keep their rectangular edges (although with rounded corners perhaps, like in Explorer in Vista?); the curved left edges just don't work IMHO. Also, would the address part of the location bar still change colour?

Comment 24

[Dão Gottwald [:dao]]

(In reply to comment #22)
> Created an attachment (id=281273) [details]
> Vista styling idea, SLL and EV Larry

I can do something like that for Vista/XP/Linux (though likely not rounded for various reasons) once bug 398020 is resolved.

Comment 25

[Jesper Kristensen]

Attachment: Style ideas

Some ideas incorporated into this image:

* Color identity ui instead of the location bar
* Give identity ui a 3d/button look
* Stop showing that the favicon is verified
* Stop overloading the favicon with too much functionality
* Simplify popup wording, remove technical word "encryption"
* Make popup act like a tooltip (use onmouseover/out instead of onclick)
* Bring up Page Info -> Security when clicking the button
* Show the hostname from the cert instead of from the url
* Always show the ui (instead of: lack of indicator = insecure)

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

I think the important things for M9 are:
 - make it look like a button (providing the affordance for clicking), see
attachment 280429 [details] or attachment 281273 [details]
 - make the text visually distinct from the URL

I kinda like the look of things with the favicon right-aligned, since it breaks
the two apart nicely, but that's less important IMO.

I'm also happy to consider ETLD+1 for DV-SSL case, but there's potentially some semantic quibbles about whether or not we're really allowed to say that. To be blunt, I'm not sure of the value of representing DV-SSL at all. But that's a different bug.

Comment 27

[Johnathan Nightingale [:johnath]]

Nominating this to block beta because the current presentation looks like a bug, and if Dao thinks he can get us to something that looks much more like it should, that's absolutely worth taking.

Comment 28

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

Attachment: Curve ratios on each platform

Dao: for the site button, here are the ratios Beltzner and I would like to use on each platform, to give the theme a subtle but through sense of visual integration.

Height of intersecting circle to height of square:
OS X, 1 : 1
Vista: 1.2666 : 1
XP: 1.8666 : 1

Comment 29

[Dão Gottwald [:dao]]

I see two problems with the curves:

- the height of the textboxes is not and should not be fixed on Windows

- we'd lose the textboxes' native appearance that I'm going to resurrect in bug 398020 (attachment 285218 [details]). That means we wouldn't ask the OS to apply its own style to the textbox, but instead we'd have to simulate that style by the use images (which would alienate the appearance with OS themes other than the default one) or plain CSS borders.

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

Let's ignore the curves for now, and just get it looking like a button (as per my previous morph and johnath's blocking nom) 

If we decide on the curves, we'll do it as a seperate bug, though Dao's argument of being able to use the native text widget is pretty weighty.

Comment 31

[Alfred Kayser]

Attachment: How I styled the larry button in my theme (Nautipolis)

This is how I styled it: 
1. it looks more or less like a button (the shading), and has hover/action effect
2. the font is different from the rest (90% bold darkblue/HighlightText)
3. the panel looks like a system panel (uses -moz-Dialog as background) (so it doesn't look like web content)
4. the link changed into a button (only the look&feel), as it opens a dialog (and not a webpage) (The link makes users think that it will open a web page). 

We need to make sure that the Larry information is presented as system/application managed information and not as information coming from the web (which may be faked/insecure).

Comment 32

[Dão Gottwald [:dao]]

(In reply to comment #31)
> 3. the panel looks like a system panel (uses -moz-Dialog as background) (so it
> doesn't look like web content)

I don't know why panels have background-color:menu in the first place. IMHO that's a bug.

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

This blocks beta, IMO, in that either we get this fixed or we need to remove Larry from the beta release, since it's not at all clear that users are expected to click on the text there.

Comment 34

[Dão Gottwald [:dao]]

I need bug 398020 to make this consistent for the Location and the Search bar. Currently the Identity box is inside of the textbox (good), while the Search engine engine button is a sibling of the textbox (bad).

If bug 398020 doesn't make M9, I suggest to simply hide Larry's label (the host) instead of implementing a half-baked solution here or backing out Larry entirely.

Comment 35

[AKIHIRO Misaki (a.k.a Kuden)]

Attachment: need dropmarker

I think that dropmarker is as necessary for Larry as the searchbar. 
It is not understood that the user pushes Larry easily.

Comment 36

[Michael Ventnor]

The Larry button just responds to one click, which opens the panel. So if we run out of time for beta a simple thing we could do is "cursor: pointer;", or whatever the default is for links.

That dropmarker could also help, yes.

Comment 37

[Dão Gottwald [:dao]]

A dropmarker would be semantically wrong. There aren't multiple values to choose from.

Comment 38

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

>I think that dropmarker is as necessary for Larry as the searchbar. 

I agree that in general referencing the appearance of the search engine button is the way to go.

It feels like the way we try to solve individual UI problems in separate bugs is leading to myopic and potentially inconsistent design.  I'm not particularly against specific suggestions listed above, but let's all try to reference design decisions for the site button against other areas of the browser chrome (like the drop marker suggestion), and think carefully about how changes would fit into the interface as a whole.

We need to think about user interface dependencies (conceptually, not literally) if we are going to maintain internal consistency.

For instance, when considering if we should change the cursor to a hand for the site button, we need to think about doing this for the star and search engine buttons as well.  Or to go even higher level, we should start thinking about external consistency, what other applications do cursor changes in chrome?

Comment 39

[Michael Ventnor]

Its not a menu though so a dropmarker might not be appropriate.

If you are really adamant about rushing this beta out the door, then consider that the fact that the cursor doesn't change to an I is proof enough that it isn't a textbox.

We shouldn't even be considering backing out Larry over something thats comparatively insignificant.

But back to the bug, unlike Larry's button the search button doesn't change colour so it might not be the right reference for this, unless you are going to change the yellow and green to a glow like with search engine discovery.

Comment 40

[Dão Gottwald [:dao]]

(In reply to comment #39)
> But back to the bug, unlike Larry's button the search button doesn't change
> colour

It does if the page provides an OpenSearch description.

Comment 41

[Dão Gottwald [:dao]]

Attachment: temporarily hide the label

IMHO that's better than backing out the whole thing.

Comment 42

[Alfred Kayser]

Just as simple is to change the background color to 'threedface' or '-moz-Dialog' and keep the cursor as the default pointer (not hand nor I) to make it clear that the label is not a textbox (This is what I have done in my themes).

The label is very useful and clear for the secure sites (https) as it shows me immediately the status, and will be a big improvement from FF2. Even if the panel is not so discoverable, the label is directly visible, and will help people to better work with 'secure' sites, and will lead people to eventually discover the popup.

So, please keep the label in for FF3, and just change the background-color. Any further design of rounding is not critical and can be handled in a separate bug.

Comment 43

[Michael Ventnor]

I agree with Alfred, I think just giving #identity-box a good background colour is nice and simple for M9. We don't need to compromise any part of Larry, nor should we, especially since the freeze is a little ways off due to the number of outstanding blockers.

ThreeDFace seems to work well, ThreeDLightShadow also looks nice.

Comment 44

[Dão Gottwald [:dao]]

Alfred is confusing M9 with the final release. As far as I know, there are no plans to durably remove the label. For the beta release it's just a less radical solution than removing Larry.
Granted, a solid background color would meet one point of this bug, but it would still be an interim solution; I'm pretty much indifferent of that.

ThreeDLightShadow is a border color, btw.

Comment 45

[Michael Ventnor]

Maybe you could make the label italic? How would that look?

Comment 46

[Dão Gottwald [:dao]]

I think it would look horrific ;-)

I could actually give the box a more final look right now, and take care of the Search engine button in a separate bug. Maybe I'll do that.

Comment 47

[Dão Gottwald [:dao]]

Attachment: patch

Comment 48

[Dão Gottwald [:dao]]

Attachment: patch v2

Adding a background color, because some OS themes don't provide a toolbox appearance.

Comment 49

[Dão Gottwald [:dao]]

Attachment: patch v3

this one actually works on Linux

Comment 50

[Asaf Romano (gone)]

What do you mean by "some OS themes", doesn't winstripe provide usable style rules for a <panel>?

Comment 51

[Dão Gottwald [:dao]]

(In reply to comment #50)
> What do you mean by "some OS themes"

Windows Classic

> doesn't winstripe provide usable style
> rules for a <panel>?

I'm not touching the CSS for the panel, although I do think both the default style and the one applied to this particular panel aren't quite right.

Comment 52

[Asaf Romano (gone)]

Comment on attachment 286694 [details] [diff] [review]
patch v3

eh, i read that wrong, s/border-right/-moz-border-end/

r=mano.

Comment 53

[Dão Gottwald [:dao]]

(In reply to comment #52)
> s/border-right/-moz-border-end/

shouldn't make a difference because of this:

/* Keep the URL bar LTR */

#urlbar .autocomplete-textbox-container {
  direction: ltr;
}

Comment 54

[Asaf Romano (gone)]

Nice catch :)

Comment 55

[Reed Loden [:reed]]

I did s/border-right/-moz-border-end/ on check-in.

Checking in browser/themes/winstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v  <--  browser.css
new revision: 1.110; previous revision: 1.109
done

Comment 56

[Steve England [:stevee]]

Attachment: Larry 'button' on win2k

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007103103 Minefield/3.0a9pre ID:2007103103

For me, larry looks nothing like a button, and after this patch still doesn't look like it's clickable. Buttons have a 3d effect, and generally don't react on hover. Larry's 'button' still looks like unclickable chrome, and gives a non system standard effect when you hover it. At least when it had a white background it was easy on the eyes. Now it looks fugly whilst retaining the impression that you can't interact with it.

Comment 57

[Tracy Walker [:tracy]]

This looks good on Win XP nightly. 
It's not so good on Mac nightly; it's just a white box.  Also for all platforms, shouldn't this button be styled like the "Go" button 'cept with squared corners instead of rounded? (Win XP is fine as is)

I'm inclined to re-open this based on the Mac ugliness alone.

Comment 58

[Reed Loden [:reed]]

Tracy, can you post a screenshot?

Comment 59

[Dão Gottwald [:dao]]

Nothing going to happen here for Mac. There's a new theme to come. For Beta 1, bug 402260 should be good enough as a fix for the "looks like two textboxes" issue on Mac.

(In reply to comment #57)
> Also for all platforms, shouldn't this button be styled like the "Go" button 'cept with
> squared corners instead of rounded?

There will be changes to Go button in the Beta 2 time frame.

Comment 60

[Tracy Walker [:tracy]]

alrighty, then, VERIFIED. Thanks Dao

Comment 61

[Jesper Kristensen]

Now that this bug has turned into a temporary quick fix for beta 1, on what bug(s) should I cc myself to follow further development?

Comment 62

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

>Now that this bug has turned into a temporary quick fix for beta 1, on what
>bug(s) should I cc myself to follow further development?

changes to the site button will likely occur in the tracking bugs for each platform, so:

mac os x: bug# 397723
linux: bug# 381206
windows xp and vista: bug# 405605

Comment 63

[Jesper Kristensen]

(In reply to comment #62)
> changes to the site button will likely occur in the tracking bugs for each
> platform, so:

Is there a specific bug for bringing back the identity text label which this bug removed?

Comment 64

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

>Is there a specific bug for bringing back the identity text label which this
>bug removed?

I know it is still being discussed, johnathan: is there a bug for this yet?

Comment 65

[Johnathan Nightingale [:johnath]]

(In reply to comment #64)
> >Is there a specific bug for bringing back the identity text label which this
> >bug removed?
> 
> I know it is still being discussed, johnathan: is there a bug for this yet?

There is now! bug 406612

Comment 66

[Chris Forbes [:chrisjf]]

Attachment: Mockup of my idea for the Larry Identity Button

Comment 67

[Chris Forbes [:chrisjf]]

(In reply to comment #56)
> For me, larry looks nothing like a button, and after this patch still doesn't
> look like it's clickable. Buttons have a 3d effect, and generally don't react
> on hover. Larry's 'button' still looks like unclickable chrome, and gives a non
> system standard effect when you hover it. 

I agree. The current identity button doesn't look like a button at all. I think it should look like an actual button (see attached GIF image). Users should be able to see right away that the identity button is an actual button.

Comment 68

[(no longer active)]

I think attachment 295983 [details] provides a very nice UI, which, in addition to the "button-ness" factor, also advertises the Larry icon in a nice way.  If you consider the metaphor of Larry being an agent which checks the "passport" of each site (which has a picture -- the favicon -- of it), you'll see that this UI inducts this metaphor well.

Comment 69

[Jesper Kristensen]

(In reply to comment #66)
> Created an attachment (id=295983) [details]
> Mockup of my idea for the Larry Identity Button

That UI will give an even greater false sense of "The favicon is verified by the CA" than the UI before this bug was fixed did.

But I like the other parts of your mockup.

Comment 70

[Chris Forbes [:chrisjf]]

(In reply to comment #69)
> That UI will give an even greater false sense of "The favicon is verified by
> the CA" than the UI before this bug was fixed did.

I don't necessarily think that's true. It's not like there is a big check mark beside the favicon or anything.
Continuing with the Larry-is-a-passport-agent metaphor, Larry is merely looking at the favicon (the passport). He's hasn't made any judgments because there is no visual clue that he has. To see Larry's judgment the user clicks on the button to see details. Anyways, that's my two cents.

Comment 71

[Michael Monreal [:micmon]]

So there is no real benefit having the larry image there. Also, an approach like this would make the toolbar even bigger and the small toolbar mode impossible.

Comment 72

[Chris Forbes [:chrisjf]]

(In reply to comment #71)
> So there is no real benefit having the larry image there. 

The whole idea of having Larry in the button is to let the user see that "Hey, there's a new button on your toolbar! Click me and find out what I do!"

The current "identity button" (aka just the fav icon) doesn't look like a button at all. If it doesn't look like a button, how is the user supposed to discover there is new functionality?

> Also, an approach like this would make the toolbar even bigger and the small
> toolbar mode impossible.

I didn't do my mockup to scale but I'm pretty sure you could make the button the same size as the other regular buttons on the toolbar in addition to keeping the fav icon its normal 16x16 size.
As for the small toolbar mode, I would suggest just having the fav icon because the small toolbar mode is an advanced feature, imo.

I guess I'm concerned about the users who aren't so tech savvy. How are they supposed to know that the fav icon is a new button that verifies the site's identity? (My idea for a solution is a visual clue.)

Comment 73

[Michael Monreal [:micmon]]

Yeah, I really like that FF3 tries to get more awareness to the user!

Small toolbar mode is an "advanced feature" in the way that it is non-default, yes. But what about novice users that set small toolbar some time ago and migrate to FF3 when it is released?

Getting this right is hard... I don't think having a part of the browser being different for first-time users is the way to go, but sure it would be nice to expose the new features.

I have to tell you some more, though. The whole think would be most interesting for non-tech savvy people who are generally unaware of security risks etc. Someone like my father for example. But knowing him, THE HELL would he click a new button to find out what it does. Well, perhaps he's an extrem example (always in fear he can break his computer by doing stuff) but "press everything to see what you get" is not a great UI concept. Sadly I don't have a nice idea myself atm :(

Comment 74

[Jesper Kristensen]

(In reply to comment #72)
> The whole idea of having Larry in the button is to let the user see that "Hey,
> there's a new button on your toolbar! Click me and find out what I do!"

That is mostly not what users do. Users are used to see things they don't understand, and they just don't click it. Also, bug 406612 is going to add the actual identity to the primary UI, which in my opinion is a much better clue. That bug is probably also better for this discussion.