Resize images in Azure Blob

Image Optimization 

The loading speed of a web page is based on the size of all the components required to render the page including images, HTML, JavaScript, and CSS. By optimizing the images with compression and resizing, we can offset the effects of very large images and increase the performance. Image rendition in SharePoint is a capability which helps to optimize images in a site by having the same image but in different sizes. This will enhance the user experience as well when browsing the site from different devices.

There are scenarios we can use Azure blob storage to store images and retrieve them from there. In such a situation, the developers have to implement a custom solution to handle the image rendition for Azure images.

Options to implement an Image Resizer

1. Using Nuget package

A Nuget package is available called ‘Image Resizer’, which is an open source ASP.NET library that handles the image processing dynamically. Based on the parameters defined in the URL, it will handle the image transformation and provide the resized version of the image in run time.

For example:  If the image source url is defined as <ImageUrl>? width=108&height=70, this will return the resized image for given dimensions.

Steps to follow:

     1. Create an Asp.Net web application and install all the NuGet packages for Image Resizer and Azure plugins.

            2. Configure the application to connect to Blob storage as an image processing platform.

            3. Create a new Azure Web App to deploy the solution.

            4. Publish the application to Azure Web App.

       2. Azure Blob Trigger Function

     Create an Azure Blob Trigger Function/Web job which will be executed whenever a new image is added to the blob storage and handle the resizing of the image in the background. The result image with the reduced size can be saved to a different container with the same name.

There are some extensions available for Asp.Net and Azure:

     ImageProcessor.Web

            ImageResizer.WebConfig

         

How to design SharePoint Taxonomy

In general, SharePoint taxonomy refers to a catalog of objects in SharePoint environment or the process of categorizing or classifying objects based on a taxonomic scheme. The ultimate goal of the taxonomy development process is to obtain a comprehensive schema that logically organizes the related objects in a hierarchical structure across a SharePoint implementation.

There are two ways to design and roll out a taxonomy for an organization.

1. TOP-DOWN DESIGN

2. BOTTOM-UP DESIGN


1. TOP-DOWN DESIGN

The obvious way to implement and take advantage of structured taxonomy would be to implement a company-wide taxonomy from day one. This requires that we develop metadata and content types plan across the whole organization before start using the taxonomy. While great in theory, this is very challenging in practice. Development of company-wide taxonomy requires company-wide participation. That means that all departments need to be involved in the development of company metadata and content type strategy. The challenge with this approach is quite obvious. Getting everyone together is a challenge by itself. Moreover, the whole concept of metadata and content types is almost always new to most in early stages of SharePoint implementation. So asking departments to categorize their content, develop metadata tags and content types might seem like learning Greek to many.

2. BOTTOM-UP DESIGN

he other way to develop company taxonomy in SharePoint is to use bottom-up approach. Essentially what that means is that we develop your taxonomy as we develop your sites and migrate content to SharePoint. As we develop the sites and document libraries, we can create metadata. Some metadata will be local or department specific (i.e. HR document types), while some will be company-wide/global (i.e. Department Names). Both might end up in the Term Store and will be the first steps to company taxonomy. As we continue to roll out other sites (say Finance, IT or project sites), we might take advantage of the company-wide/global metadata already created previously. And so on. At the end of the day, we will end up with your company-specific taxonomy that can be used and reused by various departments and types of sites.