Deb Richardson [:dria] (plz NEEDINFO) Reporter
	Description • 17 years ago

Current UI is confusing.

	Johnathan Nightingale [:johnath]
	Comment 1 • 17 years ago

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.

	Rob Campbell [:rc] (:robcee)
	Comment 2 • 17 years ago

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

	Rob Campbell [:rc] (:robcee)
	Comment 3 • 17 years ago

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

	Dave Townsend [:mossop]
	Comment 4 • 17 years ago

(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

	Johnathan Nightingale [:johnath]
	Comment 5 • 17 years ago

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

	Dave Townsend [:mossop]
	Comment 6 • 17 years ago

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

	Michael Clackler
	Comment 7 • 17 years ago

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.

	Robert Sayre
	Comment 8 • 17 years ago

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

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

	Alfred Kayser
	Comment 9 • 17 years ago

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

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 10 • 17 years ago

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.

	Robert Sayre
	Comment 11 • 17 years ago

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

So, green means "safe" ?

	Michael Clackler
	Comment 12 • 17 years ago

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.

	Michael Clackler
	Comment 13 • 17 years ago

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.

	Michael Clackler
	Comment 15 • 17 years ago

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;
}

	Jesper Kristensen
	Comment 16 • 17 years ago

(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?

	Jesper Kristensen
	Comment 17 • 17 years ago

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

	Jesper Kristensen
	Comment 18 • 17 years ago

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.

	Alfred Kayser
	Comment 19 • 17 years ago

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

	Jesper Kristensen
	Comment 20 • 17 years ago

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

	Jonathan Haas
	Comment 21 • 17 years ago

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.

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 22 • 17 years ago

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

	AndrewM
	Comment 23 • 17 years ago

(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?

	Dão Gottwald [:dao] Assignee
	Comment 24 • 17 years ago

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

	Jesper Kristensen
	Comment 25 • 17 years ago

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)

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 26 • 17 years ago

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.

	Johnathan Nightingale [:johnath]
	Comment 27 • 17 years ago

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.

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 28 • 17 years ago

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

	Dão Gottwald [:dao] Assignee
	Comment 29 • 17 years ago

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.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 30 • 17 years ago

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.

	Alfred Kayser
	Comment 31 • 17 years ago

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

	Dão Gottwald [:dao] Assignee
	Comment 32 • 17 years ago

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

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 33 • 17 years ago

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.

	Dão Gottwald [:dao] Assignee
	Comment 34 • 17 years ago

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.

	AKIHIRO Misaki (a.k.a Kuden)
	Comment 35 • 17 years ago

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

	Michael Ventnor
	Comment 36 • 17 years ago

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.

	Dão Gottwald [:dao] Assignee
	Comment 37 • 17 years ago

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

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 38 • 17 years ago

>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?

	Michael Ventnor
	Comment 39 • 17 years ago

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.

	Dão Gottwald [:dao] Assignee
	Comment 40 • 17 years ago

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

	Dão Gottwald [:dao] Assignee
	Comment 41 • 17 years ago

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

	Alfred Kayser
	Comment 42 • 17 years ago

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.

	Michael Ventnor
	Comment 43 • 17 years ago

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.

	Dão Gottwald [:dao] Assignee
	Comment 44 • 17 years ago

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.

	Michael Ventnor
	Comment 45 • 17 years ago

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

	Dão Gottwald [:dao] Assignee
	Comment 46 • 17 years ago

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.

	Dão Gottwald [:dao] Assignee
	Comment 48 • 17 years ago

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

	Dão Gottwald [:dao] Assignee
	Comment 49 • 17 years ago

this one actually works on Linux

	Asaf Romano (gone)
	Comment 50 • 17 years ago

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

	Dão Gottwald [:dao] Assignee
	Comment 51 • 17 years ago

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

	Asaf Romano (gone)
	Comment 52 • 17 years ago

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

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

r=mano.

	Dão Gottwald [:dao] Assignee
	Comment 53 • 17 years ago

(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;
}

	Asaf Romano (gone)
	Comment 54 • 17 years ago

Nice catch :)

	Reed Loden [:reed]
	Comment 55 • 17 years ago

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

	Steve England [:stevee]
	Comment 56 • 17 years ago

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.

	Tracy Walker [:tracy]
	Comment 57 • 17 years ago

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.

	Reed Loden [:reed]
	Comment 58 • 17 years ago

Tracy, can you post a screenshot?

	Dão Gottwald [:dao] Assignee
	Comment 59 • 17 years ago

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.

	Tracy Walker [:tracy]
	Comment 60 • 17 years ago

alrighty, then, VERIFIED. Thanks Dao

	Jesper Kristensen
	Comment 61 • 17 years ago

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?

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 62 • 17 years ago

>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

	Jesper Kristensen
	Comment 63 • 17 years ago

(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?

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 64 • 17 years ago

>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?

	Johnathan Nightingale [:johnath]
	Comment 65 • 17 years ago

(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

	Chris Forbes [:chrisjf]
	Comment 67 • 17 years ago

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

	(no longer active)
	Comment 68 • 17 years ago

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.

	Jesper Kristensen
	Comment 69 • 17 years ago

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

	Chris Forbes [:chrisjf]
	Comment 70 • 17 years ago

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

	Michael Monreal [:micmon]
	Comment 71 • 17 years ago

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.

	Chris Forbes [:chrisjf]
	Comment 72 • 17 years ago

(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.)

	Michael Monreal [:micmon]
	Comment 73 • 17 years ago

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

	Jesper Kristensen
	Comment 74 • 17 years ago

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