A bit of background before I dive in to the post… My team and I are responsible for developing and supporting the Brand web sites for Bristol-Myers Squibb.  The Brand Teams and external Marketing Agencies develop a concept for their site, and they deliver a fully functional version of the site in  HTML to us to implement.  We take that HTML, squeeze it into our custom content management system, and hook up all of our custom features.  This custom content platform that we call LaunchNet has built in registration management, site search, web analytics, SEO helpers, and a full suite of other tools. 

With an environment like this, managing expectations becomes essential.  Sites need to be streamlined for industrial-strength campaigns involving thousands of concurrent users and possibly millions of site users per month.  From this perspective, DHTML layers is one of the banes of development.  I have broken out why DHTML Layers make me lose my hair into 6 categories: Performance, Metrics and Analytics, Accessibility, Implementation, user Experience, and Search & SEO.

Performance

When using DHTML Layers, your users are now loading multiple pages combined into one, some of which they may not even view, wasting download time and bandwidth.  Pages are slower to download, and are slower to draw inside the browser.  Processing is now heavier on client side, and is heavily dependent on JavaScript, which is known to be a memory hog.

Metrics & Analytics

Layers are not pages.  This is a simple fact, but needs to be stated again for emphasis.  Layers are not pages.  This means that anything that is dependent on the construct of a page will break.  Google Analytics tags, which are designed to fire on page load, will need to be re-engineered to fire on layer loads instead of page loads. 

Accessibility

Mobile users on phones, PDAs, tablets, UMPCs, and other lightweight devices with web browsers will have difficulty.  These browsers are slimmed down versions of their bigger brothers, and do not have all the functionality needed to process JavaScript properly.  Cross Browser Compatibility is very difficult to implement and maintain with DHTML Layers.  You cannot bookmark a layer, either, so your users will not be able to come right back to where they were.  Popup blockers may block the use of DHTML layers, as this is a common delivery mechanism for advertising.  And, DHTML Layers could affect your site’s handicap accessibility.

Implementation

Layers on the site increase complexity, and make maintainability more difficult.  If JavaScript is turned off, any functionality to show or hide layers will not work, so your users will not see it.  Developers will need to spend lots of time to make DHTML JavaScript function with content management systems, particularly when custom functionality is delivered in this way.  And, if layers are big enough, scrolling can become an issue, as the layers may run off the page, hiding content from view. 

User Experience

User Experience is the biggest reason to implement DHTML Layers.  It adds slick new interface to the hum-drum of static pages.  But designers need to keep in mind that performance impacts user experience.  This is an “I want it an hour ago” generation, and waiting even 10 seconds for a page to load will mean your users have left and gone somewhere else.  Layers are a not a standard UI convention for web development, and some users may be intimidated by the change in interface.  And, some folks may perceive layers as “popups”, which is bad for perception.

Search & SEO

Implementing site search while using DHTML Layers is very difficult.  Most search products are page based, and as stated before, layers are not pages.  Your content might not get crawled, or may be crawled incorrectly.  Layers could also cause a problem with search engines.  Your page could end up not getting indexed, or not indexed properly.  Invisible content may also be viewed by search engine crawlers as “gaming the system” or a black hat SEO practice, and may negatively impact your page rank.

Conclusion

When implementing, DHTML Layers, think twice about the impact on other aspects of your site.  Ajax can do a lot of the same kinds of things that DHTML Layers can.  Adobe’s Flash and Microsoft’s new Silverlight products can also deliver great new user experiences.  All of these have benefits and drawbacks that need to be weighed before jumping in.  You may be providing a slick new experience to your users, but you may be creating more problems than it is worth.  There are lots of other alternatives to explore.

Pandia reviewed a new tool called TouchGraph Google Browser.  This tool allows you to visualize the connections between sites.  You can read the initial review on the Pandia web site, and you can check out the TouchGraph Google Browser on the TouchGraph site.  The TouchGraph team is a group of interface designers who are exploring better ways to visualize information.  In addition to the TouchGraph Google Browser, they have also developed TouchGraph Amazon Browser and the TouchGraph Facebook Browser using the same visualization technology. 

This has some really interesting implications for Search Engine Optimization, Web Analytics, and Web Site Development.  Optimizing a site to have each of its pages appear in a graph like this could have its site map generated dynamically.  Having a Web Analytics Dashboard where you could click on each of the pages, or series of pages, and view data relationships between them would be very powerful. 

Check it out and let me know what you think. 

So I attended the Google Website Optimizer webinar this Tuesday afternoon.   I did not know too much about the feature set of this particular tool, so I thought the webinar would be a good way for me to find out more. 

The class was moderated by ROI Revolution.  They are a Google Analytics Authorized Consultant and AdWords Qualified Company, and offer webinars and training classes for Google products.  You can find more information about them on their web site. 

Essentially, Google Website Optimizer is a tool designed to track results of content changes to your web site before you commit to them.  It works in a similar way to Google Analytics – you tag your pages, your content blocks, your action items, and your goal pages.  Google Website Optimizer will then randomize your content or your page to test it how you choose. 

There are 6 different types of tests that you can use:

1. A/B Testing – this is essentially a test to determine if one page layout is more effective than another
2. Multivariate – this tests if different content blocks (copy blocks, headers, images, etc.) are more effective than others
3. Split Path – this will test if content changes will affect the navigation through your site
4. Multipage Multivariate – this test will measure if content changes on one page will affect navigation on other pages, and if there are any other cross-page interactions that change
5. Linger – this test is good for sites that have no clear conversion, and will measure time on the page instead of number of conversions
6. Anything – an open ended type of test, particularly if your site has multiple conversion points

There was also a brief demo on how you can intertwine Google Website Optimizer, Google Analytics, and Google AdWords to measure how changes in your page affect your AdWords advertising campaigns.

Did anyone else attend the session?  Has anyone used Google Website Optimizer?  Is this a tool that you would think is useful?