Google finally has a 404 page that isn't ugly(google.com)
google.com
Google finally has a 404 page that isn't ugly
http://www.google.com/notaurl
26 comments
Just FYI, that wasn't their actual one, but the 404 for their April Fool's joke: http://www.google.com/tisp/
I like Yahoo's better:
http://www.flickr.com/photos/jkenning/464845773/
http://www.flickr.com/photos/jkenning/464845773/
Reddit's is cute too:
http://allthatsnew.files.wordpress.com/2009/04/reddit.png?w=...
http://allthatsnew.files.wordpress.com/2009/04/reddit.png?w=...
that page is reserved for 500 errors.
for a 404 they swap out several images. see http://www.reddit.com/thisisa404
for a 404 they swap out several images. see http://www.reddit.com/thisisa404
Aww, some pages just make you want to hug their creators. I wish more sites had this kind of warm gems.
[deleted]
A part of me is sad about this. The old page functioned just fine and acted as a relic of the old Internet. I thought it was kind of cool how they left it alone, especially since it served it's purpose just fine without costing anything. Not that I'm denying it was ugly as all hell :)
[deleted]
Google has been really been stepping up their design over the past few months. I really like the subtle tweaks they made to the top bar across all google pages:
https://img.skitch.com/20110302-kdhkc99usamdhb6yaptrw2y81d.j...
https://img.skitch.com/20110302-kdhkc99usamdhb6yaptrw2y81d.j...
This hasn't rolled out for everybody yet - I see it at work, but I don't see it (when signed into the same account) at home.
It is on google.com but most of the other country domains (.ie, .co.uk, etc...) havent got it yet. Currently its the same with google instant.
I'm on .ie and I have it:
http://i52.tinypic.com/2cf8kdh.jpg
I only noticed a friend with it on his account last week. The next time I singed into my account it came up, and it's been there ever since.
http://i52.tinypic.com/2cf8kdh.jpg
I only noticed a friend with it on his account last week. The next time I singed into my account it came up, and it's been there ever since.
thats not it
.ie has google instant, but not the new statusbar. I've got it from Ireland on google.com though.
To get the new look, I just deleted cookies from google.com.
It's made usability worse though, in one important respect: logging out requires two clicks, not one. :(
That's true only under the assumption that the UI should be optimized for the Signing Out process. It shouldn't, the design has improved usability by hiding less frequently used options.
And have you noticed the changes to Docs? Their list display is finally useful!
I'm a student, and I find Google Docs is super useful. I just wish for a more consistent experience. For example, I like to edit with "Compact Controls." Sometimes that feature goes missing, and I'm forced to edit in full screen – not an incredibly useful feature because the controls are completely hidden.
Yeah, though I think they should cut buck on using bold font all over the place. That should be use for emphasis but the Goog wants to use it as the default.
I have the new top bar in gmail, but not in greader.
My case too. I don`t have it in Picasa either, but I do in Docs.
<title>Error 404 (Not Found)!!1</title>Ha!1 Nice to know that even the almighty at Google are prone to some typos every once and a while.
What makes you think that's a typo? We're not allowed a bit of humor every so often? :)
Pretty sure it's not a typo ;)
Intentional typo. You could get a 404 by mistyping the URL and hence it fits.
Given the size of Google, I wonder if there was a whole team tasked with this development. A 404 page for a company as big as Google is an awfully big responsibility for just one person :)
To be honest, I prefer the idea of a more intelligent 404 page. You'd think Google would have sufficient horsepower to make a good guess at what you might have been trying to find.
To be honest, I prefer the idea of a more intelligent 404 page. You'd think Google would have sufficient horsepower to make a good guess at what you might have been trying to find.
Google's most frequently accessed pages (most prominently, the homepage itself) are designed by a team of pretty high-level engineers, to reduce latency and bandwidth requirements, by stripping bytes. Every change is reviewed with extreme scrutiny. I'm sure the 404 page was designed with similar care.
If you view source, for example, the image is base64 encoded, and they don't even bother closing their tags on the page, because that's more bytes and the browsers don't notice. This was very carefully engineered.
If you view source, for example, the image is base64 encoded, and they don't even bother closing their tags on the page, because that's more bytes and the browsers don't notice. This was very carefully engineered.
Seems weird to have Arial in the font-stack, as Arial is the default font for sans-serif on Windows. (And Helvetica on OS X which has the same metrics.)
Google uses Arial in the font stack across all of their pages, for consistency. I assume the following rationale is at least mostly correct.
In case a computer doesn't have that as the default for some reason, they don't want their page to look any different, if it is possible for the computer to display it correctly, because if it doesn't, it affects their brand image.
Imagine if you did a google search and everything looked just a little bit off (and you weren't a developer so you didn't know why): you might think someone was hacking google and stealing your information or changing your results. Consistency builds trust, and this is important to them.
In case a computer doesn't have that as the default for some reason, they don't want their page to look any different, if it is possible for the computer to display it correctly, because if it doesn't, it affects their brand image.
Imagine if you did a google search and everything looked just a little bit off (and you weren't a developer so you didn't know why): you might think someone was hacking google and stealing your information or changing your results. Consistency builds trust, and this is important to them.
Why did they not remove whitespace too?
I'm guessing it's not much of an issue when it's sent compressed over the wire.
Neither are closing tags...
Who in the world downvoted this, please own up? Can you show that gzip does not, in fact, perform well at compressing repeated strings of text such as the likes of closing tags?
Wasn't me, but why make gzip do the work when you can do it once, easily, yourself? Sure it can do it, but their servers can serve the closing tags, and google strips those. The discrepancy is weird is all.
No idea, I saw that too and was puzzled.
don't knkow if it's firefox inserting them, but i do see closing tags, apart from <p> elements, but that's allowed.
There is no <head>, </head>, <body>, </body>, or </html>.
This was something I was thinking too. I watched a video from Matt Cutts yesterday where he mentioned they have a "team" (I guess it could just be 2 people, but it sounds like more) who are entirely dedicated to parsing 404 pages that return 200 response codes. I too wonder if they had a team just for this, or maybe they have a "usability" team who were tasked with this?
This would be a completely different thing though - parsing 404 error pages that incorrectly return a status 200 OK could cause broken links to appear as duplicate content when crawled. Didn't think about this before but I am sure this does require q dedicated team to be able to distinguish this kind of content.
>> I prefer the idea of a more intelligent 404 page
There's a script for that: http://googlewebmastercentral.blogspot.com/2008/08/make-your...
Example:
There's a script for that: http://googlewebmastercentral.blogspot.com/2008/08/make-your...
Example:
<script type="text/javascript">
var GOOG_FIXURL_LANG = 'en';
var GOOG_FIXURL_SITE = 'http://www.example.com
</script>
<script type="text/javascript"
src="http://linkhelp.clients.google.com/tbproxy/lh/wm/fixurl.js>
</script>This is already shown by the rareness of a google 404. You hardly ever get it these days. Except if a server crashes for about 1 second, (where my preference would be "you are the lucky winner to click your mouse at the same second as our server crash!"
Making the new 404 HTML page was probably someone's "20% project" for a year.
I've heard about the 20% things but look a the page and ask yourself. Anyone could have made that in 5 minutes + maybe a week for discussion.
View the source. All the css is inlined, the images are base64 encoded, and there's no closing tag. That's one efficient 404!
Also:
href=//www.google.com/
`//www.google.com` will automatically translate the url to http/https depending on the requested protocol.
Yup, that way of doing it is protocol-agnostic.
is this officially accepted syntax? does it work in all browsers? (I'd really love both these answers to be yes so I can start doing this on my sites)
Yes and yes, since 1995.
More specifically: http://www.ietf.org/rfc/rfc3986.txt
Via: http://stackoverflow.com/questions/3583103/scheme-relative-u...
More specifically: http://www.ietf.org/rfc/rfc3986.txt
Via: http://stackoverflow.com/questions/3583103/scheme-relative-u...
thanks :)
Which is interesting since Google doesn't serve a 404 over HTTPS as far as I can tell.
But they're clearly doing their best to minimise file size, and so using // cuts down on a few characters.
Well maybe they will...?
None of the html attribute values are quoted either.
One image is inline, the other is a conventional file. I wonder why.
Oh, and it validates indeed: http://validator.w3.org/check?uri=http://www.google.com/nota...
Oh, and it validates indeed: http://validator.w3.org/check?uri=http://www.google.com/nota...
The other image, the logo, is probably generic enough that it's used elsewhere and a user is likely to have it cached. The other looks bespoke for this page, so wouldn't.
Maybe that logo is used elsewhere, and there's a high likelihood for that logo to be in the user's cache.
I don't understand how it validates - I'd always understood that html, head, [title] and body were required for a complete document. Certainly the draft spec at http://www.w3.org/TR/html5/semantics.html#the-html-element-0 appears to confirm this ...
Fairplay to them though, they got a semantically and structurally deficient document to validate - it's like the IE6 of webpages ;0)
Fairplay to them though, they got a semantically and structurally deficient document to validate - it's like the IE6 of webpages ;0)
The elements are required, but the tags are implied by the tag structure of the rest of the document. They're added automatically at parse time:
http://www.w3.org/TR/html5/tokenization.html#the-before-html...
http://www.w3.org/TR/html5/tokenization.html#the-before-html...
That's a strange version of "required". Basically the elements are not required in a document until parse time at which point they are inserted following an extremely arduously defined algorithm.
It seems bizarre to me that you wouldn't simply define the location of meta elements strictly as being in the head but instead define that should the parser find them they should be wrapped in to a head element.
On a brief view it looks like one can just drop a meta tag, say, in anywhere in the document and the parser has to move this to the head element?
I didn't realise that they were encouraging tag soup; this isn't part of the spec I've seen before. This sort of complex parsing algo wasn't in XHTML1.X or HTML4.X was it?
It seems bizarre to me that you wouldn't simply define the location of meta elements strictly as being in the head but instead define that should the parser find them they should be wrapped in to a head element.
On a brief view it looks like one can just drop a meta tag, say, in anywhere in the document and the parser has to move this to the head element?
I didn't realise that they were encouraging tag soup; this isn't part of the spec I've seen before. This sort of complex parsing algo wasn't in XHTML1.X or HTML4.X was it?
You can see the HTML 4.01 definitions at http://www.w3.org/TR/html401/struct/global.html#h-7.3
The complex parsing algorithm wasn't spelled out in excruciating detail, as it is in HTML5; much of it was implied, and left for the parser developers to figure out.
Strictly, the HTML, HEAD, and (BODY|FRAMESET) elements are required, in a valid document, but the tags delimiting them are optional. That way, code which manipulates the DOM can always count on a HEAD element being present, and CSS specifiers can use 'body' as a root, even if the tags themselves are missing from the source HTML file.
The first actual required tag in an HTML 4 document is <title>, as far as I know. Every HTML document has to have one, and it needs to be opened and closed explicitly. If it's the first thing in the document, it implies an <html><head> before it, and if body content comes after it, that will imply </head><body> as well.
You could put a <meta> tag anywhere before the first body content, and it would still be part of the implied HEAD element. As long as it doesn't come after the (explicit or implicit) </head> tag, it shouldn't cause the document to fail validation.
And no, none of this is valid XHTML. XHTML is always strict, and all opening and closing (or self-closing) tags must be present in the source file.
The complex parsing algorithm wasn't spelled out in excruciating detail, as it is in HTML5; much of it was implied, and left for the parser developers to figure out.
Strictly, the HTML, HEAD, and (BODY|FRAMESET) elements are required, in a valid document, but the tags delimiting them are optional. That way, code which manipulates the DOM can always count on a HEAD element being present, and CSS specifiers can use 'body' as a root, even if the tags themselves are missing from the source HTML file.
The first actual required tag in an HTML 4 document is <title>, as far as I know. Every HTML document has to have one, and it needs to be opened and closed explicitly. If it's the first thing in the document, it implies an <html><head> before it, and if body content comes after it, that will imply </head><body> as well.
You could put a <meta> tag anywhere before the first body content, and it would still be part of the implied HEAD element. As long as it doesn't come after the (explicit or implicit) </head> tag, it shouldn't cause the document to fail validation.
And no, none of this is valid XHTML. XHTML is always strict, and all opening and closing (or self-closing) tags must be present in the source file.
Does every browser support base64 encoded images embedded in css?
Almost every browser. Guess which ones don't.
(I'll give you a hint: It's MSIE 6 and 7.)
Source: http://en.wikipedia.org/wiki/Data_URI_scheme#Web_browser_sup...
(I'll give you a hint: It's MSIE 6 and 7.)
Source: http://en.wikipedia.org/wiki/Data_URI_scheme#Web_browser_sup...
I don't think the older ones do; however, I'm sure Google gives them a different 404 page (change your User-Agent to IE6 and see how different the search results HTML is).
We unfortunate users of IE6 get the new 404 page as well. I assume they just gave up on IE6 like most of the web-world has.
Yep here's what I see on our IE6 death machine:
http://i.imgur.com/bTXtn.png
http://i.imgur.com/bTXtn.png
Which could be another indication why the Google logo itself is linked (besides it being in cache as well). The page degrades well imho in IE6 - the lack of the cutsey robot isn't essential to the page - the logo however is.
Base64 isn't exactly efficient. (Though it might be more efficient than an additional HTTP request. But if so, why aren't they using it for the homepage logo, say?) I wonder if they're using it as non-useless padding for stopping the IE-overrides-too-short-404s behavior.
Base64 is ok when the response is gzipped
So, the new 404 page isn't really useful. They could maybe add some links to help people find what they were looking for.
Maybe someone at Google should take a look at these very helpful tips on what to include on a 404 page:
http://www.google.com/support/webmasters/bin/answer.py?&...
Maybe someone at Google should take a look at these very helpful tips on what to include on a 404 page:
http://www.google.com/support/webmasters/bin/answer.py?&...
I personally prefer the simple, simple, simple 404 pages.
Like, a lot.
Like, a lot.
And the page doesn't include a search bar?
> "That's all we know."
Not true. They know the sub-domain and the path. Either or both could be used to do something more intelligent.
Not true. They know the sub-domain and the path. Either or both could be used to do something more intelligent.
They could use The Google 404 search widget thingie.
<script type="text/javascript">
var GOOG_FIXURL_LANG = 'en';
var GOOG_FIXURL_SITE = 'http://www.google.com'
</script>
<script type="text/javascript"
src="http://linkhelp.clients.google.com/tbproxy/lh/wm/fixurl.js>
</script>The response says the server is "sffe". It seems to be used for static web hosting on android.com and providing HTTP error codes for other sites. I'm guessing it's running on the edge servers, but Google hasn't publicized what it is, that I could find.
Check out ours: http://loggly.com/404
And I created this one: http://access-training-amsterdam.nl/xyzzy
...abandoned in the desert...
...abandoned in the desert...
This is mine, http://demontunes.com/asdasd
poor fly
Aww, typing "skedaddle" doesn't skedaddle :(
So what is the key take away here ?
When you launch, as a matter of fact for the first 10 years, having a clever error page is not a "MUST-have".
Prioritize!
Btw, this comment is just as much for me as for the next guy.
When you launch, as a matter of fact for the first 10 years, having a clever error page is not a "MUST-have".
Prioritize!
Btw, this comment is just as much for me as for the next guy.
This is nice, but more developed, cutesy ones with animals and such are all the rage. Maybe they should ask the guy at The Oatmeal comic if he'd be willing to help; he did the Tumblr one for free iirc and it's fairly awesome.
He did their 500, not their 404 I believe
Does it matter whether 404 pages are ugly or not? I mean its a nice experience for a confused user, but I'd frankly rather it made suggestions as to similar urls that might exist, where possible.
I thought "That’s all we know." is cute because this is probably the only moment in Google's history to admit not being able to find/ know the reason why as a superpower search engine! =)
Haha, a nice simple error page! Still, nothing beats that one http://www.abovetopsecret.com/404.html
Love it. Especially the changes they have been making. Keeping Google's signature simplicity, but also adding a little modern look. to it.
Kudos to Goog.
Kudos to Goog.
Google should at least put search bar on 404 error page. Isn't that the most basic thing?
"That’s all we know." but is it 'useful' ?
[deleted]
Awkward verbiage.
Is that Salo?
that page also has no body tag
Who cares? What interesting discussion is there to be had about this?
You might have typed the URL incorrectly, for instance. Or (less likely but certainly plausible) we might have coded the URL incorrectly. Or (far less plausible, but theoretically possible, depending on which ill-defined Grand Unifying Theory of physics one subscribes to), some random fluctuation in the space-time continuum might have produced a shatteringly brief but nonetheless real electromagnetic discombobulation which caused this error page to appear.