beltzner wrote:
I'd actually keep this in the location bar, but give it a very
button-like UI treatment. That way it also acts as a "snapback" to the
root domain.
I don't know what you mean with "button-like UI treatment" and
"snapback", but I could buy that allowing users to enter something there
would both strengthen the user's focus on it (which is what I want) and
nicely solve the "where to manually enter URLs" discovery problem.
For EV I was going to suggest that we don't show the domain name, but
instead show the name of the cert holder. So [Paypal, Inc.].
I think that the domain is still the strongest trust root. I think
showing only the cert holder puts too much emphasis on EV. The realname
has phishing problems of its own. I know what ebay.com is, but I don't
know what eBay Help, Inc. is.
* Keep the search field
Yeah, that's not going anyplace soon. ;)
lol!
* Remove the urlbar
That's probably also not going anyplace soon
I know it's very tough, but it's quite central to the proposal. It's the
URL which is confusing users. (Half of the time - the other half it's
the link text - there are other ways to attack that.)
Imagine: domain label shows hosters.cx and urlbar shows
http://www.microsoft.com.hosters.cx/download/. What do you think will a
user pay attention to? You have only one guess.
BTW: The other hard, but central part is to educate companies to use one
domain only, always. No more mybankofamerica.com crap, no more
abcnews.com, much less abcnews.go.com, it *must* be either news.abc.com
or abc.com/news/. No exceptions allowed. At some point, when we
convinced most companies, we can use the press for the effort to educate
both users and the rest of companies.
Yes, for both news.abc.com and abc.com/news/, my proposal would show
only abc.com, but it would show (the bad) abcnews.com. That's kind of a
contradiction to the last paragraph. Not sure what to do. We could strip
down the URL, remove username/password and query, maybe even filename,
leaving only hostname (not just domain) and path. But then we're still
victim to microsoft.com.hosters.cx/download/, which is exactly what I
want to avoid.
Direct edit capabilities need to be there to satisfy a core user set,
and also
because, as you learn more about the internet, it turns out direct
edit of the URL field is achingly useful.
I agree that editing URLs is very useful, and I don't want to take it
away (thus the Open button, which is just as fast), but also quite rare,
and something very few users do at all. It's just faster to click on the
company logo than to select everything after the hostname and click
"Del" on the keyboard.
In many cases, even on many Wikis, the URL is hard to read, so most
people either completely ignore it or do only minimal parsing. *This* is
what got us this phishing problem. It must be dead-simple and obvious
how to read it, and always work for all users.
In other words: *Either* you make something the identifier *or* usable
for humans, but the two don't go terribly well together, and you surely
can't create a system which has seriously bad effects when the user gets
the ID wrong just once, but that's exactly what we did. The Internet
specs define the URL as a technical identifier. Some sites use it as the
latter, some try hard to make it human-readable. Some users can parse
them and pay attention to them, others are scared by the bad cases and
ignore it. And yet other users are so new to the Internet that they are
happy to have found a holiday recommendation site ("*They* said this is
a great hotel" - "Who is 'they'?" - "The people there on that site I
went to" - "Again: *who*?" - Silence).
* Put an "open" button to the left of the domain field. Clicking on
it shows the current URL in a textfield (either in dialog url
toolbar), in a way so that the user can easily either edit the URL
or enter a new one.
Or do clever things when the user gestures that they want to enter an
edit mode by moving the mouse, clicking in the text areas, etc.
Hm. May be an idea. Only thing is that I am skeptic about "clever"
software/UI :), it's not as predictable for users and thus usually
degrades usability more than explicit UI.
How about this:
* The urlbar shows the domain only
* The urlbar is editable, so an obvious way to manually enter URLs.
* The Open (or "Show") button makes the urlbar show the full url, so
the user can edit it. It's just as many clicks as right now - only
difference is that you have to click on the show button instead of
in the urlbar.
As long as the resulting structure looks sort of like a URL, I don't
think you're actually going to see this freakout, actually. I think
you will if you take away their ability to quickly cut, paste, and
edit the URL.
Yes. As I said, I don't want to. The button takes are of "quickly",
"cut" and "edit", but not "paste" and drag&drop. If the domain field
were editable, it would also be an obvious drop target.
Anyway, we're into UI design, which I promised myself I wouldn't do in
this forum, but I just find this idea of making the location bar
smarter and more useful so *intriguing*! :)
OK :)
Ben
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
