For those of you unaware, I work (as a student, sadly) in the Web Services Dept. of the University of St. Francis. It’s a nice job, really.

Alas, we’re a small school, and still pretty stupid about some things. A laundry list of all of them (even those limited to the technological) would be beyond the scope of this post. One thing in which we’re stupid is our website, which is sprawling (the faculty tend to use the web server for storage instead of their network drive) and not database driven. We’re moving to a portal system in January ’06 (tentative), but we’ll still have a lot of the current site.

Therein lies one of my biggest problems: instead of pulling content dynamically and running it through some CSS, we’re still using crufty, hardcoded pages and the horrible, byzantine templating system of Dreamweaver.

Until summer of 2004, we were on a template created entirely by Adobe GoLive. Why anyone was ever allowed to use such a miserable program is completely beyond me: it filled the code with GoLive “actions”: in other words, proprietary markup similar to what Microsoft does with its created HTML files.

But I’m not going to talk about the template per se, because I have yet to tinker with that. I am, however, going to talk about the home page, which in many respects is far more important.

In 2002 (and up until 2004), we had a homepage that looked like this [copy stored on Archive.org]. The buttons weren’t distorted when we had it live, but that’s the basic look. In 2003, we updated the menu slightly. Take a look at the source, and you’ll see hundreds of lines like this:

The page itself isn’t that large: about 133KB without rollover images. Still, it obviously needed to go, as did the rest of the template. So, in early 2004, the Web Services Department began an extensive redesign effort. It was spearheaded by my boss, Mike, and had to go through committee after committee (since the website constitutes our online image) and revision after revision. I was a new guy at that point, so the actual design work was handled by my former coworker, Ryan. He was an excellent graphic artist, but his approach to the technical aspects of web design? Eh, not so good.

His method involved creating a screen-sized picture in Photoshop and then cutting it up in ImageReady. Then he further edited it in Dreamweaver, creating editable regions and places for text. To see his version of the homepage, click for the current USF homepage [stfrancis.edu] which still uses this system or an archived copy [Archive.org] from November of 2004. There have been no substative changes between then and now.

For starters, try looking at the background image alone. The first thing you’ll notice is that the background image is the homepage. The second thing you’ll notice is that it’s 203.51KB. That’s a lot for a 56K user (we do have them).

Secondly, look at the menu system. It’s ugly, inconsistent, and under the hood, completely inadequate. For starts, it’s hardcoded into every page (this same menu persists on all pages), which means that it needs to be reloaded every time. Secondly, it works by showing and hiding individual layers.

function MM_showHideLayers(){//v3.0var i,p,v,obj,args=MM_showHideLayers.arguments;for(i=0; i<(args.length-2); i+=3)if((obj=MM_findObj(args[i]!=null){ v=args[i+2];if(obj.style){ obj=obj.style; v=(v=='show')?'visible':(v='hide')?'hidden':v;}
obj.visibility=v;}var timerID ="global";function hideMenus(){// insert the MM_showHideLayers function you create that // hides all popout layers. Be sure you put a semi-colon// at the end of the code. Here is an example:// MM_showHideLayers('menu1', '', 'hide', 'menu2', '', 'hide');
MM_showHideLayers('AboutUSF','','hide','Academics','','hide','Athletics','','hide','Prospective','','hide','StudentLife','','hide','Calendar','','hide')}function startTimer(){
stopTimer();// the number "1000" is the number of
thousands-of-a-second
timerID = setTimeout("hideMenus()",100);}function stopTimer(){
clearTimeout(timerID);}

That’s a single rollover image in the menu that calls a layer to be shown. Byzantine, right? The total size for this incarnation of the homepage to be loaded is almost half a MB (420KB without rollovers). For any users on a slow connection, that means, basically, no access. Anyone who waits that long for a University web page to load is an idiot. Also notice the number of nested tables used in the layout (it’s worse on the content pages). Dreamweaver’s templates don’t play well with tables, so this means a lot of screw-ups when we do a template update.

You’ve probably gathered by now that none of the code that the University has used so far has been anything close to standards-compliant. As you can see from the links in my meta section, I’m all about standards compliance, so this bugs me to no end.

Last week, after my boss complained about how difficult it is to make any sort of changes to the homepage (he wants the white news section expanded), I offered to recode it. I can’t make any substantial changes to the look, of course, since that would require more committee meanings and long delays. I can, however, redo the guts.

Because of the way the University web server serves up CSS files (wrong MIME type: we’re in the process of fixing it), my testing version can’t currently be viewed on that server. However, I have hosted it on mine, so you may view my tentative design now.

The first thing you’ll notice is a redesigned header. It uses our new officially approved logo, but within a 100% div, so it stretches regardless of screen size. Same with the thinner brown bar below. One of my goals was to scale the design better. Mike says that we’re only going to officially support resolutions of 1024 x 786, so my end design scrolls a bit on lower, but is still functional.

The second thing you’ll notice is the redesigned menu. Not only does it blend better with the header, but it’s consistent in its look, is simpler (in a sense) by not simply showing and hiding div layers. Also, and more importantly, it’s all housed in 3 called data files, only one of which needs editing. This makes updating the menu sitewide a matter of seconds. The off/hover colors are not finalized, depending on what input we get. The menu is cross-browser (I’ve tested on Safari 1.x, IE 5.x, Netscape 7.x, IE 6.x, Firefox 1.0.x, and Opera 8.x).

Thirdly, the new design makes extensive use of CSS. The old one, to its credit, did use a CSS file, but only for setting a sitewide default font and <h1>. I expanded it later to stylize table elements and floating images. Still, this one uses CSS for everything, and will use it even more heavily for content pages.

One of the tricks I used CSS for was eliminating image rollovers. On the current layout, you’ll notice that the five central buttons (Faculty, Current Students, Alumni, &c.) have a rollover which turns them from a sepia tone to their actual RGB values. I dislike image rollovers in general (images are largely crufty), so I instead used an opacity effect to turn them from 75% opaque to 100% opaque on a hover. It was tricky, because IE 6 doesn’t support the addition of :hover to any elements besides anchors. Here’s my CSS:

#buttonset is the floating div that houses the buttons in my version. Unfortunately, this opacity effects invalidates the standards compliance for CSS. If anyone knows a way around this, let me know. Also, Opera doesn’t show the hover effect, but since it is an infinitesimal portion of our user base, we’ll allow it. Otherwise, all tested browsers work with it.

Finally, we have the pesky news section. On the original site, the yellow news bar is graphically separate from the news section. I could have emulated this, but I thought it was better combined in a single element. I simply nested a block displayed div instead the larger news section and floated the whole thing. Something I had to grapple with after the face was getting all these different divs to clear each other; also, getting both IE and good browsers to handle the code in substantially similar ways. I really need to get my hands on a beta of IE7 and doublecheck that.

The total size for the loaded homepage is about 165KB. This is larger than I’d like, but I had to work within certain boundaries to ensure that the new design was visually compatible with the old one. I also console myself with the fact that since the menu system is separate from the page, and it persists throughout the site (as will several other key graphics), any decent browser will cache it and continue to use it during further perusal. Since the menu makes up 32KB of the load, this is significant.

Most importantly, though (to me), is the link you see at the bottom of my version that says “Valid XHTML.” Yes, it validates, even if the CSS doesn’t. I decided upon XHTML 1.0 Transitional because my boss likes to use the target="_blank" attribute a lot, and this was the only way for it to validate as such.

So, there you have it: my recent travails in the world of (semi-)corporate web design. Stay tuned, and I’ll eventually be able to write at length about redesigning the rest of the content pages, as well as all of the (enormous) headaches that such a thing entails.

For those of my readers with m4d h4xx0rz 5k1llz, any improvements or advice would be appreciated.

7 Comments to “Out with the crufty, in with the new”

The only hovering difference I notice between Opera (8.5) and Firefox (1.0.7) is that the five images below the menu flicker once in FF but not in Opera. Oh, and that the thin grey border/background of the sub-menus is completely opaque in Opera, whereas in FF it’s slightly transparent; surely you’re not talking about that though?

With regards to the incompatibility in Opera, I mean that Opera doesn’t display the 5 buttons as only 75% opaque in their normal state. Instead, it displays them as 100% opaque both normally and on a hover.

Can you not kludge Opera-compatible opacity by using a partially transparent 24-bit PNG as the background of the menu? I use this simple script to get the alpha channels in PNGs working correctly with IE, since it’s the easiest method I’ve seen. Opera doesn’t support any CSS-based form of transparency, that’s for sure; it probably will soon, since it’s a CSS3 property.

Personally, I don’t really like the slide-out menu; I prefer instantaneous ones (like Suckerfish), since they just feel snappier. Each to their own, though; yours is certainly functional, although not if the user has Javascript turned off – that might be a consideration. If you’re keen on using Javascript, it might be worth creating text-based navigation in the markup and then hiding it via the DOM, so that the drop-down navigation appears only when the user has Javascript enabled.

The markup still seems rather more crufty than it needs to be, though; whilst it’s a vast, vast improvement over the old one, you seem to suffer from (like most converts to CSS-based design) “divitis”. There are quite a few superfluous divs where simply giving the element within a class/id would suffice; as well, you seem to be using divs when there’s a more appropriate element for the same task – such as using one for the header as opposed to a level-one heading with some form of image-replacement – this is also better for SEO :) I’ve had a quick go at trimming down the markup and making it a bit more semantic; you can see the results here.

I used this particular dropdown menu because I’ve used it extensively in the past, and the fact that it’s called from a single file is nice. I’ve generally never liked list-based menu systems, even though I know that DHTML can be a crufty nightmare in and off itself. Should further browser updates or whatnot make this menu system untenable, I might consider a list. As it is, however, everyone here likes the TwinHelix menu, so I more or less have to use it.

Also at this point, I’m not sure my boss wants me to bother using further scripts and extra graphics just to get an unimportant hover effect in a browser we don’t (officially) support. If and when Opera implements CSS opacity, I can make whatever adjustments are necessary to extend support to it. Until then, it’s more trouble than it’s worth.

The level 1 header and the buttonset list is something I think I’ll implement, however, as it does seem cleaner. The only problem with the buttonset list is that at 800×600 (which, again, we don’t officially support anymore), the final list element is transposed over the news box instead of pushing it down.

1. We don’t have PHP enabled on the server. Remember what I said about being dumb?

2. I installed a code entity plugin (the one you linked to), so you don’t have to write in character codes as long as they’re in <code> tags.

3. No, not really, but it’s a side benefit if it works. See, my boss isn’t really up-to-date on the popular browsers. He wouldn’t know Gecko from KHTML from Trident. So, he still probably labours under the delusion that IE 5.2 is the predominant browser on the Mac. Whatever. Supporting it isn’t all that much different from supporting IE6.