What Does Contextual Image Delivery Mean for SDL Tridion Images?

+Will Price wrote a great explanation on the SDL Contextual Image Delivery in a DD4T setup. +Ian Homer adds even more context (pun intended) from a product and practical development perspective.

Let me add one more post try to compare SDL Contextual Image Delivery (CID) to what you may have done before with SDL Tridion and connect it to some business concerns and wins for managing and building websites.

Knowing and Solving the Right Problem

Before using or considering CID, you need to have this problem or question: "for a given (high-resolution) image, how should we handle displaying it in smaller sizes?" which I've been asked frequently by customers as described in my "Parking Lots" post.

If your default answers are:

• Markup via Responsive Web Design or HTML attributes or CSS for width and height
• Manually by creating multiple images versions (e.g. large/medium/small or full/thumbnail)
• Generated with maybe a DAM creating multiple image sizes

Then Contextual Image Delivery may not offer a solution for you just yet, but read on to see why this can be a significant tool for contextual Web development with SDL software. The documentation  (login required) explains the options Will and Ian mentioned:

• resize with cropping
• resize without cropping
• trimming
• format changes
• chaining these together

These are done by appending your image transformation URL with a command in the form of a path. For example, an original full-sized image might end with: /images/someimage.png. But making your server create version to fit 200 pixels would be: {image transformation url}/fit/200/source/site/images/someimage.png.

What might not be clear is that you can choose how to crop an image by trimming a consistent amount all around, certain amounts for top and bottom or left and right, or even an option for each side (functionally similar to CSS padding options).

"Classic" Image Variation Approaches

A series of commands and values (parameters) means this is easy-to-understand, easy to implement, and most importantly easy to template and manage for any setup you may have.. This is significant for managed multimedia across multiple contexts (hence the name Contextual Image Delivery) because up until now, using SDL Tridion you might:

• Bake in the Content Manager, by having authors upload multiple versions (small/thumbnail or large) or maybe using the Event System to automatically create versions (I haven't seen this in practice much)
• Bake at publish by having templates publish variations (called variants) to different locations on your site (content delivery). Typically you might have each template render its own variant of some to all images in the component. For example the summary template might create a thumbnail preview whereas the full template uses the original image. See an example from +Mihai Cădariu

Though you could also "fry" in your Web application or even with client-side code, this would be independent of SDL Tridion delivery-side features. Here's we're exploring "how would you do it with Tridion?"

Note: any approach also depends on the type of image and whether it needs to be the same image (but at a different resolution) or actually a different image. No single approach necessarily works for all images, it really depends on your types of content.

Business Wins

With this just released, I expect to see more community examples (update: Ian just promised a series of posts) and ways to influence these variations through the content management side. But you don't have to wait to understand the wins here:

• Authoring by reducing manual steps for authors where possible.
• Code by moving image resizing logic outside of Tridion-specific APIs to something Web developers might appreciate: Urls and possibly routing/mapping rules.
• Publishing by reducing the number of images published.
• Delivery by most importantly improving the visitor's experience and optimizing delivery of "right-sized" images.

To make this tangible, take any image size and quantity savings in publish or in delivery and multiply by both the size of your image library and the frequency of updates or visits. 

Keep this:

Get rid of this: x 5,000 images x updates in publishing and delivery, for example 

(I cheated as this is the same image, but I don't host that many images... yet)

Where to Start?

To realize these benefits I would first look at the quickest, most obvious wins based on your content model, architecture, and mobile (contextual Web) design approach.

1. Do you have "heavy" pages or image-heavy presentations that you'd like to take a single image to create multiple variations? Use the resize option for preview or thumbnail versions of your images. This can improve performance in publishing and delivery.
2. Are you using the Context Engine? In your if/else logic for what displays, choose the appropriate image size (or image variation).
3. Are you looking to optimize a Responsive Web Design approach, which may still send large images to visitors? Consider augmenting your approach with Contextual Image Delivery.
4. Of course follow +Will Price  and +Ian Homer  for additional details, examples, and implementation tips.
5. Have a question? Ask the community. Thanks to +Nuno Linhares for answering my first #contextual-image-delivery question on Tridion Stack Exchange.

If your image needs are already significant enough that you're using or are considering either a DAM (digital asset management) or MAM (rich media asset management like SDL Media Manager), consider combining the best of both:

• Large numbers of hi-resolution images that you don't have to host
• On-demand, cached, contextual variations for your visitors

Handle Context by Doing Less

The answer to large variations based on context isn't more variations to manage or publish. It's in deriving information based on context, even reducing the configuration of such variations:

It's in simplifying your BluePrint, through the minimization of localization and "omni-channel" (read that as less) content manager-side templating:

And now it's delivery-side, contextual images to let you focus on creating the right experiences for your customers.

Update (22 August 2014):
Product Manager Nuno Linhares pointed out the business often knows the right cropping and images for different contexts. Our Technical Account Manager Andy Lim reminded me the CID isn't just about resizing (see my point #3 above)--when used with the Context Engine we can combine a mix of authoring choice with presenting the right option (on the first hit, no less). Augment with your favorite HTML5 or client-side approaches for a high-performance adaptive and responsive approach.

To give authors these options, simply add additional image fields for these variations to your schemas and if needed, let authors add sizing requirements as well. Look at Custom URL extensions such as the (X & Y) Coordinate picker for a quick and easy way to let authors click for values instead of typing them out.