Are you happy with your Sling/CQ development? If yes, you’re a lucky guy – you’ve just saved a couple of minutes because there’s no need for you to read this post.

You’re still reading this, which means that you want to do your job better, write your CQ applications faster, produce better quality code; or have your code testable and reusable… or you’re just curious. Whatever your motivation is, you won’t regret reading this post because it will change the way you develop your CQ applications – exactly as Slice changed ours.

Slice has been developed internally in Cognifide and is now released to the public. It is a framework that makes Sling/CQ development much easier and more efficient. Take a while to read this short introduction to Slice and find out how you can benefit from using it.

So, why should I use it?

I promised you in the title of this post that your life (your life as a CQ developer) will be easier when using Slice. Here’s a couple of benefits you can gain:

• No more scriptlets – writing business logic of your app in JSPs is generally not a good idea, there are plenty of reasons, and plenty of post/articles that discuss this topic (like http://stackoverflow.com/a/1832327). With Slice you write your business logic in Java; JSP is a presentation layer only.
• Avoid re-inventing the wheel – think of how many times you have had to re-write your code, especially when starting a new project? The Slice framework makes it easier because it provides a lot of features you can reuse. You can also reuse your own modules and libraries.
• Improve the testability of your code – you just write simple Java classes. Thanks to dependency injection (DI) they can be easily unit-tested.
• Low cost of introduction of new developers into projects – Slice is easy to learn and if you use it in all your projects, your developers know exactly how to start.
• Faster development – code reuse, dependency injection and simplicity make you more efficient than ever.
• Reduce maintenance costs.

We’re taking off

Slice is a framework designed having modularity in mind. We divided it into a couple of modules, and you can add yours if you want. Modularity of the framework is achieved using Guice. Hold on, what?! Not OSGi? Yes, you might be a little bit surprised. You will still use OSGi bundles but inside your application bundles there will be a dependency injection framework. It allows you to inject simple objects which don’t have to be OSGi components/services. You will see in a minute how powerful it is and how it simplifies your code.

The framework is based on the presentation model pattern which means that your views (JSP files) determine which presentation model to use (Java classes) to return underlying data (a Java class with repository data).

The core feature of Slice is the Mapper. If you’re familiar with Hibernate or any other object-relational mapping (ORM) solution, you can think of the Slice Mapper as a JCR equivalent of ORM. Basically, it maps your JCR content to POJOs. Thanks to this you have access to a repository in your Java objects.

Show time!

You’re already familiarised with the basics. Now it’s time for development. We will be writing a simple CQ component and extending it by adding new features, which will show you different aspects of the Slice framework.

You’re probably expecting to have some installation guide here. I have to upset you – I’ve decided not to write about it as it is covered in the Slice documentation and, basically, there are only some maven dependencies and a bundle activator.

Let’s create a simple text component which is responsible for rendering a piece of text. A JSP file of our text component looks like this:

<%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8"
%><%@include file="/apps/myapp/core/global.jsp"
%><slice:lookup var="model" type="<%=com.cognifide.myapp.TextModel.class%>"/>
<p>${model.text}</p>

Pay attention to the third line – this is how you define the model of data you expect to be returned by the framework. When you have your model of data to be rendered, you can just output it using JSTL (line 4). Simple as that.

A model class is more interesting:

package com.cognifide.myapp;

import com.cognifide.slice.mapper.annotation.JcrProperty;
import com.cognifide.slice.mapper.annotation.SliceResource;

@SliceResource
public class TextModel {

	@JcrProperty
	private String text;

	public String getText() {
		return text;
	}

}

We’ve got here a simple POJO class annotated by @SliceResource. This is a key annotation in Slice which informs the framework that you want to have objects of this class to be mapped from the underlying resource.

Mapping resources in Slice

How does the Mapper work?

The Mapper reads the Sling resource provided by the framework (in our example it is a resource of the text component) and writes its properties to corresponding fields in a Java object. The matching between properties and fields is done by names.

All is needed to map an object is the @SliceResource annotation put at the class level. A class can define if all its fields should be mapped or only annotated. This can be done by specifying the MappingStrategy in @SliceResource:

• @SliceResource(MappingStrategy.ANNOTATED) or just @SliceResource – only fields annotated by @JcrProperty are mapped,
• @SliceResource(MappingStrategy.ALL) – all fields are mapped. If there is no property in a resource which corresponds to a field, the field will be set to null.

If a field is of a class annotated by @SliceResource – guess what – it will also be mapped recursively.

There are also other field-level annotations which can be used. They allow you to either define logic of mapping or transform the mapped value. These annotations include:

• @Unescaped – unescape an html markup, so that an html value can be correctly displayed – especially useful in fields containing richtext.
• @ImagePath – transforms String into the CQ image path. Useful when a path to an image must be displayed (like in <img src="image_path">)
• @SliceReference – my favourite one. It allows you to define a path in a repository where the SliceResource field will be mapped from.

Inject me!

By now, you should understand how our simple TextModel class was populated by repository data and then rendered in a JSP script. So far, so good. Let’s play toys for big boys now.

We haven’t use Guice so far – or, actually, you couldn’t see that Slice made use of it. Let’s modify our text component to display text with a title of a random page.

The JSP file, again, is very simple and performs no business logic – it only displays data provided:

<%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8"
%><%@include file="/apps/myapp/core/global.jsp"
%><slice:lookup var="model" type="<%=com.cognifide.myapp.PageTextModel.class%>"/>
<p>${model.text}, ${model.pageTitle}</p>

To implement business logic we need the PageManager class and a path to the page. The path will be stored in the underlying resource (chosen by the author using component dialog) and PageManger will be injected. Take a look at the code below:

package com.cognifide.myapp;

import com.cognifide.slice.mapper.annotation.JcrProperty;
import com.cognifide.slice.mapper.annotation.SliceResource;
import com.day.cq.wcm.api.PageManager;
import com.google.inject.Inject;

@SliceResource
public class PageTextModel {

	@JcrProperty
	private String text;

	@JcrProperty
	private String path;

	private final PageManager pageManager;

	@Inject
	public PageTextModel(PageManager pageManager) {
		this.pageManager = pageManager;
	}

	public String getText() {
		return text;
	}

	public String getPageTitle() {
		return pageManager.getPage(path).getTitle();
	}
}

If you want to display the title of a requested page instead of a specified one, you can… inject a requested page:

package com.cognifide.myapp;

import com.cognifide.slice.cq.qualifier.RequestedPage;
import com.cognifide.slice.mapper.annotation.JcrProperty;
import com.cognifide.slice.mapper.annotation.SliceResource;
import com.day.cq.wcm.api.Page;
import com.google.inject.Inject;

@SliceResource
public class PageTextModel {

	@JcrProperty
	private String text;

	private final Page requestedPage;

	@Inject
	public PageTextModel(@RequestedPage Page requestedPage) {
		this.requestedPage = requestedPage;
	}

	public String getText() {
		return text;
	}

	public String getPageTitle() {
		return requestedPage.getTitle();
	}
}

You will probably wonder how the framework knows what the requested page is and how to create this page. The logic of building objects which are injected is implemented in the so called providers. Providers, in turn, are defined in modules. This is a basic Guice concept. Please find out more at Guice website.

Thanks to this approach you don’t produce boiler-plate code – classes depend on classes they really need. This improves the testability of your classes, too.

Become an expert

This post is not aiming in comprehensive guide to Slice. However, there are some additional features which are worth mentioning before I type the final dot.

Inject OSGi services easily
Thanks to use of Peaberry you can inject OSGi services as if they were standard Java classes.

Scoping of objects
You can define for how long your objects are available and how many instances of your objects Guice should create. There is the request scope provided by Slice – it allows you to have one instance of a class per request, which means that Guice will reuse this instance for all its clients within a single request. Effectively, it’s a kind of a very simple cache. You can also have a dedicated scope for using objects in CQ workflows or background asynchronous jobs which are not dependent on a request. Additionally, you can introduce your own scopes, if needed.

Complex composition
Slice provides a number of useful objects which can be instantly injected into your models, e.g. SlingHttpServletRequest, ResourceResolver or PageManager. It also introduces ModelProvider and ChildrenProvider which allows you to obtain a model of data from a specified path (or resource) within a repository. Thanks to this, you can have a model of whatever repository data you need and use it inside your models, e.g.

PageTextModel pageTextModel = modelProvider.get(PageTextModel.class, "/content/mysite/mypage/jcr:content/component");

Simple validation of your models
Slice supports the validation of models and integrates it with JSP views using dedicated JSP tags.

Easy to mock
Thanks to testing the framework you can mock a repository easily and use it in your unit tests.

Modularization
Thanks to the modular architecture you can divide your application into logically separated modules.

Get it now

Slice is a framework which made our day-to-day development much easier. Now you can try if it helps you because Slice is open-source! You can find it on Github: https://github.com/Cognifide/Slice.

Enjoy!

P.S.
Some useful links:
Slice documentation: https://cognifide.atlassian.net/wiki/display/SLICE
Slice JIRA: https://cognifide.atlassian.net/browse/SLICE

Back in March, Miro, Ray and I flew out to Utah to attend the “Adobe Summit 2012”. This was the first time that I had been to a CQ event since the “Day Customer Summit” in Basel, way back in 2007 well before Adobe acquired Day so I was quite excited to see how things had changed.

The first day was Adobe Partner Day that focused on delivering the Adobe vision to the partner community before the actual customer summit started whilst also giving an opportunity for some last minute rehearsals for the Digital Marketing Suite (DMS) presentations and demos. My first thought as I stepped into the venue was that attendance was larger than what I  remember of the whole customer summit in Basel!

Days 2 and 3 were the main customer conference with an attendance of 4500 customers and partners. The format was a few keynotes in the morning and late afternoon with a choice of breakout sessions across the tracks below in-between:

•  Analytics and reporting
•  Multichannel campaigns
•  Personalized engagement
•  Mobile
•  Social
•  Tech track
•  Web experience management
•  Media monetisation

I came away from the summit feeling inspired and even more convinced that our relationship with Adobe will be a great thing for Cognifide’s continued growth and success over the years to come. I have tried to summarise my thoughts/takeaway points from the 3 days below:

• With increasing marketing and advertising dollars being devoted to digital marketing initiatives, digital marketing is the next big investment for enterprises following in the footsteps of ERP.

• Adobe recognises the opportunity that an end to end enterprise platform for digital marketing represents and has a vision with a laser focus on delivering it.

• The scope of this vision encompasses the creation, targeting, optimisation/ measurement and now even, predictive modelling of digital marketing activity. You start on this joined up journey in the creative suite and travel through the technology and tools of the rebranded Adobe Digital Marketing Suite (DMS).

• None of the traditional enterprise software players are doing this – Microsoft, Oracle, HP are all lagging behind with Adobe taking the lead..

• The fact that Adobe killed Lifecycle last year was a really positive message, reaffirming the focus they have on making this a success. As the Adobe folks would say, “we’re betting the ranch on this”

• The above obviously means a lot more ongoing work as new clients buy into the Adobe vision. Adobe stated clearly that they do not plan to increase the head count of their internal professional services team and that they will continue to rely on the partner Eco-system to deliver services to clients. So, basically, they are committed to our success and offered help in growth of skills and offerings.

• Adobe has also done some rebranding (again) with the latest terms being

1. The platform – “Adobe DMS (Digital Marketing Suite).
2. The brand “Omniture” is retiring soon and the main products that continued to evince interest amongst the delegates and partners were:
   Adobe Sitecatalyst
   Adobe Test and target
   Adobe Search and promote
   Adobe Social

• Various new acquisitions have been made and will be added to the DMS:

1. Demdex – Audience optimisation platform
2. Efficient frontier – Predictive modelling of different marketing mix and the effects on results.
3. Auditude – Video advertising platform.

• Scene 7 – the SaaS asset management platform captivated the audience.

• Traditionally, Adobe have been quite agnostic when it comes to e-commerce and the partner day was the first time I have seen Adobe do a retail demo/case study so this intrigued me.. Shortly afterwards on Day 2 they announced a strategic partnership with Hybris as the ecommerce platform of choice.

• Adobe CQ is at the centre of the DMS so we certainly have a headstart as we have been working with CQ well before Adobe started thinking of the acquisition. We saw a very compelling demo of the Adobe CQ cloud manager running on AWS.

• Over the coming year(s), the Adobe DMS will become better integrated and sold as a cohesive platform. With this, clients will expect partners to be able to deliver a full service across the platform. This will certainly influence our growth of capabilities over the coming years to ensure there is mutual benefit from our strategic partnership with Adobe.

• In addition to the Adobe presentations, I particularly enjoyed keynote sessions with Biz Stone (Twitter), Arianna Huffington (Huffington Post), a futurology session with Blake Irving (Yahoo) and a very entertaining creative suite demo with chief geek Kevin Lynch (CTO, Adobe)

As well as all the exciting presentations, we had some good fun, snowboarding on the Friday and got some valuable one-on-one time with some potential clients.

All in all, the conference was a great experience and I’m looking forward to the Adobe EMEA Summit in London next week where we’re sponsoring the Web Experience Management (WEM) track and the Adobe partner café in Poznan over the next couple of months.

But on the other side of this beautiful postcard was sweat, tears and blood of developers working on a beta version of the new platform. That was a great challenge and thanks to the support of the Adobe guys (mostly Florian and Bertrand) – a great deal of fun. But then, a final version was released and while it all got tidied up, I was surprised to find some rough edges – mostly around the just added mobile module.

Problems with mobile detection

CQ5 uses the WURFL database with over 17,000 devices defined. Each request is matched against this database and assigned to a device group and along with it – an appropriate mobile view of the requested page. The detection and mapping part is where it gets tricky. WURFL provides over 500 capabilities for each device from which five used downstream: screen size, device rotation, images, CSS and JavaScript. Sure, we’d have liked to extend this input set, but it’s hardcoded. One way around would be to specify a regular expression on user agent (there’s support for that), but good luck matching all the touch phones out there in the market with it. Unfortunately, there was no way to expand the built-in detection mechanism and fully leverage WURFL capabilities.

When we started working on a full-blown mobile site and engaged with a mobile agency, we hit a wall. Did you know you need independent designs for devices with different input methods? Big buttons for touch phones, small for joystick based, and the list went on. To add to the fun, there are a lot of touch phones that don’t support JavaScript properly and that you should consider separate template for tablet devices – rich-like desktop, but then again touch-based? The mobile agency guys could talk about these differences for hours and we were quickly convinced that we will easily end up with 23 templates, and that we need some smarter device detection.

Adobe was challenged with those requirements, and it didn’t take long to convince their architects to include our case on the product strategy roadmap. We worked on that together and soon after feature pack #36363 was released.

Salvation

There are two important things you must know about the mentioned feature pack.

1 – it made it into the CQ 5.5 mobile module!

2 – it allows you to extend mobile detection and fully leverage the WURFL database.

In addition to the original 5 criteria, another filtering mechanism was added:

• You can register your own filter (as an OSGi component) that will either let a request be assigned to a given mobile group, or deny it.
• You can assign many filters to a mobile group and a request will be assigned to it only when all filters pass.
• Inside a filter you have access to WURFL-mapped capabilities of the device that made the request.

That’s it in a nutshell. Now, how do you implement it?

Step 1 – Implement the filter

First step is to implement your filter. It’s done by exposing an OSGi component that implements the com.day.cq.wcm.mobile.api.device.DeviceGroupFilter interface. A key here is the matches method that provides the filter’s logic: returning true means a device passes the filter. This method is executed on every request from a mobile device, and a map of WURFL capabilities is passed in a parameter. All you have to do now is to check WURFL documentation and find which WURFL capabilities you really need.

The real life example below implements a simple touch filter that matches only phones and tablets with a touch screen. I used Felix SCR Annotations and maven-scr-plugin to generate OSGi metadata for the component.

package com.cognifide.simple.filters;

import java.util.Map;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;

import com.day.cq.wcm.mobile.api.device.DeviceGroup;
import com.day.cq.wcm.mobile.api.device.DeviceGroupFilter;

@Component
@Service
public class TouchFilter implements DeviceGroupFilter {

	@Override
	public String getDescription() {
		return "Includes mobile phones and tablets with touch screens";
	}

	@Override
	public String getTitle() {
		return "Touch screen devices";
	}

	@Override
	public boolean matches(DeviceGroup deviceGroup, String s,
			Map capabilities) {
		boolean isTouchScreen = isTouchScreen(capabilities);
		boolean isMobilePhone = isMobilePhone(capabilities);
		boolean isTablet = isTablet(capabilities);

		return isTouchScreen && (isMobilePhone || isTablet);
	}

	private boolean isTouchScreen(Map capabilities) {
		return "touchscreen".equals(capabilities.get("pointing_method"));
	}

	public boolean isMobilePhone(Map capabilities) {
		return "true".equals(capabilities.get("can_assign_phone_number"));
	}

	public boolean isTablet(Map capabilities) {
		return "true".equals(capabilities.get("is_tablet"));
	}
}

Step 2 – Assign the filter

With the touch filter implemented, let’s use it in the pre-defined touch device group (/etc/mobile/groups/touch). Open the page, click the Edit button to fire the dialog and go to the Filters tab. Your filter should be already available in the drop-down – choose it instead of the default one and confirm. Since this filter implements all the touch-device logic you need, it’s safe to get rid of the legacy logic. Yes, you can uncheck all capabilities from the first tab of the dialog.

If your filter is not there, double check how your bundle got installed in the OSGi console (/system/console/bundles). It should expose your filter as a service, and it should also be visible as a component of the same name (/system/console/components). If it’s not – check your build / maven-scr-plugin.

Step 3 – Test and debug

With all that set, time to test if it works. In order to do that you need a publish instance with your touch group there (activate it from author) and have your code deployed. Get a touch phone, or a browser with custom user agent (e.g. Firefox with User Agent Switcher), or simply use cURL and pass touch phone’s user agent as a parameter. Anything that makes a mobile request to your site works. Since we changed one of the default device groups, we can test it on the Geometrixx Mobile site: /content/geometrixx_mobile/en.html. If the filter works correctly, you should get redirected to en.touch.html for touch-device requests (e.g. iPhone, iPad), and to other group for non-touch devices (e.g. BlackBerry 9650).

If your device is not matching the desired group, don’t despair. The mobile module has a very verbose debug log. I recommend you create a separate log file for that: just use com.day.cq.wcm.mobile for your filter. Hint: when debugging, we recommend using cURL, so that other requests (e.g. for .css) don’t pollute your log.

Conclusion

With CQ 5.5, the mobile module gets a great boost. From a toy to play with in microsites, it has transformed into an extensible mobile solution. It may not be ideal – integrating with the legacy solution (capabilities ticks) seems awkward, and filters cannot be joined in advanced logical expressions (e.g. touch and not tablet; tablet or desktop). But even with all that, we can finally satisfy the marketers’ hunger for mobile sites with minimal effort on the development side. Since it’s no longer sweat and blood, I wouldn’t be surprised to find more and more CQ5 sites going mobile very soon.

Time to feed the marketeers.

If there is one thing the board always wants to know from their CMO after the CEO heard Mary Meeker (KPCB) talk about Top Mobile Internet Trends at the Google Think Mobile event, early last year, is generally how the group’s mobile marketing strategy is measuring up and whether you’ve cracked the SoLoMo challenge yet.

Now, you engage users over Facebook, Twitter and Foursquare, have built your mobile version of your website and are about to launch your mobile app but the question doesn’t change. It’s always – ” what next? ”

So… seriously, what’s next? Okay before you answer that, let’s take a step back and for those who are not so convinced about the mobile channel, answer  –

Why is mobile so important?

Well, if Mary Meeker’s slides on the Top 10 Mobile Trends or the latest Econsultancy UK Mobile Statistics report haven’t convinced you already, here’s a simple fact -

                     Your mobile is always within arm’s length unless you are in the shower.

In fact, it’s what some of us actually reach for, just as we wake up to check the latest news over the BBC (Facebook newsfeed for some, Twitter for others but news, all the same). You use Evernote to make your shopping list besides your work notes, listen to Spotify while playing Angry Birds on the way to work, use Skype to talk to your friends/ colleagues overseas,  check in with Foursquare at that new restaurant for dinner, frame that whacky shot using Hipstamatic before tweeting and finally, set the alarm on your mobile for that all important meeting the next day.

Hmmm, I’d like to think that you now agree that the mobile channel offers unbeatable reach to engage users as Mary has illustrated while comparing it to the other advertising media -

Source: Mary Meeker presentation on Top 10 Mobile Trends at Think Mobile – Google, USA

Now, that we agree on the reach and efficacy of the mobile channel, I’m guessing you would like to know

What are the key challenges in optimising for mobile? 

1 – Native website vs mobile app

This is always the first question when the digital marketing team is tasked with optimising the company website for mobile but I’d advise that you don’t fall prey to the argument. If you are a brand that is known to engage well, then your patrons expect a mobile app but if your mobile site doesn’t provide a consistent experience across platforms, the patrons feel you let them down! And let down by the brand not by the technology as one of our clients found out. You tell me – if you felt let down by a brand, would you still ask your friends and family to check out that brand, if your friends were likely to get a poor experience?

Surely, the savvy marketer in you doesn’t need any convincing regarding the potential ROI from a referral to friends or family, right? Just in case, there is a small doubt, remember F-Commerce is around the corner and if it’s half as successful as Facebook Photos, it’s a few billion that is likely to be up for grabs!

2 – It’s Mobile! 

There is the initial rush to deliver mobile but then, at times with the onus to just deliver, there arises the tendency to forget users expect a streamlined mobile experience and not just the ability to access the site. It’s fatal to consider the mobile user to be the same as a desktop user, remember they have different needs; they access your site on their mobile for specific needs, generally triggered by a location based urge to either visit your store or understand price difference from an online enterprise such as Amazon or Zappos.

3 – Mobile Analytics

It’s taken a while for some to realise the merits of a data driven culture and fortunately, at least now, no one debates its value over being driven by the HiPPO or a committee but yet, we are often found answering how mobile analytics differs over traditional web analytics. Here are a couple of factors as to how mobile analytics differs:

- Phone type: Touch/ Feature/ Smart

Unless you know what type of phone the user is on, its difficult to provide them with a decent experience when browsing through your site. Sure, its easy to mix up the touch and smartphone but for clarity, the iPhone is a Touch phone and the Blackberry models without a touch interface are the smartphones. Feature phones may not be the choice of the upper class but remember the feature phone is what the masses tend to be on so you cannot afford to ignore this high volume segment.

- Screen sizes

Okay, you know what type of phone the user has but unless you know how much real estate you have when you have the user’s full attention, there is little you can do. So, in a nutshell, you need to know both the type of phone and what the device actually is in order to present them with the right experience.

- Javascript support

Phones differ in their ability to handle Javascript versions so you may not be able to get away with too many fancy AJAX calls if users demand an optimal mobile user experience. Check out how many retailers do not have a mobile site or app today and you will be surprised to see that there are some who aren’t on the mobile bandwagon yet.

- Online/ Offline data collection support

We’re all data junkies now and realise that there are times the user may be without internet connectivity but we still need to understand app usage so the smart developer always ensures that usage history is sent back when the user gets online next so that the marketing team is able to optimise accordingly. I’m proud to say that we’re doing some cutting edge stuff with some of our clients in the Pharmaceuticals and Financial services sector on this front.

- Monetisation challenges

eBay CEO, John Donahoe shared that GMV (gross merchandise value) has triped YoY and was expected to hit $4 billion last year. Clearly, its not that people shy away from making high value transactions over their mobile but generally, marketers are wary when it comes to tracking solutions as sales need to be attributed to the right channels. Of course, by now there are some pretty nifty tools out there in the market and call tracking is just another option to measure revenue from the mobile stream.

It’s imperative that you evaluate how your choice of an analytics platform caters to all of the above and ensure that the integration points between various systems are clarified before you sign on the dotted line as you may otherwise, be looking at some pretty long implementation timeframes which will imply the target ROI be reduced to a dream.

Who are the mobile analytics vendors to consider?

I’d like to leave you with something to think about if you’re in the market evaluating mobile analytics vendors. I’d suggest you check out Bango, Adobe SiteCatalyst, Flurry and Webtrends to see how they stack up against your needs because

1 – Bango and Flurry are right on the money as specialists in the mobile analytics space

2 – Adobe SiteCatalyst and Webtrends Analytics 10 offer detailed mobile analytics reports and are what I’d consider as comprehensive analytics platforms across web and mobile channels.

If you want to check out the range of options that Adobe SiteCatalyst provides for mobile reports, have a look at my previous post Did Google pay $12.5 billion for Motorola or more ZMOT insights where I’ve provided a screenshot of all the reporting options you can drill down on. Oh, the fact that you could plug in Adobe Social Analytics on top of the SiteCatalyst platform should also work as an added bonus to consider SiteCatalyst as you are otherwise looking at an additional social analytics monitoring service such as Radian6 for the social space.

Whoops, I almost forgot why Google Analytics was discarded from the list even though as I mentioned in my post on ZMOT, they are ramping up quite well (Google Analytics Premium hit the market a few weeks after the post so hey, I guess my foresight isn’t too bad). It’s discarded as it’s unfortunately quite limited with respect to the mobile reports and leaves you wanting more.

Main image courtesy: Axiom Mobile Tech

It’s old news that with the Adobe Digital Enterprise Platform(ADEP) CQ 5.4, you can easily connect from CQ to Adobe SiteCatalyst report suites by simply entering your SiteCatalyst login credentials and all your basic reports would be available in a jiffy. Plus, you could edit additional parameters using the Page Data tab, map parameters of interest using the Clickstream cloud and even, set up Event Tracking. Sweet!

So, what more does ADEP WEM CQ 5.5 offer you with respect to web analytics?

Well, with Adobe CQ 5.4 itself, you already have some pre-configured reports about page activity, components, workflows, content generation, consumption, etc and as is the norm with CRX, the ability to set up additional reports with parameters of interest; be it about authoring, versioning, etc. Now, the most interesting enhancement in terms of reports, in my humble opinion, (if you are a SiteCatalyst veteran and are on the verge of becoming an ADEP customer) is that you now get a report that details all the SiteCatalyst variables which are mapped on to the CQ components throughout the site.

If you’d like to take a closer look at the SiteCatalyst view, please click on the image for a high resolution image.

It gets even more exciting as you can now drag and drop pre-configured CQ components (which already have their SiteCatalyst variables mapped) on to new pages that are created. This has all been cunningly designed with an inheritance mechanism (note: the button right below the view selector entitled Configure Inheritance lets you either enable or disable Inheritance ) so that you can have a shared configuration for a group of sites and change only the parts you need to change for an individual site. Yes, this is certainly a god send that I am sure will help quite a few analysts and marketers from having to spend the time (that they really didn’t have) on figuring out where on the content management system, certain evars/ sprops are configured to.

Oh, for the CQ veteran on the verge of integrating further into the Adobe Digital Marketing community, you can switch to the CQ view as well that provides you with the ability to drag and drop the required SiteCatalyst parameters on to the CQ components defined or just being defined.

If you’d like to take a closer look at the CQ view, please click on the image for a high resolution image.

If you enjoyed this post, join me in thanking Cognifide’s Technical Architect, David Friar, for his support with this post without which, it would not have been possible.

Of course, if you’d like to know more about the Adobe WEM/ CQ/ ADEP platform, don’t hesitate to get in touch or comment on this post with your questions!

Everything is running in OSGi

This has been rumoured about for quite a while and came more as a relief than a surprise. CQ 5.5 is finally a 100% OSGi application. Now, what does that really mean?

For as long as I remember (and that dates back to the days of Communiqué 4), CQ has been a set of two webapps running in a standalone servlet engine (by default: CQSE). The first application was CRX, and the second WCM – in CQ5 called “Launchpad”. Launchpad is an OSGi application with Sling, WCM, DAM and the rest of the family. In the two-webapp setup, Sling is accessing CRX using JNDI via an in-memory service provider. Well, it works, but feels awkward – we’ve got OSGi and yet, we use it only for a part of the application. Of course, one could argue that it is a sound failover – even when your OSGi goes wahoomi, you still have access to CRX over HTTP (so e.g. data backup is still an option), but I’ve always asked myself – is it really worth it?

It seems that it wasn’t – in CQ 5.5 everything lives inside OSGi. CQSE is an OSGi bundle (provides org.osgi.service.http and javax.servlet) and so is CRX that provides the repository as an OSGi service. RMI / JNDI are still available, but don’t seem to be used in the stack (client repository configuration is gone).

What does it mean migration-wise? Not much, really. All my applications are already working in OSGi, accessing CRX via Sling and not depending on JNDI, and even if yours did depend on JNDI – it’s still there as an option. The only scenario where something would have to be rewritten is when one had another webapp on CQSE – but I can’t imagine why would anyone want to do that. I’m not sure, though, what happens with deployments on different servlet engines (Tomcat, Weblogic, etc.). Maybe CQ5.5 will be available as a webapp too – I think we’ll have to wait for the official release notes and supported platforms to answer that.

Consoles clean-up

Another change that it brought is clean-up in consoles. /admin is now gone – CQSE is configured in Felix Configuration Manager. If you are looking for /crx, it is now /crx/explorer, and some CRX tools are exposed as separate OSGi servlets or are integrated into Felix Web Console. A very good side-effect is that now we can change instance’s admin password in a single place – CRX.

Package manager also got unified – there’s only one, and it’s the CRX one: /crx/packmgr (the WCM one – /etc/packages.list.html – is no more). Functionally nothing changed, but I’ll have to update one of my Maven plugins that was relying on the old console to deploy CQ packages.

Next steps

That’s more or less all I’ve figured out by now. Unfortunately, I didn’t get the updated documentation yet, so some areas leave me with more questions than answers. In the next few days I’ll be hunting API changes and testing feature compatibility to estimate the effort of upgrading our customers when this version is out. I’ll post my findings here as I go. Just bear in mind that it’s still beta, and everything is subject to change. Some features may not even make it into the final release. Having said that – I can’t imagine big changes like putting OSGi on the bottom of the stack being reverted. After all, it’s too good to throw it away.

One issue CQ developers might have with it is its configuration. The amount of options available makes it rather complex. Although the widget is quite easy to integrate, if the project has more than a few components using RTE in dialogs and the client requests a global change in RTE plugin configuration, going through all the dialog files can be quite painful, not too mention it’s easy to miss a file.

There is a simple solution to that – to create a dedicated plugin configuration node and include it in widgets that want to share plugin configuration.

Let’s assume you want to have a common RTE plugins configuration, i.e. all descriptions share the same plugins.
First create a node in your application code at /apps/myapp/components/text/description with following properties:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root
    xmlns:cq="http://www.day.com/jcr/cq/1.0"
    xmlns:jcr="http://www.jcp.org/jcr/1.0"
    cq:isContainer="{Boolean}false"
    jcr:primaryType="cq:Component"
    componentGroup=".hidden"/>

In the node itself create a rtePlugins childnode with the actual plugin configurations, i.e.:

<jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0"
    xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="nt:unstructured">
    <paraformat jcr:primaryType="nt:unstructured" features="*">
    <formats jcr:primaryType="cq:WidgetCollection">
        <p jcr:primaryType="nt:unstructured" description="Paragraph" tag="p" />
        <h2 jcr:primaryType="nt:unstructured" description="Heading 2" tag="h2" />
        <h3 jcr:primaryType="nt:unstructured" description="Heading 3" tag="h3" />
    </formats>
    </paraformat>
    <lists jcr:primaryType="nt:unstructured"
        features="[ordered,unordered,indent,outdent]" />
    <undo jcr:primaryType="nt:unstructured" features="*" />
    <subsuperscript jcr:primaryType="nt:unstructured" features="*" />
    <image jcr:primaryType="nt:unstructured" features="[]" />
    <misctools jcr:primaryType="nt:unstructured" features="[]" />
    <format jcr:primaryType="nt:unstructured" features="[bold,italic,underline]" />
    <justify jcr:primaryType="nt:unstructured" features="[*]" />
    <links jcr:primaryType="nt:unstructured"
        features="[anchor,modifylink,unlink]" />
    <edit jcr:primaryType="nt:unstructured"
        defaultPasteMode="plaintext"
        features="[cut,copy,paste-plaintext,paste-wordhtml]" />
</jcr:root>

Now you only need to include a link to that node in your RTE dialogs. Assuming you created your node at /apps/myapp/components/text/descriptionrtePlugins your RTE plugins entry in the dialog becomes

<rtePlugins
    jcr:primaryType="cq:Widget"
    path="/apps/myapp/components/text/rtePlugins.infinity.json"
    xtype="cqinclude" />

You can use this approach for other config nodes (i.e. htmlRules) or other components as well. This not only makes your code cleaner, but also easier to maintain and manage.

Even though news broke out two weeks ago, the press is still hot about Google’s biggest acquisition till date, i.e. Motorola Mobility. Speculation is rife that the search giant isn’t about to pay $12.5 billion for just the MMI patent vault but stands to benefit from considerable tax savings that will turn a “good deal into a great deal”. Yes, I know Larry Page has divulged that the acquisition will strengthen the Android platform and just like you, I believe it certainly is a protective measure but not just of a platform as it obviously, safeguards a lot more future revenue through considerable ZMOT insights for Google Inc!

What is ZMOT?

ZMOT stands for the Zero Moment of Truth. You can thank Jim Lecinski, Google’s Managing Director of US – Sales & Service for the acronym. Coincidentally, ZMOT is inspired by the discovery of FMOT from his time at Procter & Gamble. Sorry, no prizes for guessing that FMOT stands for the First Moment of Truth. We all know that P&G amongst many other reputed FMCG brands values the insights derived from analysing the first few instances of customer behaviour when a customer picks up one of their products from a store’s shelves. The benefactors confess they wouldn’t have their shiny sports cars if they couldn’t translate their analysis of consumer behaviour into actionable insights for the retail giants to cash in on by changing their labelling, descriptions, colours, messaging or positioning on the store’s shelves.

FMOT surfaced on the front page of the Wall Street Journal in 2005 but now it is definitely time for Lecinski’s ZMOT. Lecinski defines the Zero Moment of Truth as

“that moment when you grab your laptop, mobile phone or some other wired device and start learning about a product or service (or potential boyfriend) you’re thinking about trying or buying.”

The key here for me is “thinking about” and obviously, unless we all become mind readers, the only way an online marketer would know of prospective customers is by analysing the engagement with a digital property. Yes, in my books, you get brownie points if you are figuring out innovative ways to engage your audience while delivering a superior customer experience online. More points, if you are gamifying engagements!

Given that we understand the reasons for the “ Think Mobile First “ philosophy to be so well ingrained into the top marketing brains at Google, Adobe and other global giants, does it surprise you that Google Analytics doesn’t really offer much in terms of mobile analytics? No, I am not willing to make do with a basic devices report, as it really limits your understanding of the mobile user. Having said that, I do feel that only Google could provide so much for free in the amazing GA. However, at this point in time, Omniture’s SiteCatalyst takes the cake in providing detailed insights into how and by what devices, your mobile content is consumed.

Illustration: The options within Omniture SiteCatalyst for you to analyse mobile usage

I reckon Google will definitely invest more in developing a more comprehensive mobile analytics solution after this acquisition and will pave the way for a lot more publishers/ developers to benefit from comprehensive analysis of their So-Lo-Mo applications. I’m confident it will only be a matter of time before you get a lot more mobile insights from GA as Google Analytics v5 certainly is ramping up at an amazing pace and I’m sure you’re pleased that you can now analyse multi-channel funnels through Google Analytics. Hmm, I feel that in due course, it may mean the Android marketplace will actually take on Apple’s Appstore (can’t say if the Sony fanboys will go really crazy about the new Sony Android powered tablet devices and build the case for Android powered gaming devices). Of course, if you ask me, how much I think Google will share with us in the near future, your guess is as good as mine: but given what they paid for MMI (even if it’s actually just $3.8 bn with all the Double Irish and Dutch sandwich benefits as the tax experts say), I can safely it is much more than a million dollar question!

Next, I’ll focus on the social media aspect of the ZMOT and how it seems to be catching up with the Financial Services world but till then, I’ll leave you to ponder over Dina Howell’s opinion on the ZMOT. For those who do not follow Saatchi & Saatchi X, Dina Howell is the Chief Executive Officer at Saatchi & Saatchi X and coincidentally, she was the first ever Director of FMOT at P&G). Here is an excerpt from her Foreword on the ZMOT -

“ The Zero Moment of Truth influences which brands make the shopping list, where shoppers choose to buy and with whom they share the results. It’s up to us to join the conversation at this new moment where decisions are being made, and to provide the information that shoppers naturally crave, in all the ways that they crave it”.

If you are pursuing an optimal ROI, can you afford to ignore the ZMOT?

CQ5

1. FileVault – according to Adobe (who provide it with every CQ installation package), it :

… provides your JCR repository with file system mapping and version control. It can be used to manage CQ development projects with full support for storing and versioning project code, content, configurations and so on, in standard version control systems (for example, Subversion).

We had been using it for a while before we stopped, mainly because:

• It’s not as fast as we would like it to be. It is not only a matter of running time (which could be improved), but also the fact that it is purely a command line tool and as such requires additional effort to use it. We developed some batch scripts to automate some steps, but still… it wasn’t enough.
• It was duplicating functionality of our other version control mechanism, which was SVN. Resolving conflicts in FileVault and then, in SVN was a nightmare…

But we haven’t removed it completely from our tool box: FileVault is still providing us with some value while checking out or updating content from CRX repository to a local disk so we can prepare the final packages for an application.

2. Package Manager HTTP Service API – which provides a few URLs to perform such actions as: upload, install, uninstall, create, delete package; and directly on CRX repository. It seemed to be exactly what we needed, it is very well documented, but:

• It is not easy to integrate it with Maven, it requires other tools like curl and again… batch scripting is inevitable.
• It is not easy to understand the output of this tool. We noticed that json based requests often return successful responses even when the install command fails. It makes bug finding quite difficult. Fortunately, there are html based requests that are supported by this Api, but those simply produce too much output which cannot be understand without automated parsing tools.

The API may not be perfect, but is good enough to propose some other solution based on it. And it is exactly what we did. Let me present to you the Maven-CRX-Plugin that my colleagues developed:

Maven-CRX-Plugin is a plugin for Maven 2.x or higher builds that automates the very last step of the development process by providing you with the ability to upload and install CRX packages into the repository. It supports continuous integration processes in development, staging or integration environments.

The plugin simply integrates some of the functionality provided by CRX API with Maven builds with additional developer-friendly parsing mechanisms that report errors details.

Here’s how it can be configured:

(...)
<plugin>
 <groupId>com.cognifide.maven.plugins</groupId>
  <artifactId>maven-crx-plugin</artifactId>
  <version>1.0.0</version>
  <configuration>
   <url>http://crx-machine:5402</url>
  <user>${crx.username}</user>
 <password>${crx.password}</password>
 </configuration>
</plugin>
(...)

And here’s how it can be used:

mvn ... crx:install

Please check the Cognifide GitHub repository for more information (including configuration options). And please bear in mind that it is an early version and we appreciate all feedback received.