Using a Course Management System to Manage Promotion and Tenure Review Documents

First off, let's get right to the first question. Gasp!!! Yes, it has been over a year since my last post to this blog! The cob webs have taken over and the number of readers has dropped. While I have a regularly scheduled event on my calendar to create new entries, well, work has gotten in the way. Fortunately, my lame excuse is also a good topic for a post!

As regular readers of this blog are aware, one of my regular themes is related to scholarly communication. More specifically, the broadening of what is considered as scholarship for promotion and tenure purposes. During the past year, I have been serving as the Procedures Oversight Designee (POD) for the Ohio State University Libraries. In short, my role is to help ensure that the P&T reviews follow the procedures as defined the Board of Trustees, the Office of Academic Affairs, and the Libraries.

In addition to the normal workload required when taking on such a role, there were many significant changes made to our review process PLUS we experienced a bit of a 'baby boom.'  Until this past year, a committee of tenured faculty consisting of about 1/3 of the eligible voting faculty review all cases. Given the size of the review group and the fact there are normally around 3 cases to review annually, materials were made available in a single paper dossier stored in our HR office. Committee members checked them out and reviewed them on site. Given the scale, the system worked.

Last year, our faculty voted to change the review procedures so that all the eligible faculty would review all the cases. At the same time, the number of cases scheduled for review was 4 times larger than usual. Having almost 40 individuals descending upon HR to review over a dozen dossiers made little logistical sense. This convergence of events required a significant rethinking of the method used to make the review documents available.

The solution was to create an eDossier system using of our course management system.

A 'course' was set up for the review materials with each candidate given their own content tree. All the materials that made up the physical dossier were were scanned and uploaded into the system. The total number of documents for all the candidates was just over 600. All the eligible voting faculty were added as students and were grated access to those dossiers that they were eligible to review. Access to materials was turned on and off as required by the review schedule.

While this approach required a significant time commitment on my part, it really represented a small percentage of the time saved collectively by faculty reviewers since they didn't have to take a trip over to HR to read paper dossiers. Instead, the dossiers could be reviewed online where ever and whenever. I had one faculty member comment that they even reviewed materials on their iPad while waiting at an airport.  There will be additional workflow efficiencies in future reviews since documents from pre-tenure reviews will be added into the system as they are made available.

Based on my experience, one of my new goals is to develop a plan that uses a similar approach to distribute materials to external evaluators. This will require buy-in from the Office of Academic Affairs.

 While the POD role is considered an overload responsibility all the changes turned it into a full-time job at times. Yet, I still had to manage it plus my regular job responsibilities plus keep a reasonable work-life balance. Something had to give, and it was this blog.

So, please accept my excuse for the long time between posts. It's good to see you again


Sphere: Related Content

Should Libraries Create Native or Web Apps?

I have been having an increasing number of conversations with colleagues about the creation of mobile apps. Much of the conversation is not about IF apps are needed, but instead they are focused on how apps should be developed.

There are two different types of mobile apps with each technique having advantages and disadvantages.

The apps one would find in the iTunes App Store or the Android Marketplace are known as "native" apps. Native apps are pieces of software that must be installed on the device and in most cases are downloaded from a distribution point. A Web app, on the other hand, is not a piece of software but a web site optimized for viewing on mobile devices. A well designed Web app can have all the look and feel of a native app.

Develop a Native App if:

• your library needs to take advantages of all the features built into the device itself. For example, to vibrate the phone or use GPS. However, this will be changing soon as HTML5 rolls out. Web application developers are already using solutions like PhoneGap, an open source framework suite that provides support for a variety of device features on a variety of platforms. (video)
• your library needs to make sure content or service is available offline. If the core purpose of your application is to make your content available without an Internet connection, then a native app is needed.
• performance and user responsiveness is crucial
  
• your library is looking to try to make money directly from the sale of the app
• your application needs to access the device file system
  

Develop a Web app if:

• your library web site has all the same content that will be featured in the app
• your library is interested in potentially reaching users on different devices and platforms with the same app. An Apple native app can only be used on iDevices and is not easily ported to other platforms such as Android and BlackBerry. Web apps are platform-agnostic.
• your library wants its app content to appear in search engine results. Library users are begin to demand that library mobile content shows up in those results optimized for mobile devices. Content is a native app will not show up in Internet search results.

General considerations:

• Native app development cold be more expensive than building web apps since a greater skill set is required to build apps for multiple platforms.
• Native apps requires the use a software development kit supplied by each operating system creator.
  
• Developing apps for multiple platforms would require a maintaining and creating enhancements for each.
• Native app user interfaces tend to be smoother and takes greater advantage of the full graphics capabilities of a device.
  
• Web apps require round trips to the server where the app is hosted whereas with a native app that time is almost instantaneous.
• Web app content us more current because it refreshes itself from the network.
• Most native app stores require approval. Web apps can be deployed immediately.
• Native apps require updates to be installed. Web app changes are immediate.
  
• Native apps may be more secure.

Resources:

Meredith Farkas. The Library in Your Pocket: Mobile Trends for Libraries

Brian Fling. Mobile Design and Development: Practical concepts and techniques for creating mobile sites and web apps

Lorraine Paterson. Designing for Mobile Devices in Higher Education Research

Sphere: Related Content

Technology in Use at 2011 North American International Auto Show

My buddy Jeff and I took our annual trip up to Detroit to check out the North American International Auto Show this past Monday. While we were there to see all the new automobile technology, I again paid attention to use of technology on the floor:

The Microsoft Kinect 3D controller was being used by both Chevrolet and Ford. Chevy had five booths with a side-by-side racing game to promote the Volt while Ford used it to capture images of attendees passing by a kiosk and then green screen the image over various backgrounds and displayed it. While many manufacturers had touch screen displays for product information, Fiat used Kinect to create an interactive display that was shown on a large display screen for everyone to see (ala Minority Report)

Chevrolet had a Camero flanked by cameras that produced 3D images.

Toyota had a touch-screen wall with three large video panels that allowed one to explore the Prius. Ford had a touch screen wall that allowed one to create custom paint jobs for the Mustang.

Technology/social media seen at past shows such as foursquare and Facebook were still in use. AutoTrader.com picked on the fact that I had checked in and sent me an @mention to flash their tweet at their booth for a prize. (I didn't catch the tweet)

Just two years ago only Kia was using QR codes. This year there were many. I wan't the only one snapping images of codes this year.

Flickr continues to be the image service of choice with over 3,500 photo uploads

Sphere: Related Content

Consuming Delicious Linkrolls

No. Linkrolls are not a delicious appetizer or a holiday baked good.

Linkrolls are a way to have Delicious bookmarks displayed as part of a web site or blog posting. Although the ability to create Delicious Linkrolls has been available for over 5-years now, I've only recently began to leverage the service.

As an example of how they can be used, I've been working on an ePortfolio to track references to my various scholarly communications, appearing both in print and online. After performing various searches for references, I bookmark the ones I find on my Delicious site, making sure to add specific tags. The saved bookmarks can then be searched, sorted, and imported using scripting made available by Delicious. After all the options are set, it is as easy as copying and pasting to get the targeted Delicious links embedded into a blog post or web page.

To create a Linkroll:

- Create or log into your Delicious account

- Add bookmarks with tags
- Go to http://www.delicious.com/help/linkrolls
- Change preferences, including appropriate tags
- Copy the html code into a web page or blog post. This will import Delicious bookmarks into any post or page.

The code generated by Delicious does not include any styling , so it may need some style tweaking. The imported content should blend in and adopt the look of your site.

Sphere: Related Content