Presentation for the 18th EUNIS Congress

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
institution’s 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” can’t 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 can’t 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 else’s 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 can’t publish everything -> If we can’t find
someone responsible, we don’t publish it, but…
• The more you publish, the more people push for
more information to be published -> We don’t
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 don’t let them use
the information in their sites, they’ll copy/paste -> Let
them re-use the same information so it’s 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 it’s 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
don’t need to know” philosophy behind
• Keep adapting the information. The only thing
that does not change is the need to change.