faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: The location field; a vestige from the early d
by Stefan Wagner on Wednesday 23/Nov/2005, @07:07
|
I disagree completly!
I paste about 100 URLs per day and splitting them into 5 fields would be annoying.
How often do you keep anything fix but the protocol?
...but the port?
...but the path-and-file?
Sometimes you may only change the query-string, but who does this by hand?
If it is build as optional feature (splitted URL vs. classical URL), and the user is free to choose: Well, I can agree.
People would learn more easily how to read an URL, and might switch to the more usable feature (classical) later on. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: The location field; a vestige from the early d
by Herman Robak on Wednesday 23/Nov/2005, @07:45
|
I am not sure whether _editing_ the URLs in a 5-part form would be preferrable. But I think it is worth considering.
As for copying and pasting: there are context menus for page addresses and link URLs. I think a raw/formatted toggle is called for, to not disrupt the workflow of those who rely on raw, editable URLs in the address field. Changing it over night with no way back is way too disruptive.
bluGill: Sure, we shall forever be able to pass URLs around in one piece. Just like we can pass around files of HTML edited in Notepad. They just won't appear verbatim in modern clients, like HTML is not shown like a bunch of tags in monospaced font to most users. Old-timers will complain during the transition, because they think the URL widgets are more convoluted than plain raw URLs.
It's time to expect a richer representation of URLs than we are used to today! For example, a URL widget could contain the anchor text. Of course, the anchor text is not always helpful, like the WAI-defying "here" or "next". But would it hurt to make such accessibility failures stand out more?
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early d
by Matt on Wednesday 23/Nov/2005, @20:44
|
Yeah your right, you do need a way to toggle off and on the "formatted URL" and you also need a quick way to copy a link. But both of those features can be implemented along side the formatted features.
I guess one of the reasons why I really like this idea is because in many cases the URL ends up having so many different query strings that they become completely unreadable and quite useless at a glance. Being able to quickly see the site name and path gives an indication of the sites structure. Which I think can be useful for navigation.
Matt
|
[
Reply To This | View ]
|
query strings being replaced with long paths
by Herman Robak on Thursday 24/Nov/2005, @00:04
|
Keep in mind that some CMSses "cheats" with their URLs to make them look like static content URLs:
From
http://www.some-cms.tld/cms-app.cgi?topic=foo&article=bar
To
http://www.some-cms.tld/cms-app/foo/bar
The latter is shorter and cleaner. And if the CMS is clever enough, it can provide all the proper directives (ETag, Last-Modified, Content-Length...) of a proper static document (brace yourselves for some weird bugs...)
This can be used to make the URLs more opaque, too. Instead of a lot of semi-readable parameters, you get one or two really long numbers, or random strings. You don't know how much of the URL is the path to the web application and where the input parameters to the web app start. Systematic digging for articles or vunlerabilities becomes harder that way.
Hence, the path and the query string are not separate entities.
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early d
by jameth on Friday 25/Nov/2005, @21:11
|
I've suggested before and will suggest again that syntax highlighting be added to the address bar. It's not too hard to have some highlighting of key portions of the text (protocol, separator marks, query entries, whatever) and doesn't completely break proper usage of the location bar (pasting paths and hand-typing addresses). Also, it might make it easier for new users to learn what that stuff actually means.
Of course, I suggested that first over a year ago, so I expect nobody is gonna rush to implement it now.
|
[
Reply To This | View ]
|
|
Usability versus phishability
by Herman Robak on Thursday 24/Nov/2005, @00:36
|
The original posting was about user interfaces to maintain security. In such a context, "usability" gets a different meaning. The usual meaning is along the lines of "whatever makes the user happy, empowered, productive, faster, and is easy to learn".
Usable security features have another primary goal: Keep the user out of harm's way. Making sure that the program follows the user's _reflected_ intent. That often means deliberately slowing down the user, so that there is indeed time to reflect. It also means telling the user about perils that the user may know little or nothing about, yet avoid crying wolf too often.
In this context, the address bar has a flawed design. It is quite evident that it fails to keep the majority of users out of harm's way. The address bar does not ensure that the browser follows the user's real intent. All the successful phishing scams serve as proof of that.
The web is about serious stuff now. People buy expensive stuff and manage bank accounts with it. Yet they are totally oblivious of the underlying architecture. Which is OK! You don't need to know the building structure of a house to use it safely. Opening and closing doors is not supposed to have fatal side effects. Web browsers and web applications need to be the same way, so users can trust their gut feeling without getting burned again and again.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
