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 URLs all day long. Into FB, into Twitter, into stackoverflow answers, into HN responses.
I don't even see how this is better for Google. Links make up pagerank no? Links are what Google uses to be the best search engine. How is making it harder for people to copy and paste URLs good for Google?
I'm sure I'm in the minority as a semi-webdev but dammit, don't fix what isn't broken. Or at least give those of us with different use cases a way to get shit done without getting in our way. Sure, this may or may not be better for my grandma but it's not for me. I causes me frustration daily already. This is only going to make it anger inducing.
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.
Why do Hacker News readers need to see a URL that looks like this?
Why do users looking at Amazon Fire's landing page need to see this?
Why do EBay shoppers need to see this?
They don't. Just trim it down to the domain and call it good.
Oh, and it's worth mentioning that to copy/paste URLs, it's still only one click away, because when you click the box, it auto-selects the entire URL.
Edit: As I review my post, in the context of this story I find it humorous that even Hacker News trims the URLs I pasted because of how obnoxious and unnecessary they are.
While we're talking about things we don't need, let's include this change.
The fact is, for most of the last two decades we've already had a UI where users who don't care to attend to the URL don't have to, and users who care to notice can. What does this add? Nothing. But it does take away some legibility for people who care, and discoverability for people who might learn to.
99% of people using web browsers really get no cues from the path? Cite please. URLs aren't high tech any more than the address to your house is, and my observation is that even non-developers who are simply experienced browsers pick up cues -- even from barely legible URLs mostly meant to be parsed by machines. You don't have to be a programmer to observe that typing a string in takes you to a page, or that the string changes when the browser loads a change, and put together the address correlation until you start to understand what a URL is without even really thinking about it.
Or at least, you wouldn't have to be a programmer to learn to make that connection based off of simple observation skills if we kept the current model. If we move to this new hide-the-URL UI, probably you would (self-fulfilling prophesy!).
And sure, the web has lots of URLs that don't provide a lot of easily parsed cues. In the interest of being a little less selective, though, let's look at a few others:
Do people need to see these things? Nope. Can they derive utility from being able to see them? Yes. And they do.
When you stop by the local coffee shop, do you take note of what its address is?
The users have an idea what URLs are, they just don't care.
That's like clicking on a bookmark. But when you need to tell someone else (who is unfamiliar with the district) where that coffee shop is, or vice-versa, that information becomes really important. Hiding the path and showing only the domain is like telling someone "it's in California".
On the other hand, if the URL is displayed, then there will be many who take note of the fact that it changes whenever they click on a new link or go back/foward, and it makes them mentally associate "that piece of text" with "this page I'm looking at" - they don't even need to know the term URL to do that. It's a bit unfortunate that browsers don't have "Address:" next to it anymore, because that would've made this association so much easier (someone seems to have made the same observation almost ten years ago, although it was FF vs IE: http://cheeaun.com/blog/2004/09/address-label-for-address-ba... ). Having made that association, they can then tell you exactly where a page they're looking at is, and vice-versa.
Postal address? No, but I do know (for example) I'm on Main street, in that tiny alley one block west of 4th Ave, in the building just left of that weird giant sculpture of a bird.
I'm constantly aware of and can describe my relative location, even if I'm not always capable of expressing it using an absolute designation like postal address.
On the web, though, there is no such relativity. One website is not near or far from or above or below another. I cannot conceive of my location, much less express it, in any way but absolute address.
So: since I do not travel to reach places on the web, how do I know where I am? The address bar.
Similarly, ever tried to find your bud's house the first time in a subdivision, esp. at night? Those places all look the same and you drive past 4 times before you figure out one of the house's numbers and deduce it. The pizza guy the other night thanked me for having my number clearly displayed and lit, for the same reason.
Of course once you get into a building, it still remains annoying - I mean it's still not really obvious how the internal room/suite numbering works. That portion of addressing is totally up to the architect, and a lot of times is only intuitive after you know the space you're in (if ever).
Legible URLs are important when you need to decide to follow the link; once you're on the page, it's less important because there's bigger and more legible cues about the content right on the pages themselves then.
I noticed my 10 year old brother trying to find a song the other day in a peculiar fashion. He simply typed in youtube and "genre name." He click on the 2nd link of the search results. Then clicking on the 3rd item of a side bar linking to a playlist. He was navigating the web through links provided by google like we use the directory system.
In this case, knowing the specific url would be mind numbing and utterly useless. However, the distinction between google and the web is just too blurred for so many people.
However, I think drgath's point is ultimately correct. For some people, there really is no internet besides Facebook. For some no internet without Google. Even crazier: I've met someone who does not know the internet without Siri.
If we hold onto things like the directory structure, then we couldn't have "advancements" in user interface design like iOS. Could we eventually get a web without urls like iOS is an operating system without a visible directory structure to end users? I think it would be a big win. The directory structure was replaced by single purposed apps. What will url's be replaced by?
The holy grail of companies. Full control over 95% of the users by sacrificing 5...
you are just dead wrong thinking this is good design. obscenely profitable? Yes.
Good design is made by serving the extreme 5% while accommodating the 95... Take it from someone who actually majored in product design and usability. The rationale for user interfaces is that the 95% will at some tasks be the 5percentile, and if you don't serve them, over time you lose them. People think ios is a hallmark of usability only because the market has too much canon fodder so the 95percentile seems infinite. But eventually enough people will be fed up by being unable to send a file from one app to another the way they want. And will move to whatever crap interface that at least have a file system that allows them to compete the task.
Oh I can't upvote you enough, this isn't just for design, this is how advancements in tech happen in general. I remember when CVS was the dominant version control systems and old fogies didn't need this subversion nonsense. I read an essay in defense of svn that argued "just keep using cvs and don't worry about it, there's always going to be a minority that needs key features most people don't, let them have svn."
We're now two generations of version control down the road, both svn and git ate their predecessor's lunch by catering to the needs of the handful that were unsatisfied. Once the new thing works, most people eventually comes along because the key features turned out to be pretty nice, even if not necessary. That's how software progresses in general. Walled gardens exist to prevent others from making the next product that could eat the current one's lunch. Why else would it be verboden to "duplicate" iOS functionality?
Does Command+L still work? Because one click is too many.
With that one small change, I'd still be happy.
while you're at it you might uninstall chrome and install ... don't even remember how the AOL browser was called... But it obviously was superior to any modern browsers with their lowly urls instead of AOL keywords.
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 changes, so I tend to use IE most of the time, but I use various versions of all four on different sites - at the moment I have Firefox and Opera open as well.)
In my mind, they're all headed down the same path, just at slightly different rates. The idea that you can choose a different browser is starting to become more and more of an illusion.
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.
I was trying to think what's the difference between a 'frozen' web page / state and a bookmark. There is a difference, but for some pages, a bookmark is enough. I've always thought that tabs are really just perhaps a more convenient bookmark, but they are prone to abuse. Restarting Firefox with howevever many tabs, doesn't now reload all tabs like in the past. You loose state, but they are lighter in weight.
A bookmark doesn't retain where you are on a page. Only the page's location.
Bookmarks also don't relate to your current browser session. I usually organize mine by topic. For current task work what I want is a stack or other less-organized list that I can skip back and forth on.
Firefox's session restore was configurable. I'm a few revs back on Debian (24.4.0), so I'm not sure what all's changed recently.
Perhaps listening to a passage of text and typing some notes and reading a web page belong to a given task, and I might want to stash that away and pick it up later. Although I'm probably kidding myself thinking I can multi-task, and manage multiple tasks, sessions. Freezing one or two though might be useful.
If bookmark management was better in the browsers I'm sure people would use them far more.
You'd almost think the browser developers want you to save all state to their proprietary Web-based silos or something.
Want to read? I either fire up the Adobe PDF reader and load something from my history or I open my email/dropbox/trello card and tap an attachment, which opens up the PDF reader.
Almost all the interesting ideas in academia come in .pdf format, not .html. It just fits our use case better.
Want to shop? Fire up amazon i guess or fire up a web browser and go to amazon. Who cares if the "Amazon" uses standard HTML forms? The user doesn't.
Want to $x? Fire up $app_that_handles[$x].
Suggesting some file format, or perhaps presentation format.
ArXiV does not specify a style guide so you get this weird mix of IEEE/PAMI/single-column/double-column, but that's not really a detrement to its readability since journals wouldn't usually pick an unreadable style anyway.
I figured the format was likely "academic articles, mostly prepared with LaTeX, published as PDFs", but the commenter was being less than clear, even on reiteration.
Having file-format-specific reading utilities is stupid, awful, and is precisely the type of Windows-centric (and to a lesser extent Mac-centric) behavior I absolutely loath.
Applications centered around tasks however are a bit of a different story, and that's more of what I'm describing.
For reading, Adobe's an absolutely horrible example. Particularly on tablets. Don't make me remember the time I was buried to my waist in a colo cabinet trying to sort out load balancer issues while reading the 300+ page manual on my Android smartphone using the Adobe reader app ... which would reset to the front page each time it got kicked out ... which is precisely what was happening as a recruiter was calling me despite my repeatedly hanging up on her (and having net nil reception regardless). There are some modestly better PDF readers (say, evince), though must fail on the basis of not positioning the text optimally for reading.
Contrast with a stunning exception to the usual rule that online readers are crap: the Internet Archive's book reader. I discuss it briefly here: http://redd.it/1w0n83
The beauty of it? It autocrops the page to the visible content on it. Screenshot: http://i.imgur.com/Reg8KLB.png
You can further maximize the browser (F11) and remove the navigation elements so that _all_ you are seeing is the text you're reading. Page navigation is quick and intuitive. The entire thing is, incredibly, better than any desktop PDF viewer I've encountered.
What I'd really like is something somewhere between Calibre and Zotero: that will manage a selection of documents, organize and manage them, spawn viewers (preferably good and useful viewers -- Calibre on Linux fails massively in this regard). And, if I specify it, renders everything with minimal markup.
As for shopping: it's not that I'd fire up the Amazon app, I'd fire up the shopping app. You want a standard, uniformly designed client with solid security, not a mash of individually created apps, each with its own security flaws and excessive permissions.
Splitting shopping from web-browsing would also prevent surveilling users across the Internet from the shopping interface itself.
For specific application-based tools. Some sort of general app framework that could be fired up. The main distinction between it and the reader would be that a reader app would assume that it's valid at any time to dump state to disk and bail, whereas you could configure an app for how you wanted it to behave (I might want a monitor to be up 24/7/365, while a social networking app could shut down if I haven't interacted with it for 15 minutes).
And that same way of doing things would work quite well for a web browser, IMHO.
There are many annoyances I have with Windows, and Windows 8 specifically. That is not one of them.
When did they remove the path?
So that's just some multiple mount point weirdness, not removing the path.
(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.)
It is not clear if they are dumbing the web down for users or just to get people onto Google search.
Once you obscure URLs, web browsers become _impossible to support_. Of course Google doesn't care, because support isn't part of their lexicon.
It's easier to direct them to it because it always has the same prompt text. "Do you see a box that says 'Search Google or type URL?'? Great, type this into it..."
The thing that's harder is getting them to read the url back to you.
All of those people entering partial URLs in the omnibox, causing a Google search, releasing CO2 is terrible when they could be using local bookmarks.
I'm not sure what gets sent with regards to spelling helpers? That could almost be like a keylogger? I wonder how it works. I've turned that off also.
Edit: Apparently a useful comment offering a solution to the parent's comment is not HN worthy?
The default behavior is generally indicative of how the devs want things to be used.
So no, not an actual solution. A temporary one, yes, but not longterm.
Your comment didn't deserve a downvote but please don't assume it to be objectively useful.
On the other hand seeing the URL helps me decide if I'm on the correct webpage. mybank.com vs pretendingtobemybank.com Of course I try not to click those links in the first place but I do look at the URL to check that some link I clicked took me to the right place.
There's also plenty of apps I use where the URL is useful info. For example JSFiddle. If there's a /N in the URL I know I need to click "Set As Base" before I'm done. Of course if that's the only site I need that on maybe not a good argument. I'll have to think about if that comes up on other sites for me or not. That's also a dev only issue probably.
I wouldn't mind having 2 modes, user mode and dev mode. I can certainly accept that non-devs have different needs than devs. My only point is I'm trying to avoid frustration. I have enough that in my life. I don't want chrome to pile on more and I can see that their current URL bar already causes me frustration often while doing dev and even while just socializing on the net. At some point that frustration will lead me to find something less frustrating.
I don't hate this change so far (especially as clicking on the domain gives the full URL - although that's perhaps not very discoverable if you don't know about it already)
But would you consider that a tolerable loss, or still too much? (I think I'd say it's still too much, but I am also a web dev and thus a power user.)
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.