Site reorganization

A few words about the work I'm doing for the reorganization.

We're in the process of evaluating the Web site's usability. I already have some improvements in mind that I hope will help the site's navigability significantly. The main problem, as I see it, is the abstraction of our content from its subject matter. Most of what's on the site is presented individually with little connection to it's subject matter. I want to be change that.

There are two items on which we're working in the meantime. One, a document detailing how to use the AAAS search to find content. Two, site- and page-level surveys to find out why people are visiting the site and if they are finding the content they are seeking. The decision to prioritize these items was made by the Web Oversight Committee. The survey is pretty self-explanatory, but based on past experience I do not think we'll get the level of participation needed to guide us. The search help, on the other hand, is more in response to user complaints. While our content is not easily navigable, the new AAAS search is more than capable of helping a user find useful information. Our near-term goal while we work on making or content more navigable is to try and direct people to the search. While I'd rather address the site's shortcomings directly, this will likely prove to be at least somewhat helpful in the meantime.

In preparation for the more fundamental changes to the Web site's structure and navigation I've spent the last four days moving files (and ensuring that no links were broken in the process). I've eliminated some of the directories and consolidated a lot of the files into fewer locations. One of the problems with the current structure is that files are not grouped logically. I've tried to remove extraneous structure that didn't provide any additional value. There's still some more work to do in this area, but the updates should be smaller and more related to navigational modifications.

In regards to these structural changes, I've come to at least one conclusion ... Dreamweaver should not be used to manage a large site consisting of thousands of files. The process has been painful with regular program crashes, connectivity losses (even after changing to file sharing from FTP), and long delays as DW tries to determine what links are affected by a file move. I don't think it would have been a problem if I was working with a few files here and there, but we're talking thousands of files. I probably should have moved the files in small groups ... for some reason thoughts like that always come to me too late to be of use.

I've seen posts from Macromedia personnel stating that for large sites a server-oriented solution would be better than using DW for templating and file management. Unfortunately I'd have to agree.

It'd probably be a good idea to look into using more includes and such to simplify the link cache, but this has problems of its own. I'll have to consider what options we have as I work on restructuring the site over the next few months.

(I guess I should mention that changing to a file share for the remote site does improve the transfer process considerably. DW still has occassional connectivity problems, however, when a large number of files are being moved.)

Trials and Tribulations ...

... with SSI development resolved.

Whew, nothing like a little back-of-the-envelope note-taking to help solve a problem. On the way home on Friday I was thinking more about the issues I had been experiencing in trying to get the suvey code to work regardless of whether the use accesses HTML- or ASP-based pages. I came up with a pretty good solution. It's a little bit of hackery, but we take what we can get sometimes.

Now in addition to the #exec SSI directive for HTML-based pages I have added some ASP code which executes the survey script in the case of the user accessing an ASP-based page. A liberal dose of commenting helps ensure that the browser doesn't display any of the underlying code and mess things up. Here's what's in the menu include file:

<!--#exec cgi="/includes/surveypage.asp"-->
<!--
<%Server.Execute("/includes/surveypage.asp")%>
<!-- -->

The ASP file also needed a minor modificaiton, I added an open/close comment block at the top of the output. A little more detail ...

In the case of HTML-based pages we need to use the #exec SSI directive to execute the survey script. In the case of ASP-based pages the #exec is worthless and so we add an ASP block that uses the Server.Execute statement to execute the survey script. On an HTML-based page the ASP code is sent to the browser and shows up as regular text. The comment tags surrounding the code ensuring that the browser does not display it.

On ASP-based pages, the #exec is sent to the browser as-is and treated as a comment block. The ASP code executes and displays the survey. I included the comment tags at the top of the ASP output so that the initial comment block is closed. This ensures that the survey is not contained inside a comment block (which would defeat the purpose of all this hackery). The extra comment open tag on the inlude file ensures that the closing comment tag at the end of the code block isn't orphaned when a user accesses an ASP-based page. An orphaned closing comment tag would be interpreted as regular text by the browser. Since you can put just about anything inside a comment tag the extra opening tags don't break the code.

One note, before just trying a good ol' ASP delimeters I had tried the <script runat="server"> </script> method of running the ASP. This doesn't work very well. The output is placed at the very bottom of the document and not inline where the script tags are located. I'm not sure if this is due to a combination of factors affecting this particular usage or because it's the default output method for script tags. Either way it's something to keep in mind for future development.

Trials and Tribulations ...

... with SSI development (related to my previous post on cross-browser development).

Same project, different problem. I've pretty much completed development of the survey itself, but found myself with another problem in return. The form is included on a page by way of a #exec SSI command. This for a couple of reasons:

1. I need to be able to limit the pages on which the suvey loads;
2. I need to be able to prevent someone who has taken the survey from taking it again

Naturally I needed to use a little scripting to accomplish the above goals. Since I have SSI enabled on the site I figured an SSI #exec would be the easiest way of accomplishing my goal. The other way would be to use a combination of an externally referenced javascript and server-side scripting (namely ASP) to dynamically set up the form display. Well, it's nice not to use client-side scripting when not necessary so I went with the SSI.

The setup is like this: Pages on the site #include the left-side menu where the survey is placed. This menu does a #exec with a script that writes out the survey (gotta love nested SSI). The problem is with pages that are ASP-based. Since ASP does not support #exec the survey script is not run and therefor the survey not loaded. The main problem with this situation is that the supporting structure does not load, which then breaks the script that controls the left-side menu, causing the to not display correctly.

<rant> The AAAS template uses a horrible structural setup and complicated javascript, making fixing problems like this a real pain. Some day I'll get around to developing a better template using CSS and the DOM. </rant>

Anyway, one way around the problem is to place the supporting structural markup around the #exec. The survey still won't load correctly on ASP pages, but at least the menu isn't broken. I think it may be the best (and maybe only) option at this point. I don't forsee needing to have the survey appear on any ASP pages, but you never know so I'd like to find a way to get it working if I can. Additionally, there are all kinds of CSS quirks I have to deal with on top of the other problems.

Mass Mailing

The March/April 2005 issue of 2061 Connections was sent out Friday 15 April, 2005, at 5:20 PM EST to 3620 recipients.

Trials and Tribulations ...

... in cross-browser development.

Working on a form for a per-page survey (was this easy to find, yadda yadda) to compliment a general site survey. One of the (many) problems with the current AAAS site template is that it caters to older browsers such as Navigator 4.x. A truly outdated browser and difficult to develop for on the best of days (especially when compared to the beauty of CSS, JS, and DOM development on Mozilla). So the site uses tables nested in tables something like six layers deep for the main content and navigation. Then the secondary navigation is repositioned using JS. What fun!

So I felt it would be nice to have the survey show up in the left-hand column under the navigation. A fairly obvious location. The problem is that Nav4 doesn't like forms in positioned DIVs. Putting a form inside a positioned DIV pretty much breaks the Nav4 DOM. Not a pretty sight.

Anyway, to get around it I just decided to use a little bit of hackery known as the browser check. I hate to do it because it's a crutch for bad coding, but I was really left with no other choice. Honest! Anyway, I whipped up a quick regular expression to test the browser string against. It's not pretty, but it gets the job done:

Mozilla/4.\d\d? \[..\]

This one required a little more fudging since IE uses the old mozilla compatibility string (thank you Microsoft). Spent about a day trying to figure out a way to get things working for Nav4, but in the end there's not much you can do. If there's a match the form won't be shown, but I don't feel too bad because our Nav4 userbase is miniscule.

JavaScript and Anchors

I've been doing a lot of reading on JavaScript relating to various scripts on which I've been working. One thing that's come up that's interesting, annoying, and problematic all at once relates to HTML element IDs and page anchors (named anchors).

Interesting
According to the the W3C spec an element ID should also act as a page anchor. (Note: this is based on a small amount of reasearch so my interpretation may be flawed.) This is a very nice feature of the spec that fits in well with my show/hide script. Based on limited testing it appears that modern browsers support this.

Annoying
Older browser do not support this feature. This means that for legacy browsers (such as Netscape Navigator 4.x) I also have to provide the named anchor. This isn't really a problem, but it would've been nice to be able to just use the element ID.

Problematic
While IE may support this feature it does something related that's a bit annoying. It provides the reverse functionality: every named anchor on a page also receives a matching ID. I'm not sure if this is something that's addressed in the spec. This feature is annoying because it interferes with the scheme I was using for the show/hide JS.

I was hoping to modify the show/hide JS so that implementation would be less involved. Esentially the changes I've made would require only that the show/hide content be contained within a DIV that has a class of "shContent". (Note: I have yet to hammer out how to handle show/hide image cues.) The IE effect requires a little more care during implementation because the backup anchor tag has to be within the DIV or else the wrong element will be on the receiving end of the show/hide and the script will not work correctly.

In addition to this minor annoyance, I'm not sure how this affects IEs DOM. IE (and other browsers for that matter) appear to function just fine even with duplicate IDs in a document, but it seems like that's something that should cause an exception. This is likely something that could cause problems down the road.


Update 2005-04-27:
I just glanced through the W3C spec and it appears that IE interprets things correctly, ::gasp:: who knew!

Basically, the ID attribute and the name attribute (when applied to an anchor tag) inhabit the same name space. Since the ID attribute must be unique, you can't have a named anchor that matches another element's ID. Additionally, anchors must not match when a case-insensitive comparison is made (another thing I hadn't ever considered).

Though things are functional at present it looks like I'll need to work on making my code a little more kosher with respect to the spec.