Uploading and describing content in a digital asset management system requires an efficient process, easily integrated into people's daily work habits. In December we kicked off a project to design and implement a simplified workflow for managing design products, taking advantage of our new embedded metadata (XMP) standard. Sometimes talking about workflows can feel like dancing about architecture, so I decided to try a more hands-on workshop as part of the project.
Showing posts with label improvements. Show all posts
Showing posts with label improvements. Show all posts
Friday, 3 January 2014
Thursday, 1 November 2012
metadata - use it or lose it
Over this fall I have recruited representatives from our participating units who are working with me to simplify our digital asset management system. Not surprisingly, we have no shortage of ideas for new functionality or updates! However, our challenge has been to develop recommendations that we could implement ourselves, without requiring expensive customizations. We focused on simplifying the descriptive metadata that must be applied to assets when importing.
As discussed in my previous post, there are principles we can apply when considering which metadata fields to hide or remove. Streamlining also means reworking the remaining fields so they are easier to use for all groups. Here's a few more general principles derived from experience and information standards:
As discussed in my previous post, there are principles we can apply when considering which metadata fields to hide or remove. Streamlining also means reworking the remaining fields so they are easier to use for all groups. Here's a few more general principles derived from experience and information standards:
- Use it or lose it
- Mutual exclusivity
- Use the language of your users
- Use terms important to organizational context
Tuesday, 16 October 2012
Principles for simplifying DAM file descriptions
Our digital asset management project was launched with a goal of making it easier to find, share and reuse images and graphic assets across the City of Toronto. Participating staff can now access images from the official photographers and the City Planning photographer from a central location. After 1 year of use, we are in a good position to look for opportunities to improve for existing and future users.
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.
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.
Wednesday, 22 August 2012
Reuse - the beauty of embedded metadata
My Digital Asset Library (DAL) plans for this year included improving our capacity to manage working files and making better use of embedded metadata. These two goals came together as several staff in Information Production and City Planning participated in a working files pilot. Their feedback made clear we need to make it easier to upload, describe and reuse files. Both Information Production and City Planning, Graphics & Visualization have similar business processes, creating new design projects using Adobe Illustrator and InDesign, linked to the raw graphic & image files, and often reusing existing content.
Pilot participants noted that applying detailed metadata to the many distinct files that make up a single design product could be very time consuming. This process is quite different from uploading a batch of event photos, which all have the same metadata. We decided to re-examine how we can simplify the process of uploading and tagging files.
As a first step, we focused on making it easier to reuse files and metadata. If an event photo or graphic has already been described in DAL, we wanted that information to stay with the file once downloaded. It became clear we needed to develop an embedded metadata standard. Using Adobe's XMP technology, embedded metadata allows descriptive information (such as creator or keywords) to be written directly in the file and be read and written by different compatible applications. The first implementation of the standard will automatically apply metadata to files on download from DAL. This will save time since the files will not need to be described again if they are modified, reused and/or uploaded.
Over the summer I've worked with representatives from each business unit to develop our embedded metadata standard. I'm pretty happy we were able to identify a core set that everyone could agree on. Taking the time to debate the implications of choosing particular standards and mappings was very useful to gain consensus. Throughout the process I emphasized that this standard was our first version and not set in stone. It will change as we gain more experience and our requirements evolve. I think acknowledging the provisional nature of this particular set of metadata properties was very helpful.
We were able to build on existing mappings used to embed metadata in Archives' photos prior to upload into DAL. Looking outside the City, the Smithsonian Institution provided excellent perpective and advice with their Basic Guidelines for Minimal Descriptive Embedded Metadata in Digital Images.
We've identified 16 fields that can be embedded. Not all fields are used by all participating groups. Some are interoperable with the Dublin Core Metadata Standard, the City of Toronto Descriptive Standard and IPTC (the default fields used in Adobe CS products), while some are DAL custom fields.
We are now working to secure funding for professional services to implement our standard in DAL. Working closely with the business representatives, I have a much better understanding of their needs. Using this standard for embedding metadata in downloaded files is really a first step towards an improved model for managing working files. We will continue to plan further improvements to our metadata creation and uploading model to drive adoption, file reuse and effective search.
Pilot participants noted that applying detailed metadata to the many distinct files that make up a single design product could be very time consuming. This process is quite different from uploading a batch of event photos, which all have the same metadata. We decided to re-examine how we can simplify the process of uploading and tagging files.
As a first step, we focused on making it easier to reuse files and metadata. If an event photo or graphic has already been described in DAL, we wanted that information to stay with the file once downloaded. It became clear we needed to develop an embedded metadata standard. Using Adobe's XMP technology, embedded metadata allows descriptive information (such as creator or keywords) to be written directly in the file and be read and written by different compatible applications. The first implementation of the standard will automatically apply metadata to files on download from DAL. This will save time since the files will not need to be described again if they are modified, reused and/or uploaded.
We were able to build on existing mappings used to embed metadata in Archives' photos prior to upload into DAL. Looking outside the City, the Smithsonian Institution provided excellent perpective and advice with their Basic Guidelines for Minimal Descriptive Embedded Metadata in Digital Images.
We've identified 16 fields that can be embedded. Not all fields are used by all participating groups. Some are interoperable with the Dublin Core Metadata Standard, the City of Toronto Descriptive Standard and IPTC (the default fields used in Adobe CS products), while some are DAL custom fields.
We are now working to secure funding for professional services to implement our standard in DAL. Working closely with the business representatives, I have a much better understanding of their needs. Using this standard for embedding metadata in downloaded files is really a first step towards an improved model for managing working files. We will continue to plan further improvements to our metadata creation and uploading model to drive adoption, file reuse and effective search.
Subscribe to:
Posts (Atom)
