RSL:PD Online

Started working on getting RSL:PD ready for our site. FM doesn't want to spend a lot of time on it, but I'm not sure it'll go that well. The code for the HTML and other documents is in bad shape in some places. Plus this project was created before CSS really took a foothold. I'm going to try to keep my fixes to a minimum, but I'm already looking at a healthy amount of work because FM wants to replace frames throughout the product. At least that'll give me the opportunity to work on all the documents to a certain extent, cleaning up the code to remove the most obvious problems.

I also have to modify the Flash-based tutorial on how to use the product. In the end I've got a lot of work cut out for me, hopefully I can finish it by the end of the week. Considering what lies ahead, though, I suspect I may be working on it for a couple of weeks.

Mass Mailing

Sent out a mail today reminding people of the upcoming workshop early-bird registration deadline. The e-mail went to our Web site update list, which is currently at 2343 users.

One interesting event on this "blast" ... the swt.edu (Texas State University - San Marcos) domain name servers no longer respond with any info for the domain. Somebody's gonna get hell for that one. Initially I was removing the e-mail addresses, but the shear number made me realize this was due to DNS problems and not invalid e-mail addresses.

Also of note, fixed a minor problem with the send scripts I had introduced when performing some other updates. I hadn't tested these updates because they weren't integral to the ASP code but were part of the JavaScript interface code (and were fairly minor to boot). I think I un-did a code fix I had used when initially creating the code. The JavaScript in question creates a standard footer for text-based e-mail. A combination of factors was causing theh ASP interpreter to think it needed to process a portion of the code:

• The footer indicated the user's e-mail address for reference purposes using the format <user@address.com>.
• Since this is generated for each address I needed to use a placeholder for the e-mail address. This is currently of the form %MASSMAIL_RECIPIENT%.
• The combination of the two produces the ASP-like code <%MASSMAIL_RECIPIENT%> which throws and error for a couple of reasons.

So that it would not be processed by the ASP interpreter, I modified the JavaScript code as follows:

"<" + "%MASSMAIL_RECIPIENT%>"

Checking the locks

One item of note (otherwise I wouldn't bother to post on this subject). Somebody attempted to log in to our FTP server using a variety of names. Though it's nothing we haven't seen before we don't see much else as far as attack vectors go these days. I would report it, but it was a user at a large ISP ... not worth it. No doubt an unwitting user with a hacked machine on their network.

HS Bio Textbook Report

I've spent the past few days making some modifications and corrections to the report. I think we're about done, though that always seems to be the case until something else pops up. Most of the modifications were fairly minor ... move something here, edit text there. A few more pop-ups were created. I had thought about an icon to indicate that a window will be a pop-up, but I don't think that's necessary.

I made some modifications to the show/hide script. The "new text" indicator is now an optional item set by a js variable. I could probably make it even more flexible and add back in my "growing" text effect. Perhaps I'll investigate that for a future revision. I also made it so that links to which the show/hide script apply have a modified underline (dashed instead of solid). This could probably be a little more modular as well. Again, something to consider for a future revision.

I still need to do the documentation plus code-commenting for the scripts. I don't plan on doing it today, but I'll probably have it done early next week. There are two scripts that are modular enough for reuse that need to be commented. Plus I'd like to try and do some more general documentation on the templates and coding (to note the coding style, browser support, etc.).

IERI Utility

The detailed report is complete. The script is not the prettiest or most efficient, but it should get the job done. The script makes a number of calls to the database and works extensively with the dataset open. This has the potential of slowing things down, but the fairly linear nature should help somewhat with speed. Plus I don't expect a lot of people to be running reports at once. The portions of the sript dealing with the enacted analysis are particularly poorly written. Part of it is the complexity of the database design, which was necessitated due to the complex relationship between all the data. A lot of data pulled from the db is from other users reports. It's not displayed, but the work-arounds wouldn't be necessary if the SQL statements and scripting were better crafted.

Usability wise, the report is a bit unweildy if you're looking at a couple of activities that each have a number of sightings. A number of interface enhancements could improve things (such as turn-downs, a tabbed structure, and summary/drill-downs). But I think the report is readable regardless of the problems.

Still, this is just a temporary fix until a new version is available. Perpetually on the drawing board, but hopefully I'll get to it sometime this year.

IERI Utility

I've completed the literal portion of the reporting functionality. It looks decent, though usability could be improved somewhat by making the report more modular using a show/hide scenario or something like that. As it is, the document gets pretty large depending on the number of activities chosen from a sequence.

The enacted sequence is taking a bit longer to prepare, but I think it's coming along. I've got the framework down for getting the information. The basic info for an activity is being pulled same as with the literal, but I need to make a few modifications to allow for the sighting details to be pulled.

I'll need to do quite a bit of testing to ensure that the report accurately reflects the data stored in the database. I'm not as concerned about the data itself but of the various posibilities when data is not present (omitted, never entered, etc). Plus I'll need to make a few stylistic decisions on how to represent the various situations. I want to ensure that the representation of these various possibilities is accurate in the report. I should be able to do a comparison between the editing screens and report screens to get a good feel for whether or not the accuracy is there.

IERI Utility

I finished the "selection" portion of the summary report script. It's basically a question/answer kind of thing in order to narrow down the activity sequence that the user wants to summarize. Once the sequence has been identified the user is given a list of all the activities in that report. The user checks a box next to each activity and submits the form, which then presents the details of each activity. I guess it's not really a summary report since what's returned is all the information related to the activity it's more of a detail report.

I'm currently working on the actual report page. I haven't gotten very far just yet, but I suspect that I can hammer this out in a day (Friday to be exact). I have sequence info listed and the beginning of the activity info. I should be able to duplicate some of the script relating to the sightings from other portions of the utility. Of course, the trick comes from making the script generic enough to handle both enacted and literal while at the same time providing the information specific to each analysis. Thinking about all the data related to each type of analysis and all the possible stages of analysis can be a bit mind-boggling at times (what needs to be included, what tables need to be linked, how the data is to be represented, what if something has yet to be rated, etc.).

I think it may help to have a summary of the results somewhere on the document. Maybe at the top before the activity details are presented. I'll have to talk to KM about that.