Live data from Hacker News

Burying the URL

allenpike.com

271–280 of 376 posts

Re: Burying the URL

#271
post #153
post #145

Earlier quoted context omitted.

The only problem I see with this is the confusion between the search box and urls for most users. 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…

you described the nefarious walled garden metaphor. 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% wi…

Good design is made by serving the extreme 5% while accommodating the 95...

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?

Re: Burying the URL

#272
post #227

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've enabled it to try it out. First impression: It doesn't make any sense to hide the protocol when you reveal the URL, and I found myself looking for a "Copy URL" button. Since copying the URL is what I most often try to do when selecting a URL, it would make sense. It makes browsing feel much calmer, and I'm pretty sure I'll keep it enabled for a while.

That's actually fairly old behavior. If you copy the full contents (which is selected by default) it includes the protocol.

Re: Burying the URL

#273
post #226

Earlier quoted context omitted.

> URLs aren't high tech any more than the address to your house is 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.

No, because I know that I drove down the same street, parked in the same parking lot, and walked through the same door. The URL should always be visible so that I can glance up and see if I am in a familiar place before putting in a username/password.

The point of this is that you see and compare the domain before putting in a username/password. That's probably more reliable than comparing a full URL - the difference between y0urbank.com and yourbank.com is much more obvious than the difference between y0urbank.com/?bunch/of/state=whatever and yourbank.com/?bunch/of/state=whatever

Re: Burying the URL

#274
post #72

Earlier quoted context omitted.

>This should apply to computers. No, no, a thousand times no. What happened to cars - the replacement of mechanical, inspectable, (dare I say it) hackable components with electronic black boxes was not a good thing. You used to be able to fix and replace most things in an automobile engine with parts from the local auto shop and a shop manual. No longer. Now you have to spend hundreds or thousands to get the correct…

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

There is this weird phenomenon I see happen online sometimes.

There have been two steps forward. Simultaneously released alongside, but not dependent on, one step backward.

So why do people defend the step backward under the guise of the steps forward.

Re: Burying the URL

#275
post #234

Earlier quoted context omitted.

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,…

You seem to be asking for a generic "Tablet" interface, with multiple compartmentalized apps/processes for each of your use cases. 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…

Academia is mostly standardized on arxiv - I can read papers from 12 different journals and they're all in the same format there. The rest of the web hasn't got there yet - if I want to read 12 different blog articles I have to navigate 12 different kinds of styled pages.

Re: Burying the URL

#276
post #226

Earlier quoted context omitted.

> URLs aren't high tech any more than the address to your house is 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.

No, because I know that I drove down the same street, parked in the same parking lot, and walked through the same door. The URL should always be visible so that I can glance up and see if I am in a familiar place before putting in a username/password.

The component of the URL you check when avoiding phishing attack (the domain) is still displayed.

Re: Burying the URL

#277
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…

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.

Yes, android's intent system is neat. But after years of experience with it, it's sadly not a pancea.

Re: Burying the URL

#278
post #230
post #119

Earlier quoted context omitted.

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

Does ^L still jump to the URL bar, activate the URL button, and select it? Since that's how I copy URLs anyway, I'm fine with that. ^K should just jump to the URL bar since it's now a search bar and ^L should jump to the URL/search bar and select the URL, as before. With that one small change, I'd still be happy.

Yeah, that still works. Interesting, looks like Ctrl-K prepends a ? before you start typing, which is how you tell Chrome (and Firefox) that what you're typing should go to the default search provider instead of being used as a URL.

Re: Burying the URL

#279
post #81

This reminds me of a discussion with a university professor back in the mid-90's, when the Internet started to reach the common user. He was exactly doing a research in how to remove the URLs from the user view, without changing the HTTP protocol.

Wasn't the visible URL originally a Mosaic "innovation"? It doesn't seem to have been visible by default on WorldWideWeb https://en.wikipedia.org/wiki/WorldWideWeb , or on Erwise https://en.wikipedia.org/wiki/Erwise , though it does appear at the bottom of the screen in WP's ViolaWWW https://en.wikipedia.org/wiki/ViolaWWW screenshot.

Re: Burying the URL

#280
post #143
post #24

Earlier quoted context omitted.

You seem to assume that people are looking to learn and grow their computer abilities. Learning takes an open mind, which isn't the case for most people. Ease of use enables the user to perform actions with more impact. Think of it as Python vs C. You need a lot more knowledge to get started with C, but you can customize almost every aspect of your program. With Python, you lose some customizability, but you can do a…

So much cynicism! My experience is that people do have an open mind, especially if encouraged to learn. With the trend towards turning computers into purely consumer appliances, the danger is that maybe most people won't even know there is something to learn.

Absolutely. And for those who don't, instead of making it easier for them to keep their minds closed, we should be encouraging them to open up.

Practically all developers started as users who got curious about something and wanted to learn. In some ways, the less information a UI exposes to them, the less inclined they will be to ask - because they don't have anything they can particularly ask about. I'm extremely opposed to hiding the default hiding of the URL scheme for this reason: users are far less likely to ask "what's HTTP?" Certainly many won't care, and to them it's "just another part of the website's name", but future developers are (or should be) the ones who do, so it potentially reduces the number of genuinely curious and inquisitive developers. At the same time it conditions them to think that such opaqueness is the norm, the way things should be when they write their own applications, and the vicious cycle repeats.

Post reply on HN