Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URLs are UI

hanselman.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: URLs are UI

#51

Post by elcapitan »

Tehnix wrote: post #45
elcapitan wrote: post #27

First thing with new Safari: Change default setting for URL bar to actually show URL. Because UI.

I can’t remember if it was actually shown or just argued for, but the simplification of the URL in the address bar actually helps identify phishing sites, as there is a lot less text to process through, and that one character that might have been changes becomes more visible than before :)

For the "easier to read" part I would prefer Chrome's black vs grey url string.

But for phishing .. with all the tricks possible with Unicode lookalikes, I wonder if people are still doing easily visible character exchanges? qoogle instead of google?

Re: URLs are UI

#53

Post by sametmax »

RossM wrote: post #49
romwell wrote: post #42

Earlier quoted context omitted.

I disagree with 2a. No reason why this shouldn't be a path that the user can edit to go one level "up" to /search/product/couches. That's kind of the point of the article - these are parameters for the programmer , but are UI to the user. Separating parameters by "&", except for the first KVP which is separated by "?" from the URL is not intuitive. On the other hands, they path editing is familiar.

> No reason why this shouldn't be a path that the user can edit to go one level "up" While I find it more visually pleasing, this is my issue with this style: traversing up would first include /search/product/couches/color, which doesn't make sense. I've seen alternatives like /color:red/ before - which takes away the pairing-problem but feels odd..

And imply you only have product and color. What about size, price, date, description, rating, etc. It is a "search" url after all.

Re: URLs are UI

#54

Post by a3n »

romwell wrote: post #39
a3n wrote: post #31

> I love Stack Overflow's URLs. Here's an example: https://stackoverflow.com/users/6380/scott-hanselman > The only thing that matters there is the 6380. Try it https://stackoverflow.com/users/6380 or https://stackoverflow.com/users/6380/fancy-pants also works. SO will even support this! http://stackoverflow.com/u/6380 . This works too: https://stackoverflow.com/users/6380/a3n That doesn't seem right, and on a differe…

Dangerous? How so? This scheme is used on other sites, too.

"Other people do it," by itself, is not a great justification.

It's yet another way to mislead. Just because other misleading schemes exist doesn't mean this isn't also misleading and potentially bad.

As for "How so" ... I didn't think it through. I'll go with "potentially not good," but equally not thought through. Since the subject of the article is URLs as UI, when you send someone a URL to "look at this", what they see is the URL, and in my example the human readable part is "the site" and "a3n", but what they get is nothing to do with a3n.

I can only intuitively start with "that's misleading," and imagine (but not point out) the possibility of "something bad". Maybe something merely annoying like rick-rolling.

Re: URLs are UI

#55

Post by amptorn »

captbaritone wrote: post #11

I made a little project taking this idea to an extreme. The idea was, that you should be able to generate "meme" image macros simply by typing a URL. That way you could create memes on the fly anywhere that you can enter a URL (Slack/Twitter/Facebook/etc.) without having to leave the app. Just type a URL of the form: http://urlme.me/ / / . http://urlme.me/

The only problem here is that now I can make you appear to say anything I want you to say.

http://urlme.me/success/I,%20captbaritone/lick%20goats.jpg

This can get much nastier fast.

Re: URLs are UI

#56

Post by kmfrk »

I hate that people use shorturls on Twitter, especially news sites with paywalls. I check the full URL of articles in my Twitter client before I click them, especially when people share the links without any description.

Since Twitter gives all links the same allotment of characters, it's really frustrating that people insist on sticking to shorturls.

Goes to show how tracking and advertising keeps ruining the Web.

Re: URLs are UI

#57

Post by DanBC »

kmfrk wrote: post #56

I hate that people use shorturls on Twitter, especially news sites with paywalls. I check the full URL of articles in my Twitter client before I click them, especially when people share the links without any description. Since Twitter gives all links the same allotment of characters, it's really frustrating that people insist on sticking to shorturls. Goes to show how tracking and advertising keeps ruining the Web.

> Since Twitter gives all links the same allotment of characters

Does it? The documentation I've read doesn't suggest this, unless you're including Twitter's own wrapping of links with its own shortURL t.co

Re: URLs are UI

#58

Post by niklasrde »

sametmax wrote: post #15
morecoffee wrote: post #7

Which of the following URLS are clearer? 1a. https://foo.com/ 1b. https://www.foo.com/ 2a. https://foo.com/search/products/couches/color/red 2b. https://foo.com/search?products=couches&color=red 3a. /posts?recent 3b. /posts?recent= 3c. /posts?recent=true 4a. /post/1234/products-couches-furniture-red-cheap-recent-ikea-tags 4b. /post/1234/ I can think of good reasons for picking each of these, and even good reasons for…

> 1a. https://foo.com/ > 1b. https://www.foo.com/ www for old folks, non www for all the rest. > 2a. https://foo.com/search/products/couches/color/red > 2b. https://foo.com/search?products=couches&color=red https://foo.com/search?products=couches&color=red Those are parameters, not a path. The first one has only value as an SEO optimization. > 3a. /posts?recent > 3b. /posts?recent= > 3c. /posts?recent=true /posts/rec…

I disagree with 1 as a blanket statement.

There are technical reasons to consider, as well (yes, it's DNS again). If you want to receive emails @foo.com, you have to set MX records for foo.com., and that means you can't set a CNAME anymore - you'll have to make do with A/AAAA records.

For a lot of applications this is not an issue, but it does mean an overhead for highly distributed services. You won't see many global/high traffic companies drop the benefits 'www' gives. This is not purely to get the 'old folks' market.

(PS: The subdomain doesn't have to be www., of course - cnn goes with edition.cnn.com., for example.)

Re: URLs are UI

#59

Post by monsieurbanana »

amptorn wrote: post #55
captbaritone wrote: post #11

I made a little project taking this idea to an extreme. The idea was, that you should be able to generate "meme" image macros simply by typing a URL. That way you could create memes on the fly anywhere that you can enter a URL (Slack/Twitter/Facebook/etc.) without having to leave the app. Just type a URL of the form: http://urlme.me/ / / . http://urlme.me/

The only problem here is that now I can make you appear to say anything I want you to say. http://urlme.me/success/I,%20captbaritone/lick%20goats.jpg This can get much nastier fast.

You mean without that website you wouldn't know how to put some random text on an image?

Re: URLs are UI

#60

Post by tomatsu »

captbaritone wrote: post #11

I made a little project taking this idea to an extreme. The idea was, that you should be able to generate "meme" image macros simply by typing a URL. That way you could create memes on the fly anywhere that you can enter a URL (Slack/Twitter/Facebook/etc.) without having to leave the app. Just type a URL of the form: http://urlme.me/ / / . http://urlme.me/

The 'x' (#cancel-copy) does nothing. You've to focus/blur #link to go back.
Post reply on HN