Here’s a screencast of some of the new features:

For more info, check out the Mozilla Labs blog post about it or visit the site!

The long: An awesome book about web form design best practices that is backed up by real data and studies. The book oozes design from its glossy stock and full color images to the layout and typography. Overall you can tell that Luke is a great designer and has considerable experience with the usability of web forms. Luke covers just about every topic of web form design from from basic layout to help text to error conditions and about a dozen other topics.

Overall Web Form Design is one of my favorite design and usability books on my bookshelf for its breadth, beauty and usefulness.

So instead of just whining about it, I decided to rewrite Gmail in semantic, clean HTML:

http://ryandoherty.net/semanticgmail/

Why did I do this?

To challenge myself. To prove it could be done. To show people what clean, semantic markup looks like for a complicated app like Gmail.

What’s missing?

A lot. Many of the select menus should be DHTML. It’s just a basic inbox view so far, nothing more than that.

Why announce now?

The big challenge is over for me, writing the HTML and CSS. If someone else wants to work more on it, fine by me. I’d rather get this out than have it sit on my computer any more.

http://ryandoherty.net/semanticgmail/

Rather than throw up a bunch of slides and blab on about expires headers, gzipping and concatenating, I created an awesome social networking website called openSpaceBook. Go ahead and check it out, any login will work.

Now that you’ve realized you should cancel your Facebook account because this is going to be awesome, you can learn how it is pretty slow to load and how we can speed it up.

According to webpagetest.org, a handy-dandy webpage loading tool, it takes about 12 seconds for openSpaceBook’s home.html page to load on DSL. 12 seconds! And that’s just for a static html page, nothing going on in the backend. WTF is taking so long?

This is what’s taking so long:

26 HTTP requests, 773KB! Rendering doesn’t start until 12 seconds into downloading the page! (Thin vertical blue green line.)

Don’t think this page is bloated compared to other websites. Facebook has 182 requests and has 500KB in assets (down from over 1MB a few months ago). YouTube has 42 requests, 356KB. And those sites have most likely been optimized, openSpaceBook is not.

So I have this bloated website, but I can’t remove any features because I’ll lose the ‘ooh shiny!’ audience that I’m trying to attract. What should I do?

Step 1: Reduce HTTP requests

The first thing that can be done is reducing the number of HTTP requests. There are 3 reasons for this. One is every HTTP request has a small amount of network overhead, and the more requests you remove, the less overall network traffic.

The second reason is browsers have a limit to the # of HTTP requests they can make to a webserver (or hostname, specifically). Older browsers were limited to 2. Some newer browsers have upped that limit to 6 or 8, but they still have a limit. Therefore when a browser has reached its limit, it has to wait for requests to finish before starting up new ones. So the more requests necessary, the more queuing will occur.

The third reason is specific to JavaScript in that browsers will only download and execute 1 JavaScript file at a time. This is done because JavaScript can modify the DOM, redirect the page or do any number of things that may affect what resources need to be downloaded. So even if a browser can download 8 requests in parallel, JavaScript files will still be download sequentially. (There are efforts to improve this issue in Webkit and Gecko.)

So lets see how we fare after reducing our HTTP requests. I did this manually by copying and pasting all of my CSS files into 1 file and JS files into 1 file. I also took all my CSS background images and merged them into one. Then I can use CSS background positioning to only show the graphic I need.

Results after combining files

Shazam! Down to 5.8s! That’s a 50% increase in speed for less than 30 minutes worth of work. And 8KB has been shaved off of the page. Sweet. On to our next step.

Step 2: Set expires headers

Another simple trick that requires a few lines of code is setting expires headers. Expires headers are a type of header that tells the browser when an asset ‘expires’ from its cache. When you set it to years in the future, a browser will cache it and never ask the website again for it.

Expires headers look like this:

Expires: Thu, 15 Apr 2020 20:00:00 GMT


The assets you want to set expires headers on are things that don’t change much. Like images, CSS and JavaScript. I know, CSS & JavaScript might change every week or two and this can result in your users never seeing new content. The way around this is to change the filename of your assets whenever you update them. This can be done manually or with a build script of some sort.

You can set expires headers in Apache by adding this to your httpd.conf or .htaccess file:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"
</FilesMatch>


So let’s see how we fare:

Hmm, 6 seconds. No improvement. Not surprising, we didn’t really change anything. In fact, we actually added an extra header per request. The extra 0.2 seconds could be due to this or due to varying network latency or utilization.

What was improved was repeat response time. Down from 1.3 seconds to 0.6 seconds. And this performance improvement is carried over to all other pages. Any previously cached assets will not be downloaded again or checked to see if there is a newer version (If-Modified-Since request). So a user’s multiple page view experience will be significantly faster.

So what else can be done to really improve performance?

Step 3: Gzip your content

Now we’re talking. Compressing your content is an easy way to significantly reduce the amount of data transmitted. HTML, CSS & JS are all text, so they compress very well. So let’s see what kind of performance increase we get when we compress our content.

Yes! Down to 2.7 seconds! And we’ve cut the amount of data down to 223KB, which equates to $$$ saved when you pay for bandwidth.

To gzip your content in Apache, you can add this to your httpd.conf or .htaccess file:

<IfModule mod_deflate.c>
<FilesMatch "\.(js|css|html)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>


Step 4: Move JavaScript to the bottom

Remember way back in step #1 when I said browsers only download 1 JavaScript file at a time? Well, they also block rendering of any content after them in the DOM. So when your JavaScript is referenced at the top of the page, like most webpages do, it blocks the rest of the page. The solution? Move them below all your content!

Here’s what happens when you move your JavaScript to the bottom of the page:

So, down to 2.4 seconds (even though the amount of data is the same, discrepancy most likely due to network latency or bandwidth fluctuations between tests), but the rendering of the page starts at 0.9 seconds as opposed to 2.3 seconds in step 3. This makes the page appear to load faster because the browser will begin to show content before it has finished downloading the JavaScript file at the end of the page.

So, we’re down to 2.4 seconds, can we do any better? You’re darn tootin’!

Step 5: Minify CSS & JS

Hang in there, we’re at the last step. Here’s another way to reduce the amount of content sent even more. Minify your CSS and JS. Basically this means removing all newlines, comments and unnecessary spaces. It can also include programmatically replacing variable names in JavaScript with shorter ones.

The easiest way to do this is to use a compressor like YUI Compressor. It’s a Java app that takes a CSS or JavaScript file and spits out a minified version.

So how well does openFaceBook do after minifying?

2.2 seconds, not bad. Down to 154KB too. So openFaceBook has gone from 12 seconds and 773KB of data to 2.2 seconds and 154KB. That’s a 81% improvement in load time and a 80% decrease in page weight. And all those steps took me about an hour or two to do. That’s a pretty good ROI for a few hours worth of work.

Summary

Speed is everything. It’s a feature that is often left out of PRDs and users’ thoughts about websites, but it’s there. And they notice on a subliminal level when your site is slow. With all the hoopla about how browsers are getting faster and faster, how fast you can deliver content to your users becomes more and more important.

Resources

• WebpageTest
• Yahoo! Exceptional Performance

So in some of my previous posts about becoming/being a web developer, I say you should write code, lots of code. I also think the more varied real-world experience you get, the better developer you’d be.

So how can you get more real-world experience when you are a student or have a full-time job? Easy, you can write code for Mozilla!

Want some Python, Javascript and MySQL exeperience? Help us with our Graph Server. Dying to show off your killer PHP skills? Help us with AMO. Want to work on Drupal? Work on spreadfirefox.com. Want to work on some crazy futuristic ideas? Check out Mozilla Labs.

All of our code is open source and available through svn.mozilla.org or hg.mozilla.org. You don’t even need an account to checkout the code!

The basic workflow would go something like this:

• Take a bug
• Submit patch
• Ask someone to review the patch
• Once reviewed, submit the patch
• Pad your resume

Want more info? Check out the wiki and mozilla.org/contribute.

Photo from onthetower.

There’s been so much talk recently about performance and scaling thanks to Twitter and I really want everyone to shut up about it.

“Language Foo can scale better than Bar!”

“If only they had used language Baz!”

Pay attention to this part because I’m only going to say it once:

Your code doesn’t scale, your architecture does.

I’ve been reading about scalability for a while now and participated in a few highly-trafficked websites and I can say that the language that we used was the least of our concerns. And it would probably be trivial no matter what language we chose.

Every time I’ve ever heard someone talk about scaling issues, I don’t hear them talk about the raw execution time of their code. It’s always about disk I/O, database performance or network capacity.

When I interviewed at Insider Pages a few years ago they never mentioned Ruby or Rails as a limiting factor, it was databases and their network. A nice blog comment about Insider Pages mentions scalability tactics.

When Scribd talks about scaling with Rails, you don’t hear them mention Ruby. It’s all about adding databases and caching. (Please remember Rails is a framework (an architecture for your code) and Ruby is a language).

Flickr talks about scaling a lot [PPT] and they don’t mention PHP. They mention database sharding, caching and capacity planning.

Even Twitter’s status blog never mentions Ruby as their bottleneck. They mention database and database, load balancing and caching . Blaine Cook’s presentation about scaling Twitter mentions databases and caching. (I know, I know, he left Twitter, but his comments are still spot-on with common scaling issues.)

Yahoo’s former engineer Jeremy Zawodny has an old presentation on scaling PHP and MySQL and he never mentions PHP as the bottleneck.

So remember kids, when you are thinking about scaling, think about your architecture.

I subscribed to most of them and a few others, and here’s my writeup of the ones I think are worthwhile:

css-d

http://www.css-discuss.org/

Very high traffic list. Beginner to intermediate questions about CSS.

javascript-official

http://tech.groups.yahoo.com/group/JavaScript_Official/

Medium traffic Javascript list. Mostly beginner questions.

yui-performance

http://tech.groups.yahoo.com/group/exceptional-performance/

Low traffic front-end performance mailing list. Very high quality questions and answers.

public-webapi

http://www.mail-archive.com/public-webapi@w3.org/info.html

High-quality mailing list about the next APIs in web browsers. Very technical and active.

ydn-javascript

http://tech.groups.yahoo.com/group/ydn-javascript/

High traffic and quality mailing list about the YUI JS library. I actually unsubscribed because it was so active. Great for developers using YUI.

jQuery development

http://groups.google.com/group/jquery-dev

High quality mailing list about the development of the jQuery library. Medium traffic, very technical.

Even though I no longer work at Yahoo!, I had to blog about the Messenger website redesign (internally known as project Aurora).

I started working on it around December 2007 on preliminary planning, scoping and design feedback. After we had the specs nailed down, we hired Ryan Parman as our main developer to build out the site. Adrien Cahen worked on a new PHP framework for our site to run on and I worked as the project lead/architect/go-to guy for anything tricky.

Awesome things about the site

Shiny new CSS & HTML

We scrapped everything we had and rewrote it all with YUI Fonts and Reset. MUCH cleaner and more semantic.

Better Performance

The old Messenger website had gotten quite slow over time and I spent a few months cleaning it up to get a decent ySlow grade for the homepage and download page. The new site is blazin’ fast, getting A grades on all pages except the Plugins page, primarily because the images are pulled from the Yahoo! Gallery website and they don’t set appropriate cache headers.

Fantastic Configuration

Building a site for nearly 30 localizations isn’t easy, and configuration is one of the hardest parts. Every locale has specific features and needs that increase the complexity of the site. Ryan, Adrien and I spent a lot of time figuring out the best way to do this and I think it’s much better than before. We have base configuration files for each locale and every page is locale agnostic, it simply loads the appropriate configuration file for the locale you are viewing.

Automagical Content Updates

In the old Messenger website, we had configuration for the IMV gallery in two locations, one of them remote. In order to display a page of IMVs, the data had to be merged, which ended up in lots of code and duplication of information. The new website fetches information for the IMV and Plugin galleries automatically and caches the content. No configuration resides on the webservers, so there’s a lot less work on our side to update and edit content.

Many thanks to Ryan, Adrien, Sarah, Lorraine and Tak at Yahoo!. Good work guys!

What does semantic markup mean?

Semantic markup usually means using proper HTML tags for your content (p tags for paragraphs, divs for large content areas of your page, tables for tabular data, etc) and meaningful classes and id’s for your CSS. It also means not putting any inline CSS or Javascript in the body of your HTML page. There are exceptions to this rule, but for most of the time, this is how a properly coded webpage will be structured.

Knowing the answer to this question means the interviewee has been paying attention to web development for the past 5 years. It also means they understand the proper design and coding principles like separation of content (HTML), style (CSS) and behavior (JS).

Describe the box model

The box model describes rectangular boxes that are generated for elements in a web page. The properties of these boxes are margin, border, padding, width and height.

If an interviewee doesn’t know this, they probably haven’t read 1 book or website about the basics of CSS.

When would you use a table in a webpage?

For tabular data. Representing data in a database or a spreadsheet. NOT for layout

Tables for layout is definitely in the past, so if a developer talks about using them for layout, they’ve been out of the loop for a long time. CSS is for layout, it provides much finer control and allows for semantic markup of your content and data.

Is Javascript an object oriented language?

Yes, Javascript is an object oriented language. Base objects or classes are called prototypes. They allow for dynamically adding attributes and functions to the prototypes and they will immediately be available to all instances of the prototype. (There’s a lot more you can do with prototypes)

This question is actually a tough one. Lots of developers program in Javascript frequently and never learn more than the basics. Learning about Javascript prototypes is one of the first steps in understanding what makes Javascript different than most classical object oriented languages

Can you assign behavior (open a new window, show/hide an element in the page) to a link in a webpage without placing any Javascript in your html markup?

Yes, you can. 1) Include a Javascript file in your document 2) Search the DOM for the link by Id, class or tag. 3) Attach a function to the element’s onclick event via the addEventListener (W3C event specification) function or attachEvent (IE). 4) When the function is called, perform the required action and stop the event from continuing via event.stopPropagation or event.cancelBubble (IE), event.preventDefault or event.returnValue (IE).

Events are very tricky in browsers. I had to research a bit to figure out how to do it without a Javascript library. If a developer mentions adding javascript:foo() into the href or onlick=”foo()”, they most likely haven’t learned about proper separation of HTML and Javascript. They also most likely don’t know about graceful degradation/progressive enhancement. This allows for handling search engine crawlers, browsers with Javascript turned off, Javascript errors that stop execution and mobile browsers that don’t support Javascript.

What’s a closure and how/why would you use it in Javascript?

This one’s tough. I’m still learning how closures work in Javascript. In very simple terms, they are references to variables or functions inside a function after it has executed. (I think that’s a good explanation.)

A good use for them is to hide variables or functions from external code. This is similar to private variables and functions

Knowing at least the basics of Javascript closures means you know Javascript pretty well. Once you learn closures and how to use them, you can start doing really nifty things with Javascript.

How do you debug a webpage?

Lots of ways. Alert statements (basic debugging), Firebug, DebugBar, DragonFly, Web Inspector, and Developer Toolbar.

Knowledge of development tools is important and increases productivity immensely when you can inspect your website’s state without using alerts all over the place. Programming large websites becomes tedious and time-consuming if you don’t have tools like Firebug or the Developer Toolbar.

What are some ways to increase performance of a web(site, page)?

Any number of these methods.

With the current proliferation of AJAXy web apps and Web 2.0 designs, sites are getting much slower. Knowing how to take a site that loads in 5-10 seconds and cut it down to 1-2s is very important. Users do notice and care how fast sites load, and so should you.

Those are my questions, what are yours?

Basically it’s a 10 week intensive front-end engineering course that ends with a full time job at Yahoo!. Despite all the bad things that have happened to Yahoo! in the past few months, it’s still a great place to work and you won’t get anything like this anywhere else. The front-end engineering discipline is taken extremely seriously at Yahoo! and you will learn more than you could ever think of.

A few days ago a friend of mine asked me how he could improve his skills/knowledge of web application design and development. I had some recommendations for him, and it really got me thinking. How does one become a great web developer? It’s such a huge field that it’s hard to know where to start. Here’s what I’ve come up with so far:

Experience

I know many people are looking for a book, website or class that will make them a great web developer. After a lot of thought about how I became a (semi) decent web developer, experience really seemed to be reason why. You simply cannot become proficient at anything without doing it. A lot. And web development is no different.

Don’t believe all those “Teach Yourself X in 24 Hours” or WYSIWYG tools, you need lots of varied experience to become a great web developer. It’s rare having 1 job will teach you every part of web development, it’s such a huge field. The basic technologies/skills that are involved are HTML, CSS, JS, 1 back-end language minimum (PHP, Ruby, Python, Java, Perl), interface design, semantics, information architecture, systems architecture, database design and scalability. And that’s just a start!

Odds are you need about 2-3 years of experience before you can call yourself ‘experienced’. You need to write code, lots of code. Bad code, good code, messy code. Doesn’t really matter as long as you can look back at it in a few weeks/months and say “This code is crap!” (I do this frequently). You also need to break things, make mistakes and blow through a few deadlines before you can begin to understand the ‘soft’ parts of software development.

Continually learn

I’ve heard this from lots of other bloggers and tech gurus. If you aren’t constantly learning and expanding your skill set, you will be left behind. Technology moves fast and keeping up is paramount.

Continually learning means everything from experimenting with new technologies, reading blogs and books to going to conferences and technology groups in your surrounding area. You need to expose yourself to as many new ideas as possible all the time. You are never ‘done’ learning and can take a break.

Being a web developer/programmer is like being a shark, you have to keep moving to stay alive.

Finally

Actually, that’s it. A lot less things to follow than I thought. Add comments if you have more ideas, I’m always interested in new information!

Things to read/check out

Don’t think that by reading these books and blogs you’ll instantly become a great web developer, I still consider myself average to above average.

Books

• The Pragmatic Programmer
• Becoming a Technical Leader
• In Search of Stupidity
• Hackers & Painters
• Blockbusters
• Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
• The Best Software Writing I
• Behind Closed Doors
• Managing Humans
• The Mythical Man-Month
• Peopleware: Productive Projects and Teams
• The Non-Designers Design Book
• Founders at Work
• Good to Great
• Dreaming in Code
• The Art of the Start
• Maverick
• The Design of Everyday Things
• The Art of Project Management
• The Art of Innovation
• Building Scalable Websites
• Designing with Web Standards
• Bulletproof Web Design
• Web Standards Solutions

Blogs

• The Daily WTF
• Ajaxian
• ejohn.org
• High Scalability
• IEBlog
• miscoded
• Nate Koechley
• NCZOnline
• Quirks Mode Bug Report
• Quirks Mode Elsewhere
• ReadWriteWeb
• Scruffy-Looking Cat Herder
• Software Development in the Real World
• Yahoo! Developer Network blog
• Yahoo! User Interface Blog
• A List Apart
• Business of Software
• Coding Horror
• Joel on Software
• Scott Berkun
The Department of Style
• techno.blog
• Bruce F. Webster

RSS reader use is on the rise and a blog’s design has become an extension of the blogger’s ‘brand’. But RSS readers show every feed the same. Same font, colors, layout, everything.

So how can bloggers maintain their brand inside an RSS reader?

Here are my ideas:

• Add a small header/logo image into every post
• Use semantic markup so your headers, lists, etc will at least make it through
• Send RSS readers different content with inline CSS?
• Send RSS readers an extra, small module that links to other posts or sites?

I’m having trouble thinking up more ways to do this. I think injecting extra content for RSS readers or adding different modules would be neat. You could ‘simulate’ visiting your website by supplying design and content in the RSS reader.

Anyone have any other ideas?

So now I’m adding Bookmark.js to the mix. It is a teeny tiny JS object that insulates you from figuring out if the user’s browser can bookmark your page. It can also tell you the correct keystroke to bookmark your page, which you can then alert/show to your users.

Example:

<script type="text/javascript" src="bookmark.js"></script>
<script type="text/javascript">
    Bookmark.canBookmark(); //True if you can, false if not

    Bookmark.getKeystroke(); //"Command/Cmd + D" if Mac, "CTRL + D" if Win

    Bookmark.bookmarkPage('http://www.ryandoherty.net');
    //True if attempted to bookmark, false if not possible.
</script>

Tested in IE 6 & 7, FF 2 & 3, Safari 2 & 3 and Opera 9.

Download it here

More Info

If you search around for bookmarking scripts, you’ll find a lot of code that describes how to do it in most browsers. As usual with lots of Javascript on the net, it’s bad code and wrong.

IE has the bookmark function, window.external.AddFavorite. Firefox has the function window.sidebar.addPanel which is very similar and will add an item to your bookmarks, but will open in a sidebar panel!.

For Opera, lots of people have written about dynamically creating a link, setting the ‘rel’ attribute to ‘sidebar’ and firing the click event. I’ve tested this and can’t get it to work in the latest version of Opera. Safari doesn’t have anything available either.

This is a simple feature that I’d like implemented in all major browsers. Shouldn’t be too hard, right?

The book is written by Cal Henderson, one of Flickr’s lead engineers. Most of the examples and experience he talks about is directly from working on Flickr.

Henderson covers virtually all topics and subject areas that you would ever have questions about when building a web app. What sort of development environments should I have? How do I deal with user input? How do I scale my database servers? How do I monitor my servers? It’s a very comprehensive book.

If you have any interest in scalability, best development practices, web security and/or monitoring, I highly recommend this book. It’s a fairly good read and great reference for any budding web developer.