** If this text is too small, use your browser's View > Text-size menu to enlarge it! **
** Or, hold down the Control-Key and roll the scroll wheel on your mouse and watch what happens! **
(This is part of what we gain from this design change!)
Coming Soon...
-- Notes from Feb. 13, 2008
The basic design of the VADA/Nova website has not changed in many years. The organization of the site seems to have worked pretty well in getting information to our members. There are, however, some aspects of the internal design of the site that complicate maintenance and interact badly with some newer browsers. For a number of reasons, the time has come to move the site closer to current standards and practices.
I don't want to change the kind of information we offer here or the way that you get around the site, but changing the underlying technology means that some details of the site appearance have to change and offer the opportunity to freshen up a bit. At the very least, I need to work the 25th Anniversary Logo into the header, and that demands a bit of thought. (But do keep in mind I am not an artist).
This page discusses the current state of our site, some of the history and a bit of foreshadowing of the future. Part of this is to enlighten, part is so I can remember and part so that some poor future volunteer webmaster will know.
Origins
The original design of the site came from SiteDesignz and probably dates from around 2002 or 2003. The contents passed hands a couple times before reaching me. What I received was a tar file of the contents of the web server directories as of December, 2005. That didn't include templates, design notes, blanks for menu items or the like, so there has been a bit of a discovery process about where these pages came from and how they were built.
To understand what comes next, we need a bit of a diversion. My background includes graduate work in operating systems, programming language design, software engineering and compilers. This kind of background does not make an artist.
I spent the late 80's as a Member of Technical Staff (MTS) at Bell Labs working for Dave Korn in a department that did “technology transfer”. I worked on tools for software analysis. One basic lesson learned there is that it isn't enough to have a great new technology: it has to fit the total context and it has to offer a real gain or it won't be a winner.
Although I've been using computer networks one way or another since at least 1976 (programming Russian lessons on the PLATO system), I didn't start messing with Internet applications until the early 90's when I was at CNRI. One of the first things I did there was hack the Handle Protocol into the Mosaic Browser . I learned most of what I originally knew about web servers and site design while I was developing the merchant-side credit card processing code for Cybercash. I retired from that job to go “play with my horses” at the end of 1999, one year before Cybercash went bankrupt.
The only reason I even mention this personal history is because it does affect how I approach the maintenance of this site and its design. I am an engineer, not an artist or designer. I like clean, documented code. I like to keep up with standards, but I'm more interested in getting a workable, maintainable result than I am in technical purity or staying on the “bleeding edge”. When I have a problem to solve I tend to focus on what I need to know to solve it and don't detour a lot.
The Learning Curve
Now, back to the website I inherited. When I worked at Cybercash there weren't a whole lot of tools for developing web content. I worked on a UNIX workstation, wrote web pages using the vi editor (plain text, baby) and wrote hand templated CGIs in Perl, C++ and Java. Compared to the tools used to develop the pages I inherited, I was used to working with stone-axes and chisels.
On the other hand, when you work with stone-axes and chisels, there is a huge incentive to keep it simple and clean. Too much filigree and you'll lop off a thumb. These pages (Dec. 2005 to now: Feb. 2008) are complex. They use a lot of HTML <table> based layout and ad hoc style changes. Working with Dreamweaver 8 , I know that some of that is just what the tool encourages and generates, and some is a reflection of when the original pages were written. It does make it harder to look at the page code and really understand what is going on.
Templates
The first challenge was dealing with page templates. Page templates can be a wonderful thing. They let you keep a consistent look and feel across all the pages you develop and actually can save a lot of writing. In the package I started with there were no actual templates, just the pages generated from them. In a page generated from a template, all of the parts that come from the template are locked. Dreamweaver will not allow those parts to be edited. That is fine when you are happy with what is in the locked part, but less charming when it really needs to change.
I didn't know where the templates came from (being new to this idea of using actual design tools) and did what came naturally and edited those bits in Wordpad. Sub-optimal, but tolerable.
Lovely, Tabbed Menus
The bigger issue was managing the lovely tabbed menus at the top of the page (if you don't remember what those look like, go look). Each tab is a gif file with the lovely glossy, shaded shape and tab label. First note that there is no editable text here. It is a little picture that can only be edited pixel by pixel in something like Adobe Photoshop or Corel Photo-Paint. Second, each tab is actually represented by four gif images. See how it changes color when you point to it or click on it? That is because the browser instantly swaps images when those things happen.
Now, what happened when someone asked me to add a new tab to the menu? Uh-oh... there weren't any blank tabs in the stuff I received, so that was a real problem.
The second issue with the menus is not obvious on the surface. The menus are implemented in Javascript. When you move your cursor over a tab or click on it, a little program gets executed that changes the tab's appearance (swap the gif) and may take you to another page. This means that every time the menus have to change in any way, it involves editing code. And this particular code is extremely dense and completely undocumented. Moreover, the “business end” of this code is linked into the pages from a directory far, far away and when pages change it is very easy to forget that this code has also got to be tweaked.
The third issue with the menus is that nowadays people are getting justifiably paranoid about running little programs from foreign sources just because they are in a web page they'd like to look at. Internet Explorer 7 will ask permission each and every time you land on such a page, and when you tell it “go ahead”, it will ask “are you really, really sure"? And given the mischief a little piece of code can get up to, I can't really complain too much about this. But it does get a bit old by the third or fourth time you execute this little dance.
Again, I didn't know where these lovely, tabbed menus came from, and there certainly wasn't anything in the code or packaged with the site to help me find out.
Let's be clear here: the <table> based layout design and the Javascript menus were very common at the time the original pages were developed and pretty much state-of-the-art. There wasn't much else you could do to generate pages that could be seen by the vast majority of potential readers.
If I knew Then What I Know Now...
Over time playing with Dreamweaver 8, I've learned how to get more out of it. One of the first things I figured out was how to pull the Javascript into Dreamweaver, which at least improves the view.
Templates
Eventually I learned that the original templates were generated by an earlier version of Dreamweaver, which had left finger-prints. My Dreamweaver can extract template code from a page that originally came from a template, but the templates from older versions of Dreamweaver aren't completely compatible with the new version, so once again our old friend Wordpad got a workout. At this point I have a complete set of templates and the courage to use them.
Cascading Style Sheets (CSS)
When I left Cybercash, the Cascading Style Sheets (CSS) Standard was on the horizon, but no browsers supported that standard well enough that you wanted to bet the farm on it. Page layout was done using tables and frames and you got control of fonts, text size and style by coding those things directly into the HTML. These are all practices that are now denigrated (see particularly the Guidelines for Authoring Section).
The website I was given in 2005 had some limited use of CSS, had one CSS style sheet used to set a basic palette of styles for paragraphs, fonts, headers and a few other items of the kind. Dreamweaver 8 dumps ad hoc style definitions in a file header whenever you change the font or size of anything in the text you are editing.
The result was somewhat scattershot and never seemed to work very well. I use Firefox as my browser. For some reason the pages always displayed in a sans-serif font on any Internet Explorer browser, but stubbornly remained Times New Roman (a serif font) on Firefox.
Managing this website has a certain rhythm. During the show season (March to November), there are prizelists to amend, ride times to post and results coming in from the shows and so there is a constant stream of pages to edit, post and tear down. In the winter the site gets reworked with the new calendar and new information from the Green Book (the membership guide). The calendar this year (2008) is particularly loaded and the sheer number of events (about 12 in June alone) mean that the calendar is getting hard to read. I started poking at the CSS to see if I could use it to improve this situation. As I learned more about it, I got increasingly curious about what role CSS was playing in the site I had.
Well, around New Year's 2008 I finally decided to batten down the hatches and try to chase some of the HTML bugs out of the code and get to the bottom of the presentation inconsistencies. So I went hunting through the CSS code with a CSS manual on my lap. The font definition statements in the base style sheet looked something like this:
font-family: "Verdana, Arial, Times New Roman, sans-serif";
I hadn't looked at these too closely. This was stuff that had been “working” for years.
The manual said no quotes except where the font name is multiple words, so I rewrote these:
font-family: Verdana, Arial, "Times New Roman", sans-serif;
and the ground moved: suddenly everything I saw on Firefox was different. This is how it is supposed to work, but seeing it happen was still a shock. If you use Firefox and visited the site about then, you probably know what I mean. You see, IE ignores these little syntactical differences but Firefox just throws it all out if it isn't happy (“gotta have standards!”).
I'm still planning to get at the Calendar display problem, but in looking for a solution to that I found a CSS solution to the Tabbed Menu Monster and I found the origin of those tabs. You can't pull on a thread without unraveling the whole sweater.
Lovely, Tabbed Menus
In my explorations of CSS for solving the Calendar dilemma I came across a number of CSS implementations of pull-down menu bars. One common technique is called Suckerfish Menus, and yes... go ahead, Google that term and you will find about 200,000 references including the wonderful "Son of Suckerfish Dropdowns" article. I can't begin to make this stuff up.
This technique puts all of the menu items in plain HTML where you can see it and edit it pretty directly. There is a little bit of code involved to deal with some idiosyncrasies of Internet Explorer 6, but it isn't something that needs editing just because you changed a link or two. Now I was sold.
This isn't the sort of change that can be made in a day and it isn't something that you can get right without a lot of tweaking, testing and tools. So I built a little test bed, acquired a shiny new toy (Westciv Style Master 4.6: a CSS editor) and went to work.
The lovely tabs of the current menu were not going to be easy to use in this technology (trust me), so I went on the hunt for more rectangular menu buttons with a similar look: kind of metallic and the oh, so important purple . You can spend an entire day hunting through clip art collections at home and on the web and still not find something suitable. After a day of fruitless searching for a ready made button, I decided to just do it myself. In a fit of madness I decided to use Macromedia Flash to do it. It came with Dreamweaver. I hadn't played with it much, but something I ran across made me think it might be THE ONE.
Surprise number one: about 15 minutes of fiddling and I had a rectangle that looked an awful lot like one of our tabs. Surprise number two: it wanted to generate a set of 3 or 4 of these, just like the ones used for our lovely tabs. Surprise number three: you follow it down that particular garden path and it spits out a bunch of HTML and Javascript that is essentially identical to what has been running on our site for the past 5 or more years. At this point there is no defense against the paternity suit. We had found the father of our lovely, tabbed menus.
It turns out that it is difficult to get these kind of pictorial elements integrated into a Suckerfish Menu (I love saying that), so you won't be seeing that here any time soon. You will be seeing the Javascript go away and increasing use of CSS to manage page layout and style.
The basic look of the pages will change with the technology. That is unavoidable. The kind of information here and the ability to access it should only get better as a result. And it will be a lot easier to manage.
Stay tuned.
-- Feb. 13, 2008
The Continuing Adventure
I had originally thought that I would blog my progress with the site redesign on this page, but inserting progress notes here tends to mess up the narrative flow, so I will begin a new page with discoveries and progress reports.