Well, now that the site has been up a bit and we’ve updated some of the ‘incorrect’ content left over from the old presence, I’ve been able to go in and optimize some of the code. I know this isn’t the best way to work (get the site live, then go back a fix things), however not creating the code myself from scratch has presented some problems. I’m cleaning up some of the cumbersome code and optimizing redundant code, etc. Following is a detailed description of my goals as I clean up the site:

1. Unobtrusive Javascript

   First of all, you may be wondering what exactly is ‘unobtrusive javascript’. Well, it’s just what it says. Javascript code (for any laymen) is code that is executed by the browser. It’s a tighter version of Java that was developed to be utilized in the world wide web. Effects such as fades, rollovers, sliding menus, etc. are all implemented with Javascript. In the past it has received a bit of a bad reputation because designers would use javascript for ‘cool’ effects rather than ‘necessary’ effects. Just because you can slide a <div> element in from off of the page, doesn’t mean it is exactly user-friendly. That’s what we mean by ‘unobtrusive’. Javascript should be used to enhance the user experience, not overcomplicate it. It’s what we call ‘design etiquette’.

   Fortunately, we haven’t had much of a problem with obtrusive javascript calls. We did, however, have many inline calls that seemed to overburden the code. For example, one of the popup scrips that we use on the site is the Dreamweaver MM_openBrWindow function. If you’ve used Dreamweaver in the past, you know that this is called from an onclick event of an anchor tag. The code below shows an example call to this function:

   <a href="example.html" onclick="MM_openBrWindow('example.html', 'popup', 'toolbar=yes, location=yes, status=yes, menubar=yes, scrollbars=yes, resizable=yes, width=400, height=300')">example link</a>

   This isn’t such a huge problem until you have 30 or 40 links on a page with a popup action attached to each of them. This presents a very bloated document and is not great coding practice.

   Solution:

   I’ve implemented a DOM manipulation script to remove this redundant code. Now, the only markup within the document is a function and a class attribute for each of the anchor tags. The resulting code is much more readable and light:
   
<a href="example.html" class="popup">example link</a>

   Now, as the page is loaded into the browser, the javascript function locates all anchor tags with the class=”popup” attribute, then applies a ‘click’ event that will trigger the MM_openBrWindow function. We still maintain the popup window functionality, but also keep the code optimized at the same time. Of course, this functionality is dependent on the browser being able to execute the code. What if the user has javascript disabled on their browser? You can’t just ask the user to ‘enable javascript’. That would be intrusive. Next we discuss a couple of what I call buzzwords in the web design community, progressive enhancement and graceful degradation. These techniques help to explain how we handle instances where javascript may not be available on the user’s browser.

2. Progressive Enhancement

   In the old days (maybe 3-4 months ago), designers would start with a sliced up image from Photoshop or Fireworks and then export that into Dreamweaver (or other web authoring software). They would then make sure all cool menu drop downs, image rollovers, and expanding <div> elements were added from the ‘Behaviors’ palette. Most designers never even looked at the generated code that was inserted as they clicked through the WYSIWYG interface. They didn’t care. Macromedia (now Adobe) surely wouldn’t have allowed the code to become bloated and cumbersome. So, designers just left the page as it was. If a particular browser didn’t support a specific feature, the designer could insert another behavior, or just let the user miss out on the content.

   Now, designers are much more in tune with the user. We now know that we have to respect that some users do not have the brand new Mozilla based browser, 1900 dpi resolution, and greatest plug-ins. This brings us into the discussion of ‘progressive enhancement’. You see, the more widely accepted approach to web design is to start with the content, then structure the content into headings/paragraphs/lists etc. After the content is structured, then the page design comes into play. Images are added, formatting is implemented with CSS, and the look and feel of the page is completed. After that, interaction is implemented with the use of javascript, ajax, etc. This approach to design gives the designer a much needed advantage to the process.

   For example, let’s say you have a page like we do with glossary terms. You’d like the user to be able to click on the term and have a small window with the definition pop up on top of the current page. You would first design the page to work without the pop up (clicking on the term would open a different page in the browser in place of the current page). You would then add a javascript call to the link that would instead open the pop up window and not the full page. Users with javascript enabled would get the popup and users without javascript would get the regular page. Both users would still be able to access you content. The ‘Bells and Whistles’ however would be available to those that have support for javascript. This is the notion of progressive enhancement. Instead of designing for the high-end user and degrading the site to work with less supported browsers, now you design for the basic browser and ‘progressively enhance’ the site for users with more support.

3. Graceful Degradation

   Graceful degradation is taken care of if you’ve successfully designed a site for progressive enhancement. What this means is that a user without javascript support, will still see an aesthetically pleasing and easy-to-navigate site. They will not be restricted from any content because of the lack of support for their browser. However, this also applies to other types of browser support such as Java, Flash, CSS, etc. You must test your users’ browser features before you try to show content based on a specific feature. This will allow you to accommodate as wide an audience as possible and ultimately increase your user base.

Comments (0)

Posted in development

 Email This Post