Live data from Hacker News

Burying the URL

allenpike.com

281–290 of 376 posts

Re: Burying the URL

#281
post #235

Earlier quoted context omitted.

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?

I remember when they split the full file path into clickable pieces for each directory, making the fully-visible path even more prominent and interactable than before. When did they remove the path?

[deleted]

Re: Burying the URL

#282

Earlier quoted context omitted.

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

Well, I am no priest of REST, but I think you are completely misinterpreting Mr. Fielding's point. That whole paragraph that you are quoting there is all about discoverability, at least that's how I interpret it. I mean, he even uses the word "bookmark", a concept which you seem to claim is incompatible with the approach. There is nothing in there that suggests you have to start at the one global canonical URI (which one would that even be? http://www.google.com/?), all it says is that whatever the initial URI is that you start at, the data you get back should be hyperlinked, using URIs, to any other resources that might be related to it, so that you can discover those related resources _without_ _prior_ _knowledge_ of _how_ _to_ _find_ _those_ _related_ _resources_, except through very general knowledge about the media type that the data is formatted as. Really, all that means is that a REST API that exposes a discussion thread and the postings in it, say, should not specify that for a given thread, the postings can be found as /posting/ (because that would be out-of-band), but instead the document describing the thread should contain the URIs of the postings, so that general URI resolution mechanisms can be used to obtain them. In a way, it's all precisely about making things "bookmarkable", by using one common explicit addressing scheme for everything.

And that addresses can become dangling is completely besides the point. To solve that, you need a more stable addressing system instead of just not using addresses at all (which you really can't, if you think you can, you are confused and probably about to create an even less stable addressing system).

Re: Burying the URL

#284
I work at an academic library in IT, among other things supporting users. Supporting them using a variety of local and third-party remote web apps, which integrate in some weird ways.

Users reporting problems LOVE to send me screenshots. (Usually pasted into an MS Word document, yep). That's about the only reliable info I can get from users trying to report something they believe is a bug.

At least when the screenshot includes the location bar, I can see what site they are actually on, and in many cases with some squinting actually recover the URL.

It's gonna make support a lot harder when/if URLs stop appearing here.

I have no idea how relevant this will be to anyone else, and it probably is not a good reason to leave URLs there, but, oh boy, it's gonna be rough. We'll have to actually try to train users in how to find and copy-paste the URL, which we haven't had too much luck doing even when it's in roughly the same place in every single browser; a future where we need different browser-specific instructions, so we first need to ask them what browser they are using, then tell them how to find and send the URL, at which point they've already moved on and no longer care about the 'bug' they found before.... ugh.

Re: Burying the URL

#285
It needs to work more like how Explorer works; Show many boxes but reveal the full path when clicked anywhere. To be honest, it would be nice if it displayed a box for each part of a URL:

http://www.amazon.co.uk/WD-Desktop-SATA-Drive-Green/dp/B008Y...

Turn into this:

[amazon.co.uk] WD-Desktop-SATA-Drive-Green > dp > B008YAHW6I

That would encourage cleaner URLs while exposing the whole thing (">" is just "/"). Perhaps an API could be created to tweak them a bit. I'm not entirely sure how to handle GET params though. A box for each parameter? One box with all of them? As for clicking the first box, it has to open up the panel that normally opens if you click on the padlock / paper so it's still one click to configure cookies / see certificates and not two.

Right now I don't like the implementation as the URL is too hidden but I do like the idea; this will make it a bit harder to do phishing. Honestly, the old approach was the right idea too; dim the rest of the URL so it's more prominent what domain you are on.

Re: Burying the URL

#286
Crap, I don't use Chrome (partly because of shit like this), but this means Firefox will soon steal this "genius" idea and make copying/editing urls a pain in the ass.

Re: Burying the URL

#287

I somewhat expected this, given the trend of where things seem to be heading with software these days. In the name of "usability" configuration is removed, UIs are "simplified", and gradually the choice and freedom of the user is degraded. Opportunities to make mistakes and learn from them, or to explore and discover, a chance for users to grow . Dumbing-down software only encourages more of the same. The "senior try…

For kicks, try replacing "software" with "automobiles" in your paragraph. The innards of a modern car are incomprehensible to all but "the few elite", and its interface goes a long way to hide all that complexity. I only have the vaguest idea how it works, and am perfectly happy to outsource its maintenance to professional mechanics, because all I care about is that it works . This should apply to computers. My famil…

> The innards of a modern car are incomprehensible to all but "the few elite", and its interface goes a long way to hide all that complexity. I only have the vaguest idea how it works, and am perfectly happy to outsource its maintenance to professional mechanics, because all I care about is that it works.

This makes the same false assumption about the world when applied to computers: The world does not exist of a binary-human type: people who are experts and people who are not.

I own a 28-year old Volkswagen van. It is completely hackable: the only electronics are three relais. But I don't hack it all by myself. I still, gladly drop it at the local garage to get something fixed. I can stop in nearly any town at the local garage and get stuff replaced, fixed or solved. I've had a waterpump fixed in Germany, my brakes replaced in Sweden, the battery replaced in France and so on.

And that is where the importance of hackability comes into play. Not the fact that /I/, myself can open up a browser or tweak it, but the fact that someone in my proximity can. Instead of having to ship my Macbook-pro to the US to get a fan replaced, my local fixit-guy can open my Thinkpad and replace the fan. Instead of having your computerized and closed-down car towed to the nearest official BMW-garage, I can drop my car at any place where they have a set of screwdrivers and some nuts and bolts and have it fixed.

Re: Burying the URL

#288
post #269

Earlier quoted context omitted.

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.

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 field in chrome is whether it knows about my internet history, and maybe that's just because I have web history turned off. Sometimes I get the "Google Search" behavior and sometimes I get the "I'm feeling lucky" behavior.

In cases where the google search gives the wrong response, chrome gives the same wrong response, for example on intranet servers.

So, if it doesn't display the URL, and it behaves exactly like the search field on google.com, and it doesn't correctly navigate to some URLs entered into the field, I don't think you can really consider it a URL field any more.

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.

Re: Burying the URL

#289

I work at an academic library in IT, among other things supporting users. Supporting them using a variety of local and third-party remote web apps, which integrate in some weird ways. Users reporting problems LOVE to send me screenshots. (Usually pasted into an MS Word document, yep). That's about the only reliable info I can get from users trying to report something they believe is a bug. At least when the screensho…

You need a "REPORT PROBLEM" extension that pre-fills a form with things like URL etc, and asks the user to supply some information.

Re: Burying the URL

#290
post #289

I work at an academic library in IT, among other things supporting users. Supporting them using a variety of local and third-party remote web apps, which integrate in some weird ways. Users reporting problems LOVE to send me screenshots. (Usually pasted into an MS Word document, yep). That's about the only reliable info I can get from users trying to report something they believe is a bug. At least when the screensho…

You need a "REPORT PROBLEM" extension that pre-fills a form with things like URL etc, and asks the user to supply some information.

Not a bad idea, but I'm not sure we have the capacity to develop and maintain such an extension for every browser (every possible browser anyway, not possible in some), and I'm not sure we could get users to install it.
Post reply on HN