Worked a bit on the header image. Really there isn't a whole lot to it, but making sure the image is large enough but not too large is a challenge. I wanted to use a CSS background image so that it didn't really matter how large the user's client window was set (since the right part of the image is just for looks). Unfortunately there's not a lot of support for that out there.
Speaking of CSS, I decided to avoid using a stylesheet of any kind (external and internal). There's just too much variability in what supports out-of-line styles. Still, HTML with inline CSS looks like it'll work out nicely. Plus I can set up a section on the web site for Jonah to work on the newsletter then just copy the HTML for the newsletter.
Monday, April 12, 2004
Friday, April 02, 2004
Mass Mailing
Sent out a few more mass mailings over the past few weeks. We've been seeing a lot more returns (around 10%) than in the past. I suspect we're butting heads against SPAM filters. It looks like our biggest problem is the address from which we're sending the email (postmaster@project2061.aaas.org). I believe a number of sites are now checking the domain on that address against MX records in the DNS. Since that domain doesn't have an MX record it's being rejected. I'm going to work with Dave on setting up a new server name on project2061mail.org (lists.project2061mail.org sounds good to me) from which we can send mail. Hopefully that will prevent a lot of the problems we've been seeing.
We do have a few emails being caught by content filters, but I don't know that there's a lot we can do there. Unfortunately, a lot of SPAM uses the same language we do because it is indicative of a legitimate message. On the other hand, a lot of spammers have resorted to random text in their messages, so maybe over time we'll be less likely to be cause. I don't know how the new HTML-based newsletter we're developing will fare. I suspect a lot worse, but I should have time to test against spamassassin before we send it. Plus we should have taken care of the domain issue by then as well.
Ed's talking about using the list server built into OS X. I'm not so sure about that, my experience with a lot of list software is that they use their own proprietary format. It's be nice if it could be modified to hook into a database like mysql or mssql, but I doubt it. I'll probably stick with my current system for the time being.
Speaking of systems, I still haven't had a chance to work on the user profile/contact system that I'd like to set up to replace the communications database. Though I've talked to Serita and Barb about what I'd like to do neither of them seemed to be concerned. True, a lot of what currently done manually will be taken care of automatically with the new system, but I suspect they haven't really thought about how this will affect the random work they do with the communications database.
We do have a few emails being caught by content filters, but I don't know that there's a lot we can do there. Unfortunately, a lot of SPAM uses the same language we do because it is indicative of a legitimate message. On the other hand, a lot of spammers have resorted to random text in their messages, so maybe over time we'll be less likely to be cause. I don't know how the new HTML-based newsletter we're developing will fare. I suspect a lot worse, but I should have time to test against spamassassin before we send it. Plus we should have taken care of the domain issue by then as well.
Ed's talking about using the list server built into OS X. I'm not so sure about that, my experience with a lot of list software is that they use their own proprietary format. It's be nice if it could be modified to hook into a database like mysql or mssql, but I doubt it. I'll probably stick with my current system for the time being.
Speaking of systems, I still haven't had a chance to work on the user profile/contact system that I'd like to set up to replace the communications database. Though I've talked to Serita and Barb about what I'd like to do neither of them seemed to be concerned. True, a lot of what currently done manually will be taken care of automatically with the new system, but I suspect they haven't really thought about how this will affect the random work they do with the communications database.
Friday, March 19, 2004
Web Site Updates
I finished the Atlas Survey page. I've used a lot of the newer techniques on this page, but I think I can further refine the way I do things. Some of the new stuff I've used:
- HTML Form elements: label to give some elements a label, fieldset to group related questions together
- Updated ASP/javascript: there are problems with IE, radio buttons, and my JS validator. I've modified the JS to count the number of items to be validated and increment another counter upon actual validation. If the two counts do not match then the form is marked as not validated and the ASP validator takes over. I've also set it up to use the custom error-handler (A number of scripts had to be modified to account for some of the changes I've made).
Some ideas for further enhancement: With a form this complex a lot of manual work has to go into setting up variable capturing and database updates. I think it's time to look into modifying things so that more automation is present. I'll have to investigate the options, but a I've considered variable naming schemes and a database variable table along with the question/answer table and the user response table.
There have also been various other updates: Atlas workshops, What's New, etc.
- HTML Form elements: label to give some elements a label, fieldset to group related questions together
- Updated ASP/javascript: there are problems with IE, radio buttons, and my JS validator. I've modified the JS to count the number of items to be validated and increment another counter upon actual validation. If the two counts do not match then the form is marked as not validated and the ASP validator takes over. I've also set it up to use the custom error-handler (A number of scripts had to be modified to account for some of the changes I've made).
Some ideas for further enhancement: With a form this complex a lot of manual work has to go into setting up variable capturing and database updates. I think it's time to look into modifying things so that more automation is present. I'll have to investigate the options, but a I've considered variable naming schemes and a database variable table along with the question/answer table and the user response table.
There have also been various other updates: Atlas workshops, What's New, etc.
Instructional Components Prototype
Haven't really done much with this lately. FM decided to modify the way the demo works even though I told him I don't think the problem he's trying to fix is critical. Helped them debug by pointing out an error in the stylesheet.
CCMS Web Site
Been working full steam on the redesign this week. Encountering many bugs between the various browsers but I think I'm finally getting there. Hopefully I'll have this done next week. A quick overview of some of the bugs I've found:
- Safari: cookies generated by javascript from a local file do not appear to be saved. Luckily this isn't a problem for CCMS.
- IE Mac: (a reminder) @media print css selector not supported; does not support onbeforeprint javascript event ala IE Win. This one was bypassed by using an inline style that imports a print-only stylesheet using @import … print
- IE Win: despite the existence of multiple style declarations (link, "style" and "alternate style") IE attempts to use the default style. If this style is disabled (such as when it is by the style-sheet switcher) then IE ignores all other stylesheets and uses only inline styles. I was able to get around this problem by using an onbefore print and onafterprint event handler to switch the style to the default then back to the user's preferred.
- Getting closer on being able to finalize the design.
Tuesday, March 16, 2004
Scripting
While working on the Atlas survey form I noticed that Internet Explorer has problems with the validation of radio elements. This is probably true of checkboxes, but I haven't taken the time to investigate the extent of the problem. I've made a note to correct this.
In the meantime I've worked out a kludge.
In the ASP or HTML file where the form is located:
The number of fields to be validated is counted when the form is set up and placed in the intFormFieldCount variable. Basically the count goes like this: one for each text, textarea, file, password, select-one, and select-multiple elements; the length of the array for radio and checkbox elements.
In the validate.js file:
The script was already set up to count the number of elements that have been validated and place that number in the intValidated variable. The count will show up the same as the above because I parse through the form using the elements array instead of each validation element name. I've added some code that allows IE to skip the validation of radio form elements. After all the elements have been tested the file compares the intValidated variablee with the intFormFieldCount variable and if the former is less then the hidden form element intValidated is not set to true.
Basically what this boils down to is that if any radio form elements are to be validated then the count for IE will be less than the total and the form will be submitted as not validated, allowing the ASP companion script will take over validation chores.
In the meantime I've worked out a kludge.
In the ASP or HTML file where the form is located:
The number of fields to be validated is counted when the form is set up and placed in the intFormFieldCount variable. Basically the count goes like this: one for each text, textarea, file, password, select-one, and select-multiple elements; the length of the array for radio and checkbox elements.
In the validate.js file:
The script was already set up to count the number of elements that have been validated and place that number in the intValidated variable. The count will show up the same as the above because I parse through the form using the elements array instead of each validation element name. I've added some code that allows IE to skip the validation of radio form elements. After all the elements have been tested the file compares the intValidated variablee with the intFormFieldCount variable and if the former is less then the hidden form element intValidated is not set to true.
Basically what this boils down to is that if any radio form elements are to be validated then the count for IE will be less than the total and the form will be submitted as not validated, allowing the ASP companion script will take over validation chores.
Monday, February 02, 2004
CCMS Web Site
Spent most of last week working on the CCMS site. I think people who don't know the limitations of the Web should not be placed in charge of design decisions. The designer seems to think that the same level of control that is available in print is available on via HTML. The other suggestion being to just use images. Somewhat frustrating but I've given up on trying to help her understand. My goal now is to just implement the site as designed. If I had been involved earlier in the process maybe things would have worked out better. Once I get everything functional I plan to work on an alternate stylesheet that's pretty much just plain vanilla.
Subscribe to:
Posts (Atom)