While I do appreciate clean URLs, the reason behind all those random obfuscated query parameters in Google's url is not a mystery. They are hidden indicators that are only available at query time and/or experimentation flags and things like that to improve the results. URLs only need to be readable for the portion that the user inputted or is consciously aware of, the rest is for computers.
That was what I was trying to ask: can you do both, or would that be absurdly impractical/impossible? Alternatively, can't they do only a POST and somehow generate URLs dynamically based on the search query?
You can strip out empty fields with a bit of PHP (creating a new URL without the empty strings), which seems to work okay, but it's probably best not to risk the wrong effect, which is the end program seeing the empty fields wrongly (as NULL and not "").
Google search result URLs used to be simpler, but they made a decision not to care how they look years ago and they keep stuffing more and more data into them. I assume it helps their tracking and maybe optimization.
Logging out on outlook.com is even worse. You get redirected to msn.com with its sleazy celebrity "news" and other dubious items. It's like you're in a renovated theater thinking this new interior design is pretty good and then after the show is over the exit leads to a back alley full of trash.
URLs used for asynchronous requests seem much less important. The original comment's point was about outlook.com redirecting the actual url of the page (the one in the address bar) to a data center specific version.
They're actually letting you know what data center you're accessing as well. BLU / BL1/2 are "Blue Ridge", in Virginia (a few different towns). SN = San Antonio, TUK/TK = Tukwila WA, AMS = Amsterdam, DB2/3 = Dublin, etc. Sometimes there are multiple DCs in the same city, sometimes the number just means a different cage in the same DC, and between products you'll see different naming conventions even for the data centers.
It's fun what you can find out given those hostnames. It shows how a unified offering like Office 365 is actually just a few totally separate products, usually hosted in different data centers, that all happen to plug into the same user provisioning system.
I am. I know it's not such a big deal but I would have liked to just have a list of my users and their configuration, I imagine it wouldn't be that hard to get and we would have been much happier doing the migration.
This is a good and oft-neglected part of UI and API design to keep in mind. I especially like the discussion of the implications of hierarchical, semantic URL's in improving user trust and likelihood of clicking.
Much like with database design, it's easy for programmers to take over the task of URL design and make it easy to use from the write-first, read-never programmer perspective. User considerations come later if at all. I like the reminder to pay attention to these factors. We should all be reminded to question our first impulses; are we making something good for us or good for the user?
While I agree that URLs should be considered intrinsic to good UI, social media is also undermining the value/importance of semantic URLs.
Why put extra work into making your RESTful URL structure more semantic, in other words, if Twitter if just going to shorten them to the point that they are no longer fully readable, or Facebook is just going to hide them behind a preview view?
These are all good ideas, but there's part of me that wonders that because they are all being broken by Microsoft, Google, Amazone (as demonstrated in the article and in the comments here) that the importance of them is overstated.
URLs are fundamentally for web browsers to translate into a domain name lookup, and a HTTP request. They are for computers - the fact that we've managed to convince humans that they should care about them, that they should be decipherable by humans, is, IMHO a failing of the web as is.
On a side note, I note that films are starting to use Facebook URLs by doing [FB Logo]/trancethemovie which the user is intended to translate into https://www.facebook.com/trancethemovie
I thought that literally the entire point of URL's was that humans can't remember and use IP's naturally so we created URL's and DNS to let humans interface with the machine IP language.
If URL's are actually intended for computers, than I'd say we've failed rather badly.
The whole point was to interface with people.
If people don't matter and it's for machines, why use URLs? Just type IP's. Skip DNS all together...
Google is the new DNS. Only a small subset of people care about URLs beyond the domain name (this subset has a large overlap with HN readers). Unless you've nothing else to improve, there are usually more effective ways to improve your websites that you can spend that time on.
> I thought that literally the entire point of URL's was that humans can't remember and use IP's naturally so we created URL's and DNS to let humans interface with the machine IP language.
well, now adays there aren't enough IPv4 addresses for all the websites out there. vhosts have become very popular for hosting. I'd imagine if we didn't have DNS, IPv6 would have been pushed through much much faster.
This is an often-heard argument: "Amazon (or other large company) are doing it and it works just fine for them."
But you are not Amazon. Your listings may be competing against Amazon's listings, without the brand recognition, trust and backlinks they have built up.
So you have to do everything better, like building friendly urls, just to have a chance of getting clicks that Amazon can take for granted.
(Amazon does a pretty good job at urls, as others have pointed out, but most larger, established companies are still pretty poor at this, leaving the door open for upstarts to do it better).
Exactly, and people also forget that Amazon, eBay, et al had horrible urls when they first launched, because just having the platforms at all was a big step forward. Old eBay urls have cgi-bin in them.
URLs having any meaning at all strikes me as bias. If my parents visited a SSL site (say, a bank) and the address bar simply displayed the company name and nothing more, they would not miss URLs at all.
This is also why your parents and grandparents can just type random text into an address bar to execute a search instead of having to go to google.com or type in something cryptic like google.com?q=thing%20i%20want.
That's confusing two different concepts. URLs are the equivalent of a full postal address whereas searching is the equivalent of asking a stranger how to get somewhere. Why would you want to always ask and trust a search engine when you already know how to get somewhere? DNS spoofing aside, I know I can trust anything under, for example, bbc.co.uk and I know where /radio, /news etc takes me. Guess what, so do my seventy year old parents!
Some people I know will search for "google" using the browser's search box to get to google, then type in "yahoo" into google to find yahoo's website, then click the "mail" icon to get at their email /o\",
That's a sample size of one person's experience. I on the other hand am constantly meeting people who's only mode of navigation on the web involves typing the word "facebook", or "gmail", or, yes, even "google" into the address bar, and then clicking on the relevant google search result. It drives me crazy, and despite my constant wailings using the same exact argument you make above ("Why would you want to always ask and trust a search engine when you already know how to get somewhere?") ... they simply shrug their shoulders and keep on keepin' on.
Yes, I can't argue with that, though I am meeting an increasing number of non-techies who are interested in different (better) ways of using the web and IT in general.
this is fantastic for SEO: Main-Category/Sub-Category/Specific-Item - is practically screaming look at my site heirarchy and look how much data I have about furniture -> chairs -> chair manufacture -> chair model
In essence, Andrew Auernheimer – or Weev, as much of the Internet knows him – was found guilty of incrementing a number on a url – doing basic arithmetic – and has been ceremoniously chucked behind bars for the next 41 months of his life – as a result of speaking up to point out a security problem.
>Edward Cutrell and Zhiwei Guan from Microsoft Research have conducted an eyetracking study of search engine use (warning: PDF) that found that people spend 24% of their gaze time looking at the URLs in the search results.
>We found that searchers are particularly interested in the URL when they are assessing the credibility of a destination. If the URL looks like garbage, people are less likely to click on that search hit. On the other hand, if the URL looks like the page will address the user’s question, they are more likely to click.
I wished someone at MS would follow up on that and fix the whole bay0X.cdn url jumping everytime I connect to outlook/hotmail.com
though, to be fair ... their inbox isn't necessarily something that they have to gaze through search results to find. So that doesn't really apply there.
I'd like to see a mechanism to pass data to a page in the URL once, but have it discarded such that the URL the user sees and the URL used upon refresh lacks it. This would be nice for all sorts of things:
* That pesky analytics stuff (rel= on YouTube for instance) which you don't want to re-send on refresh or when someone passes on the URL to someone else (because now your data is inaccurate)
* Error messages specified by URL parameters (we only want to show them once)
* URL parameters containing secrets allowing someone to access a page (we don't want to accidentally pass them on)
His examples aren't helping his case. If the most successful store and the most popular search engine don't use pretty URLs why should anyone else care?
Just to review: examples of sites doing it wrong include Google and Amazon, two of the most successful websites ever. Doesn't seem to have hindered their growth much.
I like a clean semantic URL, but if I'm being honest with myself, I know that is just my opinion. I don't know of any real-life correlation between URLs and business outcomes.
Maybe there is, maybe there isn't but this argument is a fallacy. To say that "they are successful, who are we to suggest improvements" is an appeal to authority. Just because there is success, does not mean there is not room for improvement.
> To say that "they are successful, who are we to suggest improvements" is an appeal to authority.
The argument is being made that clean URLs are important to success of websites. That the most successful sites on the internet are sites that don't use clean URLs is counterevidence to the claim made. That's not an appeal to authority
There are countless examples of web sites hat have found success through better urls leading to better rankings. I can say with absolute confidence that better urls can lead to better business outcomes.
This URL will take you to the correct page, every time, and it doesn't take a genius to figure this out. It also doesn't take a genius to figure out what this page is about before you even paste the link into your browser. By putting the human-relevant portion of the URL as far forward as possible it's able to accomplish both priorities: giving the machine as much information as possible, and giving the human as much information as possible.
The trick here is that "Bioshock-Infinite-Premium-Edition-Xbox-360" is entirely superfluous. It is entirely there for SEO and human readability purposes. This URL works just fine and leads to the same place:
Amazon isn't blind to these issues. So sure, you can take this very last URL and try to make a point about obfuscated URLs, but that's not what's actually in use at Amazon. It seems odd to pick them as an example when they're not even a violator.
[edit] It looks like HN truncates long URLs for display, which only goes further to prove the point.
The Amazon case is an interesting one because, despite the appeal of the OP's argument, one can hardly deny the success of Amazon's product listings in spite of their ugly URLs.
However, this raises up an important consequence of clean URL design: when you're offering things that may be classified in several categories, it requires good design on the backed/framework to make sure your URL taxonomy isn't overly constricting. For example, example.com/toys/Nintendo-wii or example.com/consoles/Nintendo-wii?
Either one is legit but creating and keeping consistent taxonomy is difficult enough on its own without worrying simultaneously what the URL looks like
> "example.com/toys/Nintendo-wii or example.com/consoles/Nintendo-wii?"
Why not both? The URL is just a URL - it does not need to reflect your underlying data model. There would probably be a canonical URL for use when the category context isn't available (say, "consoles"), but why not have multiple URLs lead to the same information?
> "despite the appeal of the OP's argument, one can hardly deny the success of Amazon's product listings in spite of their ugly URLs"
But they're really not ugly. In fact, given the complexity of the system they represent, they are remarkably human-friendly.
In an ideal world all ideas, all businesses, and all use cases can be fulfilled by simple URLs like "example.com/shockingly-unique-identifier", but we don't live in that world. Amazon has constructed human and machine-relevant URLs. The author's argument can be applied to many sites, but I don't think Amazon is one of them.
> it does not need to reflect your underlying data model.
Absolutely! In the REST parlance, resources (which are what URIs point at) do not map 1-1 with entities (which is your internal representation of business objects). If they do, you're quite possibly exposing too many internal details and making your application brittle.
> More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent.
You can't have multiple URL leading to the same information because of SEO.
Well, you can (with canonical meta and stuff), but it's not an ideal practice.
It is often better to cater to robots rather than to humans. A sad truth, highlighting Google's failures.
I don't disagree at all, I'm just pointing out it requires an extra layer of logistics and maintenance that may outweigh the benefits of the beautiful URL. And in the rise of URL shorteners and the proliferation of UrL sharin/discovery via social media, I'd argue that the beauty-effect of URLs is even further diminished.
Just a couple months ago, I pushed out a major update to classiccars.com (it's still pretty messy) that cleaned up/reduced the url structure.. the old system had like 50 routing rules to support a wide variety of "friendly" urls for searches, and listing display... I reduced that to /listings/find/YEAR(s)/MAKE/MODEL?opts where all search params other than year/make/model were not part of the route, but querystring params... it didn't make sense to support all those routes (not to mention the old results paged via postback). (hint, you can set the page size up to 100 via a ps=100 querystring param, there's a few others not in the UI yet)... the UI is very similar to how it already was.
The new routes make more sense, and are imho more friendly. The same for listings/view/###/STUB though I put the number/id before the stub, it looks a lot better than it did. Also, I put permanent redirects for any old references to the canonical url. It took a bit of work, now some more updates are going in to make the title/description/h1's more friendly. It's more maintainable now, and some very old URLs are still supported.
Currently working on some other modernization bits, which means a lot of the cruft can finally get cleaned out (if a section at a time, slowly).. having a friendly/consistent url stucture is important imho.
This is why I fundamentally disagree with the 'friendly' URLs approach. URLs are meant to be unique and permanent resources. Injecting your information architecture or page title etc into this is a horribly leaky abstraction - and those things are meant to be able to change. Mixing them up either adds brittleness to them or means that your URLs are going to require constant grooming to keep in sync.
Although slightly unrelated, I'd just like to add something else to commend Amazon when it comes to link handling. I'm extremely impressed at Amazon's ability to handle very old links to products. Here's a link to Hitchhiker's Guide to the Galaxy that I used on a webpage I built 13 years ago and it still works:
http://www.amazon.com/exec/obidos/ASIN/0517149257/o/qid=9295...
they own so much bandwidth it's probably cheaper for them to just send uncompressed html than to waste time + power recompressing it when things change. Being so large, they're an exception to the general rule.
The more pages you send to a user the costly a single byte on a page is. Conversly the more costly a single byte is the more money you can save by compressing or removing said byte. Owning lots of bandwidth is often highly correlated with sending lots of pages. I think you may find that it's more cost efficient for them to "waste" time and power recompressing than you think.
Scale challenges a lot of your preconceptions when you actually get there.
Ok, it's not tamper-proof, but if I'm pretty sure that my friend that mailed me a amazon.com link is not attempting a cheap phishing attack, I can recognize the product directly from the email body. I would call this human friendly, IMHO.
While I understand the need and implement this on every site I'll be the first to say I really don't care about this and I think it's stupid. Just my opinion.
Well obviously URLs are for people because raw IP addresses are unsuitable, but that doesn't mean that textual URLs as they exist today are our best option. Even well-designed URLs are too complicated. "https://news.ycombinator.com/item?id=5498198 is mostly devoid of meaning even to me. I can tell that that URL is referencing a discussion on Hacker News, but "Hacker News" or the title of the article are not present in the URL.
Hierarchical URLs betray the underlying model of the internet as a series of interrelated documents. People don't care about understanding the layout of files on a web server; they just want to open Facebook, or their email, or perform a search. Nobody types "http://www.facebook.com into their browser. They either click a bookmark or type "facebook" into the search or URL bar. What happens next is up to the browser.
The best solution would conform to the already existing mental model that people have. They don't think of a website as a bunch of documents on a web server (despite the shared vocabulary with printed media - words like "page" and "bookmark"). Their mental model is probably something like buildings on a city block. You can pick one to go into, and when you're inside you can do things and learn things that are unique to that building. Rooms are connected by hallways and doors. There are windows where you can see outside or into other buildings. You can bring things with you into the building and take things out when you leave. To get back to a room in a building that you've been in previously, you can either go back to the front door and follow the path you took originally to get to the room, or you can "bookmark the page", which is like a shortcut directly that room.
Most tools and frameworks are designed from the ground up to be document-focused. Some even going as far as to purposely simulate a document when none exists (e.g. Tomcat).
Let's take PHP, ASP.net, and Java. They make up the majority of the internet right now. With RoR and MS MVC being outliers.
It is VERY hard to develop applications in them without a document focus because they use documents to direct functionality (e.g. logout.php and login.php might have different underlying functionality).
Now, yes, web-servers do support request redirection, so you can redirect from /logout to /logout.php, but such "magic" is time consuming because there is a disconnect between the underlying framework which "understands" pages and the dumb web-server which just does what it is told to do.
Even if you just automate it so you strip out the extension (e.g. strip ".php") you still wind up /thinking/ about things from a document perspective rather than a functionality perspective (e.g. "this functionality is on THIS page, this functionality is on THAT page").
We just need more modern frameworks where from the ground up the thing is based on a hierarchy rather than documents/files/etc. This should all be dictated by the framework, not the server's filesystem.
Isn't this what routing does? The problem you're describing seems to be primarily a PHP one, particularly with the lack of a dominant framework in the PHP community. (Possibly also a .Net one, I've avoided working with ASP like the plague in my career).
I don't think that's the case for PHP, at least not in the last 5-6 years or so... All the main frameworks (Symfony, Zend, etc) will force you to use the routing. It's not even possible without some work to call php files. Yes, I'm aware PHP allows you to create simple .php files, but that's not how the development is done these days.
Admittedly, I've shied away from PHP projects over the past 4-5 years in favor of Python (Django) or server-side JS.
I do still think the biggest hurdle PHP faces, at least when new devs come to it, is the lack of any one clear "best" framework. As you even mentioned, there are "main frameworks", but none of them is the clear "best" choice when you are approaching the language. In fact many people start building with PHP without a framework. Almost no one would start using Ruby to build a web app without choosing Rails. Similarly, no one would choose straight Python over using Django (waiting to get flamed by the Flask community here ;) ). With PHP, a lot of people choose it to build a "simple" web app, and end up just hacking together a few .php files. That was even more true 5+ years ago, and now there are a lot of legacy applications out there, that have grown quite large, still built on that principle.
Let's take PHP, ASP.net, and Java. They make up the majority of the internet right now. With RoR and MS MVC being outliers
This sounds very much like you're calling RoR and MS MVC outliers with regard to the fraction of the internet they occupy. You're expecting me to know that your use of "outliers" was with respect to a quality not even mentioned in that particular paragraph, rather than with respect to the sentence right before it? Not to mention the fact that With RoR and MS MVC being outliers. is a sentence fragment, so the most obvious correction to your grammar would be to put it together with the preceding sentence.
So, yes, you don't write very clearly, so I misunderstood you.
I thought it was clear enough. P2: Most tools are document-focused. P3: Some examples of these tools are XYZ. A & B are outliers. P4+: It is very hard to develop applications in "them" (the 'most tools' which are the topic of the comment) without a document focus, and here's some detail about that.
It's not winning any writing awards, but it's not at all unintelligible. The organization of a piece of writing doesn't stop at the paragraph level, so to assume that the paragraphs are unrelated is pretty odd.
These sound like complaints that would have been valid 10 years ago, but not any more. Virtually every framework has the concept of "routes" that map URLs to appropriate logic, they're not document based (whatever that means)
Server's filesystem? Are you serious? Welcome to 2013, all the problems you mention are long gone, and are only brought back from time to time by people like you who stopped learning a decade ago. You should check out symfony.com... Or any other framework for that matter! For Christ's sake.
This idea seems like a pretty normal way of seeing the world among PHP developers.
Please allow me to vent/rant -- I'm finishing up a project where your comment resonates loudly with my frustrations.
I'm a journeyman freelance programmer trying to move from doing WPress marketing sites more interesting programming/development problems, and I just got out of a 2 month Magento project (Magento is an MVC-patterned store software that is based on the Zend PHP framework): extending it to allow users to sign in and create their own product listings.
This was my first time building MVC/OOP modules in the context of a framework, and it took a little bit to connect the OOP principles that I've studied to the actual implementation within the larger framework... but the last month has been like "WOW... I can finally see in a pragmatic way why OOP and MVC are both such a powerful tools!"
Not to mention that, since we were working with extending the system, studying that stuff seemed like an essential learning process if we were going to create the system, even if I was only tasked with the "front-end" side of templates and visualizing the things from the database.
However, the senior guy in charge of creating the functionality to manage products for users thought I was from mars-- his application, which was wholly separate from the Magento install and used a separate database, was patterned around directories, with a set of configuration and include files shoved into the head.
He intend me to integrate his functions by shoving his (single, large) functions file into the head of (each of) my template files, and then calling functions to return arrays of information that I could then push into markup.
Apparently, this is "the right and normal" way to do this stuff in the PHP world, and my process of writing modules, extending existing objects, creating routes to view the data through the framework's template system was all stupidly overcomplex.
I learned a lot out of doing that, and the module that I'm building for another client (aMember/Zend) is both smooth and fun because all of the database interactions and template stuff is already in place and just works... and I can focus on the UI Javacript stuff...
but I feel really badly for the project owner of the Magento project, as I feel the codebase is... well mostly a bunch of functions in a single file and a bunch of single-form .php files that make SOAP calls and depreciated mysqli_ calls...
Now, I dunno-- I'm definitely the less experienced programmer, but if this is the norm in PHP programming (surely it can't be), I will be spending my summer trying to build enough projects in other languages that I can transition out of doing PHP.
Sorry for the rant, but it was cathartic for me :D
I feel you, but it's just a matter of finding the right circles. I would never apply for a job just because it says 'php', you have to dig deeper. At this point in my career, I would never accept a freelance gig like the one you described, because I know how that goes.
You don't need to try other languages, do it only if you want to. If you wanna save time just take my word, Symfony2 has nothing to envy to Django or Rails (I have used them and also digged into their architecture). In fact, it's more modern and better designed.
I'll leave these links here, you might find them useful:
- http://silex.sensiolabs.org/ (minimalistic version of Symfony2, it's called Silex, and might be useful for small websites)
If you still want to try something else, try something that has nothing to do with all this, like Clojure. For example, Ruby/Rails is the same as PHP/Symfony2, you won't learn much. I jumped into Rails and just started coding, because I already knew web development, I wasn't impressed, the differences were mostly syntactic sugar, monolithic vs decoupled, and issues like the lack of interfaces and type hinting. But Clojure? Mind blown. I'm gonna spend my next summer learning more Clojure, because I already know it's my perfect language, but it's hard and full of new concepts. Meanwhile, php/Symfony2/nginx is my perfect stack for web development.
Thanks for the detailed reply and list of sources... while I hadn't really seen PHP-FIG, several of those links show up as read in my browser. Lots of good concepts, and I will definitely take a read through them over the next week.
I agree that the answer is being more selective about who I work with-- logically, I can probably write terrible code in about any language. For this last contract, it was more a case of having a one of my main clients that I do other projects with hiring a firm.
I didn't apply for it so much as "oh, the project is Magento? I'd really like to work with that", and the getting on as part of the program because I was pretty familiar with the overall project goals and I'm good with javascript/css/html and was hoping to gain a little experience in how Magento templates operate... but I did learn a lot, and I have lot better idea about what kinds of approaches that I am willing to work with.
Symphony2 looks like an entirely reasonable choice for a framework. I spent some time this year working on adding functionality to a cakePHP project, but that felt a little lightweight compared to other things I've been working with... though that is just a general feeling.
I had been trying to get Zend2 and Doctrine working, but I had to run it in a VM-- it wasn't playing well with my normal OSX environment... I eventually had it running and was building a really basic project with it when I got busy last fall.
So, anyhow-- symphony2 is now on my list of "build a really basic project in this framework": thanks :D.
"Java" - what specifically are you referring to? Spring MVC, as one example, has advanced routing capability and is in no way "forced document centric."
I disagree with the "https://news.ycombinator.com/item?id=5489039 versus https://news.ycombinator.com/5489039/if-the-earth-were-100-p... - its in contradiction to the author's earlier point that URLs should be "hackable". With the former style, I know that if I want to see other hackernews articles, I can just change the number (granted, it's not the most efficient way of browsing HN) - with the latter, I can't modify the URL w/out knowing the title of the article I'm looking for.
At some point, searching for terms like "best hdtv 2013" would return a page full of sites with perfect urls like http://www.best-hdtv-2013.com/, and all of them would be extremely spammy and lacking in actual content. Seems less prevalent these days.
And the other thing is that we aren't really clicking on URLs, because it's just a string you cannot click on it. We are clicking on anchor texts and using ugly URLs as anchor text can be the problem. If the anchor text is a descriptive title then most (non-techie) users doesn't even see the URL before they click because they don't know it's displayed at the bottom of the browser if you move the mouse over them.
The OP lost me at the Google example. The search URL is one URL that is completely unnecessary to be clean. Google wants you to get used to using the omnisearch box because it can provide such niceties as auto-suggest, instant results, etc...plus, the google query interface is no longer just a text bar, but voice activated...it works against Google's UI/UX intent for you to get used to hacking things in the URL address.
And yes, for hacker types this intention of Google's seems overbearing...but for the other 99.9% of the population, google is likely more interested in making search uniformly accessible than making clean URLs
I agree that Google is aiming at most people, and not the HN crowd, and that they're doing a good job.
But I remember the days when you could craft a Google search url by hand and tweak the results. It was part of an advanced user's toolkit. All of that has been taken away. Searching is now opaque.
At the risk of inadvertently dragging us into a discussion about the "bubble" that Google and other social services lock us into...Here are two points that I think are worthwhile:
1. Search has always been opaque. We've never known the complete details of PageRank, and we know even less about the hundreds of other flags and signals used by Google search to parse a query as vague as the famous "mike siwek lawyer mi" into something useful.
2. It is largely a good thing that we don't need to hack the search parameters anymore...because, in one sense, it means that search has gotten amazingly accurate. It's so good that I hardly ever go to the second page of results...instead, if I don't find what I want in the first 10, I just slightly alter my text query and Google will eventually get what I need (or at least what I think I need, but that's a philosophical question). I think that is a better UX experience for even hackers, as you can refine using natural language rather than tinkering with vague params.
This is the point right here. Google intends these URLs for machine consumption, that you can simulate the work of the computer by hand doesn't change the facts. It also doesn't prevent them from creating another alternative URL scheme which is meant to be entered by humans explicitly.
What this boils down to is that there is space on the Web for both human consumable, and machine consumable URLs.
If a URL becomes a popular for human usage, it is a safe bet to keep it as it is, that doesn't mean you cannot have all sorts of gobbledygook URLs which also get you to that same resource.
There is no need to have this be an either-or proposition.
154 comments
[ 2.9 ms ] story [ 204 ms ] threadEDIT: Ok the follow up comment doesn't indicate that... but it would be just as valid to do it that way if they are indeed search modifiers.
For Google though I'm not sure you'd want POST requests at all; unless it's to set cookies and do a redirect on POST.
If they are the defaults, why put them in the URL?
You've probably answered your own question there.
Eg: http://www.bing.com/search?q=test&qs=n&form=QBLH&...
Here, sk is "".
You can strip out empty fields with a bit of PHP (creating a new URL without the empty strings), which seems to work okay, but it's probably best not to risk the wrong effect, which is the end program seeing the empty fields wrongly (as NULL and not "").
Even more offensive are the result URLs on the result page. Here's the URL for a logged out search for "hacker news". https://www.google.com/url?sa=t&rct=j&q=&esrc=s&...
https://www.google.com/url?
sa=t&
rct=j&
q=&
esrc=s&
source=web&
cd=1&
cad=rja&
ved=0CDMQFjAA&
url=https%3A%2F%2Fnews.ycombinator.com%2F&
ei=k99eUcfzOsePiAKjgIG4DA&
usg=AFQjCNGxnV8qCnv_rujodDj6o2ZhqU8Nxg&
bvm=bv.44770516,d.cGE
Note that none of this is necessary for clickthrough tracking; it's easy to do that separately from the href.
It's fun what you can find out given those hostnames. It shows how a unified offering like Office 365 is actually just a few totally separate products, usually hosted in different data centers, that all happen to plug into the same user provisioning system.
We've recently had to configure ~200 users and Microsoft had us login to each user's account to find out on what server they were on.
Much like with database design, it's easy for programmers to take over the task of URL design and make it easy to use from the write-first, read-never programmer perspective. User considerations come later if at all. I like the reminder to pay attention to these factors. We should all be reminded to question our first impulses; are we making something good for us or good for the user?
Why put extra work into making your RESTful URL structure more semantic, in other words, if Twitter if just going to shorten them to the point that they are no longer fully readable, or Facebook is just going to hide them behind a preview view?
URLs are fundamentally for web browsers to translate into a domain name lookup, and a HTTP request. They are for computers - the fact that we've managed to convince humans that they should care about them, that they should be decipherable by humans, is, IMHO a failing of the web as is.
On a side note, I note that films are starting to use Facebook URLs by doing [FB Logo]/trancethemovie which the user is intended to translate into https://www.facebook.com/trancethemovie
If URL's are actually intended for computers, than I'd say we've failed rather badly.
The whole point was to interface with people.
If people don't matter and it's for machines, why use URLs? Just type IP's. Skip DNS all together...
That'd be the base URI, but not the full one. If you used IPs, it would still be http://123.456.789.123/search&q=foo
How exactly would you get at a particular resource at that IP? That's what we're all talking about.
But you are not Amazon. Your listings may be competing against Amazon's listings, without the brand recognition, trust and backlinks they have built up.
So you have to do everything better, like building friendly urls, just to have a chance of getting clicks that Amazon can take for granted.
(Amazon does a pretty good job at urls, as others have pointed out, but most larger, established companies are still pretty poor at this, leaving the door open for upstarts to do it better).
This is also why your parents and grandparents can just type random text into an address bar to execute a search instead of having to go to google.com or type in something cryptic like google.com?q=thing%20i%20want.
"Cool URIs don't change"
http://www.w3.org/Provider/Style/URI.html
this is fantastic for SEO: Main-Category/Sub-Category/Specific-Item - is practically screaming look at my site heirarchy and look how much data I have about furniture -> chairs -> chair manufacture -> chair model
https://asherwolf.net/the-tragedy-of-jailing-weev-the-intern...
(waits for further downvotes)
>We found that searchers are particularly interested in the URL when they are assessing the credibility of a destination. If the URL looks like garbage, people are less likely to click on that search hit. On the other hand, if the URL looks like the page will address the user’s question, they are more likely to click.
I wished someone at MS would follow up on that and fix the whole bay0X.cdn url jumping everytime I connect to outlook/hotmail.com
* That pesky analytics stuff (rel= on YouTube for instance) which you don't want to re-send on refresh or when someone passes on the URL to someone else (because now your data is inaccurate)
* Error messages specified by URL parameters (we only want to show them once)
* URL parameters containing secrets allowing someone to access a page (we don't want to accidentally pass them on)
etc.
Case in point: it took a while to those same companies to switch from table layout to CSS based layout [1][2].
[1] http://webmasters.stackexchange.com/questions/20408/if-css-i... [2] https://forums.digitalpoint.com/threads/why-does-google-use-...
I like a clean semantic URL, but if I'm being honest with myself, I know that is just my opinion. I don't know of any real-life correlation between URLs and business outcomes.
The argument is being made that clean URLs are important to success of websites. That the most successful sites on the internet are sites that don't use clean URLs is counterevidence to the claim made. That's not an appeal to authority
Here is an Amazon URL:
http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...
Is it completely clean? Nope. It contains a lot of information that feed into the backend, but the core URL is this:
http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...
This URL will take you to the correct page, every time, and it doesn't take a genius to figure this out. It also doesn't take a genius to figure out what this page is about before you even paste the link into your browser. By putting the human-relevant portion of the URL as far forward as possible it's able to accomplish both priorities: giving the machine as much information as possible, and giving the human as much information as possible.
The trick here is that "Bioshock-Infinite-Premium-Edition-Xbox-360" is entirely superfluous. It is entirely there for SEO and human readability purposes. This URL works just fine and leads to the same place:
http://www.amazon.com/dp/B009PJ9L3Y/
Amazon isn't blind to these issues. So sure, you can take this very last URL and try to make a point about obfuscated URLs, but that's not what's actually in use at Amazon. It seems odd to pick them as an example when they're not even a violator.
[edit] It looks like HN truncates long URLs for display, which only goes further to prove the point.
However, this raises up an important consequence of clean URL design: when you're offering things that may be classified in several categories, it requires good design on the backed/framework to make sure your URL taxonomy isn't overly constricting. For example, example.com/toys/Nintendo-wii or example.com/consoles/Nintendo-wii?
Either one is legit but creating and keeping consistent taxonomy is difficult enough on its own without worrying simultaneously what the URL looks like
Why not both? The URL is just a URL - it does not need to reflect your underlying data model. There would probably be a canonical URL for use when the category context isn't available (say, "consoles"), but why not have multiple URLs lead to the same information?
> "despite the appeal of the OP's argument, one can hardly deny the success of Amazon's product listings in spite of their ugly URLs"
But they're really not ugly. In fact, given the complexity of the system they represent, they are remarkably human-friendly.
In an ideal world all ideas, all businesses, and all use cases can be fulfilled by simple URLs like "example.com/shockingly-unique-identifier", but we don't live in that world. Amazon has constructed human and machine-relevant URLs. The author's argument can be applied to many sites, but I don't think Amazon is one of them.
Absolutely! In the REST parlance, resources (which are what URIs point at) do not map 1-1 with entities (which is your internal representation of business objects). If they do, you're quite possibly exposing too many internal details and making your application brittle.
> More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...
This is actually one of the more readable parts of Fielding's dissertation, read the whole section. The examples are great.
The new routes make more sense, and are imho more friendly. The same for listings/view/###/STUB though I put the number/id before the stub, it looks a lot better than it did. Also, I put permanent redirects for any old references to the canonical url. It took a bit of work, now some more updates are going in to make the title/description/h1's more friendly. It's more maintainable now, and some very old URLs are still supported.
Currently working on some other modernization bits, which means a lot of the cruft can finally get cleaned out (if a section at a time, slowly).. having a friendly/consistent url stucture is important imho.
Note: it is a particularly ugly link
But OMG is amazons html fracking messy or what huge amounts of white space which increases the page size.
Scale challenges a lot of your preconceptions when you actually get there.
I wonder if this really matters with gzip. Or at least whether traffic overhead beats one from implementing and using HTML compression.
I bet they have it measured.
Sure, the URL
http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...
leads to the Bioshock article, but so does
http://www.amazon.com/flux-compensator/dp/B009PJ9L3Y/
or
http://www.amazon.com/hackers-and-painters/dp/B009PJ9L3Y/
In my opinion the only reason for the slug is SEO, everything else is a side effect which I personally find borderline dangerous.
BTW stackoverflow.com URLs work the same way.
Hierarchical URLs betray the underlying model of the internet as a series of interrelated documents. People don't care about understanding the layout of files on a web server; they just want to open Facebook, or their email, or perform a search. Nobody types "http://www.facebook.com into their browser. They either click a bookmark or type "facebook" into the search or URL bar. What happens next is up to the browser.
The best solution would conform to the already existing mental model that people have. They don't think of a website as a bunch of documents on a web server (despite the shared vocabulary with printed media - words like "page" and "bookmark"). Their mental model is probably something like buildings on a city block. You can pick one to go into, and when you're inside you can do things and learn things that are unique to that building. Rooms are connected by hallways and doors. There are windows where you can see outside or into other buildings. You can bring things with you into the building and take things out when you leave. To get back to a room in a building that you've been in previously, you can either go back to the front door and follow the path you took originally to get to the room, or you can "bookmark the page", which is like a shortcut directly that room.
Why then do most Microsoft sites not follow this finding? Also, a lot of their products break it as well (I'm looking at you SharePoint and CRM).
Also »Microsoft« isn't one big monolithic entity and it's not uncommon for individual parts of it doing things in quite different ways.
Most tools and frameworks are designed from the ground up to be document-focused. Some even going as far as to purposely simulate a document when none exists (e.g. Tomcat).
Let's take PHP, ASP.net, and Java. They make up the majority of the internet right now. With RoR and MS MVC being outliers.
It is VERY hard to develop applications in them without a document focus because they use documents to direct functionality (e.g. logout.php and login.php might have different underlying functionality).
Now, yes, web-servers do support request redirection, so you can redirect from /logout to /logout.php, but such "magic" is time consuming because there is a disconnect between the underlying framework which "understands" pages and the dumb web-server which just does what it is told to do.
Even if you just automate it so you strip out the extension (e.g. strip ".php") you still wind up /thinking/ about things from a document perspective rather than a functionality perspective (e.g. "this functionality is on THIS page, this functionality is on THAT page").
We just need more modern frameworks where from the ground up the thing is based on a hierarchy rather than documents/files/etc. This should all be dictated by the framework, not the server's filesystem.
I do still think the biggest hurdle PHP faces, at least when new devs come to it, is the lack of any one clear "best" framework. As you even mentioned, there are "main frameworks", but none of them is the clear "best" choice when you are approaching the language. In fact many people start building with PHP without a framework. Almost no one would start using Ruby to build a web app without choosing Rails. Similarly, no one would choose straight Python over using Django (waiting to get flamed by the Flask community here ;) ). With PHP, a lot of people choose it to build a "simple" web app, and end up just hacking together a few .php files. That was even more true 5+ years ago, and now there are a lot of legacy applications out there, that have grown quite large, still built on that principle.
Let's take PHP, ASP.net, and Java. They make up the majority of the internet right now. With RoR and MS MVC being outliers
This sounds very much like you're calling RoR and MS MVC outliers with regard to the fraction of the internet they occupy. You're expecting me to know that your use of "outliers" was with respect to a quality not even mentioned in that particular paragraph, rather than with respect to the sentence right before it? Not to mention the fact that With RoR and MS MVC being outliers. is a sentence fragment, so the most obvious correction to your grammar would be to put it together with the preceding sentence.
So, yes, you don't write very clearly, so I misunderstood you.
It's not winning any writing awards, but it's not at all unintelligible. The organization of a piece of writing doesn't stop at the paragraph level, so to assume that the paragraphs are unrelated is pretty odd.
Please allow me to vent/rant -- I'm finishing up a project where your comment resonates loudly with my frustrations.
I'm a journeyman freelance programmer trying to move from doing WPress marketing sites more interesting programming/development problems, and I just got out of a 2 month Magento project (Magento is an MVC-patterned store software that is based on the Zend PHP framework): extending it to allow users to sign in and create their own product listings.
This was my first time building MVC/OOP modules in the context of a framework, and it took a little bit to connect the OOP principles that I've studied to the actual implementation within the larger framework... but the last month has been like "WOW... I can finally see in a pragmatic way why OOP and MVC are both such a powerful tools!"
Not to mention that, since we were working with extending the system, studying that stuff seemed like an essential learning process if we were going to create the system, even if I was only tasked with the "front-end" side of templates and visualizing the things from the database.
However, the senior guy in charge of creating the functionality to manage products for users thought I was from mars-- his application, which was wholly separate from the Magento install and used a separate database, was patterned around directories, with a set of configuration and include files shoved into the head.
He intend me to integrate his functions by shoving his (single, large) functions file into the head of (each of) my template files, and then calling functions to return arrays of information that I could then push into markup.
Apparently, this is "the right and normal" way to do this stuff in the PHP world, and my process of writing modules, extending existing objects, creating routes to view the data through the framework's template system was all stupidly overcomplex.
I learned a lot out of doing that, and the module that I'm building for another client (aMember/Zend) is both smooth and fun because all of the database interactions and template stuff is already in place and just works... and I can focus on the UI Javacript stuff...
but I feel really badly for the project owner of the Magento project, as I feel the codebase is... well mostly a bunch of functions in a single file and a bunch of single-form .php files that make SOAP calls and depreciated mysqli_ calls...
Now, I dunno-- I'm definitely the less experienced programmer, but if this is the norm in PHP programming (surely it can't be), I will be spending my summer trying to build enough projects in other languages that I can transition out of doing PHP.
Sorry for the rant, but it was cathartic for me :D
You don't need to try other languages, do it only if you want to. If you wanna save time just take my word, Symfony2 has nothing to envy to Django or Rails (I have used them and also digged into their architecture). In fact, it's more modern and better designed.
I'll leave these links here, you might find them useful:
- http://www.phptherightway.com/ (general advice)
- http://getcomposer.org/ (composer, the dependency manager)
- https://packagist.org/ (the main composer repository)
- https://github.com/php-fig/fig-standards/tree/master/accepte... (accepted conventions)
- http://www.slideshare.net/fabpot/dependency-injection-with-p... (if you liked MVC, DI will blow your mind)
- http://fabien.potencier.org/article/50/create-your-own-frame... (an amazing tutorial on how to create a framework, it will let you understand it inside out)
- http://symfony.com/download (what should become your next framework)
- http://silex.sensiolabs.org/ (minimalistic version of Symfony2, it's called Silex, and might be useful for small websites)
If you still want to try something else, try something that has nothing to do with all this, like Clojure. For example, Ruby/Rails is the same as PHP/Symfony2, you won't learn much. I jumped into Rails and just started coding, because I already knew web development, I wasn't impressed, the differences were mostly syntactic sugar, monolithic vs decoupled, and issues like the lack of interfaces and type hinting. But Clojure? Mind blown. I'm gonna spend my next summer learning more Clojure, because I already know it's my perfect language, but it's hard and full of new concepts. Meanwhile, php/Symfony2/nginx is my perfect stack for web development.
I agree that the answer is being more selective about who I work with-- logically, I can probably write terrible code in about any language. For this last contract, it was more a case of having a one of my main clients that I do other projects with hiring a firm.
I didn't apply for it so much as "oh, the project is Magento? I'd really like to work with that", and the getting on as part of the program because I was pretty familiar with the overall project goals and I'm good with javascript/css/html and was hoping to gain a little experience in how Magento templates operate... but I did learn a lot, and I have lot better idea about what kinds of approaches that I am willing to work with.
Symphony2 looks like an entirely reasonable choice for a framework. I spent some time this year working on adding functionality to a cakePHP project, but that felt a little lightweight compared to other things I've been working with... though that is just a general feeling.
I had been trying to get Zend2 and Doctrine working, but I had to run it in a VM-- it wasn't playing well with my normal OSX environment... I eventually had it running and was building a really basic project with it when I got busy last fall.
So, anyhow-- symphony2 is now on my list of "build a really basic project in this framework": thanks :D.
I'm not so sure of this. URLs that are over-optimised seem link-baity to me and I'm more inclined to not click it.
At some point, searching for terms like "best hdtv 2013" would return a page full of sites with perfect urls like http://www.best-hdtv-2013.com/, and all of them would be extremely spammy and lacking in actual content. Seems less prevalent these days.
"http://example.org/furniture/desk-chairs/herman-millers-mirr... makes me think crappy search landing page website that is probably malware infested I don't want to click, ever
However, I believe that is mostly due to the domain. If it was amazon.com I'd click it likewise if it was http://www.example.com/gp/product/B0002K11BK/ref=sr_1_5?ie=U... I would also think I'm going to get spammed :)
And yes, for hacker types this intention of Google's seems overbearing...but for the other 99.9% of the population, google is likely more interested in making search uniformly accessible than making clean URLs
But I remember the days when you could craft a Google search url by hand and tweak the results. It was part of an advanced user's toolkit. All of that has been taken away. Searching is now opaque.
1. Search has always been opaque. We've never known the complete details of PageRank, and we know even less about the hundreds of other flags and signals used by Google search to parse a query as vague as the famous "mike siwek lawyer mi" into something useful.
2. It is largely a good thing that we don't need to hack the search parameters anymore...because, in one sense, it means that search has gotten amazingly accurate. It's so good that I hardly ever go to the second page of results...instead, if I don't find what I want in the first 10, I just slightly alter my text query and Google will eventually get what I need (or at least what I think I need, but that's a philosophical question). I think that is a better UX experience for even hackers, as you can refine using natural language rather than tinkering with vague params.
For example:
https://www.google.com/search?q=pillow&start=100
But you may have tweaks in mind that no longer work, and so forth.
Like somebody else said, I blame the tools, the requirements (but we gotta track the referring url of the referring url!!!), and the programmers.
If a URL becomes a popular for human usage, it is a safe bet to keep it as it is, that doesn't mean you cannot have all sorts of gobbledygook URLs which also get you to that same resource.
There is no need to have this be an either-or proposition.