How To Use AEM Assets In A More Streamlined Way, Part 1
Paul Legan, April 27, 2016
In this blog post we'll follow an asset along its path from ingestion, to collaboration, to distribution. This is often an extensive journey for an organization to undertake with many assets. But with AEM Assets there are several ways to prepare for and ultimately optimize this process to not only save money but hopefully your sanity.
Presented by: Vebeka Guess, AEM Product Marketing Manager, Adobe
Paul Legan, Managing Partner, 3|SHARE
Ben Cherian, Senior Developer, 3|SHARE
[Transcription, edited for length]
Vebeka: What we're excited to share with you today is about how to control and deliver your digital assets and deliver them from anywhere to anywhere. And to kick it off, I want to share with you a couple of recent statistics that we found that really starts to illustrate how content is becoming more important to consumers and marketers.
An average consumer is engaged with 10.4 pieces of content prior to making a purchase decision. And they're five times more dependent on content than they were five years ago. So what does this mean?
Well, rather than maybe going into a store and talking to a sales associate or talking with friends or colleagues in order to learn or learn more about a purchase that they're interested in or a service that they're interested in, consumers are more than ever likely to turn first to a digital device or web content to find out more about what they're looking for.
And of course, they're probably viewing on a plethora of different devices, mobile devices, any kind of screen, high resolution tablets, etc. to get that content. And for marketers, this high demand for content across any touch-point screen or device is really causing a lot of stress in the organization for content producers and marketers as well.
In a recent survey that we did with IDC, we found that 85% of marketing and creative professionals were under more pressure to create assets and deliver more campaigns quickly than ever before. And the majority of them were creating 10 times the number of assets to support this increasing number of channels that they have.
In order to produce and manage and deliver this content to all these channels, you're also depending a lot more likely on external agencies and teams and partners to help you do this throughout your content production and management and delivery throughout this customer life cycle.
At Adobe we've developed a product called Adobe Experience Manager Assets that is very unique in that it helps create a professional and marketing line of business users collaborate more effectively to create assets that are engaging for their consumers to be able to manage them across the life cycle of that asset. To make sure that they're easily searchable and able to be used by the partners and teams that need you to deliver those engaging experiences out to their channels.
And so, I now turn it over now to Paul Legan and Ben Cherian from 3|SHARE for the demonstration of this webinar.
Paul: Thank you, Vebeka. First of all, hello and thank you all for joining this webinar. My name is Paul Legan and I am a managing partner at 3|SHARE which is an Adobe business partner. As an Adobe business partner, we've been fortunate enough to help many organizations with their AEM Assets implementation. So hopefully, we can be informative for you this morning.
The overall approach we've taken with this webinar is to essentially follow an asset along its path from ingestion, to collaboration, to distribution. This is often an extensive journey for an organization to undertake with many assets. But with AEM Assets there are several ways to prepare for and ultimately optimize this process to not only save money but hopefully your sanity.
But naturally, all of this starts with an asset but we wish we were that lucky. More likely, there are about 10,000 or 100,000 assets that we're trying to deal with. And many of these assets come from a variety of sources and oftentimes their locations aren't even known at the start of a project. And actually, that's the fun part of the project is finding out exactly where an organization has stored their assets across different departments.
Now, these assets can have many meanings to many different people, and each group may have different methods of defining how assets relate to each other within an organization. But the bottom line is that all these assets are valuable. And a majority of that value comes from a common place and that's metadata.
Metadata is a set of data that describes and gives meaning to other data. There are certainly many ways to interact with this data and AEM Assets is just one of them. But in the case of assets, oftentimes this metadata takes the form of file properties or data embedded by the software or hardware that produced the asset.
Smart people have determined that there should be synergy behind this metadata. So there have been organizations that have created things like IPTC or XMP or ID3. So for example, a camera will store information about where a photo was taken or the specifics of the camera mode aperture that sort of thing, and that's embedded in the file itself. Creative Suite applications store license usage and attribution data within the files that you manipulate.
Now if anyone has ever managed a large music collection they know the power of properly tagged files and the aggravation of improperly tagged files. And now, I'm sure nobody on this call would have ever used something called Napster because it was illegal but if one had used Napster, would have been disappointed by users who put the wrong metadata on music files and confused others trying to download music. Again, not something anyone on this call would do but worth mentioning.
So fortunately AEM Assets can help you make sense of all this metadata right out of the gate whether by extracting it for you for later consumption or logically grouping assets by metadata for easier retrieval later on.
That said, this takes some planning. And so after implementing AEM Assets across a wide variety of clients, there are some kind of key things that we recommend doing and not doing.
Let's start with some things that you should not do. As an organization, you should definitely not assume that all existing assets are needed, especially in terms of initial migration. Oftentimes assets are kept in archival folder, that sort of thing and they're not needed in a new system. The phrase, "garbage in, garbage out" comes to mind here.
Secondly, don't forget to include legal or regulatory if retention policies are needed in your industry. This played a huge part in the pharmaceutical company that I was at before 3|SHARE where there was a lot of back and forth about which assets need to be retained and for how long. So this is something that should be discussed well before an asset migration from either an existing system or network drive.
Thirdly, do not forgo a taxonomy planning session. Despite it being just a bullet item here, so as not to belabor a somewhat boring topic, establishing a taxonomy to describe your assets is critical to the success of asset ingestion.
Now finally, do not go into a project with the intent to migrate all your assets at once. It's very common for us to see phase approaches to asset migration, specifically around choosing which assets are managed day-to-day in the future or currently like as we're speaking about a process in the project. And then later phases, you may want to migrate the multitude of assets that you have stored elsewhere for legacy assets for example. So phase approach is generally a good way to ensure success for an asset migration especially a large one.
So some things that you should do. Definitely identify which metadata properties you intend to manage in AEM. Tagging in a taxonomy is one field and it represents essentially a subset of all the different metadata properties that probably are useful within an asset's life cycle.
Also, very important to clean up previous versions of assets that are no longer needed. We're going to be talking about dynamic media later on and we're going to show how the same asset can be used to dynamically, I guess, render itself to different devices in different ways depending on the bandwidth or the type of device. So you may not need the number of assets that you currently have in the future.
Also, assess the current production process to identify pain points. There's a powerful workflow engine within AEM Assets and this is something that we would like to make use of and most clients find a lot of value in. So it's often a very good idea and exercise to assess the current process and see where things are breaking down.
Lastly, consider folder structure and a permission strategy that scales. Folder structure essentially determines how users can see assets and how users can contribute assets to AEM Assets. So I think that the most important thing here is to remember that this is something that is much easily, much more easily established upfront than jerry-rigged in later on.
Okay. So with that said, let's assume we've gone through this checklist and we're ready to begin our migration. The first thing to know is that AEM Assets provides several ways to upload assets and this is critical for adoption within an organization.
So at a bare minimum, there's a browser-based interface that lets you upload assets directly. These assets can come from a network drive, your local laptop, anywhere that you can actually drag a file into a browser.
Now this is great for a lot of people and this is the base use case. Everything that's supported out of the box is obviously supported by this method. However, it often requires a bit of work to get everyone in an organization to use the same method of uploading just given their roles and their backgrounds.
AEM Assets also provides various ways to call their API. So you can script asset migrations of a larger size, or you can utilize let's say an FTP sync, or you have a process that watches an FTP folder and automatically downloads and syncs those assets with an AEM Assets installation. So there's a lot of power and that's all based on the REST-based API provided by Adobe.
There's also WebDAV or network shares. So a lot of times, creative let's say vendors who are doing photography for a large organization will not necessarily need log-ins or will want to be part of the entire review process for an asset's life cycle. Therefore, they just need a way to upload in bulk let's say 1,000 photos and again, they want the most easy interface that they can have and perhaps WebDAV or network shares is after that.
And then finally, Adobe provides an app called the Companion App which essentially mounts the drive on your local device, and lets you interact with the assets as if it was a drive in your computer. It also has a tight integration with the UI itself within the browser so there's an easy way for you to abstract that whole entire user interface.
AEM Assets supports the following, WebDAV, browser-based uploading. There's a native companion app and then there's a REST API that could be called either from the command line using CURL or a variety of programming languages. Naturally, the last option is where things get interesting.
Over the course of the last couple of years, we've had a variety of clients and a variety of use cases for asset migration. Sometimes assets need to be migrated from one environment but the metadata is stored in a completely separate database. Or we have situations where a creative process or a creative project, let's say a work order or a request to have a photo shoot with the vendor, all that information wants to come from a multitude of different people and we needed an easy way to do that. So using the REST API, developers can build their own form and their own import tools that essentially provide a nice interface to perhaps ugly legacy systems. And it can replace the entire legacy request process for again new projects or new deliverables within AEM.
Now, it's important to note that while many organizations, AEM works first integration with grid actually, there's no reason why you can't build upon the topics we're about to discuss for non-visual documents such as Microsoft Office documents and even documents like PDF, that sort of thing. We're going to be talking a lot about assets like creative files like Photoshop files, Illustrator files but again this applies to all assets.
That said, we've identified a process. Actually, we have several interfaces into how we can ingest the assets themselves. But the real beauty within this architecture is the workflow engine that acts upon a simple system event like an upload to automate tedious tasks.
One such workflow action is metadata processing profiles. So a processing profile is essentially a set of default data that can be applied to any asset uploaded to a specific folder or a set of folders. This significantly decreases the time it takes to migrate large amounts of data. So not only can you set default values but you can also infer data based on let's say file name or again the deep folder structure that you have.
A perfect example of this is we had a client where there are a lot of events and each event has a photo shoot as well as some deliverable assets, sort of some PDFs, collateral, that sort of thing. So they established a folder structure such that when they dropped these PDFs or photos into a folder, 8 of the 10 tags that apply to the asset are automatically tagged. So the only thing that people have to do is go in and tag let's say who the photo is actually up or the most specific element of the PDF. Everything else is taken care of automatically through the use of this metadata processing profiles.
The other good part is that these profiles, among other workflow steps, can be applied to any asset that's uploaded through any method. This is not restricted to one method or just browser uploads or web dev uploads. Anything can be done and anything can be triggered off any event in the system.
So how does your organization benefit? Through the use of these workflows and ingestion frameworks, you significantly reduce the effort to upload and tag assets and that saves money. Creative people in creative industries should be spending their time being creative and less on maintaining asset metadata.
And also very important is whenever you introduce a new system into an organization, adoption rates are critical to the success of the platform. And so Adobe has taken a lot of steps especially through the use of several types of user interfaces to make sure that everyone feels comfortable utilizing AEM Assets.
With that, I'm going to turn it over to Ben Cherian to give a demo of some of the things we just discussed. Ben?
Ben: Thanks, Paul. Often when we get clients who are migrating their assets, current asset systems from a previous system, this can be an enterprise DAM solution, it could be a custom homegrown application, or it might be just be a basic folder structure that they maintain manually whether it's on their own computer or in a network drive.
Here, I've created a folder structure where I have categorized my images based on different categories here, and I have images in each of these pads. And it seems like that's well maintained. The problem is when we get into hundreds or thousands of images, this folder becomes unwieldy and harder to maintain.
The other thing is with these file names, I have metadata in the file names using these underscores. What I like to do is be able to search by this metadata. So when we're importing into AEM, what we can do is change the folder structure but maintain this categorization here. We can use AEM tags. If we look behind in the browsers, this is AEM tagging interface and we create an image category based on this folder structure.
And we're also taking this file name that's separated by underscores and store that as metadata. And the third thing we'll do is reorganize by the date that the file is modified which would create a better folder structure for the users to use.
We have a migration tool that we've created for this client, and we specified their source path, our destination within AEM. We have an option here that we can publish assets right away but we're not going to do that right now. And we're going to sort these assets by the week in which they are created.
We start our migration and I would go into the Assets folder and refresh. We have our assets part folder, and a year and a week of the year, and we have our assets loaded in here. And if I open up the properties of these assets, they have some metadata which has been pulled in from these assets itself such as width and height. It shows when it was created, it has the type of the image.
If I go into style and color, these are custom metadata fields that I've added. And so it's pulled that information from the file name. Here's the style and this is what the style is in the file name. Here's the color code and that's pulled directly from the file name. So we customized the script to be able to weave in that data that they currently manage manually and pull that into AEM as separate metadata fields. The schema is something you can customize and edit. So we have many fields here that can be used to modify the metadata on this asset itself.
Now we can also integrate with external systems. If I pull up this image here, I've taken that style, color, and graphic that it had previously, and then mapped it to an external system and pulled in additional metadata from that system. That's another way we can import other metadata and integrate other systems within AEM.
So what we've done is we've taken our current business rule, the current business practices, create and taken the features and technology within AEM to create a better taxonomy and content structure that will make it easier to organize our images, easier to organize and maintain our assets, and easier to add metadata and find the assets later on.
Itching for more on AEM Assets? We're the AEM experts, so we can help. Get in touch to learn more, or ask us about SWIFT - an AEM quick-start that delivers everything you need in an AEM Assets implementation in 8 weeks or less.
Paul Legan is the Chief Technology Officer (CTO) at 3|SHARE with significant experience architecting user-centric web and mobile applications. He takes his work seriously, but it's nothing compared to his focus on finding the best happy hour around.