Removing favicon from URL bar

12 views
Skip to first unread message

Mike Beltzner

unread,
Sep 8, 2010, 10:20:30 AM9/8/10
to devapps List
Hi,

Although it's been part of the design mockups for some time, the landing of bug 587901 [1] in the most recent nightly caught me by surprise. I understand the rationale for removing the favicon from the URL bar is that it already exists in the tabstrip, but I think that we reasoned based on mockups not on interacting with the design. We should all try to live with this change for a few days to get over the OMGCHANGE effect, but my initial reactions are:

- when the active tab is all the way to the right of the tabstrip, I cannot clearly associate it with the location in the location bar, and instead find myself trying to map the URL bar to the tab that's immediately above it. Some of this is obviously the leftover effect of me expecting a favicon there

- when the active tab isn't an SSL connection, I find the repetition of the domain to be less useful

- it is indeed the case that looking at the URL bar I can tell what domain I'm connected to much more quickly than before

- for a new tab, the identity drop-down on its own is really kind of meaningless and just adds visual noise

cheers,
mike

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=587901

al...@yahoo.com

unread,
Sep 8, 2010, 11:49:56 AM9/8/10
to
It is, thankfully, still possible to hide the tab bar (with a single tab)
and to move the new tab button to the toolbar. Therefore, since this is a
perfectly reasonable and supported scenario, there should be an option to
keep the favicon in the urlbar.


Joe Drew

unread,
Sep 8, 2010, 11:58:27 AM9/8/10
to dev-apps...@lists.mozilla.org

On 2010-09-08 10:20 AM, Mike Beltzner wrote:
> - when the active tab isn't an SSL connection, I find the repetition of the domain to be less useful

Also, less correct: without SSL, we have no idea whether you're being
MITM'd.

Alexander Limi

unread,
Sep 8, 2010, 3:15:23 PM9/8/10
to Mike Beltzner, devapps List
On Wed, Sep 8, 2010 at 7:20 AM, Mike Beltzner <belt...@mozilla.com> wrote:

> I understand the rationale for removing the favicon from the URL bar is
> that it already exists in the tabstrip, but I think that we reasoned based
> on mockups not on interacting with the design.


It's also worth noting that what has landed now isn't the approach that was
intended; the duplication of the domain in http shouldn't be present.

Eliminating this duplication is tracked in *Bug
588270*<https://bugzilla.mozilla.org/show_bug.cgi?id=588270>— "Reduce
redundancy with the site identity block + URL"


> We should all try to live with this change for a few days to get over the
> OMGCHANGE effect, but my initial reactions are:
>
> - when the active tab is all the way to the right of the tabstrip, I
> cannot clearly associate it with the location in the location bar, and
> instead find myself trying to map the URL bar to the tab that's immediately
> above it. Some of this is obviously the leftover effect of me expecting a
> favicon there
>

Yeah, this is expected, it'll take a while to adjust to this particular
aspect of the change, and this is where OMGCHANGE is most likely to hit.


> - when the active tab isn't an SSL connection, I find the repetition of
> the domain to be less useful
>

Agreed. And it wasn't intended to be like that, see below


> - for a new tab, the identity drop-down on its own is really kind of
> meaningless and just adds visual noise
>

Yeah, that part is clearly a bug, IMO.


The remainder of what should ideally happen with this change is tracked in:

*Bug 588270* <https://bugzilla.mozilla.org/show_bug.cgi?id=588270> — "Reduce
redundancy with the site identity block + URL"

I agree that the way it has landed now is suboptimal, and hopefully we
either get some resources on the second half of this, or we delay it until
later.

Screenshot of how it is intended to look/work:
https://bug587901.bugzilla.mozilla.org/attachment.cgi?id=466515
(ignore the slightly outdated colors/gradients — the interactions and
approach is the same)

--
Alexander Limi · Firefox UX Team · http://twitter.com/limi · http://limi.net

Alexander Limi

unread,
Sep 8, 2010, 3:15:23 PM9/8/10
to Mike Beltzner, devapps List

Axel Hecht

unread,
Sep 8, 2010, 5:07:16 PM9/8/10
to

I'm OMGCHANGE on this one much rather than the current behaviour.
Cutting up urls into buttons and paths makes me wonder which sites offer
the same path much rather than getting identity/privacy information on
the site.

There is a whole slew of OMGCHANGE as I do edit URLs quite frequently in
my online life.

I'd expect the drop down arrow to be on one side of the URL, tbh, not in
the middle of it, I guess that'd take away most of my OMGCHANGE. (I'd at
least had a look from scratch on it.)

Axel

Vladimir Vukicevic

unread,
Sep 8, 2010, 5:15:50 PM9/8/10
to Alexander Limi, devapps List

I'm pretty OMGCHANGE here. I understand the original desire, though I don't agree with it; doesn't it break apart if you have more than a small handful of tabs open, or if a tab scrolls? Also, if any addons move the tab location, the expected relationship between current tab and urlbar is lost. I think the favicon is a pretty important part of a site's visual identity -- e.g. when I visit paypal, I expect to see a green bar /and/ paypal's favicon. If either of those things changes, I notice. Now there's just a fairly generic "paypal.com" sitting in bold in that area, which doesn't have anywhere as near a strong association with the site as the icon does.

I don't think we should remove the favicon.

- Vlad

> --
> Alexander Limi · Firefox UX Team · http://twitter.com/limi ·
> http://limi.net

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

Shawn Wilsher

unread,
Sep 8, 2010, 5:18:24 PM9/8/10
to Vladimir Vukicevic, devapps List, Alexander Limi
On 9/8/2010 2:15 PM, Vladimir Vukicevic wrote:
> [snip] Also, if any addons move the tab location, the expected relationship between current tab and urlbar is lost.[/snip]
I don't think we should be worried about the experience an add-on might
cause in this instance. The add-on could just as easily add the favicon
back if it's moving tabs, right?

Cheers,

Shawn

Gen Kanai

unread,
Sep 8, 2010, 5:25:22 PM9/8/10
to dev-apps...@lists.mozilla.org
I'm with Vlad. I do not think we should remove the favicon.

On 9/9/10 6:15 AM, Vladimir Vukicevic wrote:
> I don't think we should remove the favicon.
>

--
Gen Kanai
http://blog.mozilla.com/gen/

Mike Beltzner

unread,
Sep 8, 2010, 5:31:22 PM9/8/10
to gka...@gmail.com, dev-apps...@lists.mozilla.org
Hey everyone - please don't mistake this newsgroup for an opinion poll. Let's keep the discussion about adding new information, and assume that the UX team is gathering the feedback and will respond.

> It's also worth noting that what has landed now isn't the approach that was intended; the duplication of the domain in http shouldn't be present.

OK, so should we make the former bug depend on this latter, and back it out until both are ready? I don't think we should be landing half-completed designs (unpolished, sure, but we should land in phases / quanta of experience that we want to enable), agreed? It's the nature of our particular system that things get split into multiple bugs, but we can control the nature of their appearance in the tree. Patch queues, ftw!

> Yeah, this is expected, it'll take a while to adjust to this particular aspect of the change, and this is where OMGCHANGE is most likely to hit.

What's the rationale/benefit? There's a lot of information on the theme, and I'm having trouble finding the relevant comment that explains why we want to get rid of the favicon in the URL bar. In the past we've advocating keeping it in there as it's a brand/representation of the site. There have been some arguments about putting web content in a chrome area, though.

cheers,
mike

Michael Lefevre

unread,
Sep 8, 2010, 5:35:09 PM9/8/10
to
On 08/09/2010 20:15, Alexander Limi wrote:
> On Wed, Sep 8, 2010 at 7:20 AM, Mike Beltzner<belt...@mozilla.com> wrote:
>
>> I understand the rationale for removing the favicon from the URL bar is
>> that it already exists in the tabstrip, but I think that we reasoned based
>> on mockups not on interacting with the design.
>
> It's also worth noting that what has landed now isn't the approach that was
> intended; the duplication of the domain in http shouldn't be present.

Sorry to be negative, but I'm not sure it is worth noting. Most users of
Firefox 4 are not going to care too much what was originally planned,
only what is actually released (and my understanding from reading the
bugs is that it is currently intended to release it as it is now).

Michael

Michael Lefevre

unread,
Sep 8, 2010, 5:54:28 PM9/8/10
to Mike Beltzner
On 08/09/2010 22:31, Mike Beltzner wrote:
> Hey everyone - please don't mistake this newsgroup for an opinion poll. Let's keep the discussion about adding new information, and assume that the UX team is gathering the feedback and will respond.
>
>> It's also worth noting that what has landed now isn't the approach that was intended; the duplication of the domain in http shouldn't be present.
>
> OK, so should we make the former bug depend on this latter, and back it out until both are ready? I don't think we should be landing half-completed designs (unpolished, sure, but we should land in phases / quanta of experience that we want to enable), agreed? It's the nature of our particular system that things get split into multiple bugs, but we can control the nature of their appearance in the tree. Patch queues, ftw!

The reason for my previous complaining post was that the intention is
the opposite of what you've just suggested. The latter bug states "this
bug is not planned for Firefox 4".

I take that to mean that the current "quanta of experience" is intended
to be the experience for Firefox 4, and therefore noting that it wasn't
all of what was originally intended does not seem very much worth noting. :(

Michael

Alex Faaborg

unread,
Sep 8, 2010, 7:37:17 PM9/8/10
to Mike Beltzner, dev-apps...@lists.mozilla.org, gka...@gmail.com
>
> What's the rationale/benefit? There's a lot of information on the theme,
> and I'm having trouble finding the relevant comment that explains why we
> want to get rid of the favicon in the URL bar. In the past we've advocating
> keeping it in there as it's a brand/representation of the site.
>

In addition to the redundancy and visual complexity (which by themselves are
bad), the main motivating factor is the design of the new notification
system. The left side of the site identity block is being used to surface
requested and granted disclosure of the user's personal identity (account
manager, password manager, geolocation, audio video stream upload). By
mixing these with a 16x16 icon that can contain anything, we can't have as
much control over the clear presentation of this very privacy sensitive
information. This is detailed at the bottom of the mockup:

https://bug587901.bugzilla.mozilla.org/attachment.cgi?id=466515

Removing stuff is nearly impossible. For instance, I've now entirely given
up on trying to get Firefox to work without an explicit work offline toggle
(while still supporting all of the various extremely rare use cases). So we
certainly aren't surprised to see an OMGCHANGE effect right after this
landed. However, the two main use cases of the previous favicon have
nonetheless remained stable. As an indicator of the site that you are on,
you have the tab itself, and as a drag target you can still drag the site
identity block (bookmarking, to the file system, etc).

A lot of these changes are woven together. For instance, if we cut the site
identity block for the non-ssl case, and brought back the favicon (same as
Firefox 3), site permission based notifications wouldn't be able to anchor
to the same control that you can use to then later revoke those permissions:

https://bug588613.bugzilla.mozilla.org/attachment.cgi?id=467307

We could theoretically anchor access to previous notifications and
permissions to the favicon itself, but that provides a stable interface
under a moving target (one moment the metaphor is a mail icon, then it's a
calendar, then it's a dinosaur). Additionally, it is very difficult to make
something visually appear as an interactive control, while still displaying
an uncontrollable icon on top of it. We introduced a glow effect under the
favicon for Firefox 3, but this was one of the messiest parts of that theme
visually.

-Alex

On Wed, Sep 8, 2010 at 2:31 PM, Mike Beltzner <belt...@mozilla.com> wrote:

> Hey everyone - please don't mistake this newsgroup for an opinion poll.
> Let's keep the discussion about adding new information, and assume that the
> UX team is gathering the feedback and will respond.
>
> > It's also worth noting that what has landed now isn't the approach that
> was intended; the duplication of the domain in http shouldn't be present.
>
> OK, so should we make the former bug depend on this latter, and back it out
> until both are ready? I don't think we should be landing half-completed
> designs (unpolished, sure, but we should land in phases / quanta of
> experience that we want to enable), agreed? It's the nature of our
> particular system that things get split into multiple bugs, but we can
> control the nature of their appearance in the tree. Patch queues, ftw!
>

> > Yeah, this is expected, it'll take a while to adjust to this particular
> aspect of the change, and this is where OMGCHANGE is most likely to hit.
>
> What's the rationale/benefit? There's a lot of information on the theme,
> and I'm having trouble finding the relevant comment that explains why we
> want to get rid of the favicon in the URL bar. In the past we've advocating
> keeping it in there as it's a brand/representation of the site. There have
> been some arguments about putting web content in a chrome area, though.
>
> cheers,
> mike

al...@yahoo.com

unread,
Sep 8, 2010, 7:49:23 PM9/8/10
to
"Alex Faaborg" <faa...@mozilla.com> wrote in message
news:mailman.2919.1283989046...@lists.mozilla.org...

> As an indicator of the site that you are on,
> you have the tab itself

And when the tab bar is hidden? There is no tab. As I mentioned, hiding
the tab bar is useful (it's basically pointless with a single tab) and is
fully supported (there is an option to hide it and its buttons can be moved)
So this scenario should be taken into acount.


Alex Faaborg

unread,
Sep 8, 2010, 7:59:55 PM9/8/10
to al...@yahoo.com, dev-apps...@lists.mozilla.org
>
> So this scenario should be taken into acount.
>

If there is no tab bar, then isn't it pretty obvious which tab is selected?
Either way, I'm fine with us putting the site favicon in the customization
pallet, or tieing it to the pref "always show the tab strip" being turned
off. But for the default out of the box interface, there were a number of
reasons we wanted to remove this redundancy.

-Alex

John Bird

unread,
Sep 8, 2010, 9:08:28 PM9/8/10
to dev-apps...@lists.mozilla.org
Thoughts on this:

1 - The advantage of the favicon is that visual recognition of an icon is
more intuitive/visual for many users, it uses a different part of the brain,
and can be much faster.

2 - I understand the reasons, among others that the favicon can be spoofed
and displaying the domain is a really really good idea.

3 - The various options for showing the URL formatted with segments are all
good too. There may even be space for the favicon too to keep everyone
happy.

4 - The way Vista/Windows 7 displays folders in Windows Explorer also works
very well - when it gets focus it switches to a text string which then can
be completely edited. Users could adopt to something like that well.
With Windows 7 explorer, Clicking to the right or end of the address
switches it, clicking on one of the breadcrumbs gives the drop down options.
In this case having the text repaint and some of the text reposition is not
really a problem - its hard to do it any other way. Something like this
could work very well.

5 - Main question is there anything lost without a favicon? I am guessing
some people either with sight problems or those looking at a foreign
language or foreign text URL might miss the favicon - which being a picture
is pretty universal.

I will watch this with interest, good ideas folks

John Bird


John Bird

unread,
Sep 8, 2010, 9:32:32 PM9/8/10
to dev-apps...@lists.mozilla.org
The latest Go/Refresh/Stop button is simple and elegant, have no problem
with the idea and functionality. It is logical.

-BUT-

There is one issue: Fitts law - its location is far away on the right.

When navigating pages there are several buttons I use a lot -
Back/Forwards/Home/Refresh/Stop. Now one of them is a long way away.
This reason is ergonomics - I have always thought Firefox is superior mainly
in the area of ergonomics:

IE8 puts the home/stop/refresh buttons on the right. Chrome puts its menu
buttons way on the right. When one has a widescreen, or a widescreen
laptop, this is a big ergonomic issue - its a long way to move the mouse.
There is almost nothing else in that part of the screen I ever use.
Bookmarks and Group Your Tabs are on the right, so for them I have got used
to using keyboard shortcuts. I can use CTRL+R or F5 to refresh a page, but
using a mixture of mouse and keyboard for navigating is clumsy. I don't
think there even is a keyboard shortcut for Stop either?

For that reason alone, I would favour a user option to have the Stop/refresh
button on the left. Doesn't have to be the default, but I would vote for it
as an option. When I saw the button had moved, the first few minutes I
went looking for an option to change it to the left - so far there isn't
one. I would likely vote for a Home button option there too. We can
customise toolbars, but not buttons?

Others agree or disagree?

John Bird


Rimas Kudelis

unread,
Sep 9, 2010, 1:38:26 AM9/9/10
to
2010.09.09 02:37, Alex Faaborg rašė:
>>
>> What's the rationale/benefit? There's a lot of information on the theme,
>> and I'm having trouble finding the relevant comment that explains why we
>> want to get rid of the favicon in the URL bar. In the past we've advocating
>> keeping it in there as it's a brand/representation of the site.
>>
>
> In addition to the redundancy and visual complexity (which by themselves are
> bad), the main motivating factor is the design of the new notification
> system. The left side of the site identity block is being used to surface
> requested and granted disclosure of the user's personal identity (account
> manager, password manager, geolocation, audio video stream upload). By
> mixing these with a 16x16 icon that can contain anything, we can't have as
> much control over the clear presentation of this very privacy sensitive
> information. This is detailed at the bottom of the mockup:
>
> https://bug587901.bugzilla.mozilla.org/attachment.cgi?id=466515

Sorry, I don't quite get how having one more icon makes the interface so
much more cluttered than it already is. Couldn't the favicon be moved
inside the button, before the domain name? You could then do pretty much
everything you can do now AND you would have the favicon, right?


There's also another thing I find annoying which I don't know if was or
was not discussed: it's the removal of page title from the window title.
If all those mockups are what is actually planned, then there's quite a
lot of empty space in the window title bar. Why can't that space be used
to display page title like is done in other OS'es?

Rimas

Ron Hunter

unread,
Sep 9, 2010, 3:34:16 AM9/9/10
to
On 9/8/2010 6:59 PM, Alex Faaborg wrote:
>>
>> So this scenario should be taken into acount.
>>
>
> If there is no tab bar, then isn't it pretty obvious which tab is selected?
> Either way, I'm fine with us putting the site favicon in the customization
> pallet, or tieing it to the pref "always show the tab strip" being turned
> off. But for the default out of the box interface, there were a number of
> reasons we wanted to remove this redundancy.
>
> -Alex
>
>
>
I don't consider the favicon as redundant, but leaving that generic icon
certainly IS. If you want to consider the favicon as redundant, then
get rid of the generic one as well, or the argument is moot.


Ron Hunter

unread,
Sep 9, 2010, 3:40:25 AM9/9/10
to
What you describe is exactly why my setup moves the back/forward
buttons, as well as the others, refresh, etc., to the LEFT where my
pointer is usually positioned. An obvious answer.

Dao

unread,
Sep 9, 2010, 5:23:09 AM9/9/10
to
On 08.09.2010 21:15, Alexander Limi wrote:
> The remainder of what should ideally happen with this change is tracked in:
>
> *Bug 588270* <https://bugzilla.mozilla.org/show_bug.cgi?id=588270> — "Reduce
> redundancy with the site identity block + URL"
>
> I agree that the way it has landed now is suboptimal, and hopefully we
> either get some resources on the second half of this, or we delay it until
> later.

Bug 587901 was filed as "Final visual styling of the identity block"
(for Firefox 4, I assume), bug 588270 starts with "note, this bug is not
planned for Firefox 4", so it seems that people aren't on the same page.

Gervase Markham

unread,
Sep 9, 2010, 8:32:20 AM9/9/10
to Joe Drew
On 08/09/10 16:58, Joe Drew wrote:
> Also, less correct: without SSL, we have no idea whether you're being
> MITM'd.

Indeed - in the past, we've avoided highlighting the domain in the
non-SSL case for exactly this reason. Has this decision been knowingly
reversed, or accidentally?

Gerv

Gervase Markham

unread,
Sep 9, 2010, 8:32:51 AM9/9/10
to Alexander Limi, Mike Beltzner
On 08/09/10 20:15, Alexander Limi wrote:
> It's also worth noting that what has landed now isn't the approach that was
> intended; the duplication of the domain in http shouldn't be present.

Ah, super :-)

Gerv


Dao

unread,
Sep 9, 2010, 9:23:22 AM9/9/10
to

Knowingly, as far as I can tell.

It was a bogus argument; by its logic we shouldn't display the location
at all. IE and Chrome highlight the domain without trouble.

Jesper Kristensen

unread,
Sep 9, 2010, 9:51:23 AM9/9/10
to
Den 08-09-2010 16:20, Mike Beltzner skrev:
> Hi,
>
> Although it's been part of the design mockups for some time, the landing of bug 587901 [1] in the most recent nightly caught me by surprise. I understand the rationale for removing the favicon from the URL bar is that it already exists in the tabstrip, but I think that we reasoned based on mockups not on interacting with the design. We should all try to live with this change for a few days to get over the OMGCHANGE effect, but my initial reactions are:

I have noticed that the domain name was displayed in the identity box
for non-SSL sited, but I didn't notice that the favicon was gone before
seeing your message.

It seems that some people like you use the favicon to identify the
current site. I normally use the big area beneath it, the content area.
There is usually a big logo of the page visible, and if not, there is
always a lot of easily recognizable design.

I have always wondered why Firefox claimed that the favicon was verified
by the CA, and is happy to see that gone.

Removing the URL from the (url?) bar seems as the mockup
https://bug587901.bugzilla.mozilla.org/attachment.cgi?id=466515 shows
seems much more radical to me, and I doubt I will like it. But I haven't
tried it yet, so I cannot tell for sure.

Gervase Markham

unread,
Sep 13, 2010, 9:36:17 AM9/13/10
to Dao
On 09/09/10 14:23, Dao wrote:
> Knowingly, as far as I can tell.
>
> It was a bogus argument; by its logic we shouldn't display the location
> at all.

No, that doesn't follow. The domain indicator is a piece of security UI
- you are supposed to be able to trust it. The URL bar, much less so.
IMO, blurring that distinction is to no-one's advantage.

> IE and Chrome highlight the domain without trouble.

What do you mean by "trouble"? Their software doesn't crash more often?

Or do you have some magic way of measuring user confusion, and
determining the success rate of phishing attempts?

Gerv


Ben Bucksch

unread,
Sep 13, 2010, 2:21:38 PM9/13/10
to
On 08.09.2010 16:20, Mike Beltzner wrote:
> - when the active tab isn't an SSL connection, I find the repetition of the domain to be less useful
>
> - it is indeed the case that looking at the URL bar I can tell what domain I'm connected to much more quickly than before

FWIW, I think always showing the domain is a good change. Both against
phishing and to improve usability as beltzner says.

That's independent from the favicon. I do like those. They are also a
proxy icon for the page, which you can drag and drop. Drag&drop of the
*domain* name to link the *page* doesn't make as much sense as the favicon.

Alex Faaborg

unread,
Sep 13, 2010, 2:44:13 PM9/13/10
to Gervase Markham, dev-apps...@lists.mozilla.org
>
> determining the success rate of phishing attempts?
>

While I still strongly believe the very best defense against phishing is to
block the page entirely (as we currently do), it is nonetheless important
for the location bar to visually convey what pieces of information are more
meaningful than others. As far as I can tell the URL highlighting found in
Chrome and IE was first shown publicly with Dao's extension, and I really
think we should have shipped that formatting with Firefox 3. The design
should reflect the reality of the URL's structure, regardless of if users
are going to look at or not, or if it has any effect on preventing phishing,
it is simply easier to understand in the event that they do look at the
location bar.

-Alex

Mike Beltzner

unread,
Sep 13, 2010, 2:48:45 PM9/13/10
to Alex Faaborg, Gervase Markham, dev-apps...@lists.mozilla.org
> Chrome and IE was first shown publicly with Dao's extension, and I really
> think we should have shipped that formatting with Firefox 3. The design

We definitely should have; as I recall the reason that we didn't was that it caused a pretty significant TXul regression. I agree that the design was clearly superior, in that it emphasized the appropriate information without adding significant cost to the overall readbility of the URL structure.

As I recall, that debate also suffered from some bikeshedding around the various options between:

- making the eTLD darker
- splitting up the url into chunks (www.beltzner.ca /mike/archives/whatever)
- removing the http / https indicators

Many of these debates seem silly now, or at least revealing as to how parts of the URL string are more meaningful to those who make browsers than to those who use them. Chunking was perhaps going too far, but visual emphasis and removing the protocol indicator were things that we could easily have done as default, with a "[x] Pretty print URL" preference that could be turned off for the purists.

cheers,
mike

Jesper Kristensen

unread,
Sep 13, 2010, 5:00:40 PM9/13/10
to


Wouldn't it be more logical to drag the star/bookmark button instead of
the favicon or the identity button? If the star button is moved to the
left as in some mockups, the thing to drag would not even move.

Ben Bucksch

unread,
Sep 13, 2010, 8:08:10 PM9/13/10
to
On 13.09.2010 23:00, Jesper Kristensen wrote:
> Wouldn't it be more logical to drag the star/bookmark button instead
> of the favicon or the identity button?

No, because clicking on the star means to bookmark (and a drag requires
a click, and I often cannot prevent accidental single click)

Ben Bucksch

unread,
Sep 13, 2010, 8:29:33 PM9/13/10
to
On 13.09.2010 20:48, Mike Beltzner wrote:
> I agree that the design [of bolding the domain in the URL] was clearly superior

I think the current design is better. The URL is a technical detail. A
detail we all grew very accustomed to, but getting less and less useful
with the URL schemes used today. It's often just glibberish. Most
non-techie users enter only domains anyway. All that's still really
significant is the host, and mainly the second level domain. The current
design highlights the domain clearly.

It's the domain which you have the trust connection with and which is
important for users.

You could even entirely remove the URL from the urlbar [1] without
loosing too much. That's a dramatic change, which almost nobody will
like at first, but it saves a lot of UI space and I think it can work in
practice. If you need to edit the URL, you could have a button that
opens a textfield with the full URL - that's actually only one click
more than now.

I think a lot of your recent designs go in that direction (show only the
essence like domain and username, in a way understandable for normal
users), and for the reasons stated I think it's a good direction.

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=228524>

Reply all
Reply to author
Forward
0 new messages