IERI: Updates

The IERI utility has been in heavy use the past few weeks, so a few minor but common issues have come up. A few of these I decided to go ahead and fix, namely:

Movie availability
In order to do an enacted analysis the timecoding of the activities has to be completed by an administrator and the movie released. Once a movie was released it could not be used for further activity-level timecoding once analysis had begun. A lot of people were releasing the movie after timecoding only a single activity, or a group of related activities, even if the movie contained other activities.

It looks like the purpose of enacting movie release restrictions in the first place are not really an issue with the utility as it's currently being used. I went ahead and made it possible to undo a movie release so that further timecoding can be done.

Movie filename
There is a filename check to ensure that the movie loaded for playback matches the one selected in the utility. This was causing some problems because there are instances of the movie name being mistyped. I updated the utility to allow for the movie information to be updated from the enacted activity timecoding page.

CD/Label information
When an activity is timecoded using the JS functionality the CD label and movie filename are updated automatically. This was not happening if the information was being entered manually. I updated the page so that manual entry would result in the movie information being updated (based on the currently playing movie if available). If not current movie information is available it will maintain the previous movie information.

In addition, I made it so that any timecoding would result in the text "Save to update information." would be placed in the label/filename table cell.

Web Site Updates: 2061 Connections Index

I updated the index of 2061 Connections issues. It now lists the issues as well as the articles from those issues. The current page is static, but it may be more benefitial to create a database-driven page since MK wants to possibly provide more than one view (such as an alphabetical list of articles).

Mass Mailing: Workshops Notification, Summer 2006

A Workshop Schedule Notification was sent out on 07 Jul 2006 4:24 to 2628 E-mail Alerts users and 13 users of the one-time notification feature.

Usage Analysis Options

Webtrends can accept custom definitions of search engines. I had previously set up the program to recognize the AAAS search. However, I remembered today that when AAAS updated the search engine I forgot to update the Webtrends search engine list. This is mostly a reference note for documentation. The settings are found in the program options under the "Search Engines" area.

Search Engine Name: AAAS Vivisimo
Identification Strings: vivisimo.aaas.org vivo.aaas.org
Keyword Indicators: &query ?query

Web Site: Indicating indexible content

I had been thinking that it would be nice if the navigation on our pages did not affect the overall ranking in search engines. Particularly the AAAS search engine, which doesn't do so well when the search terms include words from the navigation. Some kind of container tag or attribute that could be used to say "don't look at this" to the search engine spiders.

Supposedly a method was floated a few years ago, but nothing came of it. In all likelihood the major search engines have already come up with methods of decreasing the weight of content that is reapeated often on an individual domain.

To put a final nail in the coffin of this idea, AAAS updated their search engine this year and it appears to do a much better job than it used to.

IERI R3: On PEAR and Code Separation

PEAR Components

I was trying to decide if I should utilize some of the components available via the PEAR library. Some of these components are under constant development and so would provide a significant source of well-written and debugged code. Specifically, there's a authentication/permission module that might integrate nicely with the utility. Upon further thought I decided that for now I'm going to try and do a lot of the coding myself (except for the occasional module). This is my first major PHP application and I feel the best way to familiarize myself with language is to do the programming as much on my own as possible. By taking my time to develop the code myself I should be better able to evaluate third-party code in the future.

If future revisions of the utility are created it may be benefitial to look at incorporating PEAR components where possible.

Code Separation

On another note, I was thinking about the separation of processing code and user display. The more separate the two aspects of an application the easier it is to update either one. IERI is one of the more complex applications I've developed and it's a bit difficult to determine how to best achieve the separation. I've not gotten very far in the current development (authentication completed) but I can already see how even something so simple as authentication could be utilized as a separate component from the user interface for user login (allowing authentication via JavaScript, for example).

I do plan on attempting to separate the code from the display as much as possible in anticipation of AJAX-oriented development down the road. I guess one of the questions I have right now is how much extra time will be required to rewrite an integrated page into a separated one. I'm hoping that any pages I develop singularly will be fairly easy to upgrade if I utilize function calls and other methods of extracting the logic from the normal processing flow.

Web Site: Spanish Content Update

I made a relatively minor update to the Spanish content on the site ... added a lang attribute to identify the content as being in Spanish. I don't expect it will make much of a difference to users of the site, but it's good web etiquette. My one hope is that search engines will find it useful.

I should spend a little time making sure any English text in the Spanish documents is appropriately identified.