Tuesday, 5 August 2014

Contextual Image Delivery - JavaScript and TBB Open Source Integrations.

I'm really happy to share with you today a couple of Contextual Image Delivery (CID) integrations that we've made available on github. Both of these help with generating CID URLs - i.e. URLs to images that have been optimised for the current user. By releasing as open source we are also able to show by example and allow you to extend as you desire.

Image Optimisation with JavaScript

First, let's look at the JavaScript CID library. The readme covers much of this, but in summary, this JavaScript library demonstrates how you can make use of CID to optimise images purely on the client side, for example enhancing your RWD usage. Let's say you have an img on your page like :

<img src="http://www.mysite.com/my/image.jpg" 
    data-cid-rule="/scale/200" />

Where this data-cid-rule may have been set dynamically on the client side. Read Transforming Images in the CID documentation for details on the CID rules supported. You can then convert all such img elements to use CID URLs with :

<script type="text/javascript" src="js/context-image.min.js"></script>
<script type="text/javascript">
window.onload = function () {
    Context.optimize();
}
</script>

In this example this would convert the img element above to :

<img src="/t/scale/200/http/www.mysite.com/my/image.jpg" />

You could combine this with libraries like Unveil or Lazy Load to ensure that only the optimised version of the image is loaded - as opposed to the original which would add to the general page weight of the page.

Image Optimisation in Component Templates via the CID TBB

Now you can also do this technique on the server side - see example using TCDL tags - or even just straight C# / Java in your web application, getting the context properties from the ADF claim store. However, one thing you will find is that if you tried to use TCDL tags directly in the img src attribute of your Tridion Component Template. If you do this then the Link Resolver Template Building Block (TBB) will not map the URI of the media to a physical URI in your web application when the template is published.

This is where the CID TBB comes into play. Just like the JavaScript image URI manipulation this CID TBB will generate the appropriate CID URI in the web application when the Component Template is published.

Let's say you have the following img element in your Component Template :

<img src="@@Component.Fields.BannerImage@@" 
    data-cid-rule="/scale/<tcdl:eval 
    expression='browser.displayWidth'/>/source"
    (other HTML arguments) />

With the TBB Installed and configured using the SDL Tridion Template Builder, and assuming that @@Component.Fields.BannerImage@@ gets resolved to /my/image.jpg by the Link Resolver then this img element will be converted to the following when the template is published :

<img src="/t/scale/<tcdl:eval 
    expression='browser.displayWidth'/>/my/image.jpg" />

When the template is rendered in the web application then the eval expression would be evaluated for the given context. Note that if you are publishing a JSP or .NET environment then the tcdl:eval element would be published to either a JSP tag or server control respectively.

Thanks and if you've got any queries please get in touch.

Tuesday, 6 May 2014

Tridion Client-Side Device Detection

The SDL Tridion Context Engine gives you contextual information that you can use to optimise your web experience for different devices - in other words tweak and tune your web site for mobile.

In my previous blog post, I gave a quick overview of our context repository and mentioned that the context repository can give us device properties like screen width and height.

However, if you really want to know width and height of the users' device or browser - then we are often better off discovering it directly from the browser. The user might zoom in or out, they might rotate the screen or they might use a different screen.

The SDL Tridion documentation covers deploying the discovery resolver, in which it says you can add the following to your page:

<script type="text/javascript" src="js/discover-min.js"></script>

This JavaScript file simply discovers a collection of device properties, such as width, height and pixel ratio and uses these over and above those defined in the repository. As with any other context properties these are placed in the Tridion claim store, ready for your use.

SDL Mobile Context Repository Updates

As a quick summary the Context Engine module in SDL Tridion is responsible for resolving context that it places in the ADF claim store so that as a web developer you can optimise the experience based on these contextual properties.

You might be aware that context is resolved on the server based on the information sent by the client. We use a few context resolvers that use the information to enhance the context - these include:

User Agent Resolver
Algorithmic analysis of the user agent.
Discovery Resolver
Resolution of properties discovered by the JavaScript run on the client.
Expression resolver
Evaluation of expressions to resolve properties that are functions of other context properties.
Context Repository Resolver
Resolving properties from a repository of context profiles.

It's the context repository that I'd like to cover in this blog and in particular the context repository updates that are part of the SDL Mobile offering. The context repository is often referred to as a device database since that is the primary usage - however for now I'll continue to refer to it as the context repository, since it has the opportunity to be used way beyond that of device resolution.

The context repository resolver scans the repository using the information sent by the client (e.g. user agent HTTP header) and matches this against a collection of profiles that we've defined ... and continue to define. The context repository resolution is quite a cunning resolution, for example, it allows various aspects of the context - device, browser, OS - to be resolved independently and using trust settings so we can provide intelligent defaults as well as specific overrides. Now the cunningness is just a curiosity and not something we need to delve into ... what it really means to us is that we can manage the repository efficiently, so that as a user of SDL Mobile you get more accurate device resolutions.

Now since we are constantly reviewing new devices coming on to the market, we need to provide updates to the context repository to you. To pick up these updates you will need to be a licensed SDL Mobile user and you will need to contact SDL customer support to whitelist the IP address that you'll be using to pick up these updates. Note that you can update the context repository on one machine that is whitelisted and then distribute to all your servers - so, for example, you can do it once in a dev environment, QA the update and push out to test / production servers AND you don't need to give external web access permission to your production servers to get the update.

To create the context repository, open a command shell and change to the bin directory of your Tridion .NET application or WEB-INF folder of your web application and run:

java -Xms1028m -jar lib/cwd_engine.jar http://context.sdl.com/seed

The command creates a new subfolder called repository. If you need to distribute this repository to other servers in your environment you can copy this folder onto your licensed servers.

As I mentioned earlier we provide updates to this context repository which you can pick up by repeating the above process, except using the http://context.sdl.com/update URL instead:

java -Xms1028m -jar lib/cwd_engine.jar http://context.sdl.com/update

We typically provide updates to the repository every few weeks, but we sometimes do it more often if needed. We intend to provide reports on the updates we provide so that you can make an informed choice of when you should update.

It's interesting to note that the resolvers, other than the context repository resolver, do provide an added resilience to the resolution of some of the context properties. For example the discover resolver will often give you width and height of the device and browser and the user agent resolver will also give you browser and OS version numbers - both independently of the context repository resolution.

The repository on the other hand gives you that extra context resolution resilience, providing more assurance of quality. Think of the repository going the whole nine yards.

Tuesday, 22 April 2014

SDL Mobile : Contextual Image Delivery

So you already have your images for your PC site, but whilst creating your mobile site you soon realize that sending these full size images to mobile devices is far from ideal. You may do some client side adjustment to set height and width, and that may seem to work OK on a fast network, but what about real world situations? If you run your page through any web performance analysis tools you may find that your page weight is a little more than you wanted. Try running your page, or even your favourite mobile web site, through pagespeed, Chrome developer tools or IE developer tools and see what the page weight is and whether the images are optimised.

Now page weight can be attributed to various factors, but images do typically weigh in as the significant factor. As Guy Podjarny from Akamai succinctly puts:

"It all comes down to the fact that you're downloading a large amount of content and you're either hiding or shrinking it. It leads to mobile websites that look and interact like mobile websites but are over one megabyte or two megabytes in size."

Now "web performance is user experience" as Lara Swanson - Engineering Manager of Mobile Web at Etsy - points out:

"Users expect pages to load in two seconds, and after three seconds, up to 40% of users will abandon your site. Similar results have been noted by major sites like Amazon, who found that 100 milliseconds of additional page load time decreased sales by one percent, and Google, who lost 20% of revenue and traffic"

We've recently released the SDL Mobile Contextual Image Delivery module which allows you to easily resize images on the server side so that the client doesn't have to download the full image and resize on the client side. The interface is a simple rule based URL interface that takes images at given locations, transforms them on the fly and returns an optimised image.

For example ... imagine you have an image at http://mysite/images/my.jpg and you want fit this image into a 100x100 space on your page.

You can drop the optimised image on your page with:

<img src="http://mytransfomer/t/scale/100x100/mysite/images/my.jpg"/>

where http://mytransfomer/t is where you have deployed the Contextual Image Delivery module. Both .NET and Java deployments supported BTW.

This transformation is done once and cached so that subsequent requests for the same optimised image from different users is fast.

In a nutshell, that's SDL's Contextual Image Delivery a.k.a CID.

I'll blog soon about the other features of this module, including :-

  • Using context properties to set width and height for you based on the connecting device - the Context Engine already knows the client's screen size so you can make these image optimisation rules dynamic.
  • Whitelisting - to restrict which URLs you wish to allow.
  • Image source definitions - to allow a given logical URL to point to different physical locations in different environments AND to point to images on the file system.
  • Other rules such as trim, scale and format change.
  • JavaScript library to optimise image URLs client size - perhaps you want to handle screen rotation, window resize by the user.
  • Template Building Block to create dynamic CID URLs in Tridion component presentations.

Friday, 28 March 2014

What is a mobile device? What is a tablet?

I get asked this a few times so here is how our team view these definitions.

A mobile device is defined from a user context point of view as a device that can be comfortably used, for normal usewhilst on the move or standing up . Note that a tablet device and any wearable device are mobile devices. A small notebook such as the Asus Eee PC 700 measuring in at 28 cm in the diagonal (and actually physically smaller than the Nexus 10 tabletis not a mobile device since you would typically place the device on a table or on your lap to use it. PCs with detachable or flipable screens that such as Asus Transformer and VAIO Flip are not mobile devices when the physical keyboard in place.

A tablet device is a large mobile device that does not comfortably fit in one hand. From a user context point of view, a user is less likely to quickly pull a tablet out of their pocket in a crowded area, whereas they would for a non-tablet mobile device. To be precise, a tablet is a mobile device that is physically larger than 18cm measured diagonally. For example, a Galaxy Note (Phablet) measuring in at 17cm in the diagonal is not a tablet, where as a Google Nexus 7 measuring in at 23cm is a tablet.

Thursday, 6 March 2014

Context Engine Webinar from John Winter

An excellent webinar from John Winter on our Context Engine. Good overview of the Tridion Context Engine basics along with overview of different mobile web development techniques - RWD, mobile only site & RESS.

To answer to a couple of John's questions...

Q: Why do you need to include discover-min.js in your web page
<script src="js/discover-min.js" type="text/javascript"></script>
A: This JavaScript file does client side detection of some context properties, e.g. browser.displayWidth, browser.displayHeight, browser.displayColorDepth and device.pixelRatio.
Q: How do you update an existing device database
A: Run the same command as you used for the database initialisation, except swap the word seed for update, e.g.
java -Xms1028m -jar lib/cwd_engine-2011.jar \
   http://context.sdl.com/update

Tuesday, 7 January 2014

Targeting Content based on Context

With the release of SDL Tridion 2013 SP1 the concept of context becomes even more an integral part of the SDL technology suite.

One headline of this release is the start of contextual templating. It's only a start, because we’re already working on the next generation of template rendering, which will enhance the component based rendering, i.e. rendering of things, along with template inheritance. This next generation will bring an extra level of agility in the way that you can efficiently manage the tweaking of content on a per context basis. Agility, because you will be able to have full control over content rendering changes on a per context basis with zero regression risk to other contexts - this is great if you need to get quality controlled changes out in minutes instead of days or weeks. Efficiently, since you will be able to radically reduce any repetition in your templates and manage contextual variations in such a way it’s easier for different members of the team to get working ... however, I’m running ahead of myself a little.

Let’s get back to what you can use today and start with some fundamentals.

Imagine you’ve just released a new iOS and Android app and you want to promote this new app to your users.

<context:if expression="os.model == 'iOS'">
  Would you like to try our new 
  <context:eval expression="device.model"> app? 
  - <a href="... apple app store link ...">download now</a>
</context:if>

<context:if expression="os.model == 'Android'">
  Would you like to try our new Android app? 
  - <a href="... google app store link ... “>download now</a>
</context:if>

You may also have looked Android version usage and realised that about 25% of people are not yet on Android v4 - Ice Cream Sandwich and beyond - and you’ve realised that the app you've release for Android is only supported on v4.

You clearly don’t want to promote this app to people who would be frustrated to find they can use it. You can change the context expression to accommodate this.

 
<context:if expression="os.model == 'Android' and os.version ge 4">
  Would you like to try our new Android app?
  - <a href=" ... google app store link ... ">download now</a>
</context:if>

These contextual controls are available to you in a variety of templating languages - in .NET Web Forms you may see

  
<context:If ID="android-app" Expression="os.model == 'Android'" runat="server">
  Would you like to try our new Android app?
  - <a href=" ... google app store link ... ">download now</a>
</context:If>

with the following Web.config control defined.

   
<add tagPrefix="context" 
  namespace="Tridion.Context.ServerControls.Web.UI" 
  assembly="Tridion.Context.ServerControls" /> 

In JSP you might see

  
<context:if expression="os.model == 'Android'">
  Would you like to try our new Android app? 
  - <a href=" ... google app store link ... ">download now</a>
</context:if>

with the following tag lib defined.

  
<%@taglib prefix="context" uri="http://context.sdl.com/taglib" %>

In Tridion templates you might see

  
<tcdl:if expression="os.model == 'Android'">
  Would you like to try our new Android app? 
  - <a href=" ... google app store link ... ">download now</a>
</tcdl:if>

If these Tridion templates are deployed into a JSP or .NET MVC environments then these tcdl controls are transformed into the JSP and .NET Web Forms counterparts.

This shows a quick example on how you can start access the context and in particular the os aspect. Other browser and device properties are available, for example, you may wish to deliver a different variation in the rendering for small screens vs large screen to achieve an optimised user experience on the small screen. Your optimised experience may provide :

  • fine tuned user journey
  • mobile focused menu
  • lighter pages - less bandwidth & faster loading

Enjoy and ... more tips to follow.