Overview

This document contains normative guidelines for web applications built by the Interface Development practice of Isobar North America (previously Molecular). It is to be readily available to anyone who wishes to check the iterative progress of our best practices. If you have any feedback, please leave a comment on the announcement blog post.

Code Standards

This document outlines our de-facto code standards. The primary motivation is two- fold: 1) code consistency and 2) best practices. By maintaining consistency in coding styles and conventions, we can ease the burden of legacy code maintenance, and mitigate risk of breakage in the future. By adhering to best practices, we ensure optimized page loading, performance and maintainable code.

Pillars of Front-end Development

  1. Separation of presentation, content, and behavior.
  2. Markup should be well-formed, semantically correct and generally valid.
  3. Javascript should progressively enhance the experience

General Practices

Indentation

For all code languages, we require indentation to be done via soft tabs (using the space character). Hitting Tab in your text editor shall be equivalent to four spaces.

Readability vs Compression

We prefer readability over file-size savings when it comes to maintaining existing files. Plenty of whitespace is encouraged, along with ASCII art, where appropriate. There is no need for any developer to purposefully compress HTML or CSS, nor obfuscate JavaScript.

We will use server-side processes in place that automatically compress and gzip all static client-side files, such as CSS and JavaScript.

Markup

HTML5

HTML5 is a new version of HTML and XHTML. The HTML5 draft specification defines a single language that can be written in HTML and XML. It attempts to solve issues found in previous iterations of HTML and addresses the needs of Web Applications, an area previously not adequately covered by HTML. (source)

Developer are encouraged to use parts of HTML5 when appropriate, while ensuring older browsers are handled fairly.

We will test our markup against the W3C validator, to ensure that the markup is well formed. 100% valid code is not a goal, but validation certainly helps to write more maintainable sites as well as debugging code. Isobar does not guarantee code is 100% valid, but instead assures the cross-browser experience is fairly consistent.

Doctype

A nice aspect of HTML5 is that it streamlines the amount of code that is required. Meaningless attributes have been dropped, and the DOCTYPE declaration has been simplified significantly. Additionally, there is no need to use CDATA to escape inline JavaScript, formerly a requirement to meet XML strictness in XHTML.

HTML5 Doctype
XHTML 1.0 Transitional Doctype

Template

The following code snippet can be used as a template for authoring new HTML5 documents. This is the HTML from Isobar's Starting Template

Starting Template

Read the comments and code for the Starting HTML & CSS Template on the wiki. Many standards will be found there.

HTML 4.0 Strict DOCTYPE
HTML 5 DOCTYPE:
  • All markup should be delivered as UTF-8, as its the most friendly for internationalization. It should be designated in both the HTTP header and the head of the document.
Setting the character set using <meta> tags. In HTML5, just do:
  • Make use of DL (definition lists) and BLOCKQUOTE, when appropriate.
  • Items in list form should always be housed in a UL, OL, or DL, never a set of DIVs or Ps.
  • Use label fields to label each form field, the for attribute should associate itself with the input field, so users can click the labels. cursor:pointer; on the label is wise, as well. note 1 note 2
  • Do not use the size attribute on your input fields. The size attribute is relative to the font-size of the text inside the input. Instead use css width.
  • Place an html comment on some closing div tags to indicate what element you're closing. It will help when there is lots of nesting and indentation.
  • Tables shouldn't be used for page layout (duh), but can save you time, like in the case of form layout.
  • Use microformats where appropriate, specifically hCard and adr.
  • Make use of THEAD, TBODY, and TH tags (and Scope attribute) when appropriate.
Table markup with proper syntax (THEAD,TBODY,TH [scope])
  • Always use title-case for headers and titles. Do not use all caps or all lowercase titles in markup, instead apply the CSS property text-transform:uppercase/lowercase.

CSS


3D CSS Box Model diagram by Jon Hicks.

Inline Styles

We strive to maintain proper separation of content and design, and therefore highly discourage the use of inline style="..." attributes. This not only makes maintenance a nightmare, but inextricably ties the presentation to the data it represents.

Note: An exception to this rule is style="display:none" for revealing hidden elements via JavaScript.

CSS Validation

It's likely not a wise use of time to validate your CSS with the W3C validator, though it may identify a few problems.

CSS Formatting

Some developers prefer css properties on their own line. Others prefer putting them next to eachother and doing one rule per line. Both are good approaches; at the outset of development, the project team should decide which they want to do.

Pixels vs. Ems

We use the px unit of measurement to define font size, because it offers absolute control over text. We realize that using the em unit for font sizing used to be popular, to accommodate for Internet Explorer 6 not resizing pixel based text. However, all major browsers (including IE7 and IE8) now support text resizing of pixel units and/or full-page zooming. Since IE6 is largely considered deprecated, pixels sizing is preferred. Additionally, unit-less line-height is preferred because it does not inherit a percentage value of its parent element, but instead is based on a multiplier of the font-size.

Correct
Incorrect

Internet Explorer Bugs

Inevitably, when all other browsers appear to be working correctly, any and all versions of Internet Explorer will introduce a few nonsensical bugs, delaying time to deployment. While we encourage troubleshooting and building code that will work in all browsers without special modifications, sometimes it is necessary to use conditional if IE comments for CSS hooks we can use in our stylesheets. Read more on paulirish.com

Fixing IE

Shorthand

In general, CSS shorthand is preferred because of its terseness, and the ability to later go back and add in values that are already present, such as the case with margin and padding. Developers should be aware of the TRBL acronym, denoting the order in which the sides of an element are defined, in a clock-wise manner: Top, Right, Bottom, Left. If bottom is undefined, it inherits its value from top. Likewise, if left is undefined, it inherits its value from right. If only the top value is defined, all sides inherit from that one declaration.

For more on reducing stylesheet code redundancy, and using CSS shorthand in general:


General coding principles
  • Add css through external files, minimizing the # of files, if possible. It should always be in the HEAD of the document.
  • Use the LINK tag to include, never the @import.
Including a stylesheet
Don't use inline styling
  • Don't include styles inline in the document, either in a style tag or on the elements. It's harder to track down style rules.
  • Use a reset css file (like Eric Meyers reset) to zero our cross-browser weirdness.
  • Use a font-normalization file like YUI fonts.css
  • Elements that occur only once inside a document should use IDs, otherwise, use classes.
  • Understand cascading and selector specificity so you can write very terse and effective code.
  • Write selectors that are optimized for speed. Aka, where possible, avoid expensive css selectors. Avoid the * wildcard selector. Don't qualify ID selectors (e.g. div#myid) or class selectors (e.g. table.results) unless its neccessary for readability or for efficiency. More on writing efficient css on the MDC.
Reasonable use of qualifying class selectors
Multiple classes and IE6.
IE6 will ignore the earlier class rule and treat that rule like:

Images

  • For repeating images, use something larger than 1x1 pixels
  • You should never be using spacer images.
  • Use CSS sprites generously. They make hover states easy, improve page load time, and reduce carbon dioxide emissions.
  • Typically, all images should be sliced with a transparent background (PNG8). All should be cropped tightly to the image boundaries.
    • However, the logo should always have a background matte and have padding before the crop. (so other people can hotlink to the file)

JavaScript

We primarily develop new applications in jQuery, though we have expertise in plain JavaScript as well as all major modern javascript libraries.


General coding principles
  • 99% of code should be housed in external javascript files. They should be included at the END of the BODY tag for maximum page performance.
  • Don't rely on the user-agent string if you don't have to. Do proper feature detection. (More at Dive Into HTML5: Detection & jQuery.support docs)
  • Don't use document.write().
All Boolean variables should start with "is". Test for positive conditions
  • Name variables and functions logically: For example, popUpWindowForAd rather than myWindow.
  • Documentation should follow NaturalDocs structure.
  • Large blocks of code should be separated by flowerbox comments to indicate chapters of the file.
  • Constants or configuration variables (like animation durations, etc.) should be at the top of the file.
  • Strive to create functions which can be generalized, take parameters, and return values. This allows for substantial code reuse and, when combined with includes or external scripts, can reduce the overhead when scripts need to change.
    • For example, instead of hard coding a pop-window with window size, options, and url, consider creating a function which takes size, url, and options as variables.
  • Comment your code! It helps reduce time spent troubleshooting JavaScript functions.
  • Don't waste your time with <!-- --> comments surrounding your inline javascript, unless you care about Netscape 4. :)
  • Surround your inline javascript with <![CDATA[ ]]> if you're working in XHTML.
  • It's preferred to have code organized in an Object Literal/Singleton, the Module Pattern, or Objects with constructors, where possible.
  • Minimize global variables.
    When specifying any global variable, clearly identify it

White-space

In general, the use of whitespace should follow longstanding English reading conventions. Such that, there will be one space after each comma and colon (and semi-colon where applicable), but no spaces immediately inside the right and left sides of parenthesis. In short, we advocate readability within reason. Additionally, braces should always appear on the same line as their preceding argument.

Consider the following examples of a JavaScript for-loop...

Correct
Incorrect
Also incorrect

Variables, ID & Class

All JavaScript variables shall be written in either completely lowercase letter or camelCase. All id and class declarations in CSS shall be written in only lowercase. Neither dashes nor underscores shall be used.

Event Delegation

When assigning unobtrusive event listeners, it is typically acceptable to assign the event listener directly to the element(s) which will trigger some resulting action. However, occasionally there may be multiple elements which match the criteria for which you are checking, and attaching event listeners to each one might negatively impact performance. In such cases you should use event delegation instead.

jQuery's delegate() is preferred over live() for performance reasons.

Debugging

Even with the best of validators, inevitably browser quirks will cause issues. There are several invaluable tools which will help to refine code integrity and loading speed. It is important that you have all of these tools available to you, despite the browser you primarily use for development. We recommend developing for Firefox and Safari first, then Google Chrome and Opera, with additional tweaks via conditional comments just for Internet Explorer. The following is a list of helpful debuggers and speed analyzers...

Accessibility

Section 508 Standards for intranet and internet information and applications. Interfaces developed by Isobar should meet Section 508 standards. W3C checklist of checkpoints for accessibility. Interfaces developed by Isobar should meet Priority 1 guidelines. The WCAG 1.0 Guidelines.

Performance

Optimize Delivery of CSS and JavaScript

There are many optimizations that should be done for serving css and javascript in Production:

  • Follow the Yahoo Performance Guidelines
  • Smush images using smush.it. Also using YSlow can autosmush all your images for you.
  • Set caching headers appropriately.
  • Consider a cookie-less subdomain for static assets
  • Avoid inline <script> blocks.
  • CSS should be located in the <head> of the document, Javascript should be right before the </body> tag.
  • Both CSS and JavaScript should be served minified. Most people use the YUI Compressor for this.
  • Both should be served using gzip on the wire
  • CSS should be concatenated together. Obviously this can only be done for files that share the same media type (e.g. screen or print). The general goal here is to reduce the number of HTTP connections to dependencies during the loading of the page.
  • JavaScript should be concatenated. While a ajax script dependency manager would be ideal (similar to the YUI 3 Loader), it's rather complicated to implement. In its place I'd recommend a singular download of most of the script used on the site. (Of course, proper caching should be used to retain the file as long as is reasonable)
  • Concatenation and minification typically occur during an automated build process, when packaging the code for deployment on stage or production. Many use tools like Ant or Maven for this
  • Avoid inline <script> blocks within the HTML. They block rendering and are quite devastating to page load time.

Optimize JavaScript execution

During a page load, there is typically a lot of script waiting to execute, but you can prioritize it. This order prioritizes based on user response:

  1. Script that changes the visible nature of the page needs to fire absolutely first. This includes any font adjustment, box layout, or IE6 pngfixes.
  2. Page content initialization
  3. Page header, topnav and footer initialization
  4. Attaching event handlers
  5. Omniture, Doubleclick, and other 3rd party scripts

Leverage CSS Sprites

CSS Sprites basically take a number of image assets and merge them together into a singular image file. Each part of it is revealed using CSS background-position. Some typical CSS would look like: It's quite common to leverage sprites for :hover states. In that case you'll see something like:

Using sprites reduces total page weight and reduces HTTP connections which speeds up page load. More on the general technique and overview at css-tricks.com Many developers use a vertically-oriented sprite in addition to the primary sprite. This vertical sprite will be <=100px wide (and tall) and contain icons that are typically placed next to text, such as list item bullets. Yahoo uses a few such as this one. The one consideration is to not make sprites too large, something over 1000px in either direction will end up using a sizeable amount of memory. More detail about sprites and memory usage here.

Image formats

There are four main image formats that should be used, detailed here:

  1. JPEG. This will cover all photography-based images, such as homepage and category page promo images, or anything with a very high color count.

  2. PNG24. This format, easily accessible in Photoshop, outputs high-color count imagery and fully supports graded opacity by pixel. Relatively, it's quite a heavy format as far as kilobyte weight. It is the only format that IE6 needs to execute a pngfix on. In that case, Isobar recommends the DD_belatedPNG script (A pngfix fixes the issue where PNG24's appear to have a grey or light-blue background in IE6. They are not always compatible with background-position.)

    In many cases, you can use a GIF fallback for IE6, in place of a PNG24. This is especially true if any sprites need to be done in PNG24. All pngfixes are very slow and expensive, so it's best to avoid using them.

  3. PNG8.

    A surprising diversity of color can be captured inside 256 colors, so it's worth trying PNG before heading JPG. PNG also is a lot more compressible than GIF (using tools like pngcrush and pngquant). This format allows graded opacity in nearly all browsers, but in IE6, those semi-opaque pixels are just shown 100% transparent. In many cases this is sufficient. It also does not require a pngfix script to be run, so it's optimized for speed.

    Photoshop cannot output these semi-opaque files correctly but Fireworks can. More detail here: http://www.sitepoint.com/blogs/2007/09/18/png8-the-clear-winner/

  4. Transparent GIF 89a. GIF 89a offers the flexibility of transparency and wide browser support, but the constraints of no graded opacity nor a color depth above 256. In our experience, color depths of 64 still provide very good quality thumbnails, and keep the file size comparably very small.

    All low-color count imagery such as icons or thematic graphics should be done in PNG8, as it's the most size-efficient of these four. PNG8 is our primary recommendation for most site graphics.

For further optimization all of these formats, taking them through Yahoo's Smush.It will reveal how they can be smaller.

Caching

For static content, the browser should cache the file locally as long as is reasonable. Content that should have far future caching includes:

  • CSS and JavaScript
  • product images
  • thematic graphics
  • favicon.ico
  • flash .swf's
  • promo images (lighter caching likely)

For the best caching, leverage the Expires http header. This is a far future Expires header, telling the browser that this response won't be stale until April 15, 2015.

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

If your server is Apache, use the ExpiresDefault directive to set an expiration date relative to the current date. This example of the ExpiresDefault directive sets the Expires date 1 year out from the time of the request.

      ExpiresDefault "access plus 1 year"

Expires http header should be set to a value between one month from present to a year (far future) from present. Caching only applies to that exact URL, so a change in the filename of any asset will start a fresh copy. Many developers use a build process to add a version number or timestamp to their assets. Each subsequent build will start a brand new cached version, allowing you to use far future cache dates without worry. Google has a lot more detail on browser caching

Shard resources across domains

Static content should certainly be served from a domain different than the one that serves HTML. This is optimal so that there are no extra cookies headers on all static content requests. It's also much easier to write caching rules for the entire domain. (Also any subdomains of the current domain will inherit domain cookies, so it's worth using a completely new domain)

However with enough assets (especially images) the number of requests grows enough to slow down the load of the page. Many browsers have a low constraint of how many assets they will download simultaneously per domain. (In IE6 and 7, it's only two) In this case, we can serve the assets from multiple subdomains such as:

  • static1.otherdomain.com
  • static2.otherdomain.com
  • static3.otherdomain.com

More information on domain sharding on Google Speed

Avoid IFRAMEs

Iframes are the most costly element to add to a given page. They block the page from firing the onload event until they are complete. Sometimes they are useful to let another agency handle tracking scripts. For example the Doubleclick floodlight tag is an iframe, and the admin can add tracking pixels into it from their dashboard. In any case where an iframe is added, it should be appended to the DOM dynamically after window onload has fired. More detail at Yahoo's Performance site.

3rd Party Integration

Omniture

We recommend to add the Omniture JavaScript code to the DOM using JavaScript after the page has loaded (either a DOM ready event or window's load event). Using this technique, there is no external domain script dependency, which can slow down (and potentially hang) a page load.

Isobar has a jQuery Omniture plugin that incorporates this and other techniques; we'd love to share if needed.

Flash

Backup HTML content should be in place of the flash in all cases to maximize SEO value. For XML-driven flash, the backup HTML content should be leveraging the exact same XML file, to ensure data consistency.

All replacements should be done using SWFObject but without inline script tags. SWFObject initialization should fire after the DOM Ready event. Minimum player version should be set to minimum v9, to ensure AS3 compatibility.

Search Engine Optimization

Be aware of SEO best practices

Indexability

We must use semantic markup that's readable and logical when JavaScript and css are off. All page content must be in HTML; we don't want to use iframes or JavaScript for loading initial indexable content. All links should be to HTML destinations. For example: 

<a href="/shelf/jordan/page/2">
instead of 
<a href="javascript:loadPage(2);">

This lets the page get indexed correctly by search engines as well as allows users to open in new tabs and windows.

Optimization

The title tag should feature target keywords for the unique page. The titles should be unique to each page. Headings (h1,h2,etc) should form an outline of the document and represent the most important keywords for that page. URLs should be human-readable with primary target keywords present in them:

http://domain.com/mens-shoes/basketball/jordan/jordan-mens-ajf-6-basketball-shoe/
vs 
http:// domain.com/ecomm.cfm?view=prod&prodId=23425

Flash and Image Replacement

Always use backup HTML content for flash. All promo images should use CSS-based image replacement instead of alt tags. For example:

SEO Audit Tool

Isobar and iProspect have been kind enough to provide us access to one of their internal tools for SEO evaluation. 

Its output should only be used during internal analysis, but not handed over directly to a client. 

First, you create a new client. Each client bucket has no restrictions on the URLs, it's just a means of organization. Image:2009-08-28 1113.png

After creating the client, you'll want to click in and create a new website audit (or resubmit an existing one) Image:2009-08-28 1114.png

When creating a new audit:
  • Website and homepage url fields will normally match. That's fine.
  • Site map url is the HTML sitemap page. (not the xml sitemap)
  • Webpage URLs are four or five URLs you'd like to be examined more than the rest (primary landing pages, for instance)
  • The Other domains field is optional

After the audit is finished generating, there are three reports available with somewhat overlapping material. The contribution ratings are a general (and potentially outdated) idea of the importance of each aspect.

If you have any questions, contact Ben Leblanc (Isobar)

Google's SEO Report Card

Google's SEO Report Card is an effort to provide Google's product teams with ideas on how they can improve their products' pages using simple and accepted optimizations. These optimizations are intended to not only help search engines understand the content of their pages better, but also to improve their our users' experience when visiting their sites. Simple steps such as fixing 404s and broken links, simplifying URL choice, and providing easier-to-understand titles and snippets for their pages can benefit both users and search engines.

Code Reviews

What is a code review?

A code review is the cornerstone of the formal process for ensuring the quality of user experiences developed by the iDev team. This involves a meeting among authors of markup, reviewers and other stakeholders, with expected input and subsequent code revisions.

Why should I have a code review?

Code reviews are a strategic investment of time to mitigate risk on a project.

Oftentimes, interface developers are asked to author markup from wire frames or visual compositions. However, its possible that screens that are designed cannot be translated to markup easily, or without compromising quality. Code reviews provide an opportunity for this risk to be addressed and resolved before full production of pages begins.

Code reviews increase the overall level of knowledge across projects

Since code reviews involve members from within and outside a project team, techniques and best practices are easily shared throughout the entire iDev team.

Code reviews eliminate bugs before they are reproduced from a few templates into multiple pages

Ideally, code reviews are conducted early in the development process, before full production of pages begins. When templates are reviewed by the team and run through multiple validation tools and browsers, bugs can and will appear. This is the ideal time for bugs to be fixed.

Code reviews give a set of fresh eyes an opportunity to spot issues with code

Reviewers from outside a project team can spot issues with code more easily than authors of markup, who have been working with code for a longer amount of time.

Who should participate in a code review?

Ultimately, the iDev Lead on a project is required to ensure that proper code review procedures are followed.

Ideally, a practice lead should act as facilitator for a code review session, unless the practice lead is also the interface developer whose code is under review. In this situation, a project manager can be brought in as a facilitator.

The review team should include at least two senior members of the Interface Technology team versed in development and best practices.

What is required for a code review?

Before a code review is conducted, templates to be reviewed must be fully developed, validated, and tested against the browsers and platforms required by the project.

A practice lead and/or interface developer must distribute the following 48 hours prior to the date of the code review:

  • Code for all pages, associated server-side includes, CSS, and JavaScripts. These should be fully commented, printed out with line numbers along the left side, and the file/page name in the footer of each printed page.
  • Screenshots of each template
  • URLs of the templates, if applicable
  • A list of browsers and platforms supported by the project
  • A list of known issues/areas of concern

It is typical for code to be changed constantly until the code review is to take place. Unfortunately, this does not leave enough time for validation and testing. If this is the case, it is recommended that the code review be rescheduled to a date that ensures a proper code review.

In addition, a practice lead and/or interface developer should book a conference room and call-in number for all attendees, since it is possible that members of either the project or code review team are off-site. An hour should provide enough time for review of two or three templates; however, time will vary depending on the volume and complexity of the templates.

During the code review, a practice lead and/or interface developer should facilitate the meeting, while the practice lead or project manager takes notes and assigns action items. Reviewers should have reviewed the code and come prepared to ask questions or provide feedback.

Notes and action items (including owners) should be distributed to all attendees after the code review. If substantial changes come out of a code review, or all code is not reviewed, it may be necessary to schedule a second code review. However, this should be discussed amongst the project team to determine feasibility.

Browser Testing and Support

What we support

Isobar supports any browser with an A-Grade in Yahoo's Graded Browser Support, with the exception of Opera. There may be exceptions to this, given regional markets and their particular metrics.

We will strive to support any other mission critical browsers mandated by the client (IE 5.5, Opera, Konqueror, Safari 3 on PC, etc), though we cannot guarantee all functionality is possible.

How we test

IE Testing Firefox Safari Opera

Bugs in standalone versions

Note: The IE6 standalone has a buggy implementation of opacity in some cases. This will result in any opacity applied with a CSS filter, like alpha opacity or a 24-bit PNG, to fail. In the case that opacity must be tested, you will need a native IE6 installation.

It has been noticed that IE 7 using the Vista platform does have differences from IE 7 on Windows XP, therefore, you might want to make sure that someone on your team has this configuration as well. IETester is known to fix a number of these issues, as do the Xenocode browsers.

Browsertesting network machine

We also have a machine on the network with three VMs and a number of different browser versions.
  • Windows 2000: IE5, Firefox 1.5, AOL 9.0
  • Windows XP: IE6, Firefox 1.5, AOL 9.0
  • Windows Vista: IE7, Firefox 2, AOL 9.1

All details for logging in are on fusion

External Links

Browser Resolution

1024px resolution
  • Fold estimated at 570px.
  • Optimal width: 960px - Has comfortable padding on both sides, is divisible by many numbers, and also plays well with IAB ad standard widths
  • Larger width: 970px - Still has some padding on both sides in most browsers. The math plays well with the Golden Ratio
  • Maximum width: 996px - Without incurring any horizontal scrollbars in the major browsers. Based on the research here the maximum is 1003 px wide if you don't want a horizontal scrollbar.
Current stats on window sizes System resolution is not, however, the same as browser size

Cross-Browser Performance Strategy

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?

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 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, we 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.

Mobile

A copy of Cameron Moll's Mobile Web Design, which covers a lot of the best practices of both design and development.

Also: Building iPhone Apps with HTML, CSS, and JavaScript by Jonathan Stark.

Appendices

Appendix A: Validators

Appendix B: Tools

Code Editors

Aptana
Aptana Studio is a powerful, free and open source Ajax development environment which runs stand-alone or within Eclipse. Aptana Studio offers tooling for Ajax including HTML, CSS, DOM, and JavaScript editing and debugging, plus support via additional free plugins for PHP, Ruby on Rails, Adobe AIR, Apple iPhone development. It also features full SVN repository integration for committing, branching, tagging, merging and repository browsing. Aptana
Geany
Geany is a text editor using the GTK2 toolkit with basic features of an integrated development environment. It was developed to provide a small and fast IDE, which has only a few dependencies from other packages. It supports many filetypes and has some nice features. Geany
Notepad ++
Notepad++ is a free (free as in "free speech", but also as in "free beer") source code editor and Notepad replacement, which supports several programming languages, running under the MS Windows environment. Notepad ++
e TextEditor
E is a new text editor for Windows, with powerful editing features and quite a few unique abilities. It makes manipulating text fast and easy, and lets you focus on your writing by automating all the manual work. You can extend it in any language, and by supporting TextMate bundles, it allows you to tap into a huge and active community. e TextEditor
Edit Plus
EditPlus is a text editor, HTML editor and programmers editor for Windows. While it can serve as a good Notepad replacement, it also offers many powerful features for Web page authors and programmers. EditPlus
Homesite
HomeSite 5.5 provides a lean, code-only editor for web development. Advanced coding features enable you to instantly create and modify HTML, CFML, JSP, and XHTML tags, while enhanced productivity tools allow you to validate, reuse, navigate, and format code more easily. Configure Macromedia HomeSite to fit your needs by extending its functionality and customizing the interface. Homesite

Firefox Plugins

FireFTP
FireFTP is a free, secure, cross-platform FTP client for Mozilla Firefox which provides easy and intuitive access to FTP servers. FireFTP
Firebug
Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page. Firebug
Greasemonkey
Allows you to customize the way a webpage displays using small bits of JavaScript. GreaseMonkey
Web Developer Toolbar
Adds a menu and a toolbar with various web developer tools. Web Developer Toolbar
JSView
Adds an item in the status bar that displays all external JavaScript and CSS files loaded on a given page. Allows you to click on and view the files and things like their URLs. Great way to pull file URLs to put into Charles for remote debugging. JSView
Live HTTP headers
When running, captures all HTTP traffic from the browser, which enables you to see what files are being requested as well as information about the requests and server responses. Live HTTP Headers
Quick Locale Switcher
A tremendous help when doing internationalization, Quick Locale Switcher allows you to change the locale sent along in the browser's user-agent HTTP header, telling servers to display content for you in other locales.
Screengrab
Screengrab sits in the Firefox status bar, allowing you to capture and copy or save screen shots of everything from selections of a web page to the entire page, even parts displayed "below the fold." Screengrab
Total Validator
Enables one-click access to sending your page through a markup validator. No better way to quickly check for missing or mismatched tags! Also available as a standalone application. Total Validator

Charles Proxy

Charles watches all requests and can tell you a lot of information about them. Also supremely useful is Map Local which lets you use a local file in place of a given URL (good for replacing a minified js with a full one). License info located on our wiki

Firefox Plugin Repository

These plugins and more are available in single install in the Isobar iDev Plugin Repository. Versions are available for Firefox 3.5 and Firefox 3.6.

The repository is a single .xpi and includes:

  • Charles Autoconfiguration - Plugin allowing Charles to proxy Firefox traffic
  • CLEO and FEBE - Make your own extension packages!
  • ColorZilla color picker
  • Firebug
  • Firecookie - Cookie manager for Firebug.
  • Firefinder for Firebug - CSS selector / XPath query engine
  • Firefocus - Tracks which HTMLElements have focus in Firebug. Note: because this plugin impacts performance, it is recommended that you disable it until you really need it!
  • FireFTP
  • Image Zoom
  • JSView (Firefox 3.5 only)
  • Live HTTP Headers
  • MeasureIt screen ruler
  • Quick Locale Switcher
  • Screengrab
  • SenSEO - basic keyword analyzer
  • Total Validator
  • Web Developer
  • YSlow

IE Plugins

CompanionJS, DebugBar, IE8 Dev tools

IE Developer Toolbar:

The Microsoft Internet Explorer Developer Toolbar provides a variety of tools for quickly creating, understanding, and troubleshooting Web pages. IE Developer Toolbar

Tutorials & Tools:

Icons

Appendix C: Resources

Revision History

Authors: Paul Irish, Nick Cooley, Adam McIntyre, Rob Larsen, Joel Oliviera, Ben Menoza and Nathan Smith.

Table of Contents