We should hang out more, so during QA don't use bug tracking software. Come sit with us for an entire day and point out changes you want made over our shoulders. Use the opportunity for some impromptu design updates as well.
Aaah, communication between designers and developers...
Because browser detection is never perfect, web sites should let readers choose between mobile and full content. They can try to guess the right version by default, but please let users opt in or out.
On usability of automatic switching between mobile and desktop versions of websites, based on User Agent detection.
So, yes, yes; URLs are used as a key for locating documents and resources across the web. That is all well and good. But I’m thinking; what happens when the web hosts things other than documents and resources? Like applications? Like games? Like physical objects? What happens when we need to serve humans based on other signals, such as their location, the time of day, their context, their intent?
Reflections on a distinction between web resources requiring URL's and mere application states.
My mind is still full of ideas for tools of all kinds: tools for writers, designers, programmers, whatever. Wherever people are using computers to turn their ideas into reality, I want to help. I've spent the last four years of my career working on a very different kind of software. At Facebook, I've gotten to build communications tools that reach hundreds of millions of people. I've had the honor of seeing people, even my own parents, using my apps while walking down the street, in restaurants, on trains, in planes and everywhere I go. Still, I haven't been able to stop thinking about Firebug.
Joe Hewitt, the man who gave us Firebug, leaves Facebook to work on creative tools. It's a great news. Say what you want about Firebug, but before it web development was in a stone age.
Escaping &, <, >, ", ', , !, @, $, %, (, ), =, +, {, }, [, and ] is almost enough
All those characters up there (including the space character!) can be used to break out of an unquoted HTML attribute value. If you escape every last one of them, then you’re probably pretty close to being safe. But you’re still not so safe that you can just start throwing around user input willy nilly.
Why? Because this still doesn’t cover some context-specific cases like inserting user input into the body of an inline
<script>element or using user input as part of a URL.
I have yet to see an application or library that escapes all these characters. Nevertheless, the article is an interesting read.
If you take The Guardian as an example, the current average visitors per day is around 2,200,000. 1.3% of that is 28,600 users browsing without Javascript. Per day.
While I had always believed in progressive enhancement and the need to ensure that my sites work without JavaScript, this article almost convinced me to change my mind, by using weak argumentation.
While it still makes sense for content websites, providing a non-JavaScript and usable fallback for modern web apps is really a significant effort. For what benefit? Support for 1.3% users (I hope that this number excludes bots). With such a small number it really becomes a business decision: is it worth spending extra money (usually much more than 1.3% of the cost of development) to support that group?
Ability to link to a page and letting crawlers in are worth extra effort, though. But optimization of user experience for 1.3% of users who disable JS, sometimes for misguided reasons? Show me the money from that investment first.
Some specific technical goals are:
To allow many concurrent HTTP requests to run across a single TCP session.
To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers.
To define a protocol that is easy to implement and server-efficient. We hope to reduce the complexity of HTTP by cutting down on edge cases and defining easily parsed message formats.
- To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
- To enable the server to initiate communications with the client and push data to the client whenever possible.
White paper of SPDY, Google's new protocol to improve and potentially replace HTTP. The latter has served us well, but is not really optimized for speed.
Being a web developer is as awesome as Chewbacca riding a squirrel, fighting Nazis with a cross bow.
Front-end development style guide. Probably the best thing in this category since Web standards checklist.
All non-browser user-agents (crawlers, aggregators, spiders, indexers) that completely support both HTTP/1.1 and the URL specification (RFC 2396, for example) cannot crawl any Lifehacker or Gawker content. Except Googlebot.
Hashbang URL's (#!) are breaking the web. Recently Gawker Media websites (such as Gizmodo) joined Twitter in using them. The post provides good technical explanation why it's a short sighted and dangerous idea.
I grew up in this industry learning how to game search engines (well, Google) to make money off my affiliate sales, so I’m no stranger to the practice of keyword stuffing URLs. It was fairly common to end up with a URL like this:
http://guitars.example.com/best-guitars/cheap-guitars/popular-guitarThat kind of URL used to be great for SEO purposes. Fortunately Google’s hurricane updates of 2003 eliminated any ranking benefit of these URLs. Unfortunately the professional SEO industry is centered around extortion and still might advise you stuff your URLs with as many keywords as you can think of. They’re wrong — ignore them.
Some additional points to keep in mind:
- Underscores are just bad. Stick to dashes.
- Use short, full, and commonly known words. If a section has a dash or special character in it, the word is probably too long.
URLs are for humans. Design them for humans.
Every advice in this article is great and should be followed. Yet I still have to see non-developer human being that is using the path part of the URL to navigate the site.
