The final steps to release were the predictable grind: trawling through all the documentation, tutorial and help looking for screenshots and explanations that needed updating, adding of licence info to headers of files newly released as open-source (such as my Unicode spin-edit control and find/replace dialog), updates of the Website, and lots of builds and tests of the installer. Got through it, and announced it.
The Image Markup Tool version 1.7.1.0 has been released. You can get it from here.
This is a build-update rather than a version-update, meaning that the XML file format used by the program has not changed. These are the major changes:
- a fix for a bug in the Web View output, which afflicted documents with very large numbers of annotations
- the addition of a feature which enables the user to specify the
xml:idattribute of the annotation<div>, which is useful especially if you're integrating IMT documents into larger projects - the addition of Find/Replace functionality to the GUI
The TIMTDoc.FindNext routine had an endless-loop bug caused by failure to detect wrapping around correctly (in other words, having searched the whole document and got back to the starting point without a result, it should have noticed that and stopped, but it didn't). It was caused by a failure to set the ItemIndex field to -1 when wrapping back around to the teiHeader; the teiHeader doesn't use ItemIndex, because there's only one of it (as opposed to annotations or categories), so I was neglecting to set that field at all, but the test for wraparound depends on both the field type and the item index being the same as the starting point, so it does need to be set to -1. Fixed it.
It's interesting that they correlate, but what it probably means is that, in exactly the current climate, they happen to correlate; in other words, the same groups of students take them with the same level of seriousness and put similar amounts of effort into them. If the balance were disturbed -- for instance, if institutions were to start taking RateMyProfs much more seriously, because they believe it to be accurate and representative -- then the balance would be distorted, and the students' perceptions of, and willingness to contribute to, RateMyProfs would change.
There's something obnoxious about both of these evaluation systems, I think. On the one hand, the institutional imposition of a mandated evaluation system is heavy-handed and can frighten vulnerable instructors into adopting class-pleasing gimmicks instead of less popular, but ultimately more effective, teaching strategies; we've seen that particularly in the language-teaching industry, which has become to a large extent crowd-pleasing entertainment as much as it is instruction. On the other hand, taking commentary of something which is not really a public performance -- teaching -- into the public realm, without the consent of the person being discussed, is at least somewhat inappropriate; even though instructors are now able to "strike back" on the site, doing so implicitly validates the whole enterprise, and puts the prof into a kind of reality-show exchange which can get heated and unpleasant.
Perhaps the need for both of these systems apparently arises out of failures on the part of instructors and students to communicate properly with each other during ordinary teaching time. Ridiculous class sizes are surely at the root of this.
According to a recent US study, there are surprising correlations between the usually derided RateMyProfessors.com and IDEA (the student evaluation system used at about 275 US colleges).
Key findings:# Student rankings on the ease of courses were consistent in both systems and correlated with grades
# Professors’ rankings for “clarity” and “helpfulness” on RateMyProfessors.com correlated with overall rankings for course excellence on IDEA
# The similarities were such that, the journal article says, they offer “preliminary support for the validity of the evaluations on RateMyProfessors.com
Drove someone to the ferry at lunchtime, so was out for a couple of hours, and only stayed one our over, so I'm down one hour.
Somehow the latest version of the BC 1858 schedules for despatches to London was overwritten with another despatches file. Managed to retrieve a backup from April 15, and PS re-edited that. This prompted me to make another full backup, and resolve to keep multiple copies of the whole db. We should make full copies regularly, of course.
CT sent me a link to the new, more precise specification of @facs, which aims to prevent my generalized usage of it as linking anything to a facsimile element. @facs will now be limited to
"groups elements corresponding with all or part of an image,
because they contain an alternative representation of it, typically
but not necessarily a transcription of it." That's still pretty vague, but it's intended, I think, to exclude annotation. IMT needs to change to reflect this.
After some consideration, this is what I think should happen:
- Version 1.8 should add a new checkbox/boolean to the category properties, specifying that this category is transcriptional in nature (vague, but so is the above spec!). I haven't yet figured out a way to store this information in the
<rendition>element of the TEI file. Perhaps I should just add an@facsattribute to the<rendition>tag, pointing at the<facsimile>element? - Where this boolean is set, the annotations should be associated with the area using the
@facsattribute; otherwise, the@correspattribute should be used.
If this proves too complicated for the moment, a quick solution would simply be to switch from @facs to @corresp.
Finished the Replace All functionality, and documented the Find/replace dialog box for the Help file. Also found a bug while doing this: creating a new category when there are no categories (the cat list is empty) would result in an index out of range error. Tracked this down and fixed it. The difficulty of this showed some excessive complexity in the codebase; the handling of categories is shared between four forms and several other libraries, because you can get at them in so many ways (using the actions in the main and Annotation windows, and also through the Category Manager itself). This could really use some optimization in the long run.
Build the Help file, so we're now basically ready to go, but I want to do some more testing before I go for a release. This one might even warrant a beta release.