I was thinking this recently as I tried Reddit's mobile app. I found that navigating subreddits through URL was so natural that I was kind of lost in the app -- and frankly Chrome did a better job of suggesting the content I wanted than the app did.
URLs are UI
91–96 of 96 posts
Re: URLs are UI
#92Earlier quoted context omitted.
No, I can force you to host words and it looks like you said them.
It's a meme generator. Nobody's going to believe that the person who operates the site "said" anything on there. Next are you going to upload an image to imgur that "looks like" the creator of imgur is saying something bad?
Imgur has responsibility for all of the content it hosts.
Re: URLs are UI
#93Earlier quoted context omitted.
It's a meme generator. Nobody's going to believe that the person who operates the site "said" anything on there. Next are you going to upload an image to imgur that "looks like" the creator of imgur is saying something bad?
Imgur has responsibility for all of the content it hosts.
Well, only in that they shouldn't be hosting illegal content (e.g. CP). But beyond that, nothing they host can be construed as being "said" by imgur.
Re: URLs are UI
#94Earlier quoted context omitted.
When did this happen, and what frameworks did the throwing out?
Anecdote: in the last half year, and GraphQL. Proponents are coming out of the woodworks and saying all sorts of crazy stuff about how it is better than REST, and the meetup attendees are eating it up without any hint of skepticism.
Thank you very much. I will investigate.
Re: URLs are UI
#95I 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/
Wow, I love this. My girlfriend and I LOVE sending memes to each other. This will give me major points :-)
Re: URLs are UI
#96This is all solid advice, but there's something that still bothers me about URLs: From one side I hear that hypertext should be the engine of application state. This implies that the URL router should control just about everything, and that you should be able to click a link in an email and jump directly to any state of your application. From the other side I hear that web apps can be just as capable as desktop apps,…
Insisting that a URL change with state is taking it too far. It's not how I understood what Tim Berners-Lee and others were saying at the beginning. I would be interested, however, in articles that espouse this. If the URL represented state, then it should change as you're filling out an HTML form, at each keystroke. But instead there is one URL for the blank form and one after you click Submit. A better rule is one…
> Insisting that a URL change with state is taking it too far. It's not how I understood what Tim Berners-Lee and others were saying at the beginning. I would be interested, however, in articles that espouse this.
I'm referring to HATEOAS, the final and most demanding "stage" of RESTful API design: http://timelessrepo.com/haters-gonna-hateoas
> A better rule is one URL per "document" or "record." So in your Photoshop example, there would be a different URL per file that you edit (www.photoshop.com/image001.psd) but not per edit. Well, if the app saved versions, then you could append ?v=203. But in general I think it's enough to align URLs to "documents" (like a news story) or "records" (like a particular profile in a contact database).
This sounds like a good idea.