Collections Exposure Functional Analysis
Overview
Our current CMS supports publishing collections information to a publicly available website, collection.movingimage.us.
User Interface - MMI Staff
MMI staff with write permission to catalog records may publish records to the publicly available site. Records are published by changing an object's status to "completed/publish."
Use: Frequent
Notes:
- Any user with write permission can change a record's status, and there is no warning given when making changes to a record that is live on the public site
- The summary pages gives the user a preview of how the record will look on the live site
User Interface - Public
MMI's online collection catalog is available to the public via the URL http://collection.movingimage.us. No login is required to access the catalog.
Screenshots:
Catalog front page
Catalog search
Catalog search results
Catalog record detail
Backend
The public facing site is essentially a stripped down version of the staff CMS but lacking all editing controls, administrative controls, and editing history. The only pages used from the CMS are the search results and artifact description pages. These pages are built from php templates and the public facing site has been altered to match the style of the entire MMI site.
The code base for the public facing site is the same as the staff version so the two integrate very well. Read access to artifact information, images, and relationship details are accessed directly from the same database as they are written to from the staff version. Again, there is no write access from the public facing site.
The Collections landing page shows a current count of artifacts in the collection. This is a simple php script on that page's template which sends an SQL query to the database. This query merely asks for a COUNT of all artifact records in the database.
Field level access for records are controlled from two fronts: database access and template design. There is no easy configuration file to limit which fields are fetched from the database; although, this is configurable from the code itself, albeit not easy for an untrained maintainer. Secondly, the templates themselves call for specific content from the object record and simply removing the template field blocks that information from being seen by the public. Likewise, field labels can be edited quickly by changing the respective templates.
Some published artifacts do not have an accompanying image representation. Rather than leaving the image space empty on the public interface a "no image available" placeholder image is used in that place. This image is not directly associated with the artifact record. When a user runs a search query or views an artifact page then special code checks to see if the artifact has an image representation. (More specifically, a script checks for a string containing the address of the image – the backend of the CMS constructs blocks of html that get hooked into the template.) If there is no image associated with the artifact then a link to the placeholder image is used. (The address and height/width of the placeholder image is written into the html block for the template.) This is applicable for all image sizes: thumbnail, medium and large.
All thumbnails on this CMS were derived from a large original file(s) for that artifact. These thumbnails maintain the original's aspect ratio but have a maximum of 120px for either height or width. This leaves many thumbnails which have a height or width of 120px and the corresponding side of a value less than that. The current design for the public interface calls for thumbnails that are square, 100x100px. Since the thumbnails are not of a uniform shape and ratio a script was created to automatically re-size the images, with respect to aspect ratio, if either the height or width was below 100px. Having a measurement less on any side than 100px is common. Additionally, the same script creates special css positioning values to 'center' the image within the 100x100px square with the remaining image overflow hidden from view. This means that for every thumbnail on the public interface a script has adjusted that image's size and positioning using HTML and CSS. The original thumbnail isn't directly altered and maintains its original format.