Project rundown: Museum of Design – Atlanta
FletcherMartin just launched a new web site for the Museum of Design – Atlanta (MODA). I did all of the front-end web development except for the store (design by Brad Sarmiento). I installed and configured WordPress to manage the Exhibits and News sections of the web site. I also managed the transition between our development server and the client’s web host.
This project marks my deepest foray into JavaScript. I even incorporated a framework. Despite some minor browser-specific glitches, I’m proud of it.
Assumptions and issues
We assumed that MODA’s core web audience would be designers and edgy creatives — people who would be likely to visit with a 1024-by-768 or higher monitor resolution. Yet we did not want to mar the experience for those visiting with a lower-resolution monitor.
But whoa! We have a problem. In order for the sliding effect to work best, I had to use absolute positioning for everything. Changing the width of the outermost containing elements would throw off the whole page. How to solve? JavaScript.
Choosing a JavaScript library
Now as cool as this site is, I can’t take credit for most of the JavaScript / DOM Script code — at least not the wicked cool sliding bits. For that, I incorporated the Moo.fx library (and Mootools framework). Why?
- It’s fairly lightweight. The framework + scrolling effect is only 14KB
- It provided precisely what I needed to meet the goal
- The Clientside wiki documentation explained what I needed to know.
Given our original deadline, I needed quick-and-dirty-ish. Moo.fx met my needs.
Style sheets and DOM scripting
Most of the styles are the same for both versions of the site. Those styles are in one “global” style sheet file that all users receive. Resolution-specific styles are split into four different style sheets:
- s1000.css for 1024 or more pixel resolutions.
- s1000.ie.css which contains IE-specific hacks and styles for 1024+ pixel-wide resolutions.
- s800.css for resolutions that are less than 1024 pixels wide.
- s800.ie.css which contains IE-specific hacks for lower resolutions.
I used a smidgen of JavaScript to detect the visitor’s screen width. Then I used that value to determine which style sheets to serve to the client. I developed two DOM scripting functions — setStyle() and setStyleIE() — that will replace the s1000.css and s1000.ie.css files with s800.css and s800.ie.css if the visitor’s screen width is less than 1024 pixels.
Best practices versus what works best
While developing this site, I ran into another issue. Web development best practices suggest separating content from presentation and behavior. DOM Scripting best practices further suggest putting your external files and/or functions at the end of your document.
But in the practical world, doing so does not always provide the best user experience. For example, when I originally developed the automatic style sheet switching feature, the setStyle() and setStyleIE() functions fired when the page finished loading. The result: visitors would experience a screen flicker as s1000.css was replaced with s800.css and the browser re-rendered the page.
My solution was to commingle DOMScripting functions and HTML code so that each function would be fired as the page loaded and the affected elements were added to the node tree. Ugly from a code perspective, yes. But pretty from a user-experience point of view. The function definitions, however, live in external files and are linked to the HTML page in the header and footer of the file.
Navigation
The navigation may be the slickest part of this project. A few functions are at work here: moveToRightSpot(), doScroll(), and a series of scrollTosection functions (scrollToAbout, etc.).
When the page loads, we check to see whether there is a document fragment identifier at the end of the URL. If not, we change the location bar to http://www.museumofdesign.org/#welcome.
Each subsequent click on a navigation link updates the location bar with a new fragment identifier and triggers the appropriate scrollTo function. The scrollTo functions in turn invoke the doScroll() function, which uses the Moo.fx scrolling library.
Also, by updating the location bar, we’re adding that fragment to the browser’s history. If we leave index.php — most of the content exists in one file — using the back button will trigger the appropriate scrollTo function and return us to our last section.
If I could do it over?
I’d use more semantic HTML. I used some empty elements that could have — and should have — been all CSS. I also wish I had more time to tweak the CSS and JavaScript. I almost always see a better way to code something once I have enough time to review it.