CCMS Web Site

Done. Well, nearly done. Done with the design/coding aspect of things. Though nobody's really been looking at it much since I started work in earnest over the last month so I'm sure a few stylistic changes will need to be made. However, I've managed to create a site that is XHTML compliant, CSS2 compliant, and addresses (most of) the accessibility guidelines. Plus, in order to get away from the, um, questionable design (of white on light blue) I've been able to create a cross-browser, cross-platform stylesheet switcher (thank you ALA). Essentially, the default style displays a text-only site (black on white) with a somewhat stylized left-side navigation (current location is indicated using color). If the user has a modern browser (IE5+, Mozilla, et al) then the style automatically switches to the "CCMS design." However, the user is presented an option at the bottom of each page to choose how the site appears. It works brilliantly and I hope it is actually used to good affect. I have no doubt that people will want to rid themselves of the difficult-to-read design, I just hope they have no trouble figuring out how to do so. Plus, the site has a CSS-defined print style and degrades nicely to older browsers (even non-CSS ones). All this is well-documented in the site code.

I'm thinking we should add a breadcrumb trail to better indicate the users location; browsing through the site feels a tad abstract at present (it's sometimes difficult to get a feel for where you are). I's not difficult to add, but deciding on the location will be something of a challenge.

Still need to add a few things: content (waiting for Communications to finish), a search engine, and a few site notes regarding the stylesheet switcher and standards compatibility. However, I suspect we'll be completely done in the next few weeks.

At least I can move on to some other major project now.

IERI Utility

Finally after many, many, many months I am getting a chance again to work on the IERI utility. No doubt it needs a lot of work. I've got some great ideas about using CSS and Javascript to vastly improve the interface, javascript objects to enable a unified data entry system, and XML for client/server transfer. Perhaps I can even make this version more standards-compliant. This is going to require a lot of changes to the scripts and database. I've got some pretty good ideas of where to start. But this is going to easily be a six-month project. This is all still at the planning stage and things could change drastically.

Kathleen has a number of modification she would like to see added to the utility before anything else is done, so until I've made all those changes I'm going to have to stay in the planning phase. Most of the requested changes are bug fixes, but there are a few feature additions as well. Here's the list of changes I've made so far:

• Added teacher analyst user type with specified options. You can test this with username/password combo of teacher/p2061
• Made the idea boxes bigger in all areas, but the biggest change is on the activity detail screen
• I added a "Save Analysis Data" button to the left-side menu that is shown when an analyst is analyzing an activity.
• Fixed the bug so that you can now add an analyst after a movie has been checked in.
• Indicators that are "not observable" no longer have the rating/rating comment items attached to them. In the database these items are automatically marked as "not applicable" (I'm not sure if this is the preferred method or to just leave them as null.)
• When you duplicate an activity the relevant sighting information is also duplicated for that activity (along with it's connection to the literal information). I did have a question on this item (see below).
• Activities on the timecoding screen are now ordered first by their time-coding then below that by their activity number. So timecoded items will appear first in the order in which they appear on the video. The same is true of the sighting list on the enacted activity analysis screen.

Perhaps I should start maintaining a change log. It'd probably help when I get around to doing the code documentation. Based on how long it took me to do the documentation for the CCMS redesign I expect it will take me a good while to do the same for IERI. Especially when you consider that the majority of the system is code compared to CCMS. Plus I should make an effort to work on a user manual or online help system this time as well. It'll be nice to create a full-featured system compared to the work I normally have to do around here. Though it was a lot of effort, I found the extra work I did for CCMS to be gratifying.

CRM

I have a lot of work to do on the database. I'm still in the process of setting up the tables. Trying to determine all the information that will be required to run this thing is certainly a challenge. I think I'm actually pretty close to being done with the table setup (I'll attach a diagram next time). But once that's done I'll still need to set up all the stored procedure, views, and relationships. One thing of note, I decided to use the GUID feature for the external ID so that it's not as predictable as it would be otherwise. Internal linking will still be done via the autoincrement ID. I doubt the ID problem will be too much of a problem anyway because I'd like to do something similar to what I've done for the intranet authentication scripts (cookie does not contain identifying information but points to a file containing the user ID).

I still haven't quite decided on some of the issues that will need to be addressed. Such as:

• how much information we will have access to from a user-created entry
• how do we handle staff updates of a user-created or user-owned entry
• how will the e-mail list system be set up (especially for lists with an HTML option)
• if we use external list management software will we be able to integrate it with the user database

And I have about a week to get all this done :(

Newsletters - 2061 Connections

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.

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.