I lived for three months in India on a wi-fi network that would go on for two minutes, then off for three, and would randomly stop working for days at a time. So I got really, really good at getting work done on a terrible Internet connection. Here are some best practices.

1. Avoid HTTP wherever possible. Your goal is to get the information you need and nothing more. Loading a full website, with ten Javascript files each requiring their own connection, ten CSS files, and fifteen images, will take forever. Meanwhile, the page render is blocked until the CSS finished downloading, so you can't even see the damn thing.

   Instead of loading websites in your browser, use different protocols. So instead of checking your mail at gmail.com (over HTTP), check it in Mail.app (over SMTP) and save yourself a ton of bandwidth. Instead of loading a chat client in the browser, load a chat client (over XMPP) and save bandwidth. Instead of loading your favorite website in the browser, save the RSS feed and read that instead (one HTTP request instead of thirty).

   I also set up tons of stuff to work directly via email - I could post to Twitter from email, update my Facebook from email. If I could help it I tried to push every interaction I had toward email or RSS.

2. Cut down on HTTP requests, if you can't help it. Currently Firefox is the best bad-connection browser. Open up the settings and disable Javascript and images. Download the FlashBlock and AdBlock plugins. These will save you 40-50% of the number of HTTP connections you have to make, and lots of the throughput - images often use the most bandwidth and most of them add little. Furthermore any ad that streams video will kill your speed and crush your download time.

   Boost the size of your cache as high as it can go - I would say half of available RAM - so that images and other assets will be loaded from your machine, instead of downloaded from the Web. Make sure to kill tabs when you are done with them, as well - many modern AJAXy applications will continue making requests to the server even when they are not being used.

3. Use a mobile user agent. Most websites will send less data to mobile phones than to regular browsers. On Firefox you can download the User Agent Switcher add-on and pretend like you are an iPhone. You should also use the mobile versions of popular sites like Facebook (m.facebook.com) and Twitter (mobile.twitter.com)

4. Do most of your work offline. If you are developing websites, make sure you can replicate your production environment on your local machine, so you can experiment without making HTTP connections. Use a fast, compressible protocol like Git or rsync (instead of FTP) to compress the amount of data you send over the wire to your server.

   Use a good desktop mail client that can queue up outbound messages for you, then do all of your email offline. When you get back online, sending and retrieving messages over SMTP should only take a minute or two.

5. Kill background data hogs. Lots of desktop programs will automatically connect to their home bases like you have a great connection. Some you should kill: Dropbox, the Adobe AIR Updater, Microsoft Office Updater, Software Update, any programs that load on startup, the Google Chrome auto-updater, as well as any program that has an "Automatically check for updates on startup" box.

   You should also kill any programs that are set up to load on startup in the "Login Items" preference pane. You can get a list of open HTTP connections by running netstat -a in the Terminal, although note that a lot of connections to popular sites may not be to the web domain you know (eg Google serves some content from 1e100.net and other domains). Also check your /Library/LaunchAgents and /Library/LaunchDaemons, as well as your ~/Library/LaunchAgents/ folder for apps that start running themselves in the background on system startup.

Conclusion

So that's about it; I can also go on about the terrible performance of websites on degraded browsers, or how most mobile apps break unnecessarily when they don't have a data connection (looking at you, Words with Friends). A bad internet connection is really frustrating and some of these tips will hopefully help you consume the Internet like you're used to.

I have a new blog post up on the Twilio Engineering Blog about best practices for your company's documentation. The three main points:

1. Users are busy/lazy - you can't expect that they'll actually read anything, and you can't expect them to have any context, so make sure your code samples contain everything necessary to run the code.

2. Users are coming from Google - so you need to SEO all of your documentation content.

3. You are busy - so write the documentation first, when you're still excited about it.

The entire post is here - please take a look!

On a related note, I feel like I've been writing as much as I do usually, but sadly not all of it is visible to the public.

I entered my credit card the right way on the first try this morning. I think this new diagram had a lot to do with it:

I don’t understand why the white diagram works so well. From the perspective of the diagram, you are looking up at the credit card slot, and the keypad had a completely different perspective. But it does work. I guess this is why testing is so important.

The most usable credit card slot holder would be one that could accept your credit card in any orientation, or a credit card with four magnetic strips. I don’t think that’ll happen any time soon.

Last weekend I redesigned my website. The new site has a homepage featuring a bunch of different things I’ve been working on, and a blog post view with no header, just a sidebar and the post itself. As a result the site is way more usable.

With any redesign you have to start by looking at what your audience needs and then tailor the site for those needs. My user base divides into three groups:

• Friends and family, who will read more or less everything I write
• Drive by Google traffic, who are likely to visit one page and then leave
• Potential clients/employers/partners, who were referred from Hacker News, Twitter, an email I sent out or a job application.

I am guaranteed to get traffic from the first two groups, as long as I don’t break the site. The third group of clients, employers and business partners are people who do not yet know me, but may interact with me soon, and the site plays a big role in helping them make that decision. So the redesign is targeted toward that group.

To win that third group of users, my site has to answer one question: Who is this person and why should I listen to him? My old site didn’t do a very good job of answering that question. Here’s what it looked like:

The standard blog template, where posts are displayed in reverse chronological order, is good for only one use case – where the writer updates frequently and the readers want to see what’s changed since the last time they visited. The majority of blogs on the Internet don’t fit this model because the authors update infrequently and don’t have a consistent audience. Therefore, they should consider a different navigation scheme for their sites; the main problems are outlined in this Jakob Nielsen article on blog usability. My old site used a reverse chronological order for navigation, and here are some of the problems with that design:

• No way to find good content that may be a year or more older.
• Posts are on a variety of different topics, appealing to different groups of users, with no organization.
• No photo, or description of me, on any page.
• All of the action items (send email, read more about me, etc) require at least one full page refresh; this is too difficult, as most users are lazy and won’t hunt around.
• Articles are posted in full text, meaning that user attention span might run out quickly (and also that 10 posts worth of images are requested and downloaded)
• Finally, the large number of different pages made it more difficult to maintain, and each attempt to tackle a part would leave me overwhelmed thinking about fixing the whole thing.

So I had the following goals in mind for the redesign:

• Tell a better story about me on every page.
• Put the best content on my site in front of users.
• Make the action items (email, Twitter, etc) easier to click.
• Also, improve page load time, which would boost user satisfaction and my Google rankings. Google found that a half second delay in page load time dropped traffic by 20%.

So here’s what I came up with for the homepage:

And the single blog post view:

I’m pretty pleased with the way they turned out. The homepage essentially consolidates the information that was spread across five pages in the menu of the old design. Furthermore, it displays ten of my best posts, organized by category, and a sample of things I’ve tweeted, so there will be at least some dynamic content on the page for users who visit.

I also took some steps to improve the page load speed. I installed two caching plugins – WP Minify, which minifies and combines all of your Javascript and CSS files into one file of each type, and WP Super Cache, which generates a static HTML file and then serves that file to users, instead of hitting the database every time a user requests a page. These help minimize the response time, the number of requests, and the size of each request.

I also use a sprite to display the icons on the blog page view, turning five requests into just one. As a result, the blog post view gets a score of 83/100 and the home page gets a score of 78/100, about a 20 point improvement over the old design.

So that’s the analysis of my site redesign. Now if I could just to find a posting schedule and stick to it!

I just spent two hours finding and fixing all of the broken links on my site. The Broken Link Checker plugin is invaluable for this task (as well as extremely usable!) Here's what I learned:

• Don't hotlink images. Hotlinking is where you embed an image into your page that is hosted on someone else's page. Not only does it cost the other person bandwidth to serve the request, but it is extremely vulnerable to breaking whenever the other person decides to change their site, or (worse) change the image hosted at that URL, so where you thought you were showing an image of a cat, you are actually showing a porn image meant to embarrass you. The majority of broken links were hotlinks.

• The alternative to hotlinking is downloading the image, uploading it to your own site and then displaying it from there. This is pretty tedious in Wordpress; there should be a plugin that lets you do this.

• Think very, very hard before deleting or moving resources on your site. Once you create a resource, you should serve the content at that URL forever, or use a 301 redirect to indicate the new location of the resource. If you don't, you are breaking the Internet. A related problem is that it's very easy to break links: change your page title, move subdomains, or move a small section of content, and you've caused a problem for your site's users.

• If a link is broken on your site, you've created a problem for every single person that links to that resource, because now they are pointing their visitors to a broken link. The best way to handle this is with a 301 redirect. However many webmasters don't know they broke links, or don't care, so I had to update many links by hand to point to the new resource.

  It would be nice if there were some kind of link wiki service that you could update to point to the correct resource; then everyone could just point their links to the wiki and the Internet would not be broken when someone updates the location of their content.

• I had a much better chance of finding what I was looking for when the URL described the post content than when the URL was opaque (e.g. http://example.com?p=519). It's also good SEO to have the title of your posts displayed in the post URL's, so you should definitely try to do this for your posts.

• As a webmaster, you should try to make your 404 (File Not Found) page helpful for users. Try parsing the URL and outputting the results of a site search onto the page, in case you can find the content under a different name. At the very least, you should set up your CMS to send an email whenever your site serves a 404. That's an easy way to find broken links on your site that are hurting users.

All in all, there were 2300 total links on my site, and about 230 of them were broken, for about 10%. This means that, roughly speaking, a user has a 1 in 10 chance of being disappointed when they click on a link on my site; I cut that down to about 20 broken links by unlinking content that 404's or updating it to point to the correct resource. This was a good use of my time; it's important to keep a good user experience for all of my users, even the ones that will only visit once.

<ul>
    <li>First list item!</li>
    <li>Second list item!</li>
    <li>Third item!</li>
</ul>

* First list item!
* Second list item!
* Third item!

<link href="http://kevinburke.bitbucket.org/markdowncss/markdown.css" rel="stylesheet"></link>

One thing you pick up when you start having to design things on your own is a keen sense for details – all of the tiny parts of an object that make it pretty, and easy to use. A good test for this is to pick up your iPhone, open it to any screen and try to observe all of the gradients, drop shadows, bevels, fonts, and rounded corners that make up the pixels on the 640 by 480 screen. If you tried to design something with the exact same shapes but without the subtle effects, you would probably wonder why the Apple one looks so much better. And the effects are hard to get right – it’s easy to go overboard on effects and end up with something hideous.

Take, for instance, a basketball jersey, which is a pretty simple object – it’s a shirt, with letters, numbers, and a color. But there are a surprising number of rules about a jersey that make it a more usable object. At a very basic level, everyone on the same team wears the same color jersey, so it’s easy to identify which players are on your team. Traditionally, the home team wears white, and the road team wears a dark color. Why? In the old days, the road team might not have a chance to wash their jerseys between games of a road trip, so wearing dark jerseys would help hide the stains.

Another feature of jerseys is that a team’s dark jersey will usually feature the name of the city or university the team represents, whereas the home, or white, jersey, will feature the team’s nickname. This is because the team wears the white jersey inside their own gym (where everyone knows the university or city name), but for the road team, the more relevant piece of information is the city or university name.

A third principle revolves around numbering, where each sport has different rules based on how numbers are used. In high school and college basketball, players’ numbers can have at most two digits, and each digit has to be between 0 and 5. This is so referees can use their hands to report a player’s number when she commits a foul. In soccer, the players on the field traditionally wore numbers 1 through 11, where the number indicated the position of the player on the field, with 1 being the goalkeeper, 2 and 3 for the outside fullbacks, and so on. (Fortunately, rugby still follows this tradition). And of course, the numbers should be as big as possible, so people can read them.

So even in a pretty simple object like a jersey, you can see a complex set of rules develop to make things easy for people that use them. If you were asked to design a jersey from scratch, it’s unlikely that you would have covered all of these use cases, which is why it’s important to prototype, test things on real users, and then iterate.

I’m a big fan of the data-driven approach, and I love basketball, so one of my favorite sites is Ken Pomeroy’s stats site, where he tracks tons of statistics for every team, on offense and defense, and lets you break down exactly which parts of each team (rebounding, turnovers, etc) contribute to their success, and which players (efficiency, no. of possessions used, etc) are the most influential.

The site used to be entirely plain text on a blue background, which worked for me, but Ken redesigned the site this year. Last week he posted on Twitter asking for feedback on the redesign.

I agreed that it was hard to read and I had some feedback. Here’s Ken’s initial version:

Data presentation legend Edward Tufte always says that your design should be as dense as possible; that is, every single piece of ink should convey some bit of information. The table is a good format, especially when you need to search quickly by team instead of by efficiency, but you can change it to make the information easier to scan.

The first step was to replace the heavy black lines between teams. These convey no information and clutter up the design. The best alternative is so-called zebra-striping, where you shade in every alternate line with a light color. The lines are still there, because there are color differences, but they’re much more subtle and don’t clutter up the display.

I also took out the vertical dotted lines. However, the purpose of these was to distinguish between like groups. We’ve already used color to distinguish between line elements, and instead of doing a checkerboard pattern I decided to use spacing to group like elements together. I moved the small-text rankings close to their associated item and increased the space between some of the columns. I also pushed the table width to the full 960 pixels.

The final step was to make it easier to associate the numbers with the team names. I added a gray bar that highlights the table row you are hovering over with your mouse.

All in all, I think it’s much more readable and when I have more time I’ll explore some other ideas about how to stretch the data. Check it out here.