Live data from Hacker News

Burying the URL

allenpike.com

211–220 of 376 posts

Re: Burying the URL

#211

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…

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…

I'm smelling a possible reboot of the browser paradigm.

There are a few fundamental uses I see, and they're somewhat distinct:

• Reading. For which stripping 99.99966% of Web formatting would be preferred. If I got content-heavy sites in a form similar to what Readability, Pocket, Instapaper, etc., delivers, I'd be much happier. Well, slightly less grumpy. I found it interesting that the Kobo tablet was, for a while, advertising its browser as doing just that (from what I can tell of the revised copy, they're offering built-in Pocket). See: http://www.kobobooks.com/tablets Online forums are another special case.

• Commerce. Here authentication and payment are concerns. Neither are built in to existing HTML standards.

• Applications. Something that's more than just putting words (and images) on a page, or buying stuff. For this I'm actually inclined to think that the Mobile app model might be more appropriate. Say I want ... an email tool, or an interactive mapping tool, or a host monitoring solution, etc. Running this in a separate process space, in a separate windowing context, individually controllable, etc., would be a huge win.

The other element is user state: there are very few cases where I need a specific browser page running at all times (selected apps are the exception). What I do want is to be able to return to the page state I'd last left it at. With very aggressive paging out of state to local storage, and/or simply leaving a marker of "this is where you were at", and being able to recall it as needed, overall performance would vastly improve.

Neither Firefox nor Chrome presently offers this. On Firefox, there's a single process space, such that all tabs become unresponsive when system resources are exhausted. On Chrome, there are multiple subprocesses, which are individually much heavier-weight than Firefox's own tabs, but which can be individually killed. You have to reference them indirectly, however, through a task manager, rather than being able to simply kill the tab you're on at the moment (you can close it, you cannot kill it). In both cases I'm finding myself constantly manually managing resources. I've also found myself abandoning Firefox for Chrome as with the former I've got to kill/restart the whole thing, while Chrome gives more granular control, and Chrome tends to crowd out FF for resources. Both are very far from optimal.

Re: Burying the URL

#212
Hope this doesn't become a thing. URLs are the one thing that almost always works when you need orientation. "Where am I?". It's no good to tell me "you're in Amazon" if what I really mean is "what department". When reading blogs, the URL can sometimes also orient you in time, not just in (virtual) space - when the date in the path.

The worst, though, seems to be that it has been removed for a very strange reason. It's not that the URL bar takes up precious space in the browser, since it has been replaced by a search bar that takes up the same space. It's also not that it's something that's disorienting or a distraction to the user - as far as I know, most users have been browsing with URLs present in their browsers since they every laid eyes on a browser. What's the reasoning behind it? Phishing? Yeah, sure...

Re: Burying the URL

#213
I like what chrome is doing with Canary Version 36.0.1951.0

If clicking the label reveals the longer version of the URL, and its still editable, then this could be really huge I think.

I'll love to try it out.

Re: Burying the URL

#214
post #119

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 NEED TO EDIT URLs. I'm using Canary with this option enabled, and all you have to do is click the domain box, then you can freely view, edit, and copy the URL. All this update does is hide the path portion of the URL. That's it, so IMO, this story is way overblown. Google isn't removing the URL bar, they're just acknowledging the fact that 99% of users don't need to see 99% of the URLs they visit on a daily basis…

> I'm using Canary with this option enabled, and all you have to do is click the domain box, then you can freely view, edit, and copy the URL.

Does Command+L still work? Because one click is too many.

Re: Burying the URL

#215
Yet another user-hostile action from Google. How do people put up with Chrome? Firefox may be slowly rotting (cf: Australis), but Chrome is driving the destruction of usability.

Re: Burying the URL

#216
If this change lands, then a couple minutes into helping someone fix their computer you now not only have to change Windows Explorer to show file extensions, but you also get to disable this.

Re: Burying the URL

#218
post #38

Earlier quoted context omitted.

> the only time I care about URL's is when copy-pasting This is like saying the only time I care about electricity is when I need to power something. The fact that there's a universal textual way to refer to and link everything – like via copy and paste – is precisely why the web is so powerful.

More like "the only time I care about electricity is when taking a battery from one device and putting it in another". If there was a way to tell Chrome "Share this website on Skype to this person" or "Send this to this-or-that IRC channel" I would never care about the URL. The only reason I interact with it is because I want to share the page with someone specific (rather than using a spamming/sharing widget). But I…

FWIW, commands like the ones you mentioned used to be possible with the ubiquity extension for firefox. Good times.

Re: Burying the URL

#219

Even regular users want to select & copy the URL, and paste it elsewhere. How to accomplish this task when the URL is a button is unclear (source: I showed the screenshots to my wife and asked her what she thought). For this reason alone, the change seems like a big usability fail.

But you're not supposed to paste the URL elsewhere, you're supposed to hit that share button to share the content on one service, and one service only!

SCNR

Re: Burying the URL

#220

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 funny that people say not relying on URLs would be anti-web. IMHO this causation is made only on a selection of empirical observations. In fact I think, you could also draw other conclusions from empirical observations. Let's look at REST. Everybody is using it for HTTP APIs, or to be precise: everybody pretends to use it. Because, as many know, a REST API is only a true REST API, if it follows the HATEOAS parad…

>Most URLs are not human readable, even HN is an example

Personally I find the HN way fairly readable. I mean item no 7677898 is something I can read and understand and I note similar systems are used for quite a few things in the real world like phone numbers, zip codes and passport numbers.

It's stuff like "https://www.google.co.uk/search?q=address+white+house&oq=add... that I find going on unreadable.

Post reply on HN