IUSM Educational Technology

Watson and I talked about migrating cfserve, and it’s sites. I’ve already loaded the Coldfusion 8.0 software onto the main webserver, and the server admin interface appears to be working well. Now that CF is on spidey, I can begin to move the Geneinfo website database out of MS Access and into Sql server. Once the database move is complete, I’ll start the process of re-doing the design/development of the Geneinfo front-end.  Keeping in mind, that I’ll need to develop a web interface for the library staff to be able to login and add, update and delete records in the database. Need to consider a way for library staff to also perform any updates to the web front-end, without needing to know html. Will consider using Contribute.

mat

On Thursday, July 2nd, Angel was upgraded to the newest version and migrated to new hardware. To prepare for the upgrade, I used VMWare to configure a server that replicated our 7.3 installation, and ran the upgrade on that server 3 times to become aware of any problems that might crop up. The upgrade was complicated by the fact that I was not only upgrading the system, but migrating to new hardware and changing the DNS name of the server. The old address was daly.medicine.iu.edu, which people had trouble remembering. It is now angel.medicine.iu.edu which is probably what people would guess it to be if they did not know for sure. Additionally, Angel has been configured since the beginning her to use a virtual directory (/med), which I did not replicate since it complicates administration of the system and is sometimes unsupported by Angel Learning. ePortfolio was upgraded as well, but I did not run this upgrade until the following Monday. The URL for ePort changed as well, becoming eportfolio.medicine.iu.edu. ePort’s URL change is not as dramatic, since you get to ePortfolio through Angel. There are some historical portfolios on the system which will not be available from their previous public url, but all of these are dormant. ePortfolio is not heavily used here at IUSM, although the concept of a portfolio system is attractive to a number of faculty.

On July 2, I came in around 4:30am to begin the process of migrating to a new server and upgrading Angel. The process went well and was completed at around 6:20am. I spent the remainder of the day cleaning up broken URLs and testing functionality of high profile courses. I also brought up a virtual server which could capture anyone coming to daly.medicine.iu.edu, and present a page with the new URL.

The change that impacts our Angel course editors the most is the deprecation of quizzes. All the quizzes in our Angel system have now been converted to Assessments, which have more features but a different interface for creating and editing. A close second for the biggest change is the way that support for IE 6 has pretty much fallen off the cliff. Angel 7.3 did not support IE 6, but it worked most of the time. Angel 7.4 has definitely left IE 6 behind. For some IUSM faculty, installing IE 7 is not an option because they don’t have administrator rights on their computer, and if they did, the Clarian apps have to use IE 6. The option for these faculty is Firefox which works fine with Angel, but they have to find their LSP and get Firefox installed. Sometimes they do not know who supports their PC and don’t want to mess with opening a support ticket to get a new browser, so this issue is tough in this environment.

The change for Angel admins is the move towards role-based access rights. After a day or so of reviewing the way that rights are granted now, this will not a problem for us to support. In the past, faculty and staff were bulk loaded into Angel with the default role of “student”. Due to the new way of granting rights based on roles, this has prompted some support calls but the fix is easy. We just have to change the user’s role from student to faculty or staff. Also different is the way that rights are granted to the historical “system editor”, but I created roles which duplicate the functionality that these people had in 7.3.

After a couple weeks, I discovered that we had been bitten by a bug which caused migrated assessements to lose the answers that were input into the original quiz. You can still see who took the test, and what their grade was but this didn’t help much for survey type responses where the answer was critical. However, my upgrade plan mitigated the risk of this type of problem by retaining the last-moment instance of the 7.3 install. For people that need the historical data, I have an instance of 7.3 as it existed on July 2nd, and I grant people a logon to use that version of Angel to retrieve survey or quiz results. Any assessments taken after 7/2 on the new system are available normally.

Angel 7.4 has been running for 2.5 weeks as of this post, and although not without problems, the upgrade has had less impact on day to day operations than has previous upgrades.

On July 21st there was a UITS infoshare on the new Footprints service desk application which has taken the place of the old Falcon service desk, or ticket tracking, system.  In June, UITS completed the migration from Falcon to Footprints, so today was a brief demo of the product.

Owned by a company called Numara, the software appears very flexible and configurable and is very customizable due in part to the fact that when clients purchase the software, they get the source code included.  IU has already purchased 100 concurrent seats and has the ability to purchase more on an as needed basis.  There’s no charge to IU departments for one of the concurrent seats, but if a department wanted their own “fixed seat”, there would be a cost involved.  Several departments are already using Footprints including LSP services, and the Department of Medicine and Nursing.

For departments to try Footprints out, they need to request a test project via a upcoming web form via https://footprints.iu.edu/projreq. UITS will create an instance for the project and it will be in a “testing phase” until such time as the department has prepared the application and it’s admins. have attended a 1 day training session. Once the departments project has been fully tested and UITS admins have been given ample notice, then the project will move from a testing environment to a production environment.
One important note on the role of the Project Admins., the UITS presenter did stress that when in testing phase, the project admins have full power over their project instance, but once it goes to the production environment, their powers are diminished dramatically (to the production instance of the project, not the testing instance.)

The applications organizational scheme consists of individual “projects” which would be various departments or teams instance of the Footprints application .
Project administrators–all rights and control over that departments instance (IU would like each group to have at least 1 admin and an alternate/backup.)
Agents —other support team members with specific rights
Issues— are request tickets in the system

All in all the Footprints application looks promising and it looks like it’s worth it plunge in and get a testing project. We really do need to address our lack of an efficient support tracking system for Educational Technology, and the Angel system.
for more on this topic check the UITS KB on Footprints…

As with the database table changes, there was a need to modify the sync scripts and clerkship reports files for the new school year.  Previous years have had little modification in the sync scripts and clerkship reports.  However, this year, I needed to make adjustments for the different tables that now store data for clerkship encounters and BCS encounters separately.  These modifications had to incorporate features that would know which database table to retrieve BCS encounters, depending on the year’s reports being viewed.  For instance, up until the 08-09 school year all clerkship encounter data, including BCS data was stored in the same db table.  The 09-10 school year’s BCS data along with future year’s BCS data, will be stored in separate db tables.  When a student, clerkship director, or CERTTS admin chooses a report year, the clerkship reports and admin tools need to know which table/tables to query the data.  Sync scripts also had to be modified to write Pendragon data to the correct db tables.  CERTTS admins have some additional tools they can use to create encounters, copy table data to other years, create BCS encounters from clerkship encounters, etc.  All of the student, clerkship director, and admin reports have been modified and are reflecting data correctly.  All sync scripts and admin tools are creating and modifying encounters and encounter data correctly.

With the new school year, there was a need to update the Pendragon clerkship forms that the students use to log encounters with any modifications desired by the Clerkship directors.  Each form has been modified based on the new requirements and will be distributed to the students during their next hotsync.

Dr. Humbert requested an Excel spreadsheet of BCS data for the 08-09 school year.  He wanted to review all encounters logged as BCS so that he may be able to detect trends in logging encounters.  That data has been exported into an Excel spreadsheet and sent to Dr. Humbert for review.  There may be some adjustments in the types of column data he would like to see in addition to the already created report.  If so, an updated report will be exported.

The new database creation process for the end of the 08-09 school year and beginning of the 09-10 school year is complete.  This year the update/creation process was quite a bit more involved than previous years.  Dr. Humbert (BCS Clerkship Director) wanted the BCS reports to reflect data for students throughout their 4 years of logging BCS encounters rather than just the current year as previously developed.  Therefore, I created a separate database table to hold BCS encounters separate from all other encounters.  This also caused the creation of a separate procedure, diagnosis, history and miscellaneous tables for BCS encounters.  BCS data from the 08-09 school year had to be moved from the original tables to the newly created tables so that the student reports would reflect correct cumulative BCS data for the new year.  Along with the creation of these new tables, the sync scripts need to be modified for all forms that need to write a BCS encounter to the database.