388135 - Location Bar formatted view: hide certain protocols, don't de-emphasize the path

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Dão Gottwald [:dao]]

Attachment: screenshots

beltzner said he wanted to try this.

Two open questions:

1) Hide http://, https:// and file:// only or ftp:// as well? Not hiding ftp:// would make all protocols distinguishable in the formatted view. Otherwise, it would be not so easy to tell the difference between http:// and ftp://, which might be important or not.

2) For URLs with the protocol visible (e.g. chrome://, possibly ftp://), should the path be black or should it be gray?

Comment 1

[[:Aleksej]]

IMO:
ftp:// *is* important. I guess hiding ftp:// when the URL starts with "ftp." and hiding "http://" when the URL starts with "www." might be OK, though.
Hiding http:// and https:// would be bad when encryption is shown differently than by background color [bug 386896].

The space between the domain and the path is too wide; I'm using bold colored font for domain, and have disabled the spacing, because it's pointless with the other emphasis.

Comment 2

[Dão Gottwald [:dao]]

(In reply to comment #1)
> ftp:// *is* important. I guess hiding ftp:// when the URL starts with "ftp."
> and hiding "http://" when the URL starts with "www." might be OK, though.

I don't think that's an option. If anything, ftp:// wouldn't be hidden at all but http:// always.

> Hiding http:// and https:// would be bad when encryption is shown differently
> than by background color [bug 386896].

I don't understand what you're saying here.

> The space between the domain and the path is too wide;

It's half the width the protocol would take, which is needed to prevent the path from moving when editing the address and allows us to discriminate the path against the domain without making it gray.

> I'm using bold colored
> font for domain, and have disabled the spacing, because it's pointless with the
> other emphasis.

Please join mozilla.dev.apps.firefox to discuss various proposals and make new ones. Boldface is not an option, btw.

Comment 3

[[:Aleksej]]

(In reply to comment #2)
> (In reply to comment #1)
> I don't think that's an option. If anything, ftp:// wouldn't be hidden at all
> but http:// always.

I've just enabled hiding of http:// in my 2004, and it seems fine (though the protocol disappears only after switching to the tab both on this and trunk).
The need of https:// display has already been mentioned in the newsgroup.

> > Hiding http:// and https:// would be bad when encryption is shown differently
> > than by background color [bug 386896].
> I don't understand what you're saying here.

Encryption is displayed by font color of the path to me, and not by background color - not sure if it's the theme, or my Locationbar² settings. The path is short in Bugzilla, and can be non-existent elsewhere. Bug 386896 says against background color.

Comment 5

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

Oops. That was highly embarassing, especially since this one's sitting on my ui-r. Copied this comments from bug 388362:

Bug 366797 introduced a bunch of changes to the location bar, including some
that altered the formatting of a URI to emphasize the TLD+1 portion using
contrast in the text.

Feedback from our developer community is available here:

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_frm/thread/834eedd0c56a21a6/

and our nightly user community here:

http://forums.mozillazine.org/viewtopic.php?t=564386

There are some good takeaways in that feedback, notably:

 - the grey text makes it difficult to read the path-portion of the URI
 - the colour difference is effective in emphasizing TLD+1
 - we need to be careful that we want to emphasize TLD+1 which is susceptible
to MITM attacks

A lot of work was done by Dao in LocationBar^2 to get a design working where the largely implementation-detail protocol was hidden in favour of some slight
spacing between the domain and the path, with the goal of making it easier to
parse those two portions of a URL. There's a comparison of this approach with
the grey-vs-black text here:

http://design-noir.de/bugzilla/fx3-url-formatting.png

For M7, I'd like to try the "proposed approach" above, but without any grey
text at first (which is convenient seeing as the memory leak on the eTLD
service keeps us from using it the way we'd want to, anyway!) to see if we can get some over-the-shoulder testing on whether or not the spacing design makes it easier to parse URIs. Also, I think we should keep the favicons in the location bar for now.

(In reply to comment #0)
> 1) Hide http://, https:// and file:// only or ftp:// as well? Not hiding ftp://
> would make all protocols distinguishable in the formatted view. Otherwise, it
> would be not so easy to tell the difference between http:// and ftp://, which
> might be important or not.

Hide them all, but keep the favicons. If you can come up with a quick icon for FTP (maybe something like "computer_go" from Silk at famfamfam.com?) to use as the favicon, though, that would be great.

> 2) For URLs with the protocol visible (e.g. chrome://, possibly ftp://), 
> should the path be black or should it be gray?

Black. And I agree that the chrome:// protocol should be visible.

Comment 6

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

Comment on attachment 272298 [details]
screenshots

ui-r+ on the "proposed solution" with the exception of making everything grey for now

Comment 7

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

(In reply to comment #5)
> Hide them all, but keep the favicons. If you can come up with a quick icon for
> FTP (maybe something like "computer_go" from Silk at famfamfam.com?) to use as
> the favicon, though, that would be great.

Of course, you've already thought of this over in bug 294800, so I'll meet you over there!

Comment 8

[Dão Gottwald [:dao]]

Attachment: patch

Comment 9

[Dão Gottwald [:dao]]

Attachment: simplified patch

Comment 10

[Brendan Eich [:brendan]]

What are the intended effects of fixing this bug? Comment 0 does not say. I think among the unintended effects will be bad ones to do with hiding https (for those who can't detect color differences, or just those in bad light using a poor quality screen), and in general with hiding the truth.

What's the purpose? We should have a clear rationale before laying hands on code. We should not be experimenting without a falsifiable hypothesis, if not a theory.

/be

Comment 11

[Jesse Ruderman]

And why this experiment in M7?  We haven't even had an alpha with the originally proposed UI (emphasizing the domain) yet.

Comment 12

[Dão Gottwald [:dao]]

(In reply to comment #10)
> What are the intended effects of fixing this bug?

The goal is to make the domain more visible while avoiding the massive use of gray.

> I think among the unintended effects will be bad ones [...]

The single side effect that I know of is that the domain moves as you hover over the location bar. In practice, that didn't turn out to be a problem for me. And in return, you get rid of the transition from gray to black text.

> [...] to do with hiding https
> (for those who can't detect color differences, or just those in bad light using
> a poor quality screen), and in general with hiding the truth.
>
> What's the purpose? We should have a clear rationale before laying hands on
> code. We should not be experimenting without a falsifiable hypothesis, if not a
> theory.

I believe the protocol is an implementation detail that a human shouldn't have to care about. The browser should tell the user if it's using an encrypted connection and that's it. As soon as we define a cryptic part of addresses as one integral part of the UI, we've lost most users. The protocol is useless boilerplate to them. Some might think "https == secure", but is that actually desirable as a rationale?
If the UI boils down to a color change, that is problem. I think there is some work going on to improve that for Firefox 3.

(In reply to comment #11)
> And why this experiment in M7? We haven't even had an alpha with the
> originally proposed UI (emphasizing the domain) yet.

It's still the same experiment -- the idea is to emphasize the domain in a different way. We should make sure to always push for the best UI, in order to improve it again iteratively based on the feedback. Shipping an alpha with the initial implementation just for the fun of it might work once, but you can't ship more alphas for more ideas ...

Comment 13

[Robert Sayre]

(In reply to comment #12)
> 
> It's still the same experiment -- the idea is to emphasize the domain in a
> different way. 

It is not an experiment. That would go something like this:

   1. Define the question
   2. Gather information and resources
   3. Form hypothesis
   4. Perform experiment and collect data
   5. Analyze data
   6. Interpret data and draw conclusions that serve as a starting point for new hypotheses
   7. Publish results


This is more like:

   1. Change location bar
   2. ???
   3. Goal of some sort

I'm not kidding. I honestly have no idea what the goals of these changes are. All of the explanations I have heard are circular, like "the goal of the purple-scrollbar patch is to increase purpleness and awareness of the scrollbar".

Highlighting the domain under this bogus process is one thing, but this is an obvious regression, and a security nightmare.

Comment 14

[Brendan Eich [:brendan]]

The URI scheme is not an implementation detail, any more than dot-separated parts of FQDNs are implementation details, or the port number is an implementation detail. They all matter, novices not understanding all of them notwithstanding. If we change the location bar to remove vital parts of a URI such as the scheme, we will make security exploits easier, not harder; and we will make diagnosing other real-world problems harder, not easier.

This is lose-lose.

Again, it would be good to hear concrete goals and complete definitions: "Make the location bar show only these URI parts, because the rest are 'implementation details', meaning matters of indifference to web browser users." But if you said that, I would declare the matter closed, because the last definition is bogus on its face.

Some day it will all be URNs or persistent Google queries (the latter are used today by many people). In the mean time, the web uses concrete addresses whose parts are all important, even if detailed and confusing to newcomers. Hiding these important detailed facts does all users a disservice.

I could go along with bolding the domain name, even without a better rationale. Any jitter of bold vs. plain text could be fixed, or mitigated, or even lived with if there was a win. But this bug summary's first imperative ("hide certain protocols") is unjustified and wrong-headed.

/be
/be

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #14)
> The URI scheme is not an implementation detail, any more than dot-separated
> parts of FQDNs are implementation details, or the port number is an
> implementation detail.

From Wikipedia:
"In computing, a protocol is a convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints. In its simplest form, a protocol can be defined as the rules governing the syntax, semantics, and synchronization of communication."

That sounds to me like hardware and software should care about it (which is what I meant by "implementation detail"), but not the user. I agree that this applies to the port as well, but then the Location Bar doesn't disclose the default port number.

> They all matter, novices not understanding all of them
> notwithstanding.

They certainly do matter. The question is at what level they do and if they should be a primary part of the primary UI, or if there are better ways to indicate an encrypted connection for instance.
"Novices" sounds like normal non-geeky users would understand protocols if they surf the Web regularly. I think that's neither the case nor a goal.

> If we change the location bar to remove vital parts of a URI
> such as the scheme, we will make security exploits easier, not harder; and we
> will make diagnosing other real-world problems harder, not easier.

"Remove" is a hard term; the editable mode with the plain address would be very discoverable.
It's not obvious to me what kind of security exploits you have in mind.

> Some day it will all be URNs or persistent Google queries (the latter are used
> today by many people). In the mean time, the web uses concrete addresses whose
> parts are all important, even if detailed and confusing to newcomers. Hiding
> these important detailed facts does all users a disservice.

I don't think we do users a service if we confuse them.
Regarding your use of "newcomers", see my comment about "novices" from above. Only a fraction of newcomers becomes experts after some time.

> I could go along with bolding the domain name, even without a better rationale.
> Any jitter of bold vs. plain text could be fixed, or mitigated

How?

Comment 16

[Brendan Eich [:brendan]]

(In reply to comment #15)
> (In reply to comment #14)
> > The URI scheme is not an implementation detail, any more than dot-separated
> > parts of FQDNs are implementation details, or the port number is an
> > implementation detail.
> 
> From Wikipedia:

Please. We're not talking about TCP vs. UDP here, or whether the link layer involves ATM cells or Ethernet packets.

> That sounds to me like hardware and software should care about it (which is
> what I meant by "implementation detail"), but not the user.

The user of software must care about a great many details that can't and should not be abstracted fully or at all.

> I agree that this
> applies to the port as well, but then the Location Bar doesn't disclose the
> default port number.

I wasn't talking about defaults. Would you hide a non-default port number? It is an implementation detail by your own definition (don't drag Wikipedia into it; that quote said nothing about "implementation detail" and what users should or should not see).

> > They all matter, novices not understanding all of them
> > notwithstanding.
> 
> They certainly do matter. The question is at what level they do and if they
> should be a primary part of the primary UI, or if there are better ways to
> indicate an encrypted connection for instance.

There must be several ways to indicate "secure connections". You may have missed the past Mozilla bugs where (some involved redirects) the lock icon and even the gold background "stuck" and the http: URL was the only thing that indicated an insecure connection. We require defense in depth, including in the UI, meaning redundancy.

> "Novices" sounds like normal non-geeky users would understand protocols if they
> surf the Web regularly. I think that's neither the case nor a goal.

"Novices" are not the design point and should not be. The point is not whether anyone understands all the protocols. The point is that http: is not https: and you should not erase the scheme so as to make them appear to be the same (in the face of other bugs as noted above, or of the user simply missing the other clues or not being capable of recognizing them).

> It's not obvious to me what kind of security exploits you have in mind.

See above.

> I don't think we do users a service if we confuse them.

Name any study that showed user confusion due to the URI scheme, as opposed to any other part of the URI including the domain name (even just the bolded bits).

> Regarding your use of "newcomers", see my comment about "novices" from above.
> Only a fraction of newcomers becomes experts after some time.

I'm using newcomers to argue against removing vital information that they may miss or not understand. You are using it to optimize for "novices" assuming they are confused by URI schemes. I cited cases where URI scheme was necessary. You have not demonstrated any user confusion.

Worse, it seems you think the issue of URI fidelity, which means showing the entire string, is addressed by the plain text "edit" or "hover" mode. That's bad on two counts: first, users won't do it when they're being attacked or trying to help diagnose a benign error; second, it makes the GUI elements in question jump around. That's always a design problem in my experience.

> > I could go along with bolding the domain name, even without a better rationale.
> > Any jitter of bold vs. plain text could be fixed, or mitigated
> 
> How?

Use bold and plain fonts and sizes that happen to align perfectly or "close enough".

But I made a mistake bringing up bolding of the TLD, because that was also based on confused or unstated theory, unfalsifiable hypotheses, and zero experiments.

/be

Comment 17

[Brendan Eich [:brendan]]

When I use a filesystem pathname in Unix, or a Windows full C:\Luser\... pathname, I need to read and write every part. The name has meaning. It's not the case that I can shorthand except using relative pathnames, including filenames in the current working directory.

The location bar is where URIs are read and written. URI fidelity counts as much there as anywhere. When you're talking to your ISP or IT department, trying to diagnose a problem; when you think you've been hacked and you are looking closely for clues; when you glance at the string regularly and you memorize it; all of these cases do not want our fancy location bar censoring parts of the URI, any more than a filesystem interface should pretend to hide disambiguating details.

Again, where is the evidence that any user is "confused" by the URI scheme but not other parts, and shoult not see the scheme (or other parts) in normal use cases (not when editing or hovering)?

/be

Comment 18

[Ka-Ping Yee]

(In reply to comment #5)
> Oops. That was highly embarassing, especially since this one's sitting on my
> ui-r. Copied this comments from bug 388362:
> 
> Bug 366797 introduced a bunch of changes to the location bar, including some
> that altered the formatting of a URI to emphasize the TLD+1 portion using
> contrast in the text.
> 
> Feedback from our developer community is available here:
> http://groups.google.com/group/mozilla.dev.apps.firefox/browse_frm/thread/834eedd0c56a21a6/
> 
> and our nightly user community here:
> 
> http://forums.mozillazine.org/viewtopic.php?t=564386

There is a lot of rehashing in that discussion of issues that were
clearly set out much earlier, when this was first proposed.  There
are good and logical reasons why grey is the best of the options
considered.  For a summary of the arguments, please see:

http://groups.google.com/group/mozilla.dev.apps.firefox/msg/9f08af3d1aac4234

Also note that you're usually more likely to get feedback from
people who dislike the change than those that are fine with it.
But you probably know that already. :)

Comment 19

[Ka-Ping Yee]

Hiding the scheme is a big mistake, in my opinion.

Like it or not, a URL is a piece of syntax that users must interact
directly with.  It's fundamental.  Users have to know how to type
URLs and copy URLs.  We can't change the syntax.

Deleting the scheme is changing the syntax.  Adding spaces is changing
the syntax.

Maintaining a direct correspondence among URLs in all contexts is
important.  URLs appear:

  - in the location bar
  - in the status bar
  - in printed documents
  - in HTML
  - in user-entered content (blog posts, comment forms, etc.)

We've got to keep the syntax everywhere the same.  If we change
the syntax in the location bar, it becomes inconsistent with all
the rest.  I can bet that some users will type spaces after the
domain name; some users will no longer understand that the URL
can be copied and pasted as a single entity.

For one thing, you'll get many more errors by web page authors
entering incorrect links like <a href="google.com">this</a>.
But now that many people who don't write web pages are entering
content into comment boxes and such, even more people will fall
prey to this confusion.

http://foo.com/ is not the same as https://foo.com/ or ftp://foo.com/.
It's a different entity; therefore the syntax must be different,
and the UI must faithfully represent that difference.

Comment 20

[Dão Gottwald [:dao]]

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > The URI scheme is not an implementation detail, any more than dot-separated
> > > parts of FQDNs are implementation details, or the port number is an
> > > implementation detail.
> > 
> > From Wikipedia:
> 
> Please. We're not talking about TCP vs. UDP here, or whether the link layer
> involves ATM cells or Ethernet packets.

So what are the differences between HTTP, HTTPS and FTP that a user should care about?

> > That sounds to me like hardware and software should care about it (which is
> > what I meant by "implementation detail"), but not the user.
> 
> The user of software must care about a great many details that can't and should
> not be abstracted fully or at all.

s/can't/currently aren't/. I think there's room for improvement. Assuming full abstraction is possible, why shouldn't it be done?

> > I agree that this
> > applies to the port as well, but then the Location Bar doesn't disclose the
> > default port number.
> 
> I wasn't talking about defaults. Would you hide a non-default port number? It
> is an implementation detail by your own definition (don't drag Wikipedia into
> it; that quote said nothing about "implementation detail" and what users should
> or should not see).

The proposal is to hide a small set of the common boilerplate protocols, so we're kind of talking about defaults, although it's not entirely the same as with the single default port number.
As the missing port implies 80, a hidden protocol could imply HTTP to start with. We could then add an icon for FTP (bug 294800), revise the secure site UI, and probably stop to show the favicon of random sites in the Location Bar to streamline the UI, back up its clearness and remove a spoofing vector.

> There must be several ways to indicate "secure connections". You may have
> missed the past Mozilla bugs where (some involved redirects) the lock icon and
> even the gold background "stuck" and the http: URL was the only thing that
> indicated an insecure connection. We require defense in depth, including in the
> UI, meaning redundancy.

That's not less a debacle if the protocol is shown. The consequence of your fear would be to reduce the fault-prone and never-perfect UI to a minimum (well, remove it) and rely on the protocol entirely, because that's the part that a user can trust.

> > "Novices" sounds like normal non-geeky users would understand protocols if they
> > surf the Web regularly. I think that's neither the case nor a goal.
> 
> "Novices" are not the design point and should not be. The point is not whether
> anyone understands all the protocols. The point is that http: is not https: and
> you should not erase the scheme so as to make them appear to be the same (in
> the face of other bugs as noted above, or of the user simply missing the other
> clues or not being capable of recognizing them).

This assumes that the UI to communicate the important differences sucks, but I say it doesn't have to suck.

> Name any study that showed user confusion due to the URI scheme, as opposed to
> any other part of the URI including the domain name (even just the bolded
> bits).

My thinking is based on observing friends, my family, myself etc. I'm not sure whether you're claiming that both the scheme and the domain name are confusing or that none of them is.
An important point is that domain names are communicated and typed by users. The next point is that there's some brain action required to extract the domain from the address and the site name from the domain:
http://img185.imageshack.us/img185/5858/addressdm2.png (from http://cups.cs.cmu.edu/antiphishing_phil/)
I think that's not as simple as it could be and results in many users ignoring the address. I don't have a study to back that up, sorry. (You wrote "even if detailed and confusing to newcomers" though, so we should be able to discuss that as a hypothesis at least.)

> Use bold and plain fonts and sizes that happen to align perfectly or "close
> enough".

Right, I don't know how to do that.

> But I made a mistake bringing up bolding of the TLD, because that was also
> based on confused or unstated theory, unfalsifiable hypotheses, and zero
> experiments.

My Locationbar extension was an experiment, but I guess it's not scientific enough or something.

(In reply to comment #17)
> When I use a filesystem pathname in Unix, or a Windows full C:\Luser\...
> pathname, I need to read and write every part.

No, you don't need to write every part. You can use a tree-like UI that doesn't even have to start at the root. That's not comparable to URLs, but at least there is some abstraction going on.

> The location bar is where URIs are read and written. URI fidelity counts as
> much there as anywhere. When you're talking to your ISP or IT department,
> trying to diagnose a problem; when you think you've been hacked and you are
> looking closely for clues; when you glance at the string regularly and you
> memorize it;

There are several ways how the communication could happen. You could write an e-mail and a) attach a screenshot (which would include the primary non-sucky UI) or b) copy&paste the address. c), you could actually talk to the expert, in which case he or she could ask you about the UI (the lock icon currently) rather than the scheme or tell you to put your cursor into the address bar.

> all of these cases do not want our fancy location bar censoring
> parts of the URI, any more than a filesystem interface should pretend to hide
> disambiguating details.

Ironically, Windows does hide known file extensions by default, and there are magic locations such as "My Documents".

(In reply to comment #19)
> Like it or not, a URL is a piece of syntax that users must interact
> directly with.  It's fundamental.  Users have to know how to type
> URLs and copy URLs.

Users don't type schemes.

> We've got to keep the syntax everywhere the same.  If we change
> the syntax in the location bar, it becomes inconsistent with all
> the rest.  I can bet that some users will type spaces after the
> domain name; some users will no longer understand that the URL
> can be copied and pasted as a single entity.

As soon as you try to copy it, you'll find out.

> For one thing, you'll get many more errors by web page authors
> entering incorrect links like <a href="google.com">this</a>.

Yeah, or <a href="  google.com  /search">this</a>.
As far as I can tell, users authoring HTML largely copy and paste URLs. Links to main pages might be typed directly, but then even today, you can't type "google.com" as you do in the Location Bar.

> But now that many people who don't write web pages are entering
> content into comment boxes and such, even more people will fall
> prey to this confusion.

Users who don't know about URLs don't write HTML into comment boxes or already fail today.

> http://foo.com/ is not the same as https://foo.com/ or ftp://foo.com/.
> It's a different entity; therefore the syntax must be different,
> and the UI must faithfully represent that difference.

Yes, the UI must do that.

Comment 21

[Ka-Ping Yee]

(In reply to comment #20)
> So what are the differences between HTTP, HTTPS and FTP that a user
> should care about?

http://foo.com/, https://foo.com/, and ftp://foo.com/ are different sites.
This has been pointed out many times.

> As the missing port implies 80, a hidden protocol could imply HTTP to start
> with. We could then add an icon for FTP

An icon doesn't show the user what to type.  And how is the user supposed
to learn this icon and know what it means?

The simplest way to show the user what to type is... to show the user what
to type.  No rocket science here.

> you could actually talk to the expert, in
> which case he or she could ask you about the UI (the lock icon currently)
> rather than the scheme

How do you propose to get all the major browsers to standardize on the
scheme-to-icon mapping?

> Users don't type schemes.

If you want to get to an FTP or HTTPS site, you *must* type the scheme.

> Users who don't know about URLs don't write HTML into comment boxes or
> already fail today.

I don't think so.  You don't have to know much about a URL to type what
you see in the location bar into a box.  Whether the textarea accepts
HTML or Wiki syntax or some other messageboard syntax, people still
copy what they see in the location bar and put it in the box.

Making the text in the location bar change for a copy as compared to
normal viewing is going to be confusing.  The content of the URL textbox
does not change when you click on it; so the text should not change.
If you never see the scheme in the location bar, you're less likely to
understand that it's important to include the scheme when you're copying
and pasting.

Consistency is important, and especially important in two-way UI elements
(those which represent both something the computer communicates to the user
and something the user can communicate to the computer).

Comment 22

[Dão Gottwald [:dao]]

(In reply to comment #21)
> http://foo.com/, https://foo.com/, and ftp://foo.com/ are different sites.
> This has been pointed out many times.

I want the UI to communicate whatever that difference means to the user. A protocol abbreviations is a bad UI.

> > As the missing port implies 80, a hidden protocol could imply HTTP to start
> > with. We could then add an icon for FTP
> 
> An icon doesn't show the user what to type.

Users are not expected to type schemes.

> And how is the user supposed
> to learn this icon and know what it means?

In case of FTP, by looking at the icon and the content?

> The simplest way to show the user what to type is... to show the user what
> to type.  No rocket science here.

Right. Users -- if they don't follow links or search for names -- type site names, as a whole or combined with auto completion.

> > you could actually talk to the expert, in
> > which case he or she could ask you about the UI (the lock icon currently)
> > rather than the scheme
> 
> How do you propose to get all the major browsers to standardize on the
> scheme-to-icon mapping?

Other can follow, but nobody is going to force them. Firefox itself is major enough to awaken the expert.

> > Users don't type schemes.
> 
> If you want to get to an FTP or HTTPS site, you *must* type the scheme.

No, you don't have to. Firefox prepends ftp.* with ftp://. Also, you're ignoring that users often don't type addresses at all, which is actually an essential principal of the Web. There are hyperlinks. And of course, HTTP sites redirect to HTTPS sites.

> > Users who don't know about URLs don't write HTML into comment boxes or
> > already fail today.
> 
> I don't think so.  You don't have to know much about a URL to type what
> you see in the location bar into a box.  Whether the textarea accepts
> HTML or Wiki syntax or some other messageboard syntax, people still
> copy what they see in the location bar and put it in the box.

Yes, maybe. Maybe it increases the number of users failing. But trial and error works, and focusing the Location Bar and actually copying the address is easy enough to tell others about it. I don't think it's a showstopper.

Comment 23

[[:Aleksej]]

(In reply to comment #22)
> (In reply to comment #21)
> > http://foo.com/, https://foo.com/, and ftp://foo.com/ are different sites.
> > This has been pointed out many times.
> 
> I want the UI to communicate whatever that difference means to the user. A
> protocol abbreviations is a bad UI.

So are small icons.

> > > Users don't type schemes.
> > If you want to get to an FTP or HTTPS site, you *must* type the scheme.
> 
> No, you don't have to. Firefox prepends ftp.* with ftp://.

Oh, fine, may I link to a file I found at ftp.mozilla.org I got to that way?

> And of course, HTTP sites redirect to HTTPS sites.

That would be nice! Unfortunately, it's not true. :(

Comment 24

[Brendan Eich [:brendan]]

(In reply to comment #20)
> > Please. We're not talking about TCP vs. UDP here, or whether the link layer
> > involves ATM cells or Ethernet packets.
> 
> So what are the differences between HTTP, HTTPS and FTP that a user should care
> about?

That these are the concrete terms by which URIs are named, not the link layer or other lower-level protocols over which URIs *do* abstract. Not everything can or should be abstracted away!

> s/can't/currently aren't/. I think there's room for improvement. Assuming full
> abstraction is possible, why shouldn't it be done?

That assumption is unwarranted and IMHO bogus, and gratuitous or just plain bad abstraction shouldn't be done without reasoning and evidence.

I am glad Ka-Ping and Aleksej commented, so I won't repeat what they wrote in response to your comment 20.

Two more things, though. First:

> Ironically, Windows does hide known file extensions by default, and there are
magic locations such as "My Documents".

This is a constant thorn in the side of anyone having to type Windows pathnames. And since we are arguing about the Location Toolbar here, which is used to type URIs as well as read them, arguing about tree-like navigation with pictures is irrelevant. The location bar is an input and an output device. Stop treating it as only an output device based on unproven assumptions such as "users only ever click on links".

Second, you wrote, in separate comments:

> Users don't type schemes.

and

> Users are not expected to type schemes.

The first assertion is patently false. The second is interestingly different from the first (why?) and more: it is not evidence for any change such as this bug proposes -- it is a statement about your own expectation, used as a reason for the change. Sayre's right, you are arguing circularly.

What problem is solved by bogusly abstracting away URI scheme, a concrete syntactic element of URIs that must mean the same thing in all contexts? What problem are you so intent on solving, and how would you quantify it so you could demonstrate that you solved it? Please specify. This bug should not go anywhere without such a spec.

/be

Comment 25

[Brendan Eich [:brendan]]

I should hasten to add that I can only argue with Dão and anyone else willing (as Dão is, and good for him) to comment here in favor of fixing this bug. If you are a silent partner of Dão's (mconnor? beltzner? gavin?), my comments apply to you too, and it would be great to hear something other than crickets chirping.

I'm not flaming, but I am completely serious about needing a description of the problem to solve, and a spec for the solution that's founded on sound theory, which means claims that can be falsified by experiments and analysis to rule out confounding variables, free of post-hoc patching and fudging, etc. -- IOW by something resembling the scientific method at its best. Sorry, I don't see it here.

/be

Comment 26

[Dão Gottwald [:dao]]

(In reply to comment #23)
> > I want the UI to communicate whatever that difference means to the user. A
> > protocol abbreviations is a bad UI.
> 
> So are small icons.

The icon is one solution, merely as hint for FTP listings.

> > > If you want to get to an FTP or HTTPS site, you *must* type the scheme.
> > 
> > No, you don't have to. Firefox prepends ftp.* with ftp://.
> 
> Oh, fine, may I link to a file I found at ftp.mozilla.org I got to that way?

No. Firefox prepends it today so that users don't have to type ftp://, and you can't type links this way today. I suggest you file a new bug on this inconsistency.

> > And of course, HTTP sites redirect to HTTPS sites.
> 
> That would be nice! Unfortunately, it's not true. :(

http://mail.google.com/

(In reply to comment #24)
> > Ironically, Windows does hide known file extensions by default, and there are
> magic locations such as "My Documents".
> 
> This is a constant thorn in the side of anyone having to type Windows
> pathnames. And since we are arguing about the Location Toolbar here, which is
> used to type URIs as well as read them, arguing about tree-like navigation with
> pictures is irrelevant.

It wasn't me who came up with file systems, and I also said they are not comparable.

> The location bar is an input and an output device. Stop
> treating it as only an output device based on unproven assumptions such as
> "users only ever click on links".

Please don't put statements in my mouth that were never made. I wrote "users often don't type addresses at all [...]. There are hyperlinks." I also wrote they "type site names", so I'm hardly treating it as an output device.

> Second, you wrote, in separate comments:
> 
> > Users don't type schemes.
> 
> and
> 
> > Users are not expected to type schemes.
> 
> The first assertion is patently false. The second is interestingly different
> from the first (why?)

Because the context is another one. I adhere to both statements. I should add  "most" to the first statement, otherwise such a statement is insane of course. But then the proposed change doesn't prevent advanced users from typing schemes.

> What problem is solved by bogusly abstracting away URI scheme, a concrete
> syntactic element of URIs that must mean the same thing in all contexts? What
> problem are you so intent on solving, and how would you quantify it so you
> could demonstrate that you solved it? Please specify.

You may claim that my thinking is wrong or that I didn't refer to studies, but I did say that schemes are a bad UI, not understood by many users, maybe even confusing them which results in them ignoring the Location Bar. Also, I'm trying to invert the arguing a bit by asking what the schemes are needed for as a UI element. Any element that isn't inherently required should at least not be immune against being considered for removal.

(In reply to comment #25)
> If you are a silent partner of Dão's (mconnor? beltzner? gavin?)

That reminds me of another thing: Please stop biting gavin. I'm not saying you did, but at least sayre did (sometimes it sounded like a joke, sometimes it didn't). I'm glad that he's helping with the code, even though I could imagine that he doesn't agree with all changes.
No doubt that mconnor or beltzner will have to comment.

Comment 27

[[:Aleksej]]

(In reply to comment #26)
> (In reply to comment #23)
> > > No, you don't have to. Firefox prepends ftp.* with ftp://.
> > 
> > Oh, fine, may I link to a file I found at ftp.mozilla.org I got to that way?
> 
> No. Firefox prepends it today so that users don't have to type ftp://, and you
> can't type links this way today. I suggest you file a new bug on this
> inconsistency.

Sorry, what inconsistency?
I'm talking about ftp://ftp.mozilla.org/ being a worse choice for linking to than http://ftp.mozilla.org/. Or am I wrong?

> > > And of course, HTTP sites redirect to HTTPS sites.
> > That would be nice! Unfortunately, it's not true. :(
> 
> http://mail.google.com/

http://mail.yandex.ru/
or worse, http://stat.corbina.net/ - an ISP account control panel accessible from outside.

Comment 28

[Dão Gottwald [:dao]]

(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #23)
> > > > No, you don't have to. Firefox prepends ftp.* with ftp://.
> > > 
> > > Oh, fine, may I link to a file I found at ftp.mozilla.org I got to that way?
> > 
> > No. Firefox prepends it today so that users don't have to type ftp://, and you
> > can't type links this way today. I suggest you file a new bug on this
> > inconsistency.
> 
> Sorry, what inconsistency?
> I'm talking about ftp://ftp.mozilla.org/ being a worse choice for linking to
> than http://ftp.mozilla.org/. Or am I wrong?

Personally, I don't care in that case, but I'm also not sure what that question means to this bug. I'm not claiming that these sites are technically the same, although I bet most users couldn't tell the difference. Bug 294800 is about to make a visible difference.

> > > > And of course, HTTP sites redirect to HTTPS sites.
> > > That would be nice! Unfortunately, it's not true. :(
> > 
> > http://mail.google.com/
> 
> http://mail.yandex.ru/
> or worse, http://stat.corbina.net/ - an ISP account control panel accessible
> from outside.

I didn't make an absolute statement; it's up to the site.

Comment 29

[Dão Gottwald [:dao]]

(In reply to comment #12)
> The single side effect that I know of is that the domain moves as you hover
> over the location bar. In practice, that didn't turn out to be a problem for
> me. And in return, you get rid of the transition from gray to black text.

(In reply to comment #16)
> Worse, it seems you think the issue of URI fidelity, which means showing the
> entire string, is addressed by the plain text "edit" or "hover" mode. [...]
> it makes the GUI elements in question jump around. That's always a design
> problem in my experience.

I'd like to stress this: I've enabled it for quite some time and don't think it's disturbing. The color change does feel noisy to me, although I'm not sure why -- intuitively, I would have thought that a transition from gray to black is less complex. One reason why this doesn't seem to be the case is probably that the path is often longer than the host.
I also think you should trust beltzner on this point.

Comment 30

[Robert Kaiser]

I'm all for making it easier for users to parse URIs. They're useful, but not user-friendly, OK, that's true. Still, we are a browser and a browser consists of a widget that allows to display and change those location identifiers as well as an area to show the content of the document at that location.
The "protocol" or "schema" in front of the :// part of the URI is probably the most important part of the whole URI though, as it does not only specify some mere protocol for communication, it even more specifies what the parts on the left of the URI mean and how the URI should be parsed. There are schemas/protocols that exclude the server part, for example, like the "file" one.
IMHO, we can't just exclude that specifier just because some of them are usual or act very similar in many cases.
I'm all for making it easier to parse, but excluding parts of the URI from display is against web standards and logic, I believe.

Comment 31

[Dão Gottwald [:dao]]

(In reply to comment #30)
> The "protocol" or "schema" in front of the :// part of the URI is probably the
> most important part of the whole URI though, as it does not only specify some
> mere protocol for communication, it even more specifies what the parts on the
> left of the URI mean and how the URI should be parsed. There are
> schemas/protocols that exclude the server part, for example, like the "file"
> one.

The styling separates the host from the path, which means that you can identify file:// URIs (empty host) at a glance. The pref could be set to "http https ftp" (i.e. not "file"), but I think that makes little sense.

Comment 32

[Brendan Eich [:brendan]]

(In reply to comment #29)
> I'd like to stress this: I've enabled it for quite some time and don't think
> it's disturbing.

I'm used to it, and it never caused me much stress (well done font sizes help). Others disagree, some vehemently -- news at 11.

> I also think you should trust beltzner on this point.

What has an argument from authority got to do with any of this? Science, please!

/be

Comment 33

[Dão Gottwald [:dao]]

(In reply to comment #32)
> (In reply to comment #29)
> > I also think you should trust beltzner on this point.
> 
> What has an argument from authority got to do with any of this? Science,
> please!

_on this point_, i.e. gray text vs. the moving host. I wasn't referring to all issues raised in this bug.

Comment 34

[Brendan Eich [:brendan]]

(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #29)
> > > I also think you should trust beltzner on this point.
> > 
> > What has an argument from authority got to do with any of this? Science,
> > please!
> 
> _on this point_, i.e. gray text vs. the moving host. I wasn't referring to all
> issues raised in this bug.

On this point, as on any other, argument from authority is a fallacy in our rationalist, Enlightenment-era Mozilla regime.

I know there are limits to reason alone, but c'mon.

And responding to an earlier comment, I never big Gavin. Gavin's great. I think we need a group hug, and then back to the lab and evidence-based bug filing and patching.

/be

Comment 35

[Brendan Eich [:brendan]]

> And responding to an earlier comment, I never big Gavin. Gavin's great. I think

s/big/bit/

I need coffee!

/be

Comment 36

[Brendan Eich [:brendan]]

The gist of our disagreement seems to be this:

Dao-proxy: most people do not type schemes, and are confused by them; the Location Toolbar should help such people by hiding certain schemes. More often than not most users won't miss what they don't type, and won't be confused by schemes appearing when they enter URIs without schemes.

Brendan/Ka-Ping-proxy: don't try to abstract name parts that are concrete in the terms of the Web (in pages, source, plain text email, and the location toolbar among other UI such as bookmarks); don't reduce defense in depth against other bugs in the system that may be exploited; don't break consistency between syntax and meaning.

I'm trying to fair here. Let me know if I overdid it.

If this summarizes our disagreement, and we can't come to a better agreement of some sort (possibly one we haven't thought of yet), I'm unlikely to back down. So we should try to find a better way forward.

/be

Comment 37

[Ka-Ping Yee]

I believe Brendan's summary fairly well represents my position.  One further
part of the argument supporting this position (mentioned here but not in Brendan's
summary): the location bar is an input/output element, not output only.

Comment 38

[Mike Connor [:mconnor]]

FWIW, I'm intending that we try this as an experiment in M7, I believe the black/grey formatting is a clear failure, and we tried it out of respect for Ka-Ping's knowledge.  That said, given the choice between that and no change at all, I would choose no change at this point.  I'm also not sure why obscuring (or in the case of many, rendering unreadable) the scheme in that proposal is so superior to hiding it outright when the user isn't directly interacting with it.

I'm also not sure why experimenting with UI in an alpha warrants such a backlash.  If we only do what we can demonstrate to be superior in a scientific way, we will not innovate, we will not move quickly, and we will bog down and be replaced by a project more willing to take chances.

For those of you on current trunk, you can approximate the proposed UI by setting browser.urlbar.hideProtocols to "http https"  I've been doing it for a couple of days, and the readabilty of the URL bar is massively improved.  The URL restores to the real form when I interact with it, and I am not hampered in any way by the visual display.

(In reply to comment #36)
> The gist of our disagreement seems to be this:
> 
> Dao-proxy: most people do not type schemes, and are confused by them; the
> Location Toolbar should help such people by hiding certain schemes. More often
> than not most users won't miss what they don't type, and won't be confused by
> schemes appearing when they enter URIs without schemes.

I would go so far as to assert that schemes are essentially meaningless noise.  https is barely more secure that http, in terms of users establishing trust it should be meaningless.  Note Gutman's paper where he discusses the user fallacy that sites served over HTTPS, even those with cert errors, are more secure and safe, but the only thing https means is that the connection is encrypted. http vs https is largely meaningless these days in the world of $18/year certs, except to unduly promote a sense of safety.

Ultimately, Johnathan's identity/security UI concept will fill these gaps in a better way than a generally meaningless implementation detail will.

> Brendan/Ka-Ping-proxy: don't try to abstract name parts that are concrete in
> the terms of the Web (in pages, source, plain text email, and the location
> toolbar among other UI such as bookmarks); don't reduce defense in depth
> against other bugs in the system that may be exploited; don't break consistency
> between syntax and meaning.

I think defense in depth matters as a security principle, but I don't for a second believe that human beings check multiple indicators for consistency in general.  We might use a secondary indicator as a sanity check if we are unsure about the primary indicator, but if the primary secure/insecure indicator says its secure, I doubt that the users who ignored all of the current UI in Gutman's study would _ever_ check a secondary indicator.

https does have a concrete meaning, which is "use http over SSL to connect to this host and path"  All that means is your connection is encrupted, which is useful, but only so far as you are sure of the site you're connecting to.  I don't think its a sacred cow because I don't think more than 10% of users know what that really means ("you're safe" is not a valid answer), and I'm willing to take the chance in an alpha to see how a wider group of users reacts to the combination of this and Larry.

Comment 39

[Mike Connor [:mconnor]]

Comment on attachment 272621 [details] [diff] [review]
simplified patch


>-pref("browser.urlbar.hideProtocols", "");
>+pref("browser.urlbar.hideProtocols", "http https file ftp");

We should only do http and https to start, IMO.  ftp and file are trickier, so let's be conservative for now.

Comment 40

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

(In reply to comment #13)
> It is not an experiment. That would go something like this:

[...]

1. The location bar is the largest single UI element of the web browser, and yet its contents (a URI) are not optimized for human reading or general user comprehension. How can we optimize the URI to assist in visual parsing and comprehension.
 
2. Information gathered on: how the human eye reads text, how to ease visual "chunking" through information visualization techniques, what portion of the URL is most frequently remembered/referred to, what portion of the URL is most relevant for the task of web-wide navigation, what portion of the URL is most relevant for the task of intra-site navigation, how other systems have attempted to simplify hierarchical addressing schemes, 

3. By making the URI easier to parse, it will be easier for users to determine the relationship of various elements to their location on the web, and therefore easier for them to understand where they are on the web.

(h0: comprehension w/Location Bar = comprehension w/Location Bar')

4. That's what we're trying to do here, primarily by gathering data from our test users. In a perfect world we'd do power calcs and run our collection instruments through a battery of tests to ensure that we're actually measuring the metric we mean to measure and provide confidence in causality. I am trying to find some way of getting some measure of testing on this, but sadly, my resources for those activities are pretty low. In the absence of that, I would like to make the change and gather feedback from our alpha audience.

5. Feedback from earlier experiments (see above) was net-positive.

6. See comment #5

7. See comment #5

> Highlighting the domain under this bogus process is one thing, but this is an
> obvious regression, and a security nightmare.

I fail to see how it's a security nightmare, and how that comment is anything more than intentional inflammation. It's a security nightmare if it becomes impossible to determine when a site is https vs http; all we're proposing is removing that single-character indicator which study after study (including the "Why Phishing Works" one you're fond of citing) has shown isn't well-understood nor attended to by users.

(In reply to comment #36)
> Dao-proxy: most people do not type schemes, and are confused by them; the
> Location Toolbar should help such people by hiding certain schemes. More often
> than not most users won't miss what they don't type, and won't be confused by
> schemes appearing when they enter URIs without schemes.

Not quite. I'd phrase it as: most people are not aware of the various internet protocols and do not understand the difference between http:// and https://, which are implementation details about the protocol being used to communicate with the site. UI that is meaningless should be improved or removed.

> Brendan/Ka-Ping-proxy: don't try to abstract name parts that are concrete in
> the terms of the Web (in pages, source, plain text email, and the location
> toolbar among other UI such as bookmarks); don't reduce defense in depth
> against other bugs in the system that may be exploited; don't break consistency
> between syntax and meaning.

That seems about right.

> If this summarizes our disagreement, and we can't come to a better agreement 
> of some sort (possibly one we haven't thought of yet), I'm unlikely to back 
> down. So we should try to find a better way forward.

I'm not sure when UI design within this module became consensus-driven, but I'm game to try and convince you and/or work towards a better solution if one can be found.

I echo mconnor's sentiments in comment #38.

I add that this is also about re-examining UI cruft that's existed for close to 15 years. I wasn't around when - somewhere in those years - someone decided that "if a user doesn't enter http://, we should assume that's what they meant", but I'd like to shake that person's hand since they presumably went through the same sort of arguments as these.

I also add that I am entirely willing to be wrong about this design - and I bet Dao is, too - but I'm unsure why that means we can't, after months of thinking about this and experimenting with different ideas in an extension, try to get wider feedback by putting it in an alpha.

Comment 41

[Brendan Eich [:brendan]]

(In reply to comment #40)
> (In reply to comment #13)
> > It is not an experiment. That would go something like this:
> 
> [...]
> 
> 1. The location bar is the largest single UI element of the web browser, and
> yet its contents (a URI) are not optimized for human reading or general user
> comprehension. How can we optimize the URI to assist in visual parsing and
> comprehension.

You may not be able to "optimize" the URI enough to achieve any particular goal (such as reducing phishing success ratios). But you don't state your goal here: parsing and comprehension of what?

> 3. By making the URI easier to parse, it will be easier for users to determine
> the relationship of various elements to their location on the web, and
> therefore easier for them to understand where they are on the web.

Bolding the TLD+1 host part might address this "where", but removing the scheme does not.

What's more, if I'm a user and I type in http: or https: (as some sites and how-to instructions dictate), I want to see what I entered. Why wouldn't any change respect user type-in of the scheme by preserving it in the entered (non-focused/hovered) output text in the Location Toolbar?

> (h0: comprehension w/Location Bar = comprehension w/Location Bar')

What's this mean?

> 4. That's what we're trying to do here, primarily by gathering data from our
> test users. In a perfect world we'd do power calcs and run our collection
> instruments through a battery of tests to ensure that we're actually measuring
> the metric we mean to measure and provide confidence in causality.

What metric? You don't define any.

> I am trying
> to find some way of getting some measure of testing on this, but sadly, my
> resources for those activities are pretty low. In the absence of that, I would
> like to make the change and gather feedback from our alpha audience.

That's not going to result in anything but noisy complaints and faint praise, and enough volunteer effect to conclude whatever anyone wants to conclude.

> 5. Feedback from earlier experiments (see above) was net-positive.

Stick to the subject. Earlier changes did not remove crucial concrete syntax that is not abstracted by URIs.

> Not quite. I'd phrase it as: most people are not aware of the various internet
> protocols and do not understand the difference between http:// and https://,
> which are implementation details about the protocol being used to communicate
> with the site.

Asserting that these concrete syntactic parts of URIs, which name different sites at the limit, are "implementation details" does not make them so. You might as well call the port (if present), path, query and hash "implementation details". For all but the hash, it does not change the fact that all of these parts are concrete -- any variation or removal changes the meaning, even the site being visited for certain parts.

> UI that is meaningless should be improved or removed.

The scheme is not meaningless. Asserting that it is does not make it so (but it is a bit inflammatory).

> > If this summarizes our disagreement, and we can't come to a better agreement 
> > of some sort (possibly one we haven't thought of yet), I'm unlikely to back 
> > down. So we should try to find a better way forward.
> 
> I'm not sure when UI design within this module became consensus-driven, but I'm
> game to try and convince you and/or work towards a better solution if one can
> be found.

Consensus is not the issue. Credible, non-bootstrapped arguments, and before that some clear statement of measurable goal ("reduce phishing success ratio"), are necessary here, or this is at best polishing a marginal usability burden, but possibly making the Location Toolbar less usable for an important cohort of users, and at worst reducing defense in depth and helping an attack succeed.

There are lots of usability bugs more severe than the worst-case construction you can put on the scheme being present in the Location Toolbar (e.g. Download manager, Find toolbar usability bugs). What makes this so important? Phishing concerns? I don't buy it. Phishing defense needs to involve something other than the user in the loop, period, end of story.

> I add that this is also about re-examining UI cruft that's existed for close to
> 15 years. I wasn't around when - somewhere in those years - someone decided
> that "if a user doesn't enter http://, we should assume that's what they
> meant", but I'd like to shake that person's hand since they presumably went
> through the same sort of arguments as these.

They didn't. That's a bogus analogy, because there's no ambiguity in defining one default scheme.

This suggests a solution that doesn't regress the fidelity of the Location Toolbar: if the user didn't type a scheme, and the default http:// prepending results in a successful load, then leave the scheme off, just as the user typed. But if the user typed http:, or any other scheme, do not strip the scheme.

> I also add that I am entirely willing to be wrong about this design - and I bet
> Dao is, too - but I'm unsure why that means we can't, after months of thinking
> about this and experimenting with different ideas in an extension, try to get
> wider feedback by putting it in an alpha.

Feedback measured and weighed how?

/be

Comment 42

[Dão Gottwald [:dao]]

Attachment: patch v2, hide http and https

Comment 43

[Dão Gottwald [:dao]]

(In reply to comment #41)
> This suggests a solution that doesn't regress the fidelity of the Location
> Toolbar: if the user didn't type a scheme, and the default http:// prepending
> results in a successful load, then leave the scheme off, just as the user
> typed. But if the user typed http:, or any other scheme, do not strip the
> scheme.

That sounds inconsistent to me (if the user pasted an address, has he typed the scheme?). If anything, I think you should file it as a follow-up bug.

Comment 44

[Brendan Eich [:brendan]]

(In reply to comment #43)
> (In reply to comment #41)
> > This suggests a solution that doesn't regress the fidelity of the Location
> > Toolbar: if the user didn't type a scheme, and the default http:// prepending
> > results in a successful load, then leave the scheme off, just as the user
> > typed. But if the user typed http:, or any other scheme, do not strip the
> > scheme.
> 
> That sounds inconsistent to me (if the user pasted an address, has he typed the
> scheme?). If anything, I think you should file it as a follow-up bug.

No, sorry -- first let's have an understanding about why you propose to strip the scheme in all cases from the unfocused/hovered location bar. If the user types or pastes the URI including the scheme, why shouldn't the result be what the user typed or pasted? How is removing data entered by the user good UE?

I can think of good reasons for WYSIWYG meaning the URI output is not the same as the one that was input, including defaulting to http://, whitespace fixups, DNS CNAME replacement, etc. -- but not anything that removes a scheme the user typed. Yet you're the one arguing that the scheme does not matter. If it matters enough for the user to paste or type, why would it be better to remove it? It would be more "consistent" with your circular case for always stripping, but that is vacuous. It would not be more "consistent" with what the user typed in this scenario.

Desire to land should not push clear definition of the quantifiable problem, or even silly straw men such as my counter-proposal, off to some followup bug. You should be able to say why always stripping the scheme if http: or https:, even when the user typed that scheme, is better for the user because it measurably might solve problem X (X = phishing? URL recognition in print ads? I don't want to guess).

/be

Comment 45

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

The feedback we got from early testing on some points (as outlined pretty well in comment 5, I think) seems sound enough to proceed with those changes, but I don't think the protocol-hiding piece gave us results that are as clear.  To me it feels like we're converged pretty well on the other pieces, and as beltzner mentions earlier the protocol hiding was originally an implementation detail to provide some space for the host/path separation.  So I'd say that we should decouple the mostly-agreed from the mostly-disagreed, and move forward with the former quickly.  Jesse concisely, if somewhat obliquely, pointed out the value of decoupling some of the experiments to help us understand the results, too.

The person whose hand Beltzner wants to shake (chouck, possibly?) for making protocol-less inputs work as http:// also put the protocol in as part of fixup, such that the location bar actually represented an unambiguous location.  I think there might even be a bug in bugzilla covering that discussion when we were refining the NS4-parity elements of that.  That might not be the right decision now (honestly, would we invent modifier-enter as www.$1.com today?) but it's probably worth trying to reconstruct that reasoning.  But we should, I think, take that conversation elsewhere.

Actually, I think there are two discussions that we should move to a newsgroup or some such other forum:

1) What are the costs and benefits of hiding the protocol, independent of the other changes?  This needs some goal clarification, at the least, and the nay-sayers (including myself, I think) also have a burden of being explicit about the costs.

2) In the absence of useful metrics for some of the goals that we have around user protection and education/informifying (or in the presence of unbearable costs of wide-spread experimentation), how should we make decisions about when things are ready to hit the mainline of development, and how should we decide i they stick?

Gotta run, hope that makes some sense.

Comment 46

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

(In reply to comment #41)
> You may not be able to "optimize" the URI enough to achieve any particular 
> goal (such as reducing phishing success ratios). But you don't state your 
> goal here: parsing and comprehension of what?

Parsing of the URL to assist with comprehension of the user's sense of "where" they are both within the wide-Internet and the domain that they are browsing.

> Bolding the TLD+1 host part might address this "where", but removing the 
> scheme does not.

Removing the scheme addresses easier parsing. It's visual noise for the majority of the time, the equivalent of "chartjunk" like unneeded line-ticks. While the eye can mask this visual noise, that takes effort which reduces the time for parsing and comprehension.

> What's more, if I'm a user and I type in http: or https: (as some sites and
> how-to instructions dictate), I want to see what I entered. Why wouldn't any
> change respect user type-in of the scheme by preserving it in the entered
> (non-focused/hovered) output text in the Location Toolbar?

For similar reasons to why many mail clients replace "[e-mail]" with "Mike Beltzner" in the "to" field. It's replacing the underlying address with a friendlier, easier to read representation of the same information.

> > (h0: comprehension w/Location Bar = comprehension w/Location Bar')
> 
> What's this mean?

That's my null hypothesis :) The metric is "comprehension", which can be vetted and validated by a number of direct or indirect probes after asking a user to perform some tasks. It can also be inferred by eye tracking data that reveals how a user focuses on various parts of the URL when performing certain tasks.

[..in criticism of using wider feedback as a surrogate metric..] 
> That's not going to result in anything but noisy complaints and faint praise,
> and enough volunteer effect to conclude whatever anyone wants to conclude.

It will result in wider feedback, which may bring up different potential solutions, new concerns, and give people the opportunity to see how it "feels" with day to day usage. I agree that it would be fantastic to gather firmer data on this, but I want to do that in parallel.

> Asserting that these concrete syntactic parts of URIs, which name different
> sites at the limit, are "implementation details" does not make them so. You
> might as well call the port (if present), path, query and hash "implementation
> details". For all but the hash, it does not change the fact that all of these
> parts are concrete -- any variation or removal changes the meaning, even the
> site being visited for certain parts.

Perhaps this is where our impasse is: I am asserting that abstracting away the protocol in the rendering of the URI is going to result in an increase in URI "readability" by removing detail which isn't used by a majority of people. I shouldn't be stating that the protocol is "meaningless implementation detail" but rather stating that "it's detail that is irrelevant to the majority of the web browsing audience and can be safely abstracted away".

> Consensus is not the issue. Credible, non-bootstrapped arguments, and before
> that some clear statement of measurable goal ("reduce phishing success 

This touches phishing only tangentially, in that by making it easier to parse the URL I hope to make it easier to gain an understanding of "where" a user is on the web, and therefore make it easier to identify phishing attacks for those inclined to do so. A defense against phishing is not the primary design goal here, though arguments for this design have been co-opted to that end, and some people have found that it's helped in that regard.

> are necessary here, or this is at best polishing a marginal usability burden,
> but possibly making the Location Toolbar less usable for an important cohort 

Possibly, yes. I'm not sure that it does, though, beyond being a change to a long-standing design. To be clear, your concern about a usability regression comes entirely from the abstraction of the URI protocol?

> There are lots of usability bugs more severe than the worst-case construction
> you can put on the scheme being present in the Location Toolbar (e.g. Download
> manager, Find toolbar usability bugs). What makes this so important? Phishing
> concerns? I don't buy it. Phishing defense needs to involve something other
> than the user in the loop, period, end of story.

Yes, there are other usability bugs. No, that doesn't mean we can't address changes in the UI design until all of the other ones are fixed. (By that logic, we should fix all of our bugs before adding any new functionality or making any design changes.)

(In reply to comment #45)
> The feedback we got from early testing on some points (as outlined pretty well
> in comment 5, I think) seems sound enough to proceed with those changes, but I
> don't think the protocol-hiding piece gave us results that are as clear.  To 

Agreed. Protocol-hiding wasn't really tested, other than to de-emphasize it along with the rest of the non TLD+1 portion of the URL.

> provide some space for the host/path separation.  So I'd say that we should
> decouple the mostly-agreed from the mostly-disagreed, and move forward with 

The cost of doing so is the jitter that occurs when a user swipes into the field and it transforms into input mode. (I'm willing to live with that cost as long as we keep trying to figure out ways of minimizing it. For example, we could just insert 2 spaces between the domain and the path, and leave them there when the field goes into edit mode, but run a cleanup on the URI when passing it off to be loaded (or copied into the Copy buffer) that strips those spaces out.)

> Actually, I think there are two discussions that we should move to a newsgroup
> or some such other forum:

There's a lot on 1) in various d-a-f threads, but we can spawn a new one I suppose that deals specifically with the protocol-abstraction aspect of the design. 2) is definitely something that should be addressed outside the context of this bug.

Comment 47

[Brendan Eich [:brendan]]

What was the Hippocratic injunction? First, do no harm.

This bug is categorically mixed up: it puts code change before sound modeling and rationale; it calls for unmeasurable "experiments" based on changing a long-standing UI reflection of concrete Web address syntax.

I've been explicit enough about the costs of removing the protocol; the burden is on the renovators. But I'm getting steamed about all the usability bugs that are unaddressed in the front end:

- Tabs, which reproduce without bound until overflow leaves you without effective browser tab management, and you've long since lost all OS-supported window management benefit; where a background plugin can spew sound and you have to binary search for it; etc. etc. etc.

- Find toolbar, which is bi-modal and still at the bottom and I'm sure the subject of other bugs.

- Download manager; need I say more?

- Password management, a bigger security weakness than anything to do with the Locaiton Toolbar.

I could go on, but it's off topic here; on the other hand, this bug is premature and out of order, and it's better to call halt here than to push for review and landing without the necessary agreement on problem definition and method.

It's strangely wrong to focus on stripping schemes out of the URL bar. There is no anti-phishing advantage compared to graying it out along with non-TLD+1, and the anti-phishing advantage even of that is doubtful.

Everyone cites the studies that Peter Gutmann wrote about, but they all add up to this point: if you put the user in the anti-phishing defense algorithm, as a pattern matching agent, you will lose. So why is so much energy being misspent on this bug?

/be

Comment 48

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I think we all agree that there are other areas that need improvement, which is why I'm happy to report that many of them are being worked on active right now (download manager, password manager, tab management help -- though the latter is underreported on d.a.f, I think).  People are actively soliciting feedback on those works, and I'm sure your thoughts in those threads would be welcome.

It's fine to "call halt" on that element, though I don't think it's necessary to be as harshly critical as you're being, and I don't think doing so will help us get to an improved state any faster.  I apologize if I've missed the details of your explanation of the costs -- it wasn't my intent to misrepresent you or anything.  Do you have suggestions as to how we should measure those costs, so that we can better understand if alternatives reduce or eliminate them?  It's pretty clear that you've thought more about that than I have, so I'm hoping you can provide some starting points for designing crisper ways to analyze the effects of those changes.  I suspect they would also help guide us in the design of ways to test other coefficients of goodness in this area, for which I think beltzner and I share your and Rob's desire.  (If I'm missing the obvious about how to measure those things, I'd be happy to be educated off-line to spare other readers of this bug the repetition.)

Hippocrates' instruction is good, but I think too absolute for us.  We've always known, and I recall receiving sage guidance from you to this effect :), that we sometimes have to take some harm to a given use case in order to improve one that's of greater value, or for which alternatives are not as readily available.  We've done this with popup blocking (false positives), tab close buttons (conflict with existing user behaviour), installTrigger delay (installTrigger delay), and I don't think that we're going to be lucky enough that all our future improvements will come without trade-offs that can be reasonable characterized as harm.  In the absence of such unambiguous wins, we need to agree on the goods we seek and the standards by which we will measure them.  I don't think that first-class science is the only such acceptable standard -- even though I think that the protocol-auto-prefixing behaviour is good, I don't really believe that it was reached through reproduceable experimentation and testing of hypotheses as is being advocated here!  So I believe, and you may hold that I'm misguided in this belief, that domain expertise and experience can lead to us making good decisions even if we can't construct well-isolated experiments for reasons of time, resources, or simply not knowing how.  You certainly have a ridiculous amount of experience in how people deal with the web, and that experience is a great resource for people trying to make good decisions about how to improve users' interaction with, and understanding of, locations on the web.  I think it would be an even more valuable resource if we're all able to make the tone of discourse here more collegial, and if we could give each other the benefit of the doubt at the least about intent.

Comment 49

[Dão Gottwald [:dao]]

Attachment: better patch (still http and https)

Comment 50

[Brendan Eich [:brendan]]

Quick note, I won't belabor this point again, but I think it has been lost:

Firefox is not designed only for "most users" or "the average user" or "Blake's mom". It never was. Add-ons aside, there is built-in UI to disclose important information. Before 1.0 there was an attempt to remove View / Source, predicated on the notion that average users or Blake's mom never view source.

This is wrong as stated, but more important: it would flagrantly violate the expectations and legitimate use-cases of the next smaller, but still critically important cohort: "lead users". Of course there's a blurry line, and average joe user today becomes expert or lead user joe tomorrow, but even now, Firefox must not be designed only for the mean or median user.

URI schemes and indeed all of the URI will be ignored by "too many" users, and as I keep saying, effective anti-phishing means avoiding a requirement on the user being in the URI recognition loop. But not only won't removing the scheme help anti-phishing effectiveness -- it will definitely piss off and break many lead or more expert users.

*Especially* when one of those lead users (or others, including "average" users) bother to type in http: or https: (or copy and paste it), and expect to see it.

So: one-bit reasoning of the form "average user has no need/understanding, remove it" is wrong on its face. We need to balance built-in UI requirements among at least two cohorts (btw, Google does something similar, IIRC using three cohorts). 

Anyone disagree?

/be

Comment 51

[Dão Gottwald [:dao]]

I'd like to hear what you think it takes to be a lead user. If you think this change can't please lead users, that should be a tricky definition -- it will probably have to contain "likes to see the scheme".

Comment 52

[Ka-Ping Yee]

(In reply to comment #50)
> it would flagrantly violate the expectations and legitimate use-cases
> of the next smaller, but still critically important cohort: "lead users"

I think Brendan makes a good point here.  For many reasons, a lot of people
choose Firefox as THE browser on which to work with web content.

Comment 53

[Brendan Eich [:brendan]]

(In reply to comment #51)
> I'd like to hear what you think it takes to be a lead user. If you think this
> change can't please lead users, that should be a tricky definition -- it will
> probably have to contain "likes to see the scheme".

Don't play dumb, and don't quibble: do you disagree with my argument that Firefox must consider a more advanced user cohort as well as the "average user" or "most users"?

You're hearing from some of the lead users already on the bolding TLD+1 change. They are the advance guard. Ill-mannered but sensitive -- rude canaries in our coal mine. If this "experiment"'s metric is "see what we can change without pissing off too many lead users (and then try telling them to go away since they aren't average)", I can save us the grief by telling you the outcome.

But please, don't pretend you don't know any more advanced users who want and even need to see URI schemes. It is not a matter of "likes" or "dislikes".

/be

Comment 54

[Dão Gottwald [:dao]]

(In reply to comment #53)
> (In reply to comment #51)
> > I'd like to hear what you think it takes to be a lead user. If you think this
> > change can't please lead users, that should be a tricky definition -- it will
> > probably have to contain "likes to see the scheme".
> 
> Don't play dumb, and don't quibble

I'm not. I don't disagree with your argument, but I also don't think this bug goes against lead users.

(In reply to comment #53)
> But please, don't pretend you don't know any more advanced users who want and
> even need to see URI schemes. It is not a matter of "likes" or "dislikes".

I'm sure there are plenty of advanced users who think they need to see the scheme explicitly, but that doesn't mean they couldn't change their mind.

Comment 55

[Robert Sayre]

I think the criticism of the methods used in this bug and others is accurate, and it has nothing to do with innovation: better experimentation technique helps innovation, it does not hinder it. It's a tool that helps us make the right decision the first time, and it helps us know when to revisit old assumptions. 

Sometimes, hunches, intuition, and aesthetics are the right way to judge a change, but it depends on the what the downsides are. I think there's a fundamental disagreement on the level of risk changes to the presentation URIs incur. The arguments from Dão, beltzner et al. make a lot of sense for a hypothetical text field containing structured text that is too complicated.

But this is not just any text field. This is the location bar of the web browser. We need to be very careful about changing behavior where everyone is basically identical. Unilaterally messing with the presentation of the world's most functional global namespace seems dicey to me--our competitors might even view it as hostile behavior. This stuff is motherhood and apple pie: URIs, HTTP, and HTML. And probably the location bar and the back button.

The argument that https:// confers only confidentiality (and message integrity, btw) is objectively wrong. It implies a port number that is not 80, and thus designates a different authority (see: http://www.ietf.org/rfc/rfc3986.txt). Earlier comments reveal that the designers of this proposal missed this subtlety, so I don't think it can be claimed that the design took this reality into account.

Also at issue is the notion that "clarifying" parts of the URI will result in something good. Even if we measure that users better understand the URI parts we've emphasized, the benefits of this shift in focus are unstated. There's no reason to believe it will mitigate phishing, so what is the goal?

Comment 56

[Brendan Eich [:brendan]]

If the Location Toolbar were a graphical element that could be liked or disliked, but in the end, could be used without textual URI fidelity, then the approach and arguments used here might work better (still need well-defined goals, reasoning behind approach intended to reach goals, good experimental methods, etc.).

But URI schemes are not just graphical elements. They are text that affects the meaning of the whole URI. Text, not graphics.

This reminds me: anyone know how screen readers speak the current URI to someone who can't read the text? Do they consult session history's current element, or read out the text from the Location Toolbar widget? If the latter, that's yet another reason (we didn't need it, but with section 508 behind it maybe it will prove decisive) why this bug's goal of hiding certain protocols is wrong.

/be

Comment 57

[Dão Gottwald [:dao]]

I think "read out the text from the Location Toolbar widget" means to access the value property; the urlbar binding works transparently on that score.

Comment 58

[Dão Gottwald [:dao]]

(In reply to comment #57)
> I think "read out the text from the Location Toolbar widget" means to access
> the value property

That was based on <http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULFormControlAccessible.h#159>.
I'm not familiar with that stuff, but it seems pretty obvious.

Comment 59

[Ka-Ping Yee]

(In reply to comment #56)
> This reminds me: anyone know how screen readers speak the current URI to
> someone who can't read the text? Do they consult session history's current
> element, or read out the text from the Location Toolbar widget?

I could imagine a screen reader being implemented either way, but I
believe the latter is both easier to implement and more correct.
Isn't the location bar a text box in the tabbing sequence, just like
any other widget?

Audio support is useful for people with low vision as well as the
blind, so a direct correspondence between text on the screen and
text read to the user is valuable.  Consistency has indirect benefits
(beyond just the channel between one user and one browser) as well:
imagine a fully sighted user trying to communicate with a
vision-impaired user about the browser interface.

Comment 60

[Aaron Leventhal]

It depends on the screen reader or screen magnifier, but in either case it doesn't happen until the location bar is focused (otherwise the user does often get that info via the window title when they alt+tab back to the app).

But, just because people asked, on legacy Windows screen readers and screen magnifiers, they use what's called an "off screen model", which is a hack based on watching screen draw calls by acting as a display driver.

Newer AT's on Linux (Orca) and Windows (NVDA) use engineered accessibility interfaces for text.

Comment 61

[Mike Connor [:mconnor]]

Comment on attachment 273627 [details] [diff] [review]
better patch (still http and https)

r=me, but we're not going to land the pref change before a7.  We're going to do a one-week experiment in nightlies once the tree reopens for M8.

The greytext needs to go away though, that experiment clearly didn't work.

I'll land the CSS pieces shortly.

Comment 62

[Mike Connor [:mconnor]]

Checking in browser/themes/pinstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/browser.css,v  <--  browser.css
new revision: 1.60; previous revision: 1.59
done
Checking in browser/themes/winstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v  <--  browser.css
new revision: 1.70; previous revision: 1.69
done

bumping to M8 for remaining experimentation

Comment 63

[Jesse Ruderman]

> The greytext needs to go away though, that experiment clearly didn't work.

What gave you that impression?

Comment 64

[Dão Gottwald [:dao]]

(In reply to comment #63)
> > The greytext needs to go away though, that experiment clearly didn't work.
> 
> What gave you that impression?

I wouldn't go so far to say that it didn't work, but it clearly had downsides. Maybe I would have decided differently, but I can understand that mconner doesn't want to ship that.

Btw, from now on, since the CSS pieces have landed, you can simply flip the pref manually to test the full effect of this bug.

Comment 65

[Dão Gottwald [:dao]]

(In reply to comment #61)
> we're not going to land the pref change before a7.  We're going to do
> a one-week experiment in nightlies once the tree reopens for M8.

While you do this, please take a look at bug 389708. You might want to land it at the same time or a few days later as a "sub-experiment".

Comment 66

[Grey Nicholson (they/them)]

re: the user expecting to see the url as they entered it (brendan's comment #41):

I don't think the user *does* expect to see exactly what they typed. URLs are almost always advertised (on TV, for example) without a scheme, so I think most users type urls without a scheme.

As a further example, it's the BBC's policy to omit "www." from the urls they advertise. One is expected to type "bbc.co.uk/tv", and then arrives at "http://www.bbc.co.uk/tv/". Another example: Mozilla advertises Firefox's url as "getfirefox.com", which then leads to "http://www.mozilla-europe.org/en/products/firefox/". And when entering a bookmark keyword, it is replaced by the resulting address.

I think these examples demonstrate that users do *not* expect the location bar to display exactly what they just entered.

Note, however, that "exactly what they just entered" (i.e. "how they *did* get there") is a different concept to "something that, if typed in again, would return them to where they are now" (i.e. "how they *can* get there").

I think the user actually expects "how they *should* get there", which may or may not be how they *did* get there, but is definitely an example of how they *can* get there.

(((As an aside: it's possible to manually delete a few characters from the displayed url, after which the location bar could show the address of another page. Say, for example, you were in the middle of changing http:// to https:// and got side-tracked. This persists after switching to another tab and back again. The only differentiation is a faded blank page icon (though this is probably a separate bug).

Also, in many AJAX-type web pages, returning to the current page's proper address won't get you back to "where" you are now.

So the location bar doesn't even display "something that, if typed in again, would return the user to where they are now" all the time.)))

My opinions on omitting schemes:
I don't think the distinction between http:// and https:// is important; if they're the assumed default I'd omit both of them. I think file:// is assumed for locations beginning with "/", so I think file:// can be safely omitted. (Even if someone has a /example.travel folder on their computer, the "/" distinguishes it from http://example.travel.) But I think ftp:// *is* distinctly different and so shouldn't be omitted.

Comment 67

[Alfred Kayser]

Summary:
1. At least hide 'http' (as is the default scheme).
2. Also hide https (as the security indication of the 's' is not used by most).
3. If don't want to hide https (and even http) one can always reset the config-parameter.
4. If users want they can enable hiding of ftp:// and file:// if they want to (via the same config-par).

So, default browser.urlbar.hideProtocols to "http https", and let advanced users do want they want by changing their own config via about:config.
Bug 386896 is for making secure sites more visibl as 'secure'...

Comment 68

[Jim Mathies [:jimm]]

A quick comment I thought I'd throw out - browsing around the source today on Vista it struck me that the new explorer path bar might serve as a really powerful address bar for a browser. Some of the advantages:

- it singles out parts of the domain that need to be emphasized (protocol, domain) without using color, highlighting, etc..

- fine grain control over url history and site access. 

An example: navigating from 

http > www.xyz.com > blah > blah > blah > ..
to 
http > www.xyz.com

is a single mouse click on the domain.

(or)

navigating the reverse is a single click on the arrow to the right of the domain, and selecting the entry you want in the chevron.

http > www.xyz.com |
                   blah > blah > blah > ..
                   blah > blah > blah > ..
                   blah > blah > blah > ..

- removes unneeded characters '://', '/'

- still supports the full url when the user clicks the white space in the bar to select it

Just a though.

Comment 69

[Radosław Szkodziński]

Is that Vista location bar much like the one in new GTK2 file dialog?

It seems a good idea _when_ you can return to a higher level. The only problem is that with web pages, going a level up usually doesn't mean anything useful. (most often a 403 error)

It might be a good idea to present immediate history though (history bar?) supplementing the back/forward buttons, but it's a separate bug.

I won't comment on the URI change before I see it.
Grey text should be eliminated though, it's less readable. (use bold instead?)

Comment 70

[Chris Malton]

Are the changes listed in previous comments the reason why in trunk from Monday I don't see a transition to grey in the address bar?  I was just about to file it as a regression, but found this bug instead, where the location bar is being tweaked.

I personally quite liked the colour change, although it was a little drastic for my liking.  I'd have preferred it to be a little subtler.

Looking forward to see what does happen on this front.