Live data from Hacker News

Burying the URL

allenpike.com

261–270 of 376 posts

Re: Burying the URL

#261
post #235

Earlier quoted context omitted.

stop using Chrome That may solve this particular problem, but then which browser do you use instead? Firefox has had its history of similar changes (although you can still use extensions), Opera post-12 lost a ton of customisability, and IE, although appearing to have the fewest irritating interface changes, also has the most rendering quirks. (Personally I'm less concerned with the rendering quirks than the UI chang…

If 99% of what you do is in a browser then the browser has really taken the place of the operating system. And browsers are destined to follow a similar path to the OS. Remember when windows removed the full file path from explorer?

Apparently Windows 8 still has this option:

http://www.eightforums.com/attachments/tutorials/7526d134379...

(There are many things I dislike about the UI in Windows 8, but MS has not removed configuration and features quite as aggressively as others.)

Re: Burying the URL

#263

This idea (or at least, where this idea could lead) is actually a far more RESTful approach to the web. REST services should offer a single entry point - the root url - and the rest of a service's content should be navigated to through hypermedia affordances. The advantages are clear: the user never hits a broken page (theoretically) or finds that content has been relocated. The disadvantages are also clear: no more…

I think you are confusing discoverability with navigation. It's good if you can discover all content through hypermedia, but why should you prevent direct access?! It's like saying that there should be an indes in every book (yes!), and therefore you should not ever tell anyone on which page of the book they can find something relevant (wtf?).

> I think you are confusing discoverability with navigation.

I'm not. I understand why it's hard to swallow though, because I think a valid criticism of the REST architectural style is that it removes bookmark-ability.

> It's good if you can discover all content through hypermedia, but why should you prevent direct access?!

Well, precisely because direct access implies that out-of-band knowledge is driving the interaction rather than hypermedia. I would refer you to Fielding's discussion of the topic[0] where he notes:

> A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand).

> It's like saying that there should be an indes in every book (yes!), and therefore you should not ever tell anyone on which page of the book they can find something relevant (wtf?).

Interacting with a web service/site is not like interacting with a book (or a physical address), because there is no permanence as there is with physical objects. Have you never tried to go to an old bookmark to find that the content has been moved (and you get a nice 404)?

Anyway, I wasn't saying that this is all A Good Thing, just that the change in chrome doesn't seem at all at odds with REST (however, as many have pointed out, it can be at odds with usability)

[0]:http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

Re: Burying the URL

#264

This may be the reason I stop using Chrome even though I was a member of the team for 5 years. I NEED TO EDIT URLs. I need to copy and paste URLs. It was already annoying enough with it's removing of the protocol because sometimes I make a typo, try to edit it and it messes up and removes the protocol forcing me to edit it a 3rd time only after it goes as searches for something. Even as just a user I copy and paste U…

I copy and paste URLs all day long too. I use CMD+L to select the whole URL and CMD+C to copy it. No big deal.

Great for you with your 'keyboard', perhaps not so good for other input devices.

I do actually have an irritation, when I'm in Chrome and I do a CTRL+L and CTRL+C, and then I go to paste what I think I've copied, actually I have an unexpected http:// at the front of what I've copied. Sure that's what most people want, but it isn't what you see is what you get.

Re: Burying the URL

#265

(This has now been removed, according to an update by the author.) The fundamental idea isn't all that bad. But look, even in the 300px image you still have room to show more: http://i1.wp.com/garybacon.com/wp-content/uploads/2014/04/Sc... le. So while I know I want to enter a new URL or search about 20x as often as I want to edit or copy the current URL, and, therefore, I am fine with needing to click somewhere else…

If you want to see something useful in that empty space, the obvious thing to put there is the page title. (And you don't need to show the URL text at all to make it copyable.) User-visible URLs are a Bad Idea in general https://news.ycombinator.com/item?id=7679423 . If you badly want to have the tree-structured site guide that people abuse path segments for, that can happily be implemented in some other way and displayed in the same space too.

Re: Burying the URL

#266
Brilliant idea! And while we are going about removing unsightly, brain-straining details from every UI, let's remove all street signs, house numbers, highway exit signs, and so on. Also, hide all place names on all maps, Because who needs that complicated excessively detailed noise?

Instead at any time we can just call one of the ubiquitous Google-taxis, and ask it to take us to the place we can vaguely describe by some approximate references. When we get there, if it wasn't where we wanted to go, well that was our fault for not being more specific. We should try the Google-taxi again. But it might take a while to be sure it wasn't where we wanted, since... no visible address!

Seriously, this isn't just the stupidest browser-change idea ever. It's a deliberate move to dumb the net down and shift web functionality towards more total control by Google. You do realize Google censors search results, right? So if searching becomes the only way most people know to refer to/find a site, removing it from search engine results is equivalent to removing it from existence.

This isn't about 'UI tidyness' at all, this is about dis-empowerment of users, ensuring that naive web users never become more aware of how it all works, and ultimately about Control.

Personally I use full URLs all the time. I keep lists of article URLs in text files (like these: http://everist.org/archives/links/ ) as well as saving articles because they may disappear. I often explore in sites by direct editing URLs. I demand to see full URLs on mouse hover, before clicking links.

The 'hide/tidy the URL in the address bar' foolishness has been getting worse and worse for some time, and is a pain. Chopping the protocol off, graying out paths, shortening... I refuse to use a browser unless I can configure it to stop messing with the URL. No I don't want it animated, with bits appearing or disappearing depending on what I do. If you're complaining about superfluous visual detail, how is moving and changing the visible URL around all the time not worse than any static URL, no matter how long and machine-like? A static long URL I don't care about is fine, but if it _moves_ it demands attention.

I can't believe the people pushing this actually expect to get away with hiding Universal Resource Locators from web users. Literally, taking down the street signs and expecting people to trust google and other search engines to faithfully perform the task of taking us to places we want to go, without ever trying to _influence_ where we actually end up going.

Just like Google isn't trying trying to force fundamental and harmful browser functionality changes down our throats. Or coerce us all to joyfully become Google+ users. Or force everyone to use their real names in online forums, Or build Skynet for some reason (ref their ongoing purchases of every AI group they can.)

Also, take that "It's OK, the URL is still available, it's just hidden way down in here" assurance and shove it. Same thing as UEFI secure boot - "It's OK, the ability to install some other OS is still there, you just have to thenyzzzt em-thup jksdfh!" How can you be so naive? It's a process, a series of planned steps, and after the nth little harmless step, the capability won't be there at all. Most people won't even remember it ever existed.

All you people applauding this move... you've got to be kidding. Useful idiots perhaps? Or part of the choir.

If this sounds negative, do you understand how negative I think the idea of hiding URLs sounds? I'm having great difficulty refraining from using offensive language. The concept deserves a large serving of it.

Re: Burying the URL

#267
I have a compulsion to remove the unclean crap at the ends of urls that seem to be for somebody else's benefit besides my own. Query strings usually, with various tracking ids or unnecessary preferences. It bothers me when that stuff is there, and it is satisfying to remove it, although unpleasantly cumbersome. I wish people doing that stuff to urls would just stop. Let them just point to the resource.

Re: Burying the URL

#268
post #72

Earlier quoted context omitted.

Old cars: you could fix it yourself. Modern cars: rarely need fixing; also much more efficient. I know which I prefer.

Are you implying that new cars rarely need fixing and are much more efficient because they are completely closed down and harder to work on than old cars?

The converse: advances in automotive engineering have made cars more reliable and efficient, with the unfortunate but tolerable side effect of making them internally more complex and inaccessible.

Re: Burying the URL

#269

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…

I agree that it's absolutely awful. I hate how mobile safari has removed URLs, I find it very disorienting. I'm constantly looking at the URL bar to see if I've navigated to a new page or not, to see what the page I'm on is named and its purpose is, and to make sure I went where I clicked and wasn't just redirected somewhere else (sometimes this can be really confusing, for example mobile versions of webpages that du…

> 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.

Post reply on HN