Compared to standard image properties

How we (used to) do it in Optimizely CMS

A developer would add an image property by adding something like the following to a page or block type:

public class ArticlePage : PageData
{
    [UIHint(UIHint.Image)]
    public virtual ContentReference MainImage { get; set; }
}

This allowed a CMS user to upload an image and select it for the MainImage property.

The developer would then add something like the following to render the image:

@Html.PropertyFor(x => x.MainImage)

Note: This rendered the image as-is.

If a tiny 50x50 pixel image was uploaded, a tiny image image would be displayed.

Conversely, if a 6000x4000 image weighing 30 MB was uploaded, the page would display an enormous image that would - depending on bandwidth - take a long time to load.

Finally, it was non-responsive. Regardless of screen size, the same image would be rendered.

In other words, if the desktop design called for a 16:9 high-resolution hero image, that same image would often be displayed by the mobile version as well, adversely affecting both design and performance.

What about automatic scaling?

We often used libraries such as ImageResizer to automatically scale images to a suitable size.

While this prevented rendering huge images that took forever to load, it only worked for images that were large enough to begin with.

Automatic scaling risked up-scaling images that were smaller than intended, resulting in blurry images on the website.

What about automatic cropping?

With libraries such as ImageResizer an image can be rendered with any proportions by automatically cropping it.

We would for example make sure a large hero image on a start page was indeed displayed as a widescreen (16:9), regardless of the proportions of the original image uploaded by the CMS user.

This often led to all sorts of unwanted results, such as cut-off heads or key parts being missing entirely.

What's worse, even if this was immediately noticed by the CMS user, they had no way of easily changing the cropping manually to correct it.

While there are libraries such as OpenCV that can be used for context-aware automatic cropping, for example face detection, they often require a substantial development effort.

Why not just upload correctly cropped and scaled images?

In short: because it takes a lot of time and is error-prone.

  1. It takes time to manually crop, scale, and upload additional images
  2. CMS users need to be aware of what the correct image size for each property
  3. Properly optimizing images requires specialized software such as Photoshop
  4. The media library becomes more difficult to search and navigate when the number of images grows exponentially

And finally, the user might not have the time or inclination to be thorough enough to make sure everything looks and works as intended.

How we do it with Adaptive Images

Depending on whether an image should be responsive, i.e. vary for different screen sizes, we add either a SingleImage or AdaptiveImage property:

public class ArticlePage : PageData
{
    [Size(1920)]
    [Proportions(16,9)]
    public virtual SingleImage MainImage { get; set; }
}

Because we specify both minimum width and proportions, the image height is also validated, effectively making the minimum image size 1920x1080 pixels.

We render it just like the original image property, but we may specify a desired size depending on where the image is rendered (since we may re-use the same original image for multiple contexts):

@Html.PropertyFor(x => x.MainImage, new { width = 1280 })

Why is this better than the original image property?

  1. The CMS user is unable to select an image that's too small, preventing blurry images.
  2. The image will automatically be rendered with the correct 16:9 widescreen proportions.
  3. The CMS user may adjust the cropping if needed and/or set an explicit focal point.
  4. The image will automatically be scaled to the desired size.
  5. The only image that needs to be uploaded to the media library is the original image.
  6. We can use not only images uploaded in the CMS, but from any image provider that has been configured, for example to use image from the company's DAM (Digital Asset Management) system.
  7. Images can be made responsive, with different proportions and sizes for each device type (desktop, tablet, and mobile).

Learn more