Location Bar: URL formatting alternatives

[Dão]

We still lack useful proposals on how the location could be styled better.

Here's a not-so-new idea: Hide the protocol and use the gained space to
separate the domain from the path.
http://design-noir.de/bugzilla/fx3-url-formatting.png

Before starting rants about hiding the protocol, please give it a shot.
Once bug 387077 has been fixed (checkin needed), the proposed solution
can be tested by setting browser.urlbar.hideProtocols to "http https
file ftp" and adding |.formatted-url-path { color: -moz-fieldtext; }| to
userChrome.css.

Dao

[Alex Faaborg]

Here is an alternative design. My apologies if this has already been
proposed previously (these threads are getting pretty long). The
mockup shows grey text, but it would also work with the URL remaining
black.

http://people.mozilla.com/~faaborg/files/granParadisoUI/
urlFormattingIdea.png

The domain is an active link, hovering over it produce the hand
cursor, and clicking on it navigates the browser. Kind of like a
site specific home button.

One disadvantage of this approach is that users may accidently
navigate when attempting to edit the location on short URLs.

> Here's a not-so-new idea: Hide the protocol and use the gained
> space to
> separate the domain from the path.

I am personally all for hiding the protocol.

-Alex

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

[Benjamin Smedberg]

Dão wrote:
> We still lack useful proposals on how the location could be styled better.

How about "It's a text field and is perfectly styled already." I'm concerned
about the ttitude that we need to "fix" the urlbar: I'm interested in
whether there are changes that can improve it.

> Here's a not-so-new idea: Hide the protocol and use the gained space to
> separate the domain from the path.
> http://design-noir.de/bugzilla/fx3-url-formatting.png

I forget where this was tried already, but it means that any time you click
on the URL bar the text moves around considerably. This makes selection
extremely difficult. Alex's proposal below has the same problem as it adds
extra space after the domain (without hiding the protocol).

The current domain highlighting adds a little visual complexity and makes
hovering over the urlbar visually distracting, but I think it's within the
bounds of reason if it's truly useful to novice users. Changes that make
selecting/editing the URL more difficult are seriously deficient.

--BDS

[Dão]

Thanks for coming up with a concrete proposal, finally! We need more of
those.

Alex Faaborg schrieb:

> Here is an alternative design. My apologies if this has already been
> proposed previously (these threads are getting pretty long). The mockup
> shows grey text, but it would also work with the URL remaining black.
>
> http://people.mozilla.com/~faaborg/files/granParadisoUI/urlFormattingIdea.png

You're adding some space between the domain and the path. Contrary to my
previous proposal, that space wasn't gained from the hidden protocol,
which means that the whole path will move when the Location bar switches
to the editable / unstyled mode. It seems that your proposal would work
without that space, so that's not a showstopper.

> The domain is an active link, hovering over it produce the hand cursor,
> and clicking on it navigates the browser. Kind of like a site specific
> home button.

It should be discussed whether such a link would be useful. I can say
that it could be implemented quite easily based on the current urlbar
binding. Put that aside, I see two problems:

1) Blue is not available as a native color, which means that the domain
would fade away if the background is not close to white (dark gray for
instance). That's not a new problem; it exists for all in-chrome links.

2) Underlining could make the domain less readable. It also makes the
overall appearance more complex and maybe noisy.

Dao

[Dão]

Benjamin Smedberg schrieb:

> Dão wrote:
>> Here's a not-so-new idea: Hide the protocol and use the gained space to
>> separate the domain from the path.
>> http://design-noir.de/bugzilla/fx3-url-formatting.png
>
> I forget where this was tried already, but it means that any time you click
> on the URL bar the text moves around considerably. This makes selection
> extremely difficult.

I didn't think it made selection difficult, as the path stays in place.

Dao

[Michael Vincent van Rantwijk, MultiZilla]

Benjamin Smedberg wrote:
> Dão wrote:
>> We still lack useful proposals on how the location could be styled better.
>
> How about "It's a text field and is perfectly styled already." I'm concerned
> about the ttitude that we need to "fix" the urlbar: I'm interested in
> whether there are changes that can improve it.

I couldn't agree more!

Also I like to mention that the location bar is used for two different
events:

1) I am entering a keyword or URL; in which case the location bar should
stay as is (themed or natively styled).
2) I followed some link from a website; in which case some changes to
the location bar might be done, but only in a way that is not
distracting and is clearly understandable for everyone.

So far I haven't seen (IMHO) any proposal here hitting the jackpot.

>> Here's a not-so-new idea: Hide the protocol and use the gained space to
>> separate the domain from the path.
>> http://design-noir.de/bugzilla/fx3-url-formatting.png
>
> I forget where this was tried already, but it means that any time you click
> on the URL bar the text moves around considerably. This makes selection
> extremely difficult. Alex's proposal below has the same problem as it adds
> extra space after the domain (without hiding the protocol).
>
> The current domain highlighting adds a little visual complexity and makes
> hovering over the urlbar visually distracting, but I think it's within the
> bounds of reason if it's truly useful to novice users. Changes that make
> selecting/editing the URL more difficult are seriously deficient.
>
> --BDS

Q: Why can't average joe see the file name and file extension?

If you can read a book... then you can read and understand file names
and file extensions. Are people here getting too old to understand that
the number of educated users is higher than the old gray mass (at least
in Europe, where Internet use is part of our educational system
(starting at age 4).

--
Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member
- iPhone Application Developer

[Jesper Kristensen]

Alex Faaborg skrev:

> My apologies if this has already been proposed previously (these threads are getting pretty long).

Yes, very long. I have tried to make a summary. Everyone please feel free to
add missing details.

http://wiki.mozilla.org/URL_highlighting

> The domain is an active link, hovering over it produce the hand cursor,
> and clicking on it navigates the browser. Kind of like a site specific
> home button.

This has been discussed before and rejected.

[Michael Lefevre]

So the gap would stay? That will still make the selection and editing
really weird. If I am editing "www.example.com /path/file.html" and
I click just before "file" and then drag, what happens when I get to the
gap? Will the selection highlight "/path" then " /path" and then
"m /path", or will it jump from "/path" to "m /path" when the mouse
gets half way across the gap? If I select across the gap and then copy, I
guess my selection will show "m /path", but the stuff on the clipboard
will be "m/path" instead?

And if I'm using a text cursor, will that jump across the gap? Or stop in
the gap?

Sounds like it has all kinds of potential for weirdness from a user point
of view, and maybe also text selection bugs in the code around the special
handling...

--
Michael

[Dão]

Michael Lefevre schrieb:

> On 2007-07-13, Dão <d...@design-noir.de> wrote:
>> Benjamin Smedberg schrieb:
>>> Dão wrote:
>>>> Here's a not-so-new idea: Hide the protocol and use the gained space to
>>>> separate the domain from the path.
>>>> http://design-noir.de/bugzilla/fx3-url-formatting.png
>>> I forget where this was tried already, but it means that any time you click
>>> on the URL bar the text moves around considerably. This makes selection
>>> extremely difficult.
>> I didn't think it made selection difficult, as the path stays in place.
>
> So the gap would stay? That will still make the selection and editing
> really weird.

The protocol would fill the gap:

styled: [ www.example.com /path/file.html ]

editable: [ http://www.example.com/path/file.html ]

To clarify my previous message: the /path/ stays in place; the domain
doesn't.

Dao

[Mike Beltzner]

On 13-Jul-07, at 12:23 PM, Dão wrote:

> Michael Lefevre schrieb:
>> On 2007-07-13, Dão <d...@design-noir.de> wrote:
>>> Benjamin Smedberg schrieb:
>>>> Dão wrote:
>>>>> Here's a not-so-new idea: Hide the protocol and use the gained
>>>>> space to
>>>>> separate the domain from the path.
>>>>> http://design-noir.de/bugzilla/fx3-url-formatting.png
>>>> I forget where this was tried already, but it means that any
>>>> time you click
>>>> on the URL bar the text moves around considerably. This makes
>>>> selection
>>>> extremely difficult.
>>> I didn't think it made selection difficult, as the path stays in
>>> place.
>>
>> So the gap would stay? That will still make the selection and
>> editing
>> really weird.
>
> The protocol would fill the gap:

Dao spent a lot of time dealing with my feedback here, and if you try
that version of the LocationBar^2 extention you'll see the fruits of
his labours. It actually got to a really usable state, where, as you
moved to select a portion of the URL in the location bar, it changed
to the classic URL structure right beneath your mouse and the
selection lined up 1:1.

Dao: do you have a link back to that version, even if it only works
on 2.0.0.*?

cheers,
mike

[Mike Beltzner]

On 13-Jul-07, at 8:30 AM, Alex Faaborg wrote:

> Here is an alternative design. My apologies if this has already been

> proposed previously (these threads are getting pretty long). The
> mockup shows grey text, but it would also work with the URL remaining
> black.

No worries; I hope to get an opportunity - or maybe someone else can
beat me to it - to go to that wiki page (http://wiki.mozilla.org/
URL_highlighting) and add a list of all the things we've tried before :)

We actually tried a version where each portion of the URL became
active, much like the Windows Explorer in Vista. The problem was that
it made selection pretty hard. We tried putting glyphs in to replace
the "/" characters, and making those glyphs be the active part, but
again, the interactions were a little strange.

I do like the idea of just focusing on the root of the domain, though
- I think that we might be able to get there by being smarter about
what text we select when a user clicks in the location bar, so that
we're making it easier for them to prune a URL and hit enter to go to
the root.

> http://people.mozilla.com/~faaborg/files/granParadisoUI/
> urlFormattingIdea.png

>
> The domain is an active link, hovering over it produce the hand
> cursor, and clicking on it navigates the browser. Kind of like a
> site specific home button.
>

> One disadvantage of this approach is that users may accidently
> navigate when attempting to edit the location on short URLs.

Oh, see, you already thought of that ;)

>> Here's a not-so-new idea: Hide the protocol and use the gained
>> space to
>> separate the domain from the path.
>

> I am personally all for hiding the protocol.

As am I, especially if we make it visible again when you enter the
location bar (which Dao's proposal does) and come up with better
icons for when the "file" and "ftp" protocols are being used.

I've mentioned it several times, but Dao's proposal with spacing
seems to meet the goals of this exercise and all the constraints, too.

cheers,
mike

[Dão]

Mike Beltzner schrieb:

Here's a version that is aligned with my proposal:
http://design-noir.de/mozilla/locationbar2/0.9-exp-2007071318.xpi

It works on trunk builds only.

Dao

[Robert Sayre]

Alex Faaborg wrote:
> Here is an alternative design.

...
>
> http://people.mozilla.com/~faaborg/files/granParadisoUI/urlFormattingIdea.png

It's not all doom and gloom from me. I think the search box shown there
is excellent. It delivers an obvious, large reduction in complexity.

- Rob

[Justin Wood (Callek)]

Mike Beltzner wrote:
> On 13-Jul-07, at 8:30 AM, Alex Faaborg wrote:
>
>> Here is an alternative design. My apologies if this has already been
>> proposed previously (these threads are getting pretty long). The
>> mockup shows grey text, but it would also work with the URL remaining
>> black.
>
> No worries; I hope to get an opportunity - or maybe someone else can
> beat me to it - to go to that wiki page

> (http://wiki.mozilla.org/URL_highlighting) and add a list of all the

People who are remotely tech-saavy (myself for one) do not tend to
always look for a "lock icon" as that is spoofable, but DO in-fact look
for "https".

Granted I know the number of users who have no idea what http/https
means and just ignores those when using the web are probably greater, by
at least 3:1 maybe even 4:1, but still... its worth noting no icon can
detract the usefullness of exposing protocol to normal UI, imho.

[Dão]

Justin Wood (Callek) schrieb:

> Mike Beltzner wrote:
>>>> Here's a not-so-new idea: Hide the protocol and use the gained
>>>> space to
>>>> separate the domain from the path.
>>>
>>> I am personally all for hiding the protocol.
>>
>> As am I, especially if we make it visible again when you enter the
>> location bar (which Dao's proposal does) and come up with better icons
>> for when the "file" and "ftp" protocols are being used.
>>
>
> People who are remotely tech-saavy (myself for one) do not tend to
> always look for a "lock icon" as that is spoofable, but DO in-fact look
> for "https".

We certainly don't want users to ignore the security UI. Any issues with
it have to be addressed -- e.g. by not allowing sites to load a custom
icon into the Location Bar.

Dao

[Aleksej]

Dão wrote:
> Justin Wood (Callek) schrieb:

>> People who are remotely tech-saavy (myself for one) do not tend to
>> always look for a "lock icon" as that is spoofable, but DO in-fact
>> look for "https".
>
> We certainly don't want users to ignore the security UI. Any issues with
> it have to be addressed -- e.g. by not allowing sites to load a custom
> icon into the Location Bar.

While the "lock icon" is on the right, it neither has the spoofing
problem, nor is it useful (too far from the TLD+1). Except maybe for the
users who never press Enter to go to a URL.

[Michael Vincent van Rantwijk, MultiZilla]

Do you mean for https: only, or http: also?

[Dão]

Michael Vincent van Rantwijk, MultiZilla schrieb:

> Dão wrote:
>> We certainly don't want users to ignore the security UI. Any issues
>> with it have to be addressed -- e.g. by not allowing sites to load a
>> custom icon into the Location Bar.
>

> Do you mean for https: only, or http: also?

For http as well. At the most, the favicon of privileged content (error
pages, ftp dir listing) should be allowed to show up in the Location Bar.

Dao

[Aleksej]

Dão wrote:
> Benjamin Smedberg schrieb:

>> I forget where this was tried already, but it means that any time you
>> click on the URL bar the text moves around considerably. This makes selection
>> extremely difficult.
>
> I didn't think it made selection difficult, as the path stays in place.

Editing the domain may be difficult though. I'd thought it wouldn't
happen all that often first, but there are at least two cases when it will:
1. Correcting a typo (might be already difficult in case of a redirect)
2. Adding/changing/removing the 3rd+ level part.

[gr...@raizlabs.com]

A while back I did some URL bar explorations. Key points:

- Hide the protocol
- Add meaning to slashes so people can go up a level
- Hide the stuff after the ? in a URL

http://www.raizlabs.com/blog/uploaded_images/firefox_1-748711.JPG

This exploration touched on other concepts as well but focusing on the
URL bar.

- Having clearer separation between slashes helps encourage web
designers to have useful pages and logical site structure. For a well
designed site this can be used as bread crumbs. The idea could later
be enhanced to provide structured navigation:
http://www.raizlabs.com/blog/uploaded_images/firefox_4-703728.JPG
- Collapsing all the stuff after a URL ? mark makes the URL easier to
copy and select. CTRL+Copy would still grab all the extra stuff.
Clicking the little document icon would expand all the ? stuff. Again
shorter URL's are easier to deal with. It cleans up the URL and gives
more space to other stuff.

- Greg Raiz

[Dão]

In case you didn't know (I didn't until a few minutes ago), here's a
MozillaZine thread discussing the current formatting:
http://forums.mozillazine.org/viewtopic.php?t=564386

And a little bit more feedback:
http://tech.cybernetnews.com/2007/07/09/firefox-3-to-make-users-more-aware-of-domain-name/

That's all mainly positive until now. I'm looking forward to more
feedback after the Alpha 7 release.

Dao

[Aleksej]

“Editing the domain may be difficult though.”

Here I'm talking about the domain name centering.

[Justin Wood (Callek)]

....nevermind that https://foo.com/index.html and
http://foo.com/index.html could point to entirely different content.

~Justin Wood (Callek)

[Justin Dolske]

Mike Beltzner wrote:

>> I am personally all for hiding the protocol.
>
> As am I, especially if we make it visible again when you enter the
> location bar (which Dao's proposal does) and come up with better icons
> for when the "file" and "ftp" protocols are being used.

I think it absolutely makes sense to hide the protocol when it's
http://, and probably https:// as well (although I'm on the fence
there). I'm dubious that per-protocol icons will have any benefit, though.

I'd say, though, that other protocols ought to still be displayed, as
you're almost always "some place different" than with HTTP. For example,
http://apple.com vs. ftp://apple.com. [As opposed to http://amazon.com
vs. https://amazon.com/, which are basically identical.]

Another way of thinking about is that HTTP is the defacto-default
protocol on the web, and when typing "site.com" into the URL bar the
browser assumes you mean "http://site.com".

I suppose hiding it in some cases but not others can be viewed as
inconsistent, but non-HTTP[S] protocols are relatively rare for most
people to encounter, so it doesn't really matter much either way. :-)

Justin

[Robert Sayre]

Justin Dolske wrote:
>
> I think it absolutely makes sense to hide the protocol

...

> I'm dubious that per-protocol icons will have any benefit, though.

...

> I'd say, though, that other protocols ought to still be displayed

Maybe you're right. I don't have any way to evaluate these assertions
because the message didn't include any explanation or reasoning.

-Rob

[Tony Mechelynck]

On the different tabs which I see in the Firefox instance I'm using, I notice
all of the following:

http://<something>
https://<something>
ftp://<something>
file:///<something>
about:<something> (where <something> is often, but not always, empty)
chrome://<something>

I would certainly not want a confusion between chrome: and file:, or even less
between either of them and http:. So for me, yes, it does matter quite a lot.
And if (er, since) we want to display at least these last four, why not
display _all_ protocols? That would lend less "irregularity" to the Location
Bar (in the sense that "irregular verbs" and "irregular plurals" are never,
/per se/, a good quality in a language; their absence is never a "blemish").

Best regards,
Tony.
--
The First Rule of Program Optimization:
Don't do it.

The Second Rule of Program Optimization (for experts only!):
Don't do it yet.
-- Michael Jackson

[Michael Vincent van Rantwijk, MultiZilla]

Justin Dolske wrote:
> Mike Beltzner wrote:
>
>>> I am personally all for hiding the protocol.
>>
>> As am I, especially if we make it visible again when you enter the
>> location bar (which Dao's proposal does) and come up with better icons
>> for when the "file" and "ftp" protocols are being used.
>
> I think it absolutely makes sense to hide the protocol when it's
> http://, and probably https:// as well (although I'm on the fence
> there). I'm dubious that per-protocol icons will have any benefit, though.

These days more people type "www.foo.bar" instead of "http://www" but
most of them learned to use https://www/foo.bar to get to a secure site,
this because of all news related to phishing attacks, and their bank
folks telling them to make sure they are on https:// instead of http://

Think about this: How come a 10 year old kid, one who has never even
seen a computer, can work with the OLPC computer in less than 3 minutes,
but a 100+ million Firefox users can't even distinguish right from wrong???

This can't be a protective measure only, because you already have a
build in phishing protection, right? Or doesn't that work as well as
most people think? It that why you need this extra feature? What other
*advantage* over the already build in phishing protection is there with
this feature? I mean; if I get warned about a phony site, why do I need
the location bar changes?

> I'd say, though, that other protocols ought to still be displayed, as
> you're almost always "some place different" than with HTTP. For example,
> http://apple.com vs. ftp://apple.com. [As opposed to http://amazon.com
> vs. https://amazon.com/, which are basically identical.]
>
> Another way of thinking about is that HTTP is the defacto-default
> protocol on the web, and when typing "site.com" into the URL bar the
> browser assumes you mean "http://site.com".
>
> I suppose hiding it in some cases but not others can be viewed as
> inconsistent, but non-HTTP[S] protocols are relatively rare for most
> people to encounter, so it doesn't really matter much either way. :-)
>
> Justin

[Alex Faaborg]

> How come a 10 year old kid, one who has never even
> seen a computer, can work with the OLPC computer in less than 3
> minutes,
> but a 100+ million Firefox users can't even distinguish right from
> wrong???

Because URIs weren't designed correctly, they go from small to large,
and then switch to large to small:

<<<<<<<<<<<<<<<<<|>>>>>>>>>>>>>>>>
subdomain.domain.com/subfolder/subsubfolder

They really should be:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
com.domain.subdomain/subfolder/subsubfolder

But since this is the way they are, users need additional information
(outside of the browser itself, or the computer they have never seen)
to correctly parse:

good.evil.com/good/seriouslygood

URIs as they exist today are not self describing, there is no
indication of the switch in direction, you have to already know about
it. As a result of this, URIs can't (by themselves) pass the 10-year-
old-never-seen-a-computer test.

The example above uses good v. evil, but I personally view the
formatting change as being less about security UI (because as many
studies have shown chrome can't win over content), and being more
about simply helping users easily identify where they are on the Web.

-Alex

On Jul 15, 2007, at 3:20 AM, Michael Vincent van Rantwijk, MultiZilla
wrote:

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

[Gervase Markham]

Alex Faaborg wrote:
> Here is an alternative design. My apologies if this has already been
> proposed previously (these threads are getting pretty long). The mockup
> shows grey text, but it would also work with the URL remaining black.
>

> http://people.mozilla.com/~faaborg/files/granParadisoUI/urlFormattingIdea.png

This sort of thing was tried in earlier iterations of Locationbar2. I
don't want to reject it outright, but it does have some obvious issues,
which you raised.

> The domain is an active link, hovering over it produce the hand cursor,
> and clicking on it navigates the browser. Kind of like a site specific
> home button.

Previous iterations of this had a button like this for every level in
the URL path. This IMO was a bad idea; many of those buttons would have
led to 404s. but the top-level of the site

If I have:

myshop.YAHOOSHOPS.COM/foo/bar/baz

(where capitals indicates the highlighting) does clicking the button
take you to myshop.yahoo.com, or YAHOOSHOPS.COM? The former is what you
would want, but the link doesn't cover that text, so it's unexpected;
the latter makes where you go match the link, but it may not be where
you want.

> One disadvantage of this approach is that users may accidently navigate
> when attempting to edit the location on short URLs.

That, I think, will also be a problem.

Gerv

[Gervase Markham]

Michael Vincent van Rantwijk, MultiZilla wrote:

> Also I like to mention that the location bar is used for two different
> events:
>
> 1) I am entering a keyword or URL; in which case the location bar should
> stay as is (themed or natively styled).

All of the proposals so far have this property. When the location bar is
focussed (which it would be if you are typing in it) then it works just
like a textbox. So I'm surprised that you say:

> So far I haven't seen (IMHO) any proposal here hitting the jackpot.

Gerv

[Gervase Markham]

Justin Wood (Callek) wrote:
> People who are remotely tech-saavy (myself for one) do not tend to
> always look for a "lock icon" as that is spoofable,

No it's not; not if you know the correct place to look (which you do).

> but DO in-fact look for "https".

That's actually not a good indicator; if you click through a "broken
cert" dialog, it will still say HTTPS, but you'll get a broken lock.

If people need to look for a small "s" to correctly determine some
browser state, our UI needs fixing.

Gerv

[Michael Vincent van Rantwijk, MultiZilla]

Sure, but that is like 50% of the proposal, right? I mean, when I'm not
typing, I don't like the protocol to be hidden, for various reasons.
That's what I like to address (but I obviously failed to do so).

[Michael Vincent van Rantwijk, MultiZilla]

Gervase Markham wrote:
> Justin Wood (Callek) wrote:
>> People who are remotely tech-saavy (myself for one) do not tend to
>> always look for a "lock icon" as that is spoofable,
>
> No it's not; not if you know the correct place to look (which you do).
>
>> but DO in-fact look for "https".
>
> That's actually not a good indicator; if you click through a "broken
> cert" dialog, it will still say HTTPS, but you'll get a broken lock.

I agree, but Safari blocks people from entering the site when this
happens. Would that be something for Firefox?

> If people need to look for a small "s" to correctly determine some
> browser state, our UI needs fixing.

As a secondary indicator, yes, but I agree that the primary indicator
should be the padlock; or Larry in the new proposals.

[Robert Kaiser]

Alex Faaborg wrote:
> Here is an alternative design. My apologies if this has already been
> proposed previously (these threads are getting pretty long). The mockup
> shows grey text, but it would also work with the URL remaining black.
>
> http://people.mozilla.com/~faaborg/files/granParadisoUI/urlFormattingIdea.png

I just realized that this has a strange effect on at least most wikis.

e.g. enter "en.wikipedia.org" into your location bar and you will be
forwarded instantly to "http://en.wikipedia.org/wiki/Main_Page". when
the host name is linked, looking like it would go to something
different, it immediately jumps back to where you already are...

Just wanted to note this here.

Robert Kaiser

[Robert Kaiser]

Gervase Markham wrote:
> Justin Wood (Callek) wrote:
>> People who are remotely tech-saavy (myself for one) do not tend to
>> always look for a "lock icon" as that is spoofable,
>
> No it's not; not if you know the correct place to look (which you do).
>
>> but DO in-fact look for "https".
>
> That's actually not a good indicator; if you click through a "broken
> cert" dialog, it will still say HTTPS, but you'll get a broken lock.

True, but then you had to click through that dialog anyways, so you
already know about this, right?

Robert kaiser

[Jeremy Morton]

Dão wrote:
> We still lack useful proposals on how the location could be styled better.

>
> Here's a not-so-new idea: Hide the protocol and use the gained space to
> separate the domain from the path.

> http://design-noir.de/bugzilla/fx3-url-formatting.png
>
> Before starting rants about hiding the protocol, please give it a shot.
> Once bug 387077 has been fixed (checkin needed), the proposed solution
> can be tested by setting browser.urlbar.hideProtocols to "http https
> file ftp" and adding |.formatted-url-path { color: -moz-fieldtext; }| to
> userChrome.css.
>
> Dao

Dao,

Just a thought. Could you implement the 'jazzed up' URLbar as a
separate toolbar widget? So users like me, who just want the URLbar to
be as it was, can add back the normal-style URLbar using customize
toolbar? That would seem to be a decent compromise. Then, I don't mind
you doing what you want to the other bar. ;-)

Best regards,
Jeremy Morton (Jez)

[Jeremy Morton]

Dão wrote:
> We still lack useful proposals on how the location could be styled better.
>
> Here's a not-so-new idea: Hide the protocol and use the gained space to
> separate the domain from the path.
> http://design-noir.de/bugzilla/fx3-url-formatting.png
>
> Before starting rants about hiding the protocol, please give it a shot.
> Once bug 387077 has been fixed (checkin needed), the proposed solution
> can be tested by setting browser.urlbar.hideProtocols to "http https
> file ftp" and adding |.formatted-url-path { color: -moz-fieldtext; }| to
> userChrome.css.
>
> Dao

I think a better way of highlighting the hostname part wuld be the
colour the background light-blue. It would not annoy people like me,
who want to see the whole URL clearly, but would still inform people
what the hostname part was. I've written a patch to do it; here's a
screenshot from the patched Firefox on my system:
http://www.game-point.net/misc/diff3.png

My patch also stops the URL from changing formatting on mouseover
(something I found annoying), and only 'un-prettyfies' the URL when it's
clicked on.

In addition, I'd suggest either
- Implementing the 'pretty' URLbar as a separate widget in the customize
toolbar box or
- having a check-option when one right-clicks on the URLbar, such as
'Highlight hostname'. This should be easily discoverable, not a hidden
pref. If I had just upgraded and didn't like the colouring, I wouldn't
want to go searching for a hidden pref.

[Jeremy Morton]

Alex Faaborg wrote:
[...]

>
> Because URIs weren't designed correctly, they go from small to large,
> and then switch to large to small:
>
> <<<<<<<<<<<<<<<<<|>>>>>>>>>>>>>>>>
> subdomain.domain.com/subfolder/subsubfolder
>
> They really should be:
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> com.domain.subdomain/subfolder/subsubfolder
>
> But since this is the way they are, users need additional information
> (outside of the browser itself, or the computer they have never seen) to
> correctly parse:
>
> good.evil.com/good/seriouslygood
>
> URIs as they exist today are not self describing, there is no indication
> of the switch in direction, you have to already know about it. As a
> result of this, URIs can't (by themselves) pass the
> 10-year-old-never-seen-a-computer test.

I think you're insulting the average user, apparently by saying that
their level of understanding isn't capable of going beyond
10-year-old-never-seen-a-computer. I can guarantee you that the vast
majority of average users will be able to identify what the hostname
part of a URL is after 5 minutes of seeing it highlighted in a web
browsing session. "it's the bit after http:// and before /". That's
the irony of this formatting - it will be useful for the very short
period of time the user is being taught that the hostname part is, then
not. A tutorial would probably be better.

[Michael Vincent van Rantwijk, MultiZilla]

Jeremy Morton wrote:
> Alex Faaborg wrote:
> [...]
>>
>> Because URIs weren't designed correctly, they go from small to large,
>> and then switch to large to small:
>>
>> <<<<<<<<<<<<<<<<<|>>>>>>>>>>>>>>>>
>> subdomain.domain.com/subfolder/subsubfolder
>>
>> They really should be:
>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> com.domain.subdomain/subfolder/subsubfolder
>>
>> But since this is the way they are, users need additional information
>> (outside of the browser itself, or the computer they have never seen)
>> to correctly parse:
>>
>> good.evil.com/good/seriouslygood
>>
>> URIs as they exist today are not self describing, there is no
>> indication of the switch in direction, you have to already know about
>> it. As a result of this, URIs can't (by themselves) pass the
>> 10-year-old-never-seen-a-computer test.
>
> I think you're insulting the average user,

No, I'm not thank you.

> apparently by saying that
> their level of understanding isn't capable of going beyond
> 10-year-old-never-seen-a-computer.

What I say with this is that the proposed change of location bar format
isn't necessary, and that OLPC[1] proofed that *even* uneducated
children, who have not even seen electricity, that *even* they can
understand it in under three minutes but hey, if *you* want to read it
in a bad way... then go ahead.

[1] http://laptop.org/

[Jeremy Morton]

Michael Vincent van Rantwijk, MultiZilla wrote:

I was responding to Alex, not you?

[Alex Faaborg]

> I think you're insulting the average user

I'm not making any assertions about our user's intelligence, I'm
making assertions about how good our user interface is. As a side
note, I've seen brilliant surgeons and mathematicians have trouble
using Firefox (things like knowing that the location bar is editable,
or scrolling). An inability to use an interface has much more to do
with the quality of the interface itself, as opposed to the user's
intelligence.

> saying that their level of understanding isn't capable of going beyond
> 10-year-old-never-seen-a-computer.

I'm not saying their level of understanding can't go beyond the
information gained from a first impression, I'm saying that good
interfaces are self describing so that users don't have to rely on
external sources of information for basic comprehension. If the 10-
year-old-never-seen-a-computer example seems for some reason
insulting, imagine we cloned Einstein, placed him in an empty room
with a location bar drawn on the wall, and asked him "which is more
important, apple or orange:"

http://apple.orange.com/banana/strawberry

> "it's the bit after http:// and before /"

That's what you would have to personally tell cloned-usability-test-
Einstein before he understood. Interfaces shouldn't have to rely on
tutorials. Also, this isn't just about the domain name, we are
additionally concerned about domain/sub-domain disambiguation (apple
v. orange).

> it will be useful for the very short
> period of time the user is being taught that the hostname part is,
> then
> not.

I believe the formating changes make URLs easier to parse visually,
even for advanced users. Here is the rationale, reposed from an
earlier location bar thread:

>> Previously in this thread the main arguments for greying out parts of
>> the URL has been preventing phishing attacks, and helping novice
>> users correctly parse the URL. There seems to be an implicit
>> assumption that this change doesn't help advanced users, people who
>> already know what "effective TLD" means. However, I believe this
>> change improves the overall usability of the location bar, even for
>> advanced users.
>>
>> First, a quick description of the human visual system: we have a very
>> high resolution fovea, and low resollution peripheral vision. Our
>> fovea takes up 1-2% of our visual field (if our peripheral vision had
>> the same resolution as the fovea, an eyeball would be about the same
>> size as a human head). To view particular areas of the screen, our
>> eyes make very fast movements (called saccades) to direct the high
>> resolution fovea to different targets that we acquire using our low
>> resolution peripheral vision.
>>
>> Here is why I think this change to the location bar will help
>> advanced users:
>>
>> 1) The vast majority of time people look at the location bar they are
>> doing so to read the domain name. Now, of course I know this
>> percentage probably goes down a bit for very advanced users (who
>> might be trying to view the protocol in certain cases, or the port,
>> etc.) But it's still the case that advanced users regularly look at
>> the location bar to see the domain name.
>>
>> 2) By providing contrast for the public suffix +2, users will be
>> able to read this information with a single saccade to the center of
>> the darker text. Without the visual change, our eyes will make a
>> saccade to the start of the URL, and then will jump back and forth
>> inside the location bar, identifying the relevant parts of the URL.
>>
>> It's too bad we don't have an eye tracking system set up, because
>> then we could get some real data on the average number of saccades it
>> currently takes to parse a URL. But either way, I believe this
>> change to the location bar is going to decrease both the number of
>> eye movements, and the time it takes the user to figure out which
>> domain they are on, regardless of how technical they are.
>>
>> We are talking about milliseconds, and this isn't the kind of thing
>> the user will be consciously aware of. But these types of
>> improvements to (human) performance make a difference.

-Alex

[Jeremy Morton]

Alex Faaborg wrote:
> I'm not making any assertions about our user's intelligence, I'm making
> assertions about how good our user interface is. As a side note, I've
> seen brilliant surgeons and mathematicians have trouble using Firefox
> (things like knowing that the location bar is editable, or scrolling).
> An inability to use an interface has much more to do with the quality of
> the interface itself, as opposed to the user's intelligence.

I think it has a bit to do with both. By any chance were the people you
saw having trouble with the interface either:
- Very new to the interface or
- People who hadn't been making much of an effort to get used to it?

Interfaces beyond Fisher-Price toys *should* take some getting used to.
No, they shouldn't be more complex than necessary, but I really
think it's silly to say that they should be immediately fully usable.
There is inevitably a learning curve.

> imagine we cloned Einstein, placed him in an empty room with
> a location bar drawn on the wall, and asked him "which is more
> important, apple or orange:"
>
> http://apple.orange.com/banana/strawberry
>
>> "it's the bit after http:// and before /"
>
> That's what you would have to personally tell
> cloned-usability-test-Einstein before he understood.

Actually, that would only tell him which was the hostname part. Finding
that is *really* easy, so the need to highlight it seems questionable at
best.

> Interfaces
> shouldn't have to rely on tutorials.

That's a very wide-ranging assumption, and many interfaces certainly
rely on tutorials. Would you expect to be able to pick up Photoship
from scratch and be able to use all of its features by figuring them
out? Now, many parts of the FF interface do lend themselves to being
figured out, but the location bar isn't really one of them.

> Also, this isn't just about the
> domain name, we are additionally concerned about domain/sub-domain
> disambiguation (apple v. orange).

Indeed, and this does not lend itself to being figured out. What do you
have against a very brief tutorial? The fact that browsers are already
very popular point to the fact that it's somewhat unnecessary for users
to know this information, and I recognise that it may help in
identifying phishing scame, but I still say a tutorial is the best way
of dealing with this. It could be included in a more general phishing
tutorial.

> I believe the formating changes make URLs easier to parse visually, even
> for advanced users. Here is the rationale, reposed from an earlier
> location bar thread:

> [...]

>> Here is why I think this change to the location bar will help
>> advanced users:
>>
>> 1) The vast majority of time people look at the location bar they are
>> doing so to read the domain name. Now, of course I know this
>> percentage probably goes down a bit for very advanced users (who
>> might be trying to view the protocol in certain cases, or the port,
>> etc.) But it's still the case that advanced users regularly look at
>> the location bar to see the domain name.

I totally disagree with the 'vast majority of the time' comment. When
I'm on a domain, I can generally remember which domain I'm on. When I
look at the location bar, it's to look at the path, in general, not the
domain.. the only exception is if I think I've made a typo because the
content doesn't look right (rare), or I've forgotten what domain I'm on
(exceedingly rare). Some examples of URLs where I'm far more interested
in the path:

http://www.game-point.net/misc/election2005/

http://www.google.com/search?hl=en&q=Baskets&btnG=Google+Search

http://dictionary.reference.com/search?q=commodity

http://www.willitblend.com/videos.aspx?type=unsafe&video=iphone

http://consult.libdems.org.uk/poverty/index.php/consultation-paper/cross-cutting-issues/women/

Greying out the path in these URLs is *ANNOYING*.

>> 2) By providing contrast for the public suffix +2, users will be
>> able to read this information with a single saccade to the center of
>> the darker text. Without the visual change, our eyes will make a
>> saccade to the start of the URL, and then will jump back and forth
>> inside the location bar, identifying the relevant parts of the URL.

Sorry, but this just sounds like biology-speak to try and make the point
sound more important than it is. All I can say is that I have no
problem whatsoever doing this, and I can read an all-black URL perfectly
quickly, thankyouverymuch.

>> It's too bad we don't have an eye tracking system set up, because
>> then we could get some real data on the average number of saccades it
>> currently takes to parse a URL. But either way, I believe this
>> change to the location bar is going to decrease both the number of
>> eye movements, and the time it takes the user to figure out which
>> domain they are on, regardless of how technical they are.

Sure. But it will increase the amount of time taken and decrease the
amount of ease for reading other parts of the URL, which is often done.
Highlight the hostname if you must, but do not make the rest harder to
read!

>> We are talking about milliseconds, and this isn't the kind of thing
>> the user will be consciously aware of. But these types of
>> improvements to (human) performance make a difference.

I strongly disagree, except for the difference of being more annoying.

[Alex Faaborg]

> - Very new to the interface or
> - People who hadn't been making much of an effort to get used to it?

Sure, but I believe that blaming the user instead of the interface
won't lead to improving the interface.

> many interfaces certainly rely on tutorials

Yes, but those that don't are better. If we could magically design
an image editing application that was simultaneously as powerful as
photoshop but as easy to use as a fisher price toy, it would be very
popular.

> When I'm on a domain, I can generally remember which domain I'm
> on. When I
> look at the location bar, it's to look at the path

I'll agree that you personally usually look at the path, but I'm less
convinced that the vast majority of users extract any meaning from
"videos.aspx?type=unsafe&video=iphone" and "search?
hl=en&q=Baskets&btnG=Google+Search") Most URLs are not designed to
be human readable (although thankfully some are).

Either way, I think one big advantage of Dao's most recent proposal
is that it will make it easier for people to view both the domain and
the path, since the white space creates two chunks of information
that you can target using peripheral vision:

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

> Sorry, but this just sounds like biology-speak to try and make the
> point
> sound more important than it is.

If we invested as much effort in understanding humans as we do code,
we would make better software. We measure Ts and Tp in milliseconds,
why not measure Th for common tasks?

Cheers,
-Alex

[Alex Faaborg]

Here is another idea:

http://people.mozilla.com/~faaborg/files/granParadisoUI/
urlFormattingIdea2.png

The effective TLD+1 is highlighted, similar to our new UI for
tagging, or how email addresses are converted to contact names in
Mail.app

There is no change on hover or selection, however the new formatting
does disappear when it is directly edited, causing a shift due to the
extra spacing. This shift shouldn't be too noticeable, since typing
new information will cause a shift either way.

I personally don't like this idea as much as the current proposal in
bug 388135, but I figured I would throw it out there in case it
triggers anyone else to brainstorm a solution.

-Alex

On Jul 13, 2007, at 4:17 AM, Dão wrote:

> We still lack useful proposals on how the location could be styled
> better.
>
> Here's a not-so-new idea: Hide the protocol and use the gained
> space to
> separate the domain from the path.
> http://design-noir.de/bugzilla/fx3-url-formatting.png
>
> Before starting rants about hiding the protocol, please give it a
> shot.
> Once bug 387077 has been fixed (checkin needed), the proposed solution
> can be tested by setting browser.urlbar.hideProtocols to "http https
> file ftp" and adding |.formatted-url-path { color: -moz-
> fieldtext; }| to
> userChrome.css.
>
> Dao

[Michael Vincent van Rantwijk, MultiZilla]

Alex Faaborg wrote:
>> - Very new to the interface or
>> - People who hadn't been making much of an effort to get used to it?
>
> Sure, but I believe that blaming the user instead of the interface won't
> lead to improving the interface.

Letting people *guess* what the protocol is, and probably make judgment
errors just because of this, does a better job than the current and
normal i.e. expected and usual implementation? Can you please explain
this to me?

>> many interfaces certainly rely on tutorials
>
> Yes, but those that don't are better. If we could magically design an
> image editing application that was simultaneously as powerful as
> photoshop but as easy to use as a fisher price toy, it would be very
> popular.
>
>> When I'm on a domain, I can generally remember which domain I'm on.
>> When I
>> look at the location bar, it's to look at the path
>
> I'll agree that you personally usually look at the path, but I'm less
> convinced that the vast majority of users extract any meaning from
> "videos.aspx?type=unsafe&video=iphone" and

> "search?hl=en&q=Baskets&btnG=Google+Search") Most URLs are not designed

> to be human readable (although thankfully some are).
>
> Either way, I think one big advantage of Dao's most recent proposal is
> that it will make it easier for people to view both the domain and the
> path, since the white space creates two chunks of information that you
> can target using peripheral vision:

The only problem I have with this... is that it hides the protocol.

> https://bugzilla.mozilla.org/attachment.cgi?id=272298
>
>> Sorry, but this just sounds like biology-speak to try and make the point
>> sound more important than it is.
>
> If we invested as much effort in understanding humans as we do code, we
> would make better software. We measure Ts and Tp in milliseconds, why
> not measure Th for common tasks?

Yeah, but when you make too many changes at once... err... people
collapse over it ;)

> Cheers,
> -Alex

[Alex Faaborg]

> Letting people *guess* what the protocol is, and probably make
> judgment
> errors just because of this, does a better job than the current and
> normal i.e. expected and usual implementation?

Personally, I think we should hide (and I mean totally hide) the
protocol for http[s], but still show every other protocol. So if you
are viewing ftp://, chrome://, file://, about:, gopher:// etc, these
would appear as they always have, without any formating changes. But
these are also all boundary cases of normal browser usage (especially
gopher).

I think an analogy could be made to hiding the fact that HTTP traffic
normally is sent on port 80, and HTTPS on port 443 , but we don't
show ":80" or ":443" on every single URL in the location bar. We
only show the port (and you only really care) in the rare case that
it actually happens to be different from what is expected.

For both protocols and ports, I agree that disambiguation is really
important, especially for developers. But I think constantly
pointing out obvious (and also implementation centric) information
results in an interface that is needlessly complex.

For instance, regardless of what protocol you are using in Firefox,
we don't bother to tell you that it is communicating over TCP/IP,
because you either already know this, or you simply don't care.

-Alex

On Jul 25, 2007, at 5:08 PM, Michael Vincent van Rantwijk, MultiZilla
wrote:

> Alex Faaborg wrote:

[Andy Burns]

On 25/07/2007 23:35, Alex Faaborg wrote:

> I'll agree that you personally usually look at the path, but I'm less
> convinced that the vast majority of users extract any meaning from
> "videos.aspx?type=unsafe&video=iphone" and

> "search?hl=en&q=Baskets&btnG=Google+Search") Most URLs are not designed

> to be human readable (although thankfully some are).

I think back to when Microsoft first starting hiding the file extension
for known file types by default, of course /I/ didn't like it, but was
able to un-hide them for myself (though I wonder how many times, on how
many times I've had to reset that preference)

But I find that it is also confusing to "normal" users to have the
extension hidden, sure .xls or whatever might not mean so much to them
but when they have files called MyImportantProject.xls and
MyImportantProject.doc it appears to them that they somehow have two
files the same name, it is also more difficult to help these people
remotely.

Completely hiding URL schemes, and full URLs and seems like a dumbing
down step in the same direction.

[Robert Kaiser]

Justin Dolske wrote:
> I think it absolutely makes sense to hide the protocol when it's
> http://, and probably https:// as well

I just remembered this night that browsers had just "http://" in that
bar on startup when displaying an empty page (and some mobile browsers
still do, i think) and that was to to make it clearly identifiable that
this is the location bar, and it seemed to work that way for users.
Interestingly, some arguments here seem to point in the opposite
direction now...

Robert Kaiser

[Jeremy Morton]

Alex Faaborg wrote:
> Here is another idea:
>
> http://people.mozilla.com/~faaborg/files/granParadisoUI/urlFormattingIdea2.png

I don't like that, it's vastly too intrusive. Something subtle would be
best... failing just leaving the URLbar alone.

[Jeremy Morton]

Alex Faaborg wrote:
>> Letting people *guess* what the protocol is, and probably make judgment
>> errors just because of this, does a better job than the current and
>> normal i.e. expected and usual implementation?
>
> Personally, I think we should hide (and I mean totally hide) the
> protocol for http[s], but still show every other protocol. So if you

Just as long as there's an easily discoverable to restore the URLbar to
a normal text field. I've grown used to it, and that's the way I likes it!

> For instance, regardless of what protocol you are using in Firefox, we
> don't bother to tell you that it is communicating over TCP/IP, because
> you either already know this, or you simply don't care.

Or, perhaps because it's *not part of the URL*?

[Alex Faaborg]

> Just as long as there's an easily discoverable to restore the
> URLbar to
> a normal text field.

Yeah, I think any change we make needs to be easily disabled in both
preferences and on the contextual menu of the location bar itself.
This would help mitigate a potentially vocal minority of users who
keep a copy of RFC 1738 on their desk, especially since this subset
of users is also clearly adept at modifying preferences.

> Or, perhaps because it's *not part of the URL*?

I meant somewhere in our new status bar of obvious and implementation
centric information. Perhaps we could list TCP/IP to the right of
the part that reminds you that your hardware is designed for base 2
operations, and to the left of the part that reminds you that this
device is Turing complete :)

After 15 years of gui-based Web browsers, do we really need to remind
people what protocol they have been using all this time?

-Alex

[Mike Beltzner]

> I meant somewhere in our new status bar of obvious and implementation
> centric information. Perhaps we could list TCP/IP to the right of
> the part that reminds you that your hardware is designed for base 2
> operations, and to the left of the part that reminds you that this
> device is Turing complete :)

*snicker*

It's a brave new web. :)

I think what we're seeing here are some good questions about what
sort of details can be safely abstracted due to the nature of the
present-day web where most people can get where they want using
http://, and rely on being redirected to https:// when appropriate,
and other, more visible (and human-centric) indicators of the
additional value of the https:// protocol.

Obviously this would not be exclusive of being able to see the full
page address and protocol upon request. There's a huge amount of
value in that, just as there is value in being able to view source,
get detailed page info, etc. Nobody's suggesting that we eliminate
the functionality, just that we examine better ways of rendering it
meaningfully for users.

cheers,
mike

On 26-Jul-07, at 6:36 PM, Alex Faaborg wrote:

>> Just as long as there's an easily discoverable to restore the
>> URLbar to
>> a normal text field.
>

> Yeah, I think any change we make needs to be easily disabled in both
> preferences and on the contextual menu of the location bar itself.
> This would help mitigate a potentially vocal minority of users who
> keep a copy of RFC 1738 on their desk, especially since this subset
> of users is also clearly adept at modifying preferences.
>

>> Or, perhaps because it's *not part of the URL*?
>

> I meant somewhere in our new status bar of obvious and implementation
> centric information. Perhaps we could list TCP/IP to the right of
> the part that reminds you that your hardware is designed for base 2
> operations, and to the left of the part that reminds you that this
> device is Turing complete :)
>
> After 15 years of gui-based Web browsers, do we really need to remind
> people what protocol they have been using all this time?
>
> -Alex
>
>
>
> On Jul 26, 2007, at 6:08 AM, Jeremy Morton wrote:
>

[gr...@raizlabs.com]

Alex,

I sketched out my own alternative:

http://www.raizlabs.com/blog/images/FF_URL.gif

1) I'm using a http icon to minimize the http part but not remove it.
This would also allow you to switch to https and back. This helps
people understand that they don't need to type this part of the URL.
(If you simply remove it many people would continue their old habit).
I agree that long term you may be able to get rid of it but it may
take a couple versions.
2) I'm bolding the TLD and increasing the font. I'm also decreasing
the font after the ? of the URL.
3) I'm avoiding adding spaces to the URL because this may cause users
to type a space when typing a URL. Having spaces in a URL will cause
the URL bar to search so this wouldn't be desirable.

The bubbles that you used in tags and mail allow for easy selection
and deletion of a tag or an email. With a URL you're not really
looking to change just the TLD. You typically need to change the whole
thing.

- Greg Raiz
www.raizlabs.com

[Alex Faaborg]

Here is another mockup of an alternative:

http://people.mozilla.com/~faaborg/files/granParadisoUI/
urlFormattingIdea3.png

This is based on Dão's design.

Modification: The characters / - and _ are displayed in grey in the
path, to increase contrast for URLs designed to be human readable.

I think this display would also be useful when visually scanning auto-
complete suggestions in the location bar.

-Alex

[Dão]

Alex Faaborg schrieb:

> Here is another mockup of an alternative:
>
> http://people.mozilla.com/~faaborg/files/granParadisoUI/urlFormattingIdea3.png
>
>
> This is based on Dão's design.
>
> Modification: The characters / - and _ are displayed in grey in the
> path, to increase contrast for URLs designed to be human readable.

Note that while the Locationbar² extension and previous versions
supported that for /, the binding currently in use doesn't. I didn't see
much support for that idea, so when I optimized the code for Firefox, I
made the path a single element.

Dao

> I think this display would also be useful when visually scanning

> auto-complete suggestions in the location bar.

[Robert Sayre]

Mike Beltzner wrote:
>
> I think what we're seeing here are some good questions about what sort
> of details can be safely abstracted due to the nature of the present-day
> web where most people can get where they want using http://, and rely on
> being redirected to https:// when appropriate, and other, more visible
> (and human-centric) indicators of the additional value of the https://
> protocol.

This has been pointed out many times, but

http://example.com/index.html

and

https://example.com/index.html

are different URLs, and point at different documents as far as the
browser is concerned. In fact, hosting accounts often have different
document roots for each scheme:

myaccount/
web/
httpdocs/
httpsdocs/

Alex is correct that the schemes imply a port that we don't show, and we
rely on the scheme to differentiate the two URLs. I don't think we
should elide parts of the URL required to differentiate between unique
resources. That's kinda the point of URLs. :)

- Rob

[Jesper Kristensen]

Alex Faaborg skrev:

> Here is another mockup of an alternative:
>
> http://people.mozilla.com/~faaborg/files/granParadisoUI/urlFormattingIdea3.png
>
>
> This is based on Dão's design.
>
> Modification: The characters / - and _ are displayed in grey in the
> path, to increase contrast for URLs designed to be human readable.
>
> I think this display would also be useful when visually scanning

> auto-complete suggestions in the location bar.
>
> -Alex

This is the first alternative I have seen that actually looks like it could
work. But:
* There is a space between the hostname and the path. That is a problem when
people is visually copying an URL. They may think the space is part of the
URL. Same goes for the missing scheme.
* "." Should be gray and "-" should not in the domain part.
* Why is the subdomain gray? It may still hold useful information, and from a
security point of view I think there was an agreement that any coloring of
the URL wouldn't help.

http://temp.jesperkristensen.dk/mozilla/url1.html

[Jesper Kristensen]

Jeremy Morton skrev:
> http://www.game-point.net/misc/diff3.png

The text looks selected, and that is confusing. Maybe it could work if the
background color changed in the whole height of the location bar and that it
faded over to the normal background in the left and right side.