The Ohio State University Libraries has a blog post and linked report on their recent work on a digital exhibits pilot project. The report is well worth reading because it details the process, including goals, findings from the process, and next steps; this includes a technical review with review of the functional requirements (system design) that then extends into non-functional requirements (system architecture: scale, interoperability, extensibility, supportability etc.) during the testing of the pilot project:
The project leadership asked IT to create a default ‘OSUL’ theme for the Omeka instance, and a customized theme for the exhibit. While they were successful in doing so, Omeka does not handle the two themes gracefully – the exhibit itself is beautiful, but whenever the user draws upon functionality available through Omeka itself, rather than through the exhibits plugin, it would revert back to the default theme. This awkwardness was also evident in the navigation structure.
Scalability and sustainability
In theory, a new exhibit without customizations could be created in our existing Omeka instance with negligible investment of IT time. A customized exhibit could be added with approximately 40 hours of work by someone with intermediate knowledge of PHP, HTML, and CSS.
In practice, few Omeka adopters use the platform this way – instead, almost all of them install a new instance of Omeka for each project/exhibit. When asked why, they cite the same theming and navigation awkwardness we experienced, and the software’s less-than-graceful handling of multiple collections and exhibits. The Omeka development team itself has acknowledged this problem, and is working on a multi-site version of the software that will allow a user to easily create ‘separate’ Omeka sites on the same platform. ‘Omeka 3.0’ is expected to be released in fall of 2014, and it is not yet clear exactly how it will work or how best to structure work in Omeka 2.0 to be compatible with it when it launches.
The ability to use a single Omeka instance for multiple exhibits was one of the cornerstones of our programmatic approach to digital exhibits. The data we gathered on expected time to create future exhibits was based on using Omeka this way. With some development work on our part, we might be able to get Omeka to work the way we expected it to, but we would be fighting the current of developing practice in the Omeka community. If we decide to adopt Omeka for digital exhibits, we will need to look carefully at the most sustainable way to handle this problem.
This is just a really useful example of evaluating functional and non-functional requirements and the importance of doing so. Non-functional requirements can be difficult to evaluate without testing, which is why it’s so important to test real level, especially for scale. There are many demos of great looking software for a demo-world, but where that software fails at any real environment (one example is a simple digital asset system that would take 20-30 seconds to serve anything for the web page when a basic search is done, and other painful issues). Being able to document the importance of non-functional requirements in testing and reporting is useful in helping to communicate how software and technology should work, and to making sure it does what we need.