When the system went live in 2011, it incorporated the requirements of four different business units. During the development process, metadata fields were added anticipating future functionality or to create an exhaustive list of descriptive information. The list grew as each group identified what seemed to be unique details or processes. The result was a fairly large set of metadata (50 fields!). Before launch, we reviewed the overal set and developed a custom profile for each group. Here's an example, from our Photo Video unit:
You can imagine that this list might be somewhat daunting for new users! Keep in mind that some fields are left blank for certain files, and some are automatically captured.
"Make it simpler"
If all our staff feedback could be reduced into a single idea, this would be it. Even a seasoned cataloger might be challenged by our set of metadata at first glance. Given our distributed model, in which individual units and staff are responsible for uploading and describing their own content, overly complex metadata represents a serious impediment to consistent adoption for graphic design project files.
This review project will reduce the barriers to sharing by streamlining description, upload and searching for files. Some fields might be "nice to have", but are they essential to share photos? Are they necessary to describe most graphic design project files in Information Production and City Planning? We will consider the benefits of each metadata field against the staff resources required to complete them.
Principles to consider when evaluating metadata fields to hide or remove:
Fields with no current functionality. Example: Records Classification Code. This was included anticipating lifecycle management, but was not budgeted for in our first phase. The field can be hidden. It may be reused for administrators only at a later date, if we choose to implement.
Fields that are unused. Example: master/source file location. Intended to capture the location of high-resolution master video files, this field has seen limited use with only a small set of videos uploaded. Managing the master-derivative file relationship is a larger issue that requires an approach across all asset types. The field can be hidden.
Fields that duplicate information available in other systems. Example: Creator contact info. Static contact information stored in DAL becomes less useful over time as staff move to new positions or leave the City. City staff contact information is also available from our email system. This field can be hidden.
Fields that are not needed for a user group's primary content. Example: Date(s) of Creation. This Archives field provides space for a variety of date formats when the actual date the photograph was shot is unknown. A sample value might be ca. 1910. This is important descriptive information for Archives, but not needed for groups whose content is born-digital and have another field with a validated timestamp format. This field can be hidden for non-Archives groups. It may be made visible to other groups when needed for search, as part of a future customization.
Fields that are only required for specific asset types. Example: Related Images. This field is only used when Consent Forms or Client Request Forms are uploaded and linked to their related images. It can be made visible only when those asset types are selected.
These principles should help guide our work to simplify our system and lay the groundwork for expanded adoption. In my next post, I will examine options to improve the remaining core fields and controlled lists.
No comments:
Post a Comment