Eunis 2012 42
- 1. Publishing academic information as a sanity check for Higher Education Institutions' information systems EUNIS Daniel L坦pez ( D.Lopez@uib.es ) Isabel Perell坦 ( Isabel.Perello@uib.cat ) July 2012 Carlos Juiz ( CJuiz@uib.es )
- 2. Publishing academic information why? Providing accurate information helps current and prospective users (students, staff) In some cases, it can even be a requirement (legal or institutional) It alleviates the load on human information services, which are more costly. Transparency helps because: It improves institutional image It serves as external sanity check of the data stored in the institutions information services.
- 3. Is it as easy? Detailed academic information is more complex than what it looks like at first sight: Degrees, studies, campuses, subjects, groups, academic years, taxes, teachers, languages x scheduling x size Publishing it does not have a direct measurable ROI, so it can be a tough sell. The solution has to balance accuracy and cost- effectiveness. Biggest hurdles are not just technical but institutional
- 4. The devil is in the details Information changes at specific periods There are tons of specific details that seldom change, but change in batches Keeping them all updated manually is error-prone. Read/update ratio is very high SEO (Search Engine Optimization) is important Displaying detailed live data can be quite costly
- 5. How do we do it? We developed an application that gathers information from different systems and publishes the information in web form (html, PDF) The database content is combined with information introduced at the institutional CMS for specific data that is not considered institutional information Custom texts/recommendations for studies, subjects Data not yet taken into account at the IS and can be introduced manually while the service is. So far, a typical web application
- 6. How do we publish it? I One option would have been to implement a dynamic cache. But There usually are no real hot topics Search engine crawlers browse it all, and you want it to happen If the system goes down, a huge number of pages can be affected Nothing that money cant fix, but is it worthy?
- 7. How do we publish it? II We opted for a static dumb cache -> the file system . An specifically developed application takes snapshots of the information and stores them as files. The institutional CMS uses those files and formats them appropriately using its own template system. Snapshots are taken: Periodically (usually daily) for most of the information On demand, implemented by applications, for specific sensitive data that requires a faster refresh By hand, when there is a specific change that cant wait until the next day
- 8. How do we publish it? III We also publish the same information as components for the CMS, so editors can use them at their own web sites (department, faculty) The Web Office acts as a hub to redirect questions, requests, complaints about the information published or to be published. There are flags that are automatically and/or manually operated that control which information is published. Ex. During the transition from one academic year to another, some data is not published until officially approved.
- 9. Does it work? It does! . Publishing application can be offline. Access is as fast as any other CMS content, with no extra cost. The quality/quantity/detail of the information published has grown tremendously. User feedback (internal and external) has helped purge/refine the information at the information system. In use since 2007, the same technique is now being used for other types of information due to its success.
- 10. Pitfalls Technically there are no big problems but simply implement it the most efficient way. The institutional front is where the biggest hurdles are found: Defining the information to be published and how it is presented (devil is in the details). Defining who is responsible for the information (nobody wants to assume responsibility). Getting the flow of error detection/notification/fix to work (it is always somebody elses problem). Getting the information to be published in the system (the web is usually considered low priority)
- 11. What did we learn? I Just publishing what it is at the institutional databases is not enough -> CMS to introduce custom texts You cant publish everything -> If we cant find someone responsible, we dont publish it, but The more you publish, the more people push for more information to be published -> We dont wait to have it all to start publishing: Publish and they will come
- 12. What did we learn? II Initial stages are hard -> Be ready for changes Information that had never been published contained many errors (that were being worked around by hand) and nobody was responsible. New features/requirements pop up only when people look at the information. Feedback/changes, specially at the beginning, come in waves, when new sets of users start really looking at the information. Allow information to be shared. If you dont let them use the information in their sites, theyll copy/paste -> Let them re-use the same information so its always up to date.
- 13. Trivia UIB: > 14K students, >1.2K lecturers, 3 languages 97 degrees (42 studies), 35 postgraduate courses, 29 PHD programs, 3.4K subjects Overall generated information: 2,9 Gb (>100K html, >20K PDF), including archive. >36K pages refreshed daily in <4h ~12 pages/day refreshed on demand.
- 14. Conclusions In order to publish detailed information, the institution has to be really involved It is a heavy boulder to push Transparency forces changes deadlines, stored information are now public Change takes time, but its worthy Build the new system/culture, step by step
- 15. Future work Publish even more information Improve user involvement and encourage feedback Focus on transparency and leave the they dont need to know philosophy behind Keep adapting the information. The only thing that does not change is the need to change.