Done. Done. Done! I had pretty much finished all of the stuff I wanted to do with the design weeks ago. I've mostly been waiting on the content from Communications. Well, chock up another item to a last minute deadline. CCMS was being highlighted at a conference and they wanted to site redesign published prior to that date. A few items had to be knocked off the menus, but otherwise the site is finally complete.
There were a few pages I was working on myself regarding the functionality of the site. Those were fairly minor, though, and I was able to hammer them out when the site was going live. I still need to work on the site search (now that I think about it). Though I don't think it's a high priority it's still something we need to do (especially if we'll be moving more of our sites to open-source platforms). I've been distracted by the AAAS redesign, so hopefully I can get on that particular item next week.
After getting everything worked out and spending some time editing the site rather than designing it I think I'd like to make some changes to some of the navigation. The image-based navigation is too much trouble to maintain since we're not using any round-trip method of editing such as Dreamweaver/Fireworks or GoLive/ImageReady. When I get a chance I think I'll investigate using only text for the navigation again. I gave up that idea after having to deal with the designer, but now that we've completed the initial development I should be able to make that kind of change to the site and support that kind of change with consideration of the time required to make navigational modificiation.
Plus now that the designer is done with the project I won't have to bend to the wishes of someone who has no idea about the limitations of HTML.
Friday, May 28, 2004
Atlas Workshops
Almost forgot about this one. Spent the better part of two weeks getting the site ready for the addition of information and applications regarding the new scholarships being offered. Created a new form mailer so that I don't have to spend all my time creating scripts to handle any forms that we use on our site. I'm sure I'll still be spending a good amount of time on these, but at least now I can quickly create forms that require nothing more than that the information be passed along to a staff member.
The form can be fairly simple and only requires a few fields for the mailer to operate on it. However, the mailer is also capable of more complex tasks such as data validation. A number of hidden fields must be included for each form object that needs the validation, so a little more effort is required to create the form in this respect. But the payoff in processing time should be great. I hope I'll get an opportunity to use it often. A brief overview of the required and optional fields and what they do.
In order to use this script the submitting form must contain the following elements:
Hidden Field: ctrl_bolValidated (0)
Hidden Field: ctrl_bolProcess (1)
Hidden Field: ctrl_strRecipient (email address)
Hidden Field: ctrl_strSubject (text)
The form can be designed without any modifications to the structure of the form. However, user form fields also require the following information hidden form fields to enable processing:
ctrl_fieldname_userfield (1)
ctrl_fieldname_type (1=string,2=number)
ctrl_fieldname_required (1=yes,0=no)
ctrl_fieldname_format (only for string values, currently available: NUL=no format,EML=email address)
ctrl_fieldname_friendlyname (text, displayed if something is wrong with the field)
Optional fields to aid in processing the data and to provide a success message and confirmation email:
Hidden Field: ctrl_strSuccessMsg (text)
Hidden Field: ctrl_strSuccessLink (URL)
Hidden Field: ctrl_strOrdered (list of field names, these will be listed in order specified in the e-mail, all others will be listed in order provided by the Request object)
Hidden Field: ctrl_bolConfirm (1, Send an e-mail confirmation to the user)
Hidden Field: ctrl_strConfirmSubject (text, subject of the email confirmation)
Hidden Field: ctrl_strConfirmBody (text, contents of the email confirmation)
For any other field on the form, the "ctrl_" prefix will prevent those fields from showing up in the results e-mail.
The form can be fairly simple and only requires a few fields for the mailer to operate on it. However, the mailer is also capable of more complex tasks such as data validation. A number of hidden fields must be included for each form object that needs the validation, so a little more effort is required to create the form in this respect. But the payoff in processing time should be great. I hope I'll get an opportunity to use it often. A brief overview of the required and optional fields and what they do.
In order to use this script the submitting form must contain the following elements:
Hidden Field: ctrl_bolValidated (0)
Hidden Field: ctrl_bolProcess (1)
Hidden Field: ctrl_strRecipient (email address)
Hidden Field: ctrl_strSubject (text)
The form can be designed without any modifications to the structure of the form. However, user form fields also require the following information hidden form fields to enable processing:
ctrl_fieldname_userfield (1)
ctrl_fieldname_type (1=string,2=number)
ctrl_fieldname_required (1=yes,0=no)
ctrl_fieldname_format (only for string values, currently available: NUL=no format,EML=email address)
ctrl_fieldname_friendlyname (text, displayed if something is wrong with the field)
Optional fields to aid in processing the data and to provide a success message and confirmation email:
Hidden Field: ctrl_strSuccessMsg (text)
Hidden Field: ctrl_strSuccessLink (URL)
Hidden Field: ctrl_strOrdered (list of field names, these will be listed in order specified in the e-mail, all others will be listed in order provided by the Request object)
Hidden Field: ctrl_bolConfirm (1, Send an e-mail confirmation to the user)
Hidden Field: ctrl_strConfirmSubject (text, subject of the email confirmation)
Hidden Field: ctrl_strConfirmBody (text, contents of the email confirmation)
For any other field on the form, the "ctrl_" prefix will prevent those fields from showing up in the results e-mail.
AAAS Redesign
This one's a doozy. I like the look of the new design well enough, but I absolutely hate the actual coding. I just don't understand why someone would design a web site using nested tables these days (up to 6 or 7 levels deep in some places). I could have looked past a single table setting up the columns and such … maybe even two-level tables. But this thing is just horribly designed. And as if the structure weren't bad enough, the code itself is ugly and, in more than one case, invalid. I've done my best to go through and clean up the code as best as I could. Some code couldn't be touched without f'ing up the layout, but I think I've done a decent job of getting things prettied up and well-formed (considering the limitations).
I hate the methods being used by AAAS to formulate a template as well. The method they use to make it so people can't destroy the layout are ugly at best. The choice of what to place in include files and how to group things just seems completely random. I've created a pretty decent include structure that I'm going to try and pass along to Kelly to see if she'll replace the currently crappy template files. I think it would go a long way towards making the site easier to maintain.
If I have time I'm going to try and make a more CSS-oriented design. I've already shown what I can do with the CCMS site. If I can create a cleaner template using mostly CSS I think I may be able to convince Kelly the benefits of such a system. Of course, I don't know if she or anybody has time to reimplement the template in such a manner. I believe the whole reason things ended up this way is because deadlines seem to be more important than quality work … which I guess is true just about anywhere.
On the plus side the CSS file pretty much uses only classes and identifiers. No more p styles or h1 styles making my life that much harder. There was a single td style that was giving me problems, but I was able to eliminate that with hardly any problems. I'll have a lot more flexibility in setting up the styles for our site, which is great because they have once again specified an incredibly tiny font size for the content areas. The downside to their usage of CSS, though, is pretty big. They're using javascript to write out the CSS link because they wanted to use different stylesheets depending on the browser. This despite the fact that the stylesheets were amazingly similar. I was able to overcome the problem by using the !imporant declaration in a few places (it appears that the second stylesheet was targetted towards Nav4 users … ick, luckily Nav4 ignores the !important declaration). Also, in my opinion the stylesheets were not well written, declaring the same style for the same element in different states. It made for some difficult reading and I spent some time cleaning it up so that it's now easier to tell what's modified in the various states.
I've been trying to find out what constraints we'll be working under with the new design but I guess nobody's really talked it over. Kelly told me she's been getting conflicting instructions and is trying to clarify things. I've gone ahead and made some variations on the template for review by our staff. Hopefully Kelly will get back to me soon. I'd like to know what kind of constraints I'll be working under. No matter the response I'm definitely going to want to make some modifications. It obviously hadn't been considered that the templates would be applied across hundreds of documents. I can't believe a site design would be created without consideration of variations in display that would accommodate a wide range of content such as that available on the various AAAS Web sites.
At any rate, I've already taken the first step towards application of the template. I've applied the template that has no right or left side editable regions. I had to make changes to some of the documents since there were a few that did actually use these areas. No doubt I'll be making a number of adjustments over the next few months to accommodate this design. I would like to apply the design and make it live by the end of next week. I don't really see any major need to go through as extensive of a preparation period as was done for the previous design. I believe our current structure will hold up well enough under the new design. That's not to say that no changes will occur, I just think we'll be able to gradually refine our site over the next few months as we work to better integrate in the new design. It's what I had hoped to do after the previous redesign … but time constraints always seem to hamper our efforts.
I hate the methods being used by AAAS to formulate a template as well. The method they use to make it so people can't destroy the layout are ugly at best. The choice of what to place in include files and how to group things just seems completely random. I've created a pretty decent include structure that I'm going to try and pass along to Kelly to see if she'll replace the currently crappy template files. I think it would go a long way towards making the site easier to maintain.
If I have time I'm going to try and make a more CSS-oriented design. I've already shown what I can do with the CCMS site. If I can create a cleaner template using mostly CSS I think I may be able to convince Kelly the benefits of such a system. Of course, I don't know if she or anybody has time to reimplement the template in such a manner. I believe the whole reason things ended up this way is because deadlines seem to be more important than quality work … which I guess is true just about anywhere.
On the plus side the CSS file pretty much uses only classes and identifiers. No more p styles or h1 styles making my life that much harder. There was a single td style that was giving me problems, but I was able to eliminate that with hardly any problems. I'll have a lot more flexibility in setting up the styles for our site, which is great because they have once again specified an incredibly tiny font size for the content areas. The downside to their usage of CSS, though, is pretty big. They're using javascript to write out the CSS link because they wanted to use different stylesheets depending on the browser. This despite the fact that the stylesheets were amazingly similar. I was able to overcome the problem by using the !imporant declaration in a few places (it appears that the second stylesheet was targetted towards Nav4 users … ick, luckily Nav4 ignores the !important declaration). Also, in my opinion the stylesheets were not well written, declaring the same style for the same element in different states. It made for some difficult reading and I spent some time cleaning it up so that it's now easier to tell what's modified in the various states.
I've been trying to find out what constraints we'll be working under with the new design but I guess nobody's really talked it over. Kelly told me she's been getting conflicting instructions and is trying to clarify things. I've gone ahead and made some variations on the template for review by our staff. Hopefully Kelly will get back to me soon. I'd like to know what kind of constraints I'll be working under. No matter the response I'm definitely going to want to make some modifications. It obviously hadn't been considered that the templates would be applied across hundreds of documents. I can't believe a site design would be created without consideration of variations in display that would accommodate a wide range of content such as that available on the various AAAS Web sites.
At any rate, I've already taken the first step towards application of the template. I've applied the template that has no right or left side editable regions. I had to make changes to some of the documents since there were a few that did actually use these areas. No doubt I'll be making a number of adjustments over the next few months to accommodate this design. I would like to apply the design and make it live by the end of next week. I don't really see any major need to go through as extensive of a preparation period as was done for the previous design. I believe our current structure will hold up well enough under the new design. That's not to say that no changes will occur, I just think we'll be able to gradually refine our site over the next few months as we work to better integrate in the new design. It's what I had hoped to do after the previous redesign … but time constraints always seem to hamper our efforts.
404 Script
I've been running into a number of problems with the text-only portion of newsletters. Some clients just don't understand the method of URL demarcation. I've managed to modify the 404 page so that it now catches most of these problems. Unfortunately, I think I'll need to consider another method. Maybe square brackets or something similar.
I've had to make a number of modifications to the 404 page. Fix something and another problem crops up, fix that problem and break something else, yadda, yadda. It's a continual process, naturally. Luckily most of the major problems have been showing up in the URLScan log so I can address them fairly quickly. I can't really remember a number of the changes, though they're easy enough to determine just by looking at the script. I'll definitely need to spend some time going through the script so I can document what's going on in there.
I've had to make a number of modifications to the 404 page. Fix something and another problem crops up, fix that problem and break something else, yadda, yadda. It's a continual process, naturally. Luckily most of the major problems have been showing up in the URLScan log so I can address them fairly quickly. I can't really remember a number of the changes, though they're easy enough to determine just by looking at the script. I'll definitely need to spend some time going through the script so I can document what's going on in there.
Newsletters - 2061 Connections
The new newsletter went out without a hitch. Modifying the "FROM" address to use postmaster@list.project2061mail.org seems to have solved a number of our problems. We were caught by a few SpamAssassin filters … some of which I've tried to address (see below). Some of the triggers didn't seem to have any relevance to the message we sent out, so I'll just have to wait and see how the next one goes. Still getting the usual number of bounces, etc. I sometimes wonder if some of the messages are getting lost in the ether as some of the bounces seem like they should have been addressed months or years ago. I'll need to investigate this at some point, perhaps I can send a few hundred test messages to my mail server and check the results.
SA Filters Triggered and resolution (if any):
BODY: Words dis|guised with a pipe sym|bol
(Don't know how this one was triggered … unless within the base64 text)
BODY: Claims you can be removed from the list
BODY: I wonder how many emails they sent in error
BODY: {5}Letter - punctuation - {4}Letter
(Probably from URLs in the body … should be more intelligent)
BODY: To be removed from list
(Not many good ways to word this, and most are probably filtered)
BODY: HTML has unbalanced "body" tags
(Was unable to verify this as a problem)
BODY: HTML included in message
BODY: HTML comment has 3 consecutive 8-bit chars
(Was unable to verify this as a problem … I don't think we even had HTML comments)
BODY: HTML has excess "a" close tags
(Was unable to verify this as a problem)
BODY: Message only has text/html MIME parts
(Not even close to being accurate)
URI: URL of page called "remove"
(Changed URL to http://www.project2061.org/listpref)
URI: URL of CGI script has unsubscribe or remove
(See previous comment)
Spam tool pattern in MIME boundary
(Modified the MIME boundary)
One of the sysadmins also suggested we add a preface to the subject of our newsletters to better indicate their source, something like "[Project 2061 Newsletter]" or something like that. Me likee, but perhaps we can come up with something shorter. I used "[Project 2061 Update]" on our last mass mailing but it still feels a bit long.
I have a feeling we'll need to consider using SPF, Domain Keys, Caller ID for E-mail, or some combination of these soon. Drafts have been written and are getting a lot of press lately, which means more people will be paying attention. Sadly, most people prefer to require compliance rather than use header-addition. Bad sysadmin!
SA Filters Triggered and resolution (if any):
BODY: Words dis|guised with a pipe sym|bol
(Don't know how this one was triggered … unless within the base64 text)
BODY: Claims you can be removed from the list
BODY: I wonder how many emails they sent in error
BODY: {5}Letter - punctuation - {4}Letter
(Probably from URLs in the body … should be more intelligent)
BODY: To be removed from list
(Not many good ways to word this, and most are probably filtered)
BODY: HTML has unbalanced "body" tags
(Was unable to verify this as a problem)
BODY: HTML included in message
BODY: HTML comment has 3 consecutive 8-bit chars
(Was unable to verify this as a problem … I don't think we even had HTML comments)
BODY: HTML has excess "a" close tags
(Was unable to verify this as a problem)
BODY: Message only has text/html MIME parts
(Not even close to being accurate)
URI: URL of page called "remove"
(Changed URL to http://www.project2061.org/listpref)
URI: URL of CGI script has unsubscribe or remove
(See previous comment)
Spam tool pattern in MIME boundary
(Modified the MIME boundary)
One of the sysadmins also suggested we add a preface to the subject of our newsletters to better indicate their source, something like "[Project 2061 Newsletter]" or something like that. Me likee, but perhaps we can come up with something shorter. I used "[Project 2061 Update]" on our last mass mailing but it still feels a bit long.
I have a feeling we'll need to consider using SPF, Domain Keys, Caller ID for E-mail, or some combination of these soon. Drafts have been written and are getting a lot of press lately, which means more people will be paying attention. Sadly, most people prefer to require compliance rather than use header-addition. Bad sysadmin!
Friday, May 07, 2004
Instructional Components Prototype
I love creating modular code. Francis didn't want to abandon people without SVG capability and so created PDF versions of the maps being used for the demo. He requested that I come up with a way to have the IE users go to the SVG version while everyone else goes to the PDF version. The knee-jerk reaction would have been to set up a function that could be applied to each link's onClick event handler to take care of this. But that seemed like a waste of time and effort. I came up with the brilliant (if I do say so myself) method of linking to the PDF version and using the DOM to add an event listener to the document object that captures the click and redirects if necessary. On page load a script runs (obtained from a third-party source, see internal reference) that sets a variable indicating whether or not the browser has SVG support. Then, once the page has loaded completely, an event listener is added to the document that captures onClick events. This event checks to see if the event has an href property (meaning it's a link), prevents the default action (visiting the link), and then directs the browser to open the desired document based on whether or not it supports SVG (and the user is trying to access a map).
Unfortunately IE's event model (bottom-to-top) is different from the W3 recommended (top-to-bottom-to-top). So I had to add modify the script for IE using a loop that adds the event capture to each and every link tag. A little annoying, but the code is pretty much just as concise. Also had to take into account the IE event object which is slightly different from the standard.
Still, the functionality appears to work perfectly across platform. The only glitch now is that Mac OS 10.3 has no browser plug-in from Adobe, meaning the PDF version are pretty to look at but little else (as they are loaded externally).
Unfortunately IE's event model (bottom-to-top) is different from the W3 recommended (top-to-bottom-to-top). So I had to add modify the script for IE using a loop that adds the event capture to each and every link tag. A little annoying, but the code is pretty much just as concise. Also had to take into account the IE event object which is slightly different from the standard.
Still, the functionality appears to work perfectly across platform. The only glitch now is that Mac OS 10.3 has no browser plug-in from Adobe, meaning the PDF version are pretty to look at but little else (as they are loaded externally).
2061 Logo
AAAS has released a new Identity Manual that includes font specification and usage, logo specification and usage, and a number of other similar things. I'm still not sure about the implementation of the directives from the manual, which appears to be non-optional. But indications from others at AAAS are that things are still up to the discretion of the people producing the media (print, web, etc). A site license wasn't even obtained for the organizational font and I'm not sure if we'll be ponying up for it. We did manage to get the new 2061/AAAS co-branded logos and I plan on using that on all new print/web productions.
Mass Mailing
I had wanted to completely rewrite the mass mailing system to allow users to control all the information we have about them. Kind of a profile system where people can update their personal information, subscriptions, contact preferences, and other information. This will tie in quite well with purchasing and workshops once it's completed. Minimal information will be required and collected (though no doubt somebody will want to try and collect more and more once they see how the system works). The best part will be the tie-in with the communications database … unifying two of our biggest contact management systems (big for us anyway).
Sadly I ran out of time to complete this project and had to resort to massive modifications to the current system. It's still disociated from the communications database, but now a lot of the electronic items are tied together better. A user can subscribe/unsubscribe from the various newsletters much easier now (though I still have one more page to adjust). It probably wouldn't take much of an effort to add the ability to subscribe/unsubscribe from the print newsletter … which would be a great stop-gap solution until I have time to complete the larger overhaul.
The majority of the work, however, went into the new mailer. I had to spend a significant amount of time figuring out the format of plain-text and HTML-based multipart/mime mail. Though more "manual labor" is required on the part of the person doing the mailing (that would be me), the new system is a lot more flexible. Plain text mailing basically utilize the same system as before with the CDO NewMail object. I've moved the standard footer portion to the client side so that I could de-couple the mail creation from the actual sending of the messages. This had the benefit of allowing me to set up a preview option where an EML file is created and downloaded (thanks to the content-disposition HTTP header). All this, however, was gravy after spending around two weeks attempting to set up a system that can do multipart mailing as well. A number of considerations had to be made:
I'm not sure if the mime boundaries are RFC acceptable, but they seem to work well enough and I'm not overly concerned about running into duplicate boundary identifyers. All tests on the system have gone smoothly. I've already sent out a text-based message and it went off without a hitch. As a matter of fact, it went better than the previous few months because I've finally implemented the new from address with the new system. This had been giving us no end of headaches previously thanks to filters and such. There were no messages stuck in the queue at all … which is a pleasant change.
Sadly I ran out of time to complete this project and had to resort to massive modifications to the current system. It's still disociated from the communications database, but now a lot of the electronic items are tied together better. A user can subscribe/unsubscribe from the various newsletters much easier now (though I still have one more page to adjust). It probably wouldn't take much of an effort to add the ability to subscribe/unsubscribe from the print newsletter … which would be a great stop-gap solution until I have time to complete the larger overhaul.
The majority of the work, however, went into the new mailer. I had to spend a significant amount of time figuring out the format of plain-text and HTML-based multipart/mime mail. Though more "manual labor" is required on the part of the person doing the mailing (that would be me), the new system is a lot more flexible. Plain text mailing basically utilize the same system as before with the CDO NewMail object. I've moved the standard footer portion to the client side so that I could de-couple the mail creation from the actual sending of the messages. This had the benefit of allowing me to set up a preview option where an EML file is created and downloaded (thanks to the content-disposition HTTP header). All this, however, was gravy after spending around two weeks attempting to set up a system that can do multipart mailing as well. A number of considerations had to be made:
- line length … I wanted to stick to around 69 for URL modification purposes
- what encoding format to use … I wanted to stay away from quoted-printable to make my life easier; I ended up having to set up QP for the text portion of the message anyway; perhaps I should rethink the current encoding on the HTML portion of the message
- mime encoding of images and internal reference … I had originally wanted to pre-encode the images and just insert them where necessary, but decided that could cause other problems so I went with dynamic inclusion
I'm not sure if the mime boundaries are RFC acceptable, but they seem to work well enough and I'm not overly concerned about running into duplicate boundary identifyers. All tests on the system have gone smoothly. I've already sent out a text-based message and it went off without a hitch. As a matter of fact, it went better than the previous few months because I've finally implemented the new from address with the new system. This had been giving us no end of headaches previously thanks to filters and such. There were no messages stuck in the queue at all … which is a pleasant change.
Newsletters - 2061 Connections
The new newsletter is just about ready to go. After weeks of testing HTML-based e-mail on various systems (Outlook, Outlook Express, Yahoo!, Mozilla, AOL, AOL Webmail, Hotmail, Squirrelmail) I think we've got the basic formula down. The HTML is fairly simple and uses inline styles for presentation. I wanted to try and use current standards as much as possible. I think it just makes things easier. Display is either perfect or good enough on all tested platforms except Squirrelmail which, for some reason, displays the text version of the message. I think this is probably more due to administrative settings rather than support, but I haven't done extensive testing to figure it out. Plus this is the whole reason I went with multipart/alternative. At least I know that it works the way it's meant to if the HTML version is not displayed.
Everyone seems to be happy with the newsletter and the first issue will go out on Monday. I've run the newsletter through couple of different free SpamAssassin testers and it never came back with a rating high enough to cause concern, so I think we'll be ok on that part. I've also done what I can to adhere to the CAN-SPAM laws on this (and all other) mass mailings so we shouldn't run into problems there. I'm still not happy with the staff's penchant for mailing any address we can get our hands on. At least on the bright side we are not sending commercial mail and provide a true opt-out option.
Everyone seems to be happy with the newsletter and the first issue will go out on Monday. I've run the newsletter through couple of different free SpamAssassin testers and it never came back with a rating high enough to cause concern, so I think we'll be ok on that part. I've also done what I can to adhere to the CAN-SPAM laws on this (and all other) mass mailings so we shouldn't run into problems there. I'm still not happy with the staff's penchant for mailing any address we can get our hands on. At least on the bright side we are not sending commercial mail and provide a true opt-out option.
AAAS Redesign
Speaking of the boss-man. Met with Kelly Gayden the other day to review the new AAAS design and discuss what it would take to get things done over here. It actually looks like we'll be able to make the transition to the new look without much trouble. That doesn't mean, however, that it'll be a no-brainer.
The new design still uses a familiar top/left-side shell structure found on so many web sites. Replacement of the top area will be easy enough. The left-side navigation, however, should be modified to take advantage of the new functionality. Also, it looks like we'll need to forego our handy drop-down/search modifications. But I think most of these items can be easily enough integrated into the new navigational scheme.
The right-side … um … sidebar is no longer present so we'll need to rethink some of the pages on the site. I think with a number of these items we may just be able to integrate them into the actual content. For the rest I'm currently leaning towards using floated divs to allow for a similar affect. Some content I think I'd like to make more
The content areas should be a simple drop-in.
I haven't had a chance to review the stylesheets so it's hard to say if I'll need to make another end-run around their CSS code in order to have a site that's more user-friendly. Sadly, it appears they're still using tables for layout … I can't wait to boast about the work that was put in to the CCMS site. No doubt in the end I'll want to make a number of modifications. At the very least I'll need to do what I can to fit the code into our Dreamweaver templates. Much as I like what they've done to separate out things as much as possible, I'd rather see more time spent on standards-compliance.
The new design still uses a familiar top/left-side shell structure found on so many web sites. Replacement of the top area will be easy enough. The left-side navigation, however, should be modified to take advantage of the new functionality. Also, it looks like we'll need to forego our handy drop-down/search modifications. But I think most of these items can be easily enough integrated into the new navigational scheme.
The right-side … um … sidebar is no longer present so we'll need to rethink some of the pages on the site. I think with a number of these items we may just be able to integrate them into the actual content. For the rest I'm currently leaning towards using floated divs to allow for a similar affect. Some content I think I'd like to make more
The content areas should be a simple drop-in.
I haven't had a chance to review the stylesheets so it's hard to say if I'll need to make another end-run around their CSS code in order to have a site that's more user-friendly. Sadly, it appears they're still using tables for layout … I can't wait to boast about the work that was put in to the CCMS site. No doubt in the end I'll want to make a number of modifications. At the very least I'll need to do what I can to fit the code into our Dreamweaver templates. Much as I like what they've done to separate out things as much as possible, I'd rather see more time spent on standards-compliance.
Web Site Updates
Created a template that has no sidebar on the right. The main purpose of doing this was to accommodate content that doesn't use the sidebar and would benefit from a wider content area. I'll probably go ahead and apply this site-wide, however, since I'll need to adopt a similar design once I apply the new AAAS template.
Subscribe to:
Posts (Atom)