Today, we’re releasing our front-end development coding standards and best practices.

This document contains a wealth of information for people doing standards-based development on:

• Coding Principles
• Performance Guidelines
• How to approach performance issues with the client
• Browser resolutions
• Browser testing and support
• SEO and accessibility
• … and all the tools that we have at our disposal

I hope others can find it useful in determining the best way for your team to approach high-quality front-end work.

I’ve been using this when working with clients to come up with an agreement on how we handle older and slower browsers. I’m eager to hear your thoughts on it.

There are two major truths when it comes to in-browser experience:

1. Both we and the client want the most responsive experience possible.
2. Everything added to the page slows it down.

So with these two facts of life, what steps do we need to take so everyone is happy? Onward!

Create success metrics with the client

These should be customized to your client and project and done before the wireframing phase. These goals should be reasonable from a technical POV, as well as testable.

Some goals that would be appropriate:

1. The slowest browser supported must go from an empty cache to fully loaded and initialized within 10 seconds.
2. Hover states (and other ‘instant’ changes) should respond within 300ms.
3. Animations should appear smooth, with jumpiness occurring < 15% of the time (across all browsers).

For load-time based goals, it’s important to define who’s computer and connection this must be done on (e.g. the clients). Additionally, the goal may be defined for multiple pages, for example: the two most popular landing pages (e.g. homepage and support).

If the client has more wants more aggressive goals than are reasonable with the intended design, expectations need to be set with visual and interactive design to keep things more minimal.

Communicating the performance impact during design phase

Internally

During IA, IxD, and visual design, it is the interface developer’s role to communicate the performance impact of interactive features or certain visual techniques on the target browsers. Give the designers constraints: “If we’re using Cufon, we cannot have more than 10 elements of custom font per page.”

Externally

Expectations need to be set that all browsers will not have the same experience. They won’t perform as well as eachother, nor may it make sense to have feature parity.

It may be sensible to drop a few features from the IE6 and IE7 experience. Features that could be considered to be dropped are: shadows, transitions, rounded corners, opacity, gradients.

When communicating the impact of something:

• Clarify the impact with as much detail as possible: “it will hurt page load” vs “it will add 2 seconds to page load in IE”
• Provide a quick POC (proof of concept) if it’s reasonable: “This similar-looking page without siFR loads in 4 seconds, with siFR it loads in 8 and has a delay to show during scrolling”

Develop according to best practices

Choose libraries and plugins that are performance optimized. Make wise architecture decisions based on performance goals. Also minimize DOM manipulation when possible, and write styles to avoid visual changes to the page as it loads and initializes.

Measure performance during QA

QA teams should also prioritize performance related tickets alongside visual, functional, and usability issues. Developers and QA should determine how that priority will be assigned.

During QA, the success metrics should be tested regularly.

Tools to test with:

• YSlow, Page Speed, Hammerhead, MSFast, PageTest

When performance goals aren’t met, there are three options:

1. Redevelop the code – profile, discover bottlenecks, refactor code, optimize to target faster execution in the browser
2. Drop the feature – turn it off for slower browsers only
3. Redesign approach of the UI – perhaps the design could use a tweak which would bypass the issue entirely

With this approach, I think all parties have  a better chance of having aligned expectations heading in as well as a more sensible workflow in dealing with performance challenges.

What do ya’ll think? Realistic?

In the current discussions around fonts on the web, there is much confusion between the techniques. Most seem to think that TypeKit and .webfont are our only options. They are not, but the rest of the landscape is quite busy.

Things have been moving very quickly in the last three weeks, so let me break it down like this:

• Webfont services: TypeKit, fontdeck, Typotheque
• Proposals: EOT-Lite, .webfont, ZOT, webOTF
• Implemented standards: @font-face using EOT and TTF
• JavaScript-based font solutions: sIFR, Facelift, Cufón

The commercial webfont services players

While many have considered TypeKit as an alternative to .webfont, it’s just a smart implementation of CSS and JavaScript along with a shop and licensing model. I agree with Pablo Impallari who commented:

You don’t need typekit, .webfont or any other solution. You can start using real fonts on the web right now.

Typekit makes a somewhat complicated implementation drop-dead easy, but if you’ve used sIFR before, than I’m confident you can handle this on your own.

The licensing legwork that TypeKit is doing is a significant value-add and may be worth it for people who don’t want to deal directly with font resellers. I’m quite interested in how the smart folks at Clearleft expect to differentiate their competing service, fontdeck.

Typotheque and Kernest are also new entrants to watch, both created by font shops. Both seem to only license their own foundries’ typefaces, so their library size may end up being quite small, but I can say right now Typotheque’s offering looks strong.

At the same time, we’ve had web font services already: Fontburner and Flir Premium, but they never really gained popularity, so I’m surprised people expect such a different outcome from these new players.

The EOT-Lite and .webfont proposals

The general complaint from the type community around non-EOT @font-face is that the naked font is so accessible, anyone could trivially take it off a webserver and install it on their machine. These two proposals offer a “garden fence” approach to protection; it’s still quite easy to get inside and snag the font, but it’s harder than if there were no protection at all.

.webfont, the format proposed by Tal Leming and Erik van Blokland is a great compromise solution: basically a zip file containing both an xml file of metadata and the font. While it uses the same css @font-face syntax, and everyone seems to love it, having it work in all browsers is at least three years off.

EOT-Lite, on the other hand, seems to be covered much less in roundups to date. The basic idea is that it’s the same as EOT but without the two major complaints of the format: domain binding and MTX compression. (Interesting as, the compression’s patent owner is offering to free it up.)

The huge plus of EOT-Lite is that the format works, right now, in IE4-IE8. Adobe, Monotype, Microsoft and a cadre of type shops support it. Perhaps surprising for some, Mozilla is also quite involved in the EOT-Lite discussion, not only helping to define the spec, but also making a test build of Firefox that handles the new format.

ZOT is a new format proposed by Mozilla; essentially TTF with compression. It’s well considered, but as .webfont comes with the same advantages and already has a wave of support, I think ZOT is best left as an academic discussion. Oh, and Berlow’s OpenType permissions table – which would have been a great idea to have in 2000, but not now.

Update 2009.08.10: .webfont and ZOT merged their proposals. It’s now called WebOTF.

The @font-face standard

By my calculations, the current implementation (using EOT or TTF/OTF) covers ~70% of users. When Firefox 3.0 users upgrade to 3.5 that figure will increase to ~90% of users (I bet we’ll see that within six months). Things still do visually look a little different across browser implementations, but they currently work cross-browser and with fixes like forcing Cleartype on for web fonts in Firefox, render quality is improving steadily.

/* it's this easy: */
@font-face {
  font-family: 'Gentium';
  src: url(Gentium.eot); /* EOT for IE */
}
@font-face {
  font-family: 'Gentium';
  /* IE ignores this one because of the format value */
  src: url(Gentium.ttf) format("opentype");
}
h1,h2,h3 { font-family: 'Gentium', Tahoma, sans-serif;

I generally side with the concerns of type foundries here, rather than the Fuck The Foundries crowd. I want myself and other designers to have access to the best of typography, but understand the fonts used for Firefox/Webkit are a little too naked at this point. While we’re waiting for the rest of this to pan out we may see a new market of type designers that are comfortable with naked fonts (like David Březina), but I’m skeptical about the efficacy of that.

JavaScript-based custom font solutions

We’ve had sIFR for nearly 5 years and I’m glad we have, but we now have better options. After significant research I think Cufón is the best library in this space; it’s small, clever, and very performant. However, many foundries aren’t ready to license their typefaces for use with Cufon. Facelift is a great alternative here, as it doesn’t expose the font data to the browser (instead generating PNGs via PHP), thus very licensing-friendly.

These libraries will be useful in bringing custom fonts to older browsers (currently: Firefox 3.0, Chrome, and Opera 9), but still lack flexibility when it comes to rtl languages.

It’s also possible that they won’t be treated only as a fallback solution. If  foundries remain unwilling to license for the naked @font-face implementation in Firefox and Webkit, we may have no choice but to use Cufón while we’re waiting for these browsers to adopt EOT-Lite or .webfont. In fact, Monotype’s web embedding EULA currently allows use with siFR and Cufón, as long as there is domain-binding.

Conclusions

I don’t think webfont services are the future, but I do think the landscape is hairy enough now to convince web developers to take the easy route by relying on a TypeKit or Fontdeck for their custom type. Taking advantage of the best techniques available isn’t insurmountable without a hosted webfont service, and I think we’ll see developers going it alone with their own implementations and licensing directly with the font resellers.

I believe EOT-Lite is the right direction for webfonts right now. It already works in the most stubborn browser, and since Firefox just released a test build with support for EOT-Lite, it’s looking more reasonable than ever. It’s also quite interesting that after the months of debate at the W3C surrounding Microsoft’s proposal of making EOT the standard, it took quite some time for the sensible proposal of EOT-Lite to emerge. I guess both sides had to soften a little. :)

If you have any comments or questions, please leave them below.

We’ve had a thread going internally on how we want to use Twitter as a company with @MolecularInc. We all want to open up this conversation to a broader audience and get all our good ideas together. So let me bring everyone up to speed:

Options

Some feel that one employee should own the account and can act as editor or contributed tweets. (That is, take any tweets employees wish to offer and post them).

The primary advantages of a singular editor are:

• ultimately accountable for quality
• a unified and consistent voice — not all over the place

CoTweet was offered a solution, which offers companies a unified publishing platform and (we assume) some sort of workflow option. While we don’t have access yet, a number of tweeting companies leverage it and presumably enjoy it.

A suggestion (from Bryan) is for @Molecularinc to retweet a tweet from an employee. Retweets have emerged as a de-facto standard for sharing someone else’s thoughts/links/etc. This would require employees (that wish to contribute) to have their own twitter account, of course.

Voices

Steve said, “My experience is that Twitter is a bit different than other channels in that it works best when there is a consistent human voice behind the tweets. Blogs and conferences work well with disparate voices and perspectives, but the business Twitter accounts that seem to be most effective (Zappos, Comcast, etc.) are written by one person or (in Comcast’s case) one voice that feels like one person even though it isn’t.”

Heather offered, “I understand that the ideal state of affairs for companies and brands to take advantage of the Twitter platform is to engage an audience- be it peers in the digital community, existing clients, prospective clients, or just interested parties- in a lively and active conversation.
“In doing so, the brand/company demonstrates transparency and authenticity, and as such, accepts that they have exposed themselves to some degree of risk. But, I think we’d agree that the payoff in customer trust and loyalty far exceeds it.”

Bryan said, “I second Steve that a consistent voice is an important element of organizational success with Twitter, but I also agree with Heather that the power of the Twitter platform is the potential for “lively and active conversation” – something that generally requires a diverse set of voices. ”

What are your thoughts?

Stephen Anderson (aka poetpainter) recently shared an inspiring presentation on elevating interfaces beyond the functional, reliable and usable… to the convenient, pleasurable and meaningful.

| View on slideshare

We developed a very dynamic, responsive, and adaptive UI for a health insurance plan selection tool for Humana One. The original prototype for this application was developed in Flash and our stakeholders expected the sort of responsiveness and richness that Flash delivers, except developed in ajax (with MS Ajax, specifically).

One of the more major shifts in our development came when we no longer could make use of the MS AJAX Control Toolkit widgets as designed, by writing XML and C#; instead we reverse-engineering the generated javascript so we could maintain more control over the execution inside our application. Once we had on-the-ground control over the javascript, we were able to bend it to do things we never thought were possible at the outset of this project.

We’re pleased at the results and I’d love to share with you some of details.

Overview Video:

Some more highlights of what we did in our development effort:

• Heavy use of MS Ajax as a transport layer
• All product data retrieved over WebMethod web service calls, and sent to client over JSON
• Extensive (ab)use  of MS Ajax Control Toolkit: Animation, Autocomplete, ModalPopup, HoverMenu (for tooltips), Slider
• Client-side instantiation, manipulation, and triggering of Control Toolkit controls
• Custom extended Collapsible Panel control with simultaneous x/y movement, and more callbacks.
• Browser History Management for permalinks and backbutton, using ASP.NET Futures
• Serverside JavaScript exception logging using Ajax.Logging.ExceptionManager.js
• CombineScriptsHandler to concatenate and compress the javascript files for delivery
• Coremetrics integration into all major app events
• Serious DOM manipulation and animation
• Templating engine using commented HTML to reconstruct DOM elements with XHR’d JSON data, instead of pushing all HTML in the ajax response. 7x smaller response size.
• Large performance gains using replaceHTML and setHTML
• Here’s more on our experience with UpdatePanels, ScriptMethods, delivery optimization,  a critique of documentation, support, and developer tools from our enginner Craig Andrews.  

Demo:

To test the site, visit https://www.humana-one.com/, select Lousiana on the right, hit the Plan Pointer button in the right column, and use zip code 70001.

The molecules have landed in Austin and we’re excited. Brandon also scored his first parking ticket so far, but compared to Boston, these Austin fines are a bargain!

Before the trip we used Sched.org to pick and organize the panels we wanted to see. It’s a clever ajax application that pulls in all the festival info and helps you get your agenda straight.
Here is the combined schedule of all of us. We’ll be employing divide and conquer to cover as much ground as possible.

Stay tuned…

Zecco.com is an online brokerage and investment community embracing the Web 2.0 mindset.  The company (whose name is a clever abbreviation of zero commission) first embraced one of the major tenets of the open Web — making it free! Once customer fears were assuaged that their free trades came with no catch, Zecco combined that offer with a rich interface, and they grew steadily in customers.

Often, sites will rush to adopt new interaction techniques without heavy consideration of the impact on customer experience. Zecco has made many improvements to speed and performance, but some fundamental interactions within the application can languish. The trading platform is a legacy user interface with an inconsistent visual design and many usability problems and design flaws that can make interaction frustrating at times.

For instance, when a first-time customer goes to the “Move Cash” screen to transfer funds into their account, of the eight possible controls, only one of them initiates a new transfer. (Furthermore, that singular button has now been obstructed by a recent redesign–see edge of button in right side of screenshot). The first step required of all new users is incredibly challenging.

Zecco has also implemented a rich user community featuring standard social features of friends, groups, and forums and more clever features like personal blogs, news feeds, and performance metrics. They’ve done well in balancing privacy with publicly sharing personal data. For example, customers can opt-in to share their trading data. Customers can then be ranked on performance, and others can follow their buys and sells, leading to more engaged customers.

I consider Zecco a leader of bringing practical rich interactivity to financial services online. They’ve made mistakes, but earned much customer trust by reacting quickly to suggestions and concerns. While other complementary Web 2.0 money properties like Mint, Wesabe, and Billmonk continue to innovate, Zecco has affirmed its position as the trading home for the 2008 online investor.

I’ve put together all the feeds and blogs that I follow that cover front-end development. (That’s HTML, CSS, and JavaScript!)
Here is the OPML file: front-end-development-feeds.xml.opml

All the classics like Ajaxian and A List Apart are in here.. but also more technical ninja developers like John Resig, Hedgerwow and Peter Michaux. I think there are 55 feeds in total.

If you currently use a RSS aggregator (like Bloglines, Google Reader, or Netvibes) you can import this file right in.
iGoogle won’t take an OPML file but you can do each RSS feed individiually.

You can also preview what’s in it here: http://www.bloglines.com/public/molecular-frontend-feeds

Enough buzzwords in that headline? :)

With the newly launched Google AJAX Feed API, you can now publish any RSS feed to a webpage all with client-side scripting. (Previously, server-side techniques like CaRP have been the tool of choice.) I’ll demonstrate how we implemented the AJAX Feed API to take a collection of links that our Experience Design team thought interesting, and transform them into a short truncated link list.

First, include the API javascript with the API key that was provided to you when you sign up:

<script src="http://www.google.com/jsapi?key=ABQIAAAA0lvnyAoFc4pShBfG..." type="text/javascript"></script>

Then we’re going specify what feed we’re going to publish and how many entries to show. We’re using the RSS feed from all items in del.icio.us tagged with molexd.
Then we create markup to wrap each feed item as a LI, all inside of a UL. In the end, all this new content is inserted into a div with the id=”feeds”.

<script type="text/javascript">
google.load("feeds", "1");
function initialize() {
  var feed = new google.feeds.Feed("http://del.icio.us/rss/tag/molexd");
  feed.setNumEntries(10);
  feed.load(function(result) {
    if (!result.error) {
      var container = document.getElementById("feed");
      var ul = document.createElement("ul");
      for (var i = 0; i < result.feed.entries.length; i++) {
        var entry = result.feed.entries[i];
        var li = document.createElement("li");
        var a = document.createElement("a");
        li.appendChild(a);
        a.href = entry.link;
        a.appendChild(document.createTextNode(entry.title));
        li.appendChild(document.createTextNode(entry.publishedDate.substr(5,12)));
        ul.appendChild(li);
      }
      container.appendChild(ul);
    }
  });
}
google.setOnLoadCallback(initialize);
</script></script>

This will actually make use of the feed retrieval and caching system that is managed by Google Reader and Google Blogsearch. On the client-side, it’s only making a call to Google which has previously retrieved this feed.