Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Burying the URL

allenpike.com

Post reply on HN
Print view View original

361–370 of 376 posts

Re: Burying the URL

#361

Post by lmm »

kijin wrote: post #356
lmm wrote: post #292

Earlier quoted context omitted.

> Most URLs are human-readable enough that I think street addresses make a better analogy. I'd like that to be true, but I think we lost that battle a long time ago. Google results aren't a readable URL; nor are products on Amazon or Ebay or anywhere else I can think of. Newspaper-type URLs are often "fake human-readable"; the URL is something like http://somepaper.com/12345-Local-Man-Found , but in fact http://somep…

I agree about Google and Amazon's long and cryptic query strings. But I don't think "fake human-readable" URLs break the analogy with physical addresses. There are many different ways of writing the same address: 987 Some Avenue West, Unit 123, Brooklyn, New York, NY 12345-6789 Unit 123, 987 W. Some Ave., New York 12345 123-987 Some Av W, NYC, NY Some are more correct than others, and there's probably a canonical ver…

If you meant to send a letter to "The Foundry, 28 Some Street" and instead put 26, the postman would probably deliver it to the right place. Not so with these fake human-readable URLs.

And the numbers aren't just opaque identifiers (except for the zip), at least if you're walking down the street: you know that 28 is next to 26, opposite-ish 27, and halfway to 56. There's nothing that corresponds to walking along the street on a website.

Re: Burying the URL

#362

Post by schrodinger »

djeikyb wrote: post #358
esrauch wrote: post #323

Earlier quoted context omitted.

> In cases where the google search gives the wrong response, chrome gives the same wrong response, for example on intranet servers. What? Intranet addresses work perfectly fine in the chrome url bar, unless it 1) has spaces (which aren't technically allowed in urls, and you can type %20 to avoid) or 2) is only letters (which you can avoid by just appending a slash or something). Also, if the omnibox automatically red…

My experience is that chrome works great with intranet addresses if you fully type them out. "gerrit.gps" searches for the string "gerrit.gps". I have to fully type out " http://gerrit.gps" to get to our gerrit server.

Usually for me it loads the search results, but also puts a "did you mean http://gerrit.gps" at the top. Clicking yes to that also remembers it for the future. I'm totally cool with this approach.

Re: Burying the URL

#363

Post by tfinniga »

esrauch wrote: post #323
tfinniga wrote: post #288

Earlier quoted context omitted.

I think we can probably agree that the text field on google.com is a search field. However, if I enter "face" into the text field on google.com, then facebook.com is the top result. If I enter a complete URL like " https://news.ycombinator.com/item?id=7677898" or even "news.ycombinator.com/item?id=7677898", it turns it into a link to that page. The only difference between the search field on google.com and the URL fi…

> In cases where the google search gives the wrong response, chrome gives the same wrong response, for example on intranet servers. What? Intranet addresses work perfectly fine in the chrome url bar, unless it 1) has spaces (which aren't technically allowed in urls, and you can type %20 to avoid) or 2) is only letters (which you can avoid by just appending a slash or something). Also, if the omnibox automatically red…

I agree, intranet addresses mostly work. For those that don't work, there are workarounds, like specifying the protocol or adding /. Personally, I'm happy with the current omnibox behavior.

Getting back to the earlier question, is the omnibox a URL field or a search field? Well, it's a combination of the two. But it's sort of like a UX version of the ship of Theseus.. if you slowly remove all the behaviors of a URL field and replace them with those of a search field, at what point does it become something different? When does it become a search field with URL behaviors instead of a URL field with search behaviors?

If you look at the screenshot in the linked article, the field says "Search Google or type URL" instead of showing the URL. I think that's the watershed moment. Given all the behavioral changes already, subjectively I'd say that's not a URL bar any more. Even if the omnibox behavior is exactly the same as now, it's no longer showing the URL.

I hope it doesn't make its way into the release version of chrome.

Re: Burying the URL

#364

Post by Turing_Machine »

mreiland wrote: post #310
albertsun wrote: post #307

Earlier quoted context omitted.

It might test well in metrics, but this is the kind of thing that points out why purely data based decision making can be dangerous. A-B testing assumes users will all behave the same in the future as in the past. But people's future behavior is dependent on their present behavior and experiences. With repeated exposure to URLs more people will learn how URLs work. Hiding URLs means that people will never be able to…

I already really dislike that win7 hides the filepath, and lies about it in many cases. It makes me click on the bar to actually see where I'm at in the filepath, please don't take that design mistake and apply it to the web.

Related: Microsoft's decision to hide file extensions by default was arguably one of the worst UI mistakes of all time, leading to naive users launching coolpic.jpg.exe because all they saw was coolpic.jpg, among many other problems.

Re: Burying the URL

#365

Post by parasubvert »

alandarev wrote: post #184
jpatokal wrote: post #127

Earlier quoted context omitted.

Since this is getting misinterpreted: I'm not saying software (or computers) should be locked down, DRM'd to death and hidden. I'm saying that hiding complexity that does not serve the average user is desirable, and browsers are going down the same path now that cars did a hundred years ago. So for this specific case, if Chrome wants to hide URLs, go for it; and I'm sure there's a configuration toggle somewhere to tu…

Yes, yes, logical thinking, I even agree with it. But imagine this happening, average users will become fully IT illiterate. Growing children will no longer know anything about computers, as they grew up in an environment where everything is hidden from them for sake of simplicity. What will happen, after our generation(s) all get old, and the growned up illiterate children take place of improving world's technology?

There will always be curious people, and relatively inexpensive ways to get access to the inside of things, and large communities of people supporting each other in this endeavor. Yesterday's Commodore 64 game pirate is today's Minecraft modder or iOS jail breaker with Cydia.

We might have an engineering shortage in future ( we do already ), but it will be for many factors , not just lack of opportunities to tinker. If it isn't addressed, we will go long periods of time without nice things (think of the relative stagnation of the web from 2000 to 2008).

Re: Burying the URL

#366

Post by rnirnber »

paulirish wrote: post #121

This is a new UI experiment that's deployed to a small fraction of users. We're looking at a few key metrics to see if this change is a net positive for Chrome users. (I imagine it may help defend against phishing). My personal opinion is that it's a very bad change and runs anti-thetical to Chrome's goals. I hope the data backs that up as well. But regardless, this change is far from shipping as the new default beha…

It's going to be annoying for developers. We often put special query string hooks to test functionality or debug queries...it'd be kind of a pain to have to enable flag in chrome just to be able to type in the URL.

Re: Burying the URL

#367

Post by dredmorbius »

lmm wrote: post #346
dredmorbius wrote: post #327

Earlier quoted context omitted.

What's the arxiv format if I could ask?

Not a format, a website; arxiv.org.

You wrote: "I can read papers from 12 different journals and they're all in the same format there."

Suggesting some file format, or perhaps presentation format.

Re: Burying the URL

#368

Post by dredmorbius »

insky wrote: post #350
dredmorbius wrote: post #342

Earlier quoted context omitted.

I like tabs. They needn't be to specific pages, however. And I hugely dislike horizontal tabs -- tree-style tabs (available as an extension on Firefox) give you additional cues of position and nesting, and can show far more context even in a busy browser session (and all my browser sessions are busy). A bookmark doesn't retain where you are on a page . Only the page's location. Bookmarks also don't relate to your cur…

I'm on Debian Nightly 31. And I can't even find the managing session stuff in the menus. I'm sure I used to be able to save a group of tabs. If bookmark management was better in the browsers I'm sure people would use them far more.

Bookmarks as is are a complete nightmare, agreed.

You'd almost think the browser developers want you to save all state to their proprietary Web-based silos or something.

Re: Burying the URL

#369

Post by rspeed »

tfinniga wrote: post #288
rspeed wrote: post #269

Earlier quoted context omitted.

> The new change would just make the whole thing a search field. This is incorrect. Entering a URL into the field produces the exact same behavior as it does with this option disabled. Typing a URL and pressing enter goes directly to that URL. Typing part of a URL that has been previously visited (like "face" => " http://www.facebook.com/" ) will default to visiting that URL.

I think we can probably agree that the text field on google.com is a search field. However, if I enter "face" into the text field on google.com, then facebook.com is the top result. If I enter a complete URL like " https://news.ycombinator.com/item?id=7677898" or even "news.ycombinator.com/item?id=7677898", it turns it into a link to that page. The only difference between the search field on google.com and the URL fi…

> In other words, it will make the whole thing a search field, with some smart url-friendly behaviors, so that most of the time when you enter a url it will take you to that url.

In other words: what Chrome has already done for a very long time.

Re: Burying the URL

#370

Post by dredmorbius »

insky wrote: post #347
dredmorbius wrote: post #341

Earlier quoted context omitted.

On most modern OSes, the OS will generally know. Though I find "app for document type" models largely broken.

I interpreted the comment differently. I read that the human was to do the association more on a task base, rather than a file association.

Fair point, though IME task-oriented apps tend to be more comprehensible than format-oriented ones.
Post reply on HN