Start an Activiti Process via Rest Script in Crafter CMS

Activiti is a powerful open source workflow engine built by Alfresco.  Incorporating a workflow engine into your customer and employee facing sites and portals is an excellent solution for automating complex workflows that cross system boundaries while providing the user with a simple to use, contextual user experience.   Working for a bank or an insurance company and need to workflow contracts with customers?  No problem. Crafter CMS (an open source Java based CMS) paired with Alfresco is a perfect solution.  It’s customer friendly, highly scalable and about as powerful as enterprise technology gets!

In this blog, I’ll demonstrate the most straightforward example of a Crafter CMS REST service being used to start an Activiti Process.

Prerequisites

  • You have Activiti (http://www.activiti.org/) installed
    NOTE:
    The authentication and process are hard coded to simplify the example

Step 1: Create a REST Controller

  • Under Scripts/rest right click and click create controller
    • Enter start-process.get as the controller name
  • Add the following code to the controller. This code assumes Activiti is deployed into the same container as Crafter Engine.
@Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.7')
@Grab('oauth.signpost:signpost-core:1.2.1.2')
@Grab('oauth.signpost:signpost-commonshttp4:1.2.1.2')

import groovyx.net.http.HTTPBuilder
import groovyx.net.http.ContentType
import groovyx.net.http.Method
import groovyx.net.http.RESTClient

def http = new HTTPBuilder("http://localhost:8080")
def user = "kermit"
def password = "kermit"
def authPair = user + ":" + password
def authEncoded = authPair.bytes.encodeBase64().toString()

http.setHeaders([Authorization: "Basic "+authEncoded])

def ret = null

http.request( Method.POST ) {
    uri.path = "/activiti-rest/service/runtime/process-instances"
    // ACTIVITI ENTERPRISE URL
    // uri.path = "/activiti-app/api/enterprise/process-instances"

    requestContentType = ContentType.JSON
    body =  [ processDefinitionKey: "vacationRequest", variables:[  [name:"employeeName", value: "Russ"], [name:"numberOfDays", value: "5"],[name:"startDate", value:"10-08-2015 11:11"],[name:"vacationMotivation", value: "rest"]    ]]

    response.success = { resp, reader ->
        ret = reader
    }
}

return ret

Step 2: Execute the Service

Step 3: Verify that a new process instance has been started

Active Cache a RESTful Response in Crafter CMS

This article will demonstrate how to create a RESTful service in Crafter Engine that has predictable performance and reliability when your service relies on an external service.

Any time your services depend on another service there is a cause for concern. You can’t control the performance or the availability of the external service. Further, if the response of the external service is not unique across calls then there may be no real need to call out to it on each request you receive.

In this case, what you want to do is cache the request from the external service and have your service attempt to get the content from the cache. Active cache is a built in Crafter CMS capability that makes building these sort of solutions much easier. You tell Active Cache what you want, how to get it and how often to refresh it in the background. From there on, you simply ask Active cache for whatever the current response is.

Step 1: Create a REST Controller

Under Scripts/rest right click and click create controller
Enter my-data.get as the controller name
Add the following code to the controller.

 import org.craftercms.core.cache.CacheLoader
 import org.craftercms.core.service.CachingOptions
 import groovy.json.JsonSlurper

 def cacheService = applicationContext["crafter.cacheService"]
 def cacheContext = siteContext.getContext()
 def myCacheKey = "aServiceCallResponse"
 def loader = new ExternalServiceLoader()

 def value = ""
 def responseItem = cacheService.get(cacheContext, myCacheKey)

 if(responseItem == null) {
    // item is not cached, get the value
    def myObject = loader.load()
    value = myObject

   // cache the value with a loader to periodically refresh its value
    def cachingOptions = CachingOptions.DEFAULT_CACHING_OPTIONS
    // def cachingOptions = new CachingOptions() // define your own options
    // cachingOptions.setRefreshFrequency(1) // set the number of ticks for refresh

    try {
        cacheService.put(cacheContext, myCacheKey, myObject, [], cachingOptions, loader)
    }
    catch(err) {
        logger.error("error adding ${myCacheKey} to cache: ${err}")
     }
 }
 else {
    value = responseItem
 }

 return value

/**
 * Define an active cache loader that will be used to prime and then
 * periodically refresh the cache with the latest data from an external
 * service.
 */
 class ExternalServiceLoader implements CacheLoader {
    Object load(Object... parameters) throws Exception {
       def externalServiceHost = "http://api.population.io/1.0"
       def externalServiceURL = "/population/United%20States/today-and-tomorrow/"

       // call the service
       def response = (externalServiceHost+externalServiceURL).toURL().getText()

       // parse service's the JSON response to an object
       def result = new JsonSlurper().parseText( response )

       return result
    }
 }

Step 2: Execute the Service

Open a browser and hit the following URL: http://localhost:8080/api/1/services/my-data.json
Note that your hostname, ports and pageId values may differ than the example
See results

Your CMS is the Walking Dead, Crafter CMS is the Antidote

Your CMS was built 20 years ago.  Think about that.  It’s true.  For the vast majority of CMS technologies out there, the core of the system and the architecture was put in place 20 years ago!

Got an RDBMS Database? How about a JCR repository?  Having trouble scaling? Can’t easily move code and content between environments?  Can’t easily go global or build at cloud scale? No?  That’s because your CMS architecture is 20 years old.  It matters.

How about development?  Do your developers love your CMS?  Can they innovate quickly?  Can you support multiple teams and workstreams?   Can you handle content that isn’t a web page? Can you quickly adapt to new kinds of channels?  No again?  20 years ago the pace of development was slower, expectations were lower.  Today the demands are much higher but CMS vendors and technologies have not kept pace.

Your CMS may still be walking but it’s already dead.  You can change from one product to another but it’s not going to solve the fundamental problem.  Traditional CMS is dead.

It’s time to breathe new life into CMS.

 

At Crafter Software we’ve been working hard for several years to completely re-invent and redefine the architecture of CMS for today’s’ needs.   We’ve let go of industry dogma and the same old design patterns.  We’ve stayed focused on the core rather than chasing the bright shiny objects, buzzwords, and technologies. We’re committed to being great on what matters most to organizations that depend on digital channels: innovation.  The speed of innovation and the ease of deploying it at scale.  We’ve built a CMS with a completely different architecture designed to support today’s demand for innovation. As a result, the world has a completely new take on CMS, built for the “crafters” and innovators, Crafter CMS:

  • Can manage any kind of content and experience
  • Supports any channel and can easily adapt to new ones as they emerge
  • Is easy for authors:
    • Web-based publishing tools
    • Safe editing sandbox
    • Desktop tool support
    • Completely in-context
    • Drag and drop
    • Workflow & versioning
  • Is amazing for developers:
    • Based on well known, proven technology stack: Git, Java, Spring, Groovy and Solr
    • Native support for Git
    • Allows developers to work locally and in teams
    • Supports multiple workstreams
    • Enables team to easily move code & content between environments
    • Makes it possible to use desktop native development tools
  • Is insanely great for ops teams:
    • Extremely high performance
    • Has a small footprint
    • Is built to run in secure environments
    • Is multi-tenant
    • Is horizontally scalable
    • Is geo Distributable

Check it out! Crafter CMS is powering 1000s of the world’s top digital experiences.  It’s open source, it’s powerful and it’s wildly different than the hordes of “zombie” CMS’ out there that put a new name and a new skin on the same 20-year-old architectures and approaches.  If digital content and innovation are critical to your success, don’t fall prey to yet another zombie CMS.  Stop Walking.  Start Running.  Check out Crafter CMS!

Reindexing Content for Search and Queries in Crafter CMS

It is necessary from time to time to reindex content due to schema changes, migrations, and other scenarios. A bulk deployment will push all content to your index but involves several steps in addition to indexing which may not be needed. This article shows how to use the deployer to (re)index content that has already been deployed.

Reindexing the site content can be done using the reprocess feature in Crafter Deployer.

Step 1: Delete any existing content in the index

curl "http://hostname:port/solr-crafter/update/?commit=true" -H "Content-Type: text/xml" -d "<delete><query>crafterSite:MYSITENAME</query></delete>"

Step 2: Invoke the reprocessing

curl http://hostname:port/reprocess?password=MYPASSWORD&target=MYTARGET&processor=MyBeanName
Parameter Name Description Example
hostname Deployer’s hostname localhost
port Deployer’s port. 9191 default is 9191
password Deployer password
target The name property value of a target bean in target context file. demodotcomprod
processor The bean name of a processor. For reindexing, it should be the bean name of a search update post processor registered for a target bean in target context file. (e.g. SearchUpdateFlattenXmlProcessor) DemoDotComProdSearchProcessor

Step 3: Wait for indexing

You will see indexing activity in the deployment log as well as entries on the server(s) running Crafter Search and Solr. Indexing activity time is dependant on the amount of content which must be re-processed.

Reindexing Content Without Disrupting Service in Production

In some scenarios, it’s not possible/appropriate to delete a live index and wait for the index to rebuild in production. Perhaps the index is driving dynamic features on the site that will break while the index is empty or being rebuilt. In these scenarios, you need a process for building the index offline and swapping it in.

Step 1: Prepare a re-index core

The first step is to prepare an additional empty core on Solr where you can index the content.

Step 2: Set up a new deployment context that points to the new core

The next step is to create a new deployment context that mimics/is a copy of the production deployment context but that points to the “re-index” core. Note that you must restart the deployer in order for the new context to be detected.

Step 3: Content freeze

Once you are about to start a re-index you need to freeze your authoring/editing activity. If Content is being updated in the live environment while you are rebuilding your indexes, you may miss updates. Ask your authors not to publish during your re-index process.

Step 4: Re-index

Following the process above “Reindexing Content for Search and Queries” for re-indexing content, you want to invoke a reprocess action against your new deployment context.

Step 5: Wait

You will see indexing activity in the deployment log as well as entries on the server(s) running Crafter Search and Solr. Indexing activity time is dependant on the amount of content which must be re-processed.

Step 6: Swap indexes

Now that indexing is complete you need to load the re-indexed content. Follow these steps * In the solr console for the core administration click swap cores and provide the paths to the new index. * Once the core has reloaded, move the original core to backup * Consider creating a copy of the re-indexed core with the original name and swapping again to preserve file/folder names.

Step 7: Unfreeze Content

Now that you are certain everything is working as it should, notify your authors that they may start editing and publishing activities.

Step 8: Clean up

Now that your process is complete you can clean up some of the artifacts created by the process. * The re-index core if swapped out * The new deployment context

Building CMS Backed Augmented Reality Apps with Crafter CMS

From SnapChat to Pokemon Go to the helmets used by F-35 fighter pilots, Augmented Reality (AR) applications are gaining a ton of traction. Unlike virtual reality which attempts to completely replace actual reality with an alternative universe and sensory experience, augmented reality, leverages technology to add a sensory (typically visual) layer of interaction and data on top of our everyday experiences. You can learn more about the difference between VR and AR by watching this free tech-talk / webinar. Augmented reality is so exciting and opens up so many new opportunities because it enhances our physical experience, giving us a way to experience things in a way we never could before.

As with most applications today, AR applications frequently contain a lot of content and related digital media such as 3D models, images, and videos.  Often times textual/markup content and digital media are deployed statically along with the application. This approach creates unwanted dependencies for content updates on the developers and requires laborious deployment processes.

In a business context, this misalignment and lack of independence can slow activities way down and ultimately impact the bottom line.  To address this common problem, developers often build custom applications for non-technical users or leverage content management system (CMS) technology.  Building custom authoring tools double development time and creates an additional support burden on your development team. Leveraging a CMS is a great idea, but you need to make the right choice.  Many CMS architectures impose severe limitations on markup, application and API architecture and design. As we’ll see in this article, Crafter CMS provides you with the tools and flexibility you need to create innovative, rich experiences like Augmented Reality.

In this article, we’ll build a simple (but not too trivial) AR application. After that, we’ll update it so that non-technical users can upload new models and edit and deploy/publish changes to the scene through Crafter CMS without any technical background.

For our application, we’ll start with a simple AR application based on open source frameworks AR.js, ARToolkit, and THREE.js.  Given that this is a tutorial and we want to have some fun with it, we’ll use (USC 17 107) some freely available 3D Models from (http://roestudios.co.uk/project/3d-pokemon-models.) You may also use any other models as long as they can be loaded by THREE.js’s library of loaders.  Free models vary in availability and quality. I chose this library because of the number of available models.

 

Step 1: Get a Simple, Static Browser-based Augmented Reality Application Running

Before we put anything in the CMS, let’s first make a basic static AR example application work.  We won’t get into the nuts and bolts of the various AR and 3D web related libraries.  There is a lot of material and examples already available on the subject.  Instead, we’ll try to avoid a lot of abstraction and construct an example that is simple enough in what it does so that the code can be readily understood.  You can find the code here on my Github account.

  • Clone or download this code as a zip
  • Open code/simple-ar.html with a browser

In your browser, you should see a video of yourself (captured by  your camera if it’s available and you have authorized it to be used by the browser.)  Additionally, hovering on screen, there should be a 3D model of Pikachu.

Now that we have a VERY SIMPLE working example of an AR application working we can get started integrating content management capabilities with our CMS so that anyone can add new 3D models to the application.

Step 2: Get Crafter CMS Downloaded and Installed

The first step is to get the CMS downloaded and installed. Crafter CMS is free and open source software licensed under GPL v3.

2.1 Download the Crafter CMS bundle

2.2 Install Crafter CMS and start it up

  • Unzip the download
  • Execute startup.sh (or startup.bat if windows) inside the unzipped folder
    • Prerequisite: Java 8 JDK is installed, and JAVA_HOME is defined as an environment variable
  • Open a browser to http://localhost:8080/studio. I recommend using Chrome. Chrome has the best support for desktop file drag and drop of all the browsers which will come into play later in this article.studio-login
  • Login with username ‘admin‘ and password ‘admin.’studio-no-sites

Step 3: Install the Application as a Project in the CMS

We now have the prerequisites done, and we’re ready to party! Let’s install the application into the CMS.

3.1 Create and setup a CMS project to manage your application

  • In Step 1.2 you logged into the CMS as the admin user who has an admin role. On the screen, you will see a button on the left hand that says “Create Site.” Locate and click this button.

  • Enter AR Tutorial as the application name.  Crafter CMS will generate a Site ID for you.
  • Select “Empty” for your blueprint and click the Create button.  Crafter CMS will create a new project for your AR Tutorial application with a basic “Hello World” type configuration.hello-site

3.2 Upload your application to the CMS

  • Click on Site Content in the menu at the top of the screen. This will open a panel on the left
  • Click on the Static Assets label this will open the folder.
  • Right click on the static-assets folder and choose Bulk Upload Assetsupload-static-assets
  • In your code folder from step 2, you will find a static-assets folder.  Drag the contents of this folder onto the upload dialog in the browser. When it’s done, you will be able to click Done.
  • By uploading the compiled assets, we’ve loaded the app into the CMS.  Now we have to tell the CMS to render our single page.  To do this, we must update our out-of-the-box template provided to us by the blueprint.  In Crafter CMS, templates are coded in Freemarker and can contain any kind of markup (typically HTML 5) as well as Freemarker Directives that make it dynamic.

    3.3 Update the site template with the content from the HTML page

  • To update the template: click “Site Content” in the menu at the top to hide the Site Content panel.   Then locate the Wrench in the upper right-hand corner on the toolbar.  Click the Wrench.  This will open the Preview Tools panel on the right-hand side of the screen.  preview-tools
  • Now click on In-context Editing to expand that specific tool.  You will notice this tool allows you to edit content, templates, and controllers.  We’re interested in the templates.  Click Edit Template.edit-tempate
  • Replace the code in this template with the HTML found in your build directory at code/simple-ar.html.
  • Note that the static code example assumes the application assets are at ./static-assets on the server.  In Crafter CMS, static assets like CSS, Java Scripts and images are served from /static-assets.  You will want to modify the paths (remove the ‘.’) in the HTML template to use the /static-assets folder as shown above.  Once done, click update.
  • Your app is now running in the CMS!  Congrats!   With this complete, we can start working on making the application dynamic, editable by a non-technical user and updatable at any time without a deployment.

Step 4: Content enable the application

The first step in content enabling the application is determining what the content model is.  A content model is a definition and structure of the content.  We maintain the definition of the content structures within Crafter CMS by declaring Content Types.

To figure out what your Content Types should be, look for the NOUNS in the application that you want a non-technical user to be able TO easily update and publish at any time.  In our case, this is an individual 3D model of a Pokemon like Pikachu.

While the model in this simple application will be very simple, Crafter CMS is capable of modeling very sophisticated objects as well as relationships between objects to handle real world scenarios.

Before getting into the CMS, let’s figure out what the definition for our Pokemon type should be.  We do this by looking at the application and seeing what fields the app will require. Because this particular type of content is a 3D asset rather than traditional digital media, we need to understand a little about what goes into making a model and how it’s described. We’ll start by looking at the two models in the model directory.  By examining both the pikachu and snorlax model directories we can see that a model can contain a different number of files.  Complex models may contain a lot of files.

We want the act of adding these models to the CMS to be really easy.  Other than adding the files to the CMS there is nothing to configure about them. Further, a folder is a good grouping mechanism for keeping the files for a specific model together. Given this, we’ll assume that the first step for the author in adding a new model is to simply upload it by dragging the model folder into the static-assets model directory via bulk upload.  In other words, for the 3D models themselves, we’ll leverage folder structure and IA rather than Content Model to store and organize the raw 3D content assets.

The next thing to look at is how the model is loaded into, positioned and scaled in the world.  For this, we need to look at the code.  Specifically, the code that loads the 3D model:

By examining this we see there are a number of important attributes:

  • We also see that every model has a file that defines its structure (.obj)
  • And a file that defines how to apply its textures (.mtl)
  • The Model Scale Multiplier
  • The Object Rotation on the X axis
  • The Object Position on the X axis
  • The Object Position on the Y axis

If we think about it, some of these are directly related to the 3D model itself and belong to the Pokemon content model.  Other attributes like scale and position are used to place the model in the world.  It’s more flexible if we manage the scale and positioning attributes outside of the object.

OK! We have a list of fields we need for our Pokemon, let’s get started defining the Content Type in the CMS:

4.1 Declare a Pokemon 3D Model Content Type

  • Open the Site Content panel.
  • Locate and click the menu item for Admin Console. This will take you to the power user area in the CMS used to manage and perform various site administration tasks.
  • On the left panel in the Admin Console, locate and click the menu option for Content Types. This tool is used to create new Content Types and edit existing ones.
  • content-types-consoleOn the toolbar at the top of your screen, you will notice two options: Open Existing Type and Create New Type. Because a Pokemon is a new concept you want to introduce and define in the CMS, click on Create New Type. This action will pop up a dialog to prompt you for some basic information about the content type.
  • Enter Pokemon for the display label. Crafter CMS will suggest a content type name automatically for you.
  • The Type you want to choose is Component. In Crafter CMS anything that you are modeling which is NOT a page is a Component. The main difference in the CMS between pages and components is that page objects are automatically URL addressable while components are not.create-type-dialog
  • Once the dialog is configured, click Create. This will open the content type editor for your Pokemon Content Type. You can learn more about the content type editor in detail at http://docs.craftercms.org/en/stable/developers/content-modeling.htmlnew-pokemon-type
  • The Content Type Editor lets you drag/drop editing field types from the right-hand controls list into your Content Type definition. You then click on the individual controls and configure them with Labels, properties, data sources, and constraints.
  • For each field, you need to add (Object File, Texture file, etc.), look through available controls list on the right, find the appropriate editing control for that content and drag/drop it into the Pokemon properties area.
  • After you add a field to the Content Type, click on it to configure it in the Properties Explorer.
    • Add a Title. This is the user-facing name the author will see alongside the input control.
    • Crafter CMS will automatically suggest a variable name which you can use later in templates and controllers to access the content values.
    • Scroll down in the Properties Explorer to see all the properties and constraints for the given field. This is how you mark fields as required, change their input length and make other adjustments.
  • Because you want the user to be able to pick the object and texture fields, you will need to give them a file picker control.  In Crafter CMS this is called the Item Selector control. Drag one of these on the screen as shown above and give it a title of “Object File.”
  • Now you need to tell the Item Selector where to find the content it’s going to allow the user to pick from (remember the authors will upload models into the /static-assets/model folder via drag and drop.)  To wire this up, you will need a Data Source. In Crafter CMS the way picker type controls get their values is via a Data Source.  There are several out of the box Data Sources, and it’s possible to define your own as well.  For our example, because we want to pick an existing file in the repo we’re going to use the data source called File Browse.  Scroll down within the Data Sources area until you see it then drag/drop it onto the Data Sources portion of the Content Type definition.

    Click on the added Data Source and begin to configure it as shown above.  Note that we’re simply identifying a path elsewhere in the CMS where we want to pick a file from.
  • Once our Model Files Data Source is defined, let’s connect it to our Item Selector control for Object Files.  Click on the Object Files control and configure it in the property editor as shown below:
  • Add another field for Text Files and connect it to the same data source.
  • Add an input control for X Rotation and configure it as shown below:
  • Perfect! Your Content Type definition is now complete.  Click Save at the bottom of the screen.Note that you are going to get a warning that the content type does not have a template associated with it. That’s ok.  Not every Content Type needs a template.  In our case, the app already knows how to render the content, and we don’t need another template.  Click Save on the dialog.  You’ll notice a small save indicator on successful save.no-template-warn

4.2 Create Pokemon Content Objects

Now it’s time to create some test content.  To return to your project Click the Crafter Logo on the toolbar in the top left corner of the screen.  This takes you to your workflow dashboard.  From here you can create content or navigate back to your application preview via the Site Content panel.

  • Click on Site Content in the menu at the top of the screen. This will open a panel on the left
  • Click on the Components label this will open the folder.
  • Right click on components folder and Create Folder.

  • Provide the folder name “pokemon”.

  • By clicking Create, you will have added a pokemon folder to the components folder.  This is simply to help organize your content.
  • Right click on the pokemon folder and Create Content.
  • The CMS will prompt you for the type of content you want to create.  You will note the Pokemon option.  Choose Pokemon and click “Ok.”choose-conent-type
  • Once you click OK, you will be given the entry form for your Pokemon which you can start filling out.  Awesome! Crafter CMS automatically creates your Pokemon editing interface based on the Content Type Definition.

  • Repeat this process as many times as you want, creating a new Pokemon each time.  When you save the form, you will see the Pokemon item listed under the pokemon folder as whatever value you entered into the Internal Name field (which is only used by the CMS editing tools as a label in the tool.)
    • Note:  Included an X Access Rotation in the model object because based on the available models the models all start facing in different positions.  The same is true for scale.  You may wish to add a “normalizing” scale value in addition to the rotation.

Step 5: Configure the AR Page Controller to Show a Pokemon Loaded from the CMS

Now that you have content objects in the system it’s time to provide the CMS with the logic to determine which items to show.  To start, we’ll keep things simple.  We’ll provide the template with a static list of models to display.

5.1 Update the Controller

The controller contains the business logic.  In our case, the controller is for a “Page.”  In Crafter CMS you can have controllers for pages, components, services, jobs and other kinds of objects as well.  To get to the page controller:

  • Locate the Wrench in the upper right-hand corner on the toolbar.  Click the Wrench.  This will open the Preview Tools panel on the right-hand side of the screen.
  • Now click In-Context Editing to open the In-Context Editing tools.
  • Now click Edit Controller.

  • Now add the following code:

def pokemonModelIds = [ “/site/components/pokemon/snorlax.xml”]

templateModel.pokemonInstances = []

pokemonModelIds.each { id ->
def pokemonInstance = [:]
def modelItemId = id

pokemonInstance.model = siteItemService.getSiteItem(modelItemId)
pokemonInstance.xPosition = -2
pokemonInstance.yPosition = -2
pokemonInstance.zPosition = -2
pokemonInstance.scaleMultiplier = 1

templateModel.pokemonInstances.add(pokemonInstance)
}

  • Now click update to save the controller.

The changes we made to the controller have added a new variable called pokemonInstances to our template model.

5.2 Update the Template

Now that our template has pokemonInstances available to it, we have to update it to take advantage of the values in that data structure.  We’re going to iterate over the items in the array and call the addModelToScene function for each item.

  • Locate the Wrench in the upper right-hand corner on the toolbar.  Click the Wrench.  This will open the Preview Tools panel on the right-hand side of the screen.
  • Now click In-Context Editing to open the In-Context Editing tools.
  • Now click Edit Template.
  • Find line 99 and make the following updates

<#list pokemonInstances as pokemonInstance>

<#assign texturePath = pokemonInstance.model.textureFile.item[0].key />
<#assign objectPath = pokemonInstance.model.objectFile.item[0].key />

loadModelIntoScene({
basePath: “${texturePath?substring(0, texturePath?last_index_of(‘/’)+1)}”,
mtlPath: “${texturePath?substring(texturePath?last_index_of(‘/’) + 1)}”,
objPath: “${objectPath}”,
scaleMultiplier: ${pokemonInstance.scaleMultiplier},
xPosition: ${pokemonInstance.xPosition},
yPosition: ${pokemonInstance.yPosition},
xRotation: ${pokemonInstance.model.xRotation}}, scene);
</#list>

  • Now click update to save the controller.

AWESOME! Our template now renders models that we add through the CMS.

The only issue is, adding a new model to the scene requires us to edit the controller.  This is the job of a developer.  In essence, we’ve moved the responsibility of deciding what models to render from the Javascript to the groovy code, but we haven’t put the power of deciding what to show in the hands of the authors yet.  So let’s do that.

Step 6. Give the Author the Ability to Add Models to the Scene

6.1 Update the Scene Content Model

To give the author, a non-technical user, the ability to update the scene, we have to first update our content model.  In this project, the content model that controls the scene is called Entry.  To edit the Entry Content Model:

  • Open the Site Content panel.
  • Locate and click the menu item for Admin Console. This will take you to power user area in the CMS used to manage and perform various site administration tasks.
  • On the left panel in the Admin Console, locate and click the menu option for Content Types.
  • Now click Open Existing Types and select Entry.

  • Click the Body Content Field.
  • Now click the dark X in the upper right-hand corner to remove the Body Content field.  It’s not used.

  • Drag a Repeat Group object on to the Page Settings section.
  • Configure the Repeat Group with a title of Models
  • Then Drag a Node Selector control into the repeat group.
  • Configure the node selector with the title Model
  • Drag a Child Content data source onto the Data Sources area and configure it as shown below.

  • Wire/Configure the Models Node Selector control to use the Models data source by clicking on the Model control and configuring the Item Manager property in the property sheet on the right.

  • Add additional fields for X Position, Y Position, Z Position and Scale Multiplier as shown below.
    • Note the use of the input control and the configuration in the properties panel on the right.

Once you have completed this, you can click edit on the main toolbar whenever you are looking at Home scene in Preview, and you will be able to, through a simple user interface, add models to the scene.

  • Click the Crafter Logo in the upper left corner.
  • Click on Site Content in the menu at the top of the screen. This will open a panel on the left.
  • Open Pages and then click Home to load the Preview
  • Now click Edit in the toolbar at the top.

  • Click Add on Models to add your first model.
  • Now click Add on the Model element and choose “Browse for Existing.”

This will open a browser to the pokemon folder where you have been creating Pokemon content objects.  You can click Add & Close to select an item and add it to a model in the scene.

Repeat this process as many times as you need to add the items you want in your scene.

  • Note you want to alter the X Position for each model that you add so that they do not overlap when they render.

6.2 Update the Scene Controller to Use the Scene Content Model

Now that we’ve modified the Scene content model and we’ve updated our content accordingly, we need to tell our controller to look at it and populate the template variables accordingly.

  • Locate the Wrench in the upper right-hand corner on the toolbar.  Click the Wrench.  This will open the Preview Tools panel on the right-hand side of the screen.
  • Now click In-Context Editing to open the In-Context Editing tools.
  • Now click Edit Controller.
  • Now Update the code with following:

    def pokemonModelIds = contentModel.get(“models/item”)
    templateModel.pokemonInstances = []
    pokemonModelIds.each { item ->
    def pokemonInstance = [:]
    def modelItemId = item.get(“model/item/key”).text

    pokemonInstance.model = siteItemService.getSiteItem(modelItemId)
    pokemonInstance.xPosition = item.get(“xPosition”).text
    pokemonInstance.yPosition = item.get(“yPosition”).text
    pokemonInstance.zPosition = item.get(“zPosition”).text
    pokemonInstance.scaleMultiplier = item.get(“scaleMultiplier”).text

    templateModel.pokemonInstances.add(pokemonInstance)
    }

  • Click Update to save your work.

6.3 Update the Scene Template to Use the Scene Content Model

Now that our template has pokemonInstances updated to include the values updated by the author via the content model, we have to update the template to use the new values.

  • Locate the Wrench in the upper right-hand corner on the toolbar.  Click the Wrench.  This will open the Preview Tools panel on the right-hand side of the screen.
  • Now click In-Context Editing to open the In-Context Editing tools.
  • Now click Edit Template.
  • Find line 99 and make the following updatesloadModelIntoScene({
    basePath: “${texturePath?substring(0, texturePath?last_index_of(‘/’)+1)}”,
    mtlPath: “${texturePath?substring(texturePath?last_index_of(‘/’) + 1)}”,
    objPath: “${objectPath}”,
    scaleMultiplier: ${pokemonInstance.scaleMultiplier},
    xPosition: ${pokemonInstance.xPosition},
    yPosition: ${pokemonInstance.yPosition},
    xRotation: ${pokemonInstance.model.xRotation}}, scene);

  • Click Update to save your work.

Step: 7 Play Around!

Congratulations! Now anyone with access to the CMS can quickly and easily add new models and configure it into the scene.  Download additional 3D models and play around with them!

Taking It Further

Our example is very basic.  We’re simply adding user configured 3D Models on top of a live video feed. This is just the start!

Real world AR use cases typically include animation, interaction and use visual triggers like QR codes, GEO Location or pure play vision to place the augmentation into the scene.  We excluded these additional capabilities from the article because they obscure the main point of the article which is making the scene configurable by non-technical users. That said, adding triggers is very easy to do. In fact, the CMS makes triggers even more powerful by giving you the tools to understand what device the user is using, where they are (geolocation) along with other contextual information. Further, you have the full personalization capability of the CMS to help you make your AR experiences dynamic and personalized. How awesome is that?!

Conclusion

Web-based augmented reality frameworks that help developers build AR experiences are making it easier than ever for companies to leverage AR as a way to communicate, educate, entertain and assist users in a rich fashion not previously achievable without huge investments.

Today most AR work is done exclusively by technical users, and the experiences are statically designed and deployed.  This is extremely limiting.  It significantly reduces the value of the development, makes it challenging and costly to update and significantly reduces the RoI on the effort. Smart developers will separate code from content so that non-technical users can quickly and easily update the application’s content without involvement from technical resources for code updates or deployments.

Integrating your CMS with your AR is a strong pattern for solving this problem — but architects beware, not all CMS platforms are the same.  The wrong CMS will interfere with the development process and force interface and implementation details.  Crafter CMS, a modern, open source, Java-based CMS, offers the right architecture, technology, and flexibility for the job. Crafter CMS integrates with your development process and tools and puts your app in control of the interfaces and implementation code while providing content authors with the tools they need to update and publish the application independently.  To learn more check out Crafter CMS at http://craftercms.org.

Responsive vs Adaptive Web Design: Better Together

Responsive web design (RWD), the ability for your web application to “respond” to the size of the view port (traditional screen size vs mobile screen size) is common place and practice today.  Responsive design leverages client sidefront end UI frameworks to hide, show, stack, shrink and grow elements on the screen in a way that is appropriate for the size of the device’s screen.  In essence, it is many user interfaces in a single code base.

Adaptive web design (AWD), a (seemingly) alternative approach to RWD is a server side capability to respond to the client with completely unique templates / markup for a given device type (amongst other facets.)  Adaptive design, while extremely powerful is somewhat less common in part because it relies on a server and is thus a less general technology. It’s also less prevalent in part because, for a large class of problems, RWD is “enough” to get the job done.  However, as complexity and sophistication of requirements mount, adaptive design starts to show clear advantages over a purely responsive approach.

Responsive design and adaptive design are often thought of as an either/or architectural choice.  There is clear overlap in the problems they address and each approach has clear strengths and weaknesses over one-another.  Let’s take a quick look at a side by side comparison:

Comparison

Technical Approach

Responsive Design: Leverages server agnostic front end frameworks (eg. Twitter Bootstrap) to render a appropriate content flow for the given screen size.

Adaptive Design: Leverages back-end server templates (e.g. Crafter CMS) to render distinct markup for the device and context requesting the application.

Strengths

Responsive Design:

  • Mainstream approach with many frameworks that can be applied to any backend technology.
  • Single code base

Adaptive Design:

  • Truly unique markup can be delivered based on any kind of context (not just screen size.)  This means it’s much easier to deliver contextual functionality to your users.  Example:  A retail store .com site that has a traditional marketing website at mystore.com but once it’s detected that a user is inside a physical store location, it gives them a personalized in-store assistance to enhance their shopping experience.
  • Performance.  With AWD you send only the data you need for the experience you are delivering.  On slower, mobile networks that can make a big difference.

Weaknesses

Responsive Design:

  • Single code base.  The more variations you want to support, the more code and complexity there is in that single code base.  This can get out of control.
  • Performance can be an issue:  RWD sends all of the code for all variations to every consumer whether or not they will see it in their flow or not.  If the amount of code is significant, this can lead to a performance hit on slower/mobile networks.
  • It’s difficult (although not impossible) to address different contexts beyond screen size with Responsive design.  RWD was really intended to different screen sizes (view ports.)  Stretching its role beyond that takes the technology out of its wheelhouse.

Adaptive Design:

  • You need a server backend to support AWD.
  • Instead of a single UI design and template code base, you potentially have many.  If you don’t manage and factor the code properly it will be more difficult to maintain.

Opportunities

Responsive Design:

  • Provides a usable experience on any screen size.

Adaptive Design:

  • Provides a usable experience on any screen size.
  • Provide faster experiences for your users.
  • Allows you to truly contextualize the experience.  Device type/class/screen size is really just the tip of the iceberg.  Once the server is involved any type of contextual data (location, previous use, time of day, etc) can be used to deliver unique and relevant experience/features to the user.  That can be huge.

Threats

Responsive Design:

  • If requirements go beyond screen size, RWD may not be the appropriate solution.
  • If the number of variations is too high performance and code complexity may be an issue.

Adaptive Design:

  • Managing unique templates is a heavier approach that requires server technology and the skills to go along with it.

Better Together

While RWD and AWD are most commonly looked at as competitive approaches, the simple fact is that they are not.  These two approaches are in fact mutually exclusive with another and can be combined to acquire the benefits of both.

Responsive design is front end technology.   Adaptive design is backend technology.  Combine them.

Consider leveraging Adaptive design to drive truly unique and contextual markup to the user for what they are doing, on the device of their choice at that moment.   Allow the front end to leverage Responsive frameworks to make sure those experiences flow nicely on a given device.  For performance and code maintainability, as your RWD code grows in complexity and size, consider breaking it down in to smaller code bases that can be individually delivered to a device by RWD (the server.)

A simple example of this is to have AWD templates for Small, Medium and Large screens.  Each with their own unique features and markup.  When it comes to the specifics like an iPhone vs a Galaxy smart phone (both considered small), RWD steps in to make the minor adjustments required to provide a perfect fit for the given device type. This makes the code more maintainable and more importantly it makes the user’s experience much more zippy.

 

Patterns for Integrating 3rd Party Content in Your CMS

There are often times when you will want to integrate content in your site that does not ORIGINATE in your content management system.  In this article we’ll look at a few high level patterns for integration and discuss the pros and cons of each approach.

Approach 1: Sync to CMS, publish to site as full content

Approach 1 focuses the integration at the CMS level only.  Content is either pulled or pushed from the 3rd party system in to the CMS.  From there it can be further processed and is ultimately published to the website where it can be used like any other type of content including native involvement in search and targeting scenarios.

Pros

  • 3rd party content is converted to 1st class content which allows it to be used natively by the system with not rendering engine level integration.
  • Authors may augment the content coming from the 3rd party system to include additional content and metadata
  • This integration is typically very simple
  • There is no impact on the performance or complexity profile of your delivery environment

Cons

  • Syncs can be tricky.  Remember content originates in the 3rd party system but it’s possible that it may need to be further modified by the CMS.  
  • A mechanism and a process must be defined that allows content updates to flow from the 3rd party system in to the CMS.  Typically this involves a strong ID that identifies each object, a mapping of fields that can always be overridden in the CMS  and mechanism for communicating creates, updates and deletes.

Other Considerations

  • By passing through the CMS 3rd party content is not “immediately” available on the website.  Content must wait for the sync mechanism to operate. Further, there may be workflow required before content can be made live.

When to use this pattern

  • This pattern is often preferred
    • It is relatively simple
    • Allows augmentation of the content in the CMS
    • Requires no run-time integration
    • Has no impact on the performance and SLA of the run-time

When not to use this pattern

  • When any create, update or delete to the content in the 3rd party system must be IMMEDIATELY available on the live site.

Approach 2: Partial sync to CMS, full details retrieved at run-time

Approach 2 syncs a simple jacket for the content to the CMS but relies on runtime integration with the 3rd party system for the full details of the 3rd party content.  The jacket in the CMS carries only the metadata required for the 3rd party content to participate in search, targeting and other dynamic behavior on the site.   The “sync” that creates the jacket in the CMS may be done through a simple integration or can even be a manual process.

Pros

  • Less content is relied on from the CMS which means that for items that have been previously published, detailed data is always 100% in sync with the 3rd party system.
  • Search, targeting and other dynamic capabilities native to the delivery system may still be relied on for functionality within the site.

Cons

  • There is a runtime dependency on the third party system for the actual content.  If that site is down, the content is unavailable.
  • As discussed in approach 1, syncs can be tricky.  In the case of approach 2 we still have some sort of manual or automated sync to create a jacket in the CMS.
  • In this approach there are 2 points of integration 1 at the CMS and one at delivery.  When you add additional moving parts, you are adding operation complexity that must be maintained and supported.
  • Content can be out of sync between what the site has in it’s jacket (and this in the indexes) and what is in the 3rd party system.  You must consider all cases: create, update, and delete

Other Considerations

  • By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

When to use this pattern

  • When detailed aspects of the 3rd party content must be IMMEDIATELY up to date.
  • When it is impractical to import all of the 3rd party content in to the CMS.  A typical use case for this approach is 3rd party hosted video.  The CMS may contain only basic metadata and thumbnails while the 3rd party system retains all of the various video encodings.

When not to use this pattern

  • If the website and the 3rd party system must be 100% in sync on ALL aspects of the content at all times
  • When approach 1 is viable.

Approach 3: Run-time integration only

Approach 3 focuses integration at the content delivery tier only.  Display and behavior related to the 3rd party content is all handled through integration.

Pros

  • Approach is the most simple from a “moving parts” perspective. There is no syncing involved
  • 3rd party content is immediately up to date when changes are made in the 3rd party system

Cons

  • There is a runtime dependency on the third party system for the actual content.  If that site is down, the content is unavailable.
  • All content display, and behavior such as query driven listings, content targeting, and search must be integrated.
  • It can be difficult to integrate functionality like search where CMS content and 3rd party content are placed together on the page in a seamless way.  This is because the implementation is very likely to require issuing at least two queries (one to the CMS and one to the 3rd party system.)

Other Considerations

  • By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

When to use this pattern

  • When 3rd party content must be IMMEDIATELY available and up to date on the site the instant it is updated in the 3rd party system.
  • When there is no need to rely on native capabilities of your delivery platform for delivery of the content and dynamic behavior (like search.)

When not to use this pattern

  • When option 1 or 2 are viable and use of native capabilities of the content delivery platform useful / required.

 

Never Use a Traditional CMS to Back Your Applications!

Almost every application today, regardless of the delivery technology and channel (web, mobile, kiosk, etc) has content in it. Smart developers quickly realize that managing the strings and the other content should be done outside the application rather than embedding it in the code base. Rather than build custom databases and authoring tools most developers look for a Content Management Systems (CMS) to fill this need. But there’s a problem with that…

Traditional CMS technologies (WordPress, Drupal and many others) have an architecture and approach that was designed and built over 20+ years ago. Let that sink in.

How can something built over 20 years ago or even something that was built “today” but that maintains the same basic pattern that was introduced over 20 years ago possibly be the right answer for today?  It can’t.  Here is just a few of the issues:

  • They are built with older technologies like legacy PHP, Struts, Sling and JSPs etc.
  • They don’t scale easily/cost effectively because of shared content stores based on SQL and Java Content Repositories (JCR.)
  • They are monolithic.  Most systems couple authoring and delivery which makes the system complex to maintain, hard to secure and even more difficult to scale.
  • They mandate rigid development and theme frameworks that slow down and limit innovation.
  • They make it difficult to roll out new functionality through your dev-ops process.
  • Thy are full of bolt-on solutions to keep up today’s needs like content as a service. Remember when they were designed, the world was just web pages.  You can’t teach an old dog new tricks.
  • Because of their heritage as page centric platforms they lack flexibility

Who in their right mind would put a technology with all that baggage in their application architecture?! Don’t do it. Just don’t.

So what’s the answer?  Back to building custom databases and editorial tools?  No.

To solve this problem a class of CMS solutions have show up in the called Headless CMS.  These solutions provide very basic content management and deliver the content as a API.  This capability is called Content as a Service (CaaS.)  Many of these are available only as Software as a Service (SaaS) solutions in the cloud.  These solutions solve some of the problems that traditional CMS solutions have by moving all presentation and development responsibility to the consumer (outside the CMS) and making scalability a vendor issue.

If all you need is “headless content”/CaaS and public cloud/SaaS vendors are a viable answer for you then you may have a solution.

However, many situations call for a solution that includes but go far beyond headless content — templates, personalization engines, queries and other key CMS capabilities are still needed by most solutions. Further, some companies still require on-premise installations.  For these organizations the field of viable solutions is much smaller.  They need a fully featured CMS platform without all the baggage — one that that has been completely re-architected and re-oriented for today’s high rate of innovation/iteration and digital experience challenges. That’s where Crafter CMS, an open source, Java based, enterprise-grade CMS really shines.

Crafter CMS is not a traditional CMS. Crafter CMS is a new platform built on modern technologies and a completely different architecture that is designed for situations that require rapid innovation, flexibility, enterprise integration and extreme performance and scalability.

How is Crafter CMS different from traditional CMS technologies? Here are 10 reasons why:

  1. Not page centric: Crafter was built to manage any kind of digital experience and related content.  Unlike legacy CMS software, it’s not page centric.
  2. Modern technology: Crafter is built with today’s most modern enterprise friendly technology like Java, Groovy and Spring, Git and Apache Solr.
  3. Tech you know, skills you have: While Crafter CMS has a lot of built in services and capabilities it doesn’t add or enforce a lot of framework. Developers leverage existing skills for familiar technologies rather being forced to learn and use platform/vendor specific technologies, and frameworks.
  4. Rapid development: Coding support for Groovy and Freemarker scripting removes the need to for heavy coding and deployment cycles.
  5. Amazing for devs and ops: Crafter fits seamlessly into your development and DevOps process. Finally there’s a CMS available that is not only powerful from a development perspective but that also plugs into your development process!
  6. Micro servicesCrafter is a decoupled CMS with separate authoring/management and delivery capabilities that are built on a micro services architecture.
  7. FAST! Crafter is blazingly fast. Rather than use databases and JCR repositories that are fundamentally slow and difficult to scale, Crafter uses an in memory database, disk and Apache Solr for content storage and retrieval.
  8. Extreme scalability: Crafter is horizontally scalable. Experiencing a huge surge in “traffic”? Just add more nodes. There’s no database to scale behind Crafter’s delivery tier. Further, because Crafter uses simple but powerful technology to drive dynamic content a single server can do a tremendous amount of work.  That means fewer servers are required to get the job done.  Fewer servers translates to less infrastructure, less labor, less cost.  Huge win.
  9. Geo-deployable: Crafter is geographically scalable and can even serve content in remote or disconnected environments. No databases. No clusters. No problem.
  10. Proven: Crafter CMS is battle tested and powering content and experiences at many of the world’s top brands and most innovation-forward companies.

Separating content from code is smart move. Betting on a traditional CMS to try an make it happen when you need development agility and scalability is a dumb move. Check out Crafter CMS!  It’s a totally new take on what a CMS platform should be!!

Querying Content in Crafter CMS

Types of Content Queries

Crafter CMS supports 3 specific types of content queries:

  • Cross content Lucene/Solr queries. This enables you to query any/all content objects, by any group of properties.)
  • Filtered Structural Queries. This enables you to query against the repository structure e.g. “Get all articles by author XYZ”
  • Content Item specific query. This enables you to write queries inside of a given content item.

Type 1: Make a Lucene/Solr Query

The following code examples use the Crafter Search Service in Crafter Egnine to get content. You can find the interface for this service HERE.

def queryStatement = 'content-type:"/component/article" AND author:"Russ Danner"'

def query = searchService.createQuery()
query = query.setQuery(queryStatement)

def executedQuery = searchService.search(query)
def itemsFound = executedQuery.response.numFound
def items = executedQuery.response.documents

return items

Type 2: Make a Query for Content Based on Structure

The following code examples use the Site Item Service in Crafter Egnine to get content. You can find the interface for this service HERE.

def topNavItems = [:]
def siteDir = siteItemService.getSiteTree("/site/website", 2)

if(siteDir) {
    def dirs = siteDir.childItems
    dirs.each { dir ->
            def dirName = dir.getStoreName()
            def dirItem = siteItemService.getSiteItem("/site/website/${dirName}/index.xml")
            if (dirItem != null) {
                def dirDisplayName = dirItem.queryValue('internal-name')
                   topNavItems.put(dirName, dirDisplayName)
            }
   }
}

return topNavItems

Make a Query for Content Based on Structure with Filter

The following code examples use the Site Item Service in Crafter Engine to get content. In the example we build on the Site Item Service of getting objects under a specific tree in the repository by supplying a filter that will be applied to each object first to determine if it should be part of the result. Filters can make their determination based on the path or the content or even “outside” influence.

  • You can find the interface for this service HERE.
  • Note in the example below we define our own filter based on the ItemFilter interface found HERE.
  • However, you may use out of the box filters as well if they meet your needs. These are found HERE.
  • Finally be aware that for simple filename patterns, methods for this already exist in the Site Item Service and no filter is required (but they make for an simple to understand example.)
import org.craftercms.core.service.ItemFilter
import org.craftercms.core.service.Item
import java.util.List


def result = [:]
def navItems = [:]
def siteDir = siteItemService.getSiteTree("/site/website", 2, new StartsWithAItemFilter(), null)

if(siteDir) {
    def dirs = siteDir.childItems
    dirs.each { dir ->
            def dirName = dir.getStoreName()
            def dirItem = siteItemService.getSiteItem("/site/website/${dirName}/index.xml")
            if (dirItem != null) {
                def dirDisplayName = dirItem.queryValue('internal-name')
                   navItems.put(dirName, dirDisplayName)
            }
   }
}
result.navItems = navItems

return result


/**
 * Define a filter that returns only items that have a name that starts with "A" or "a"
 */
class StartsWithAItemFilter implements ItemFilter {

    public boolean runBeforeProcessing() {
        return true
    }

    public boolean runAfterProcessing() {
        return false
    }

    public boolean accepts(Item item, List acceptedItems, List rejectedItems, boolean runBeforeProcessing) {

      if (item.getName().toLowerCase().startsWith("a")) {
          return true
      }

      return false
    }
 }

Type 3: Make a Query Against Fields in a Content Object

The following code examples use the Site Item Service in Crafter Engine to get content. You can find the interface for this service HERE.

def result = [:]
def segment = "a segment value" // could come from profile, query param etc

// load a specific content object
def itemDom = siteItemService.getSiteItem("/site/components/sliders/default.xml")

// query specific values from the object
result.header = itemDom.queryValue("/component/targetedSlide//segment[contains(.,'" +  segment + "')]../label")
result.image = itemDom.queryValue("/component/targetedSlide//segment[contains(.,'" +  segment + "')]/../image")

return result

Building and Optimizing Multi-Channel Digital Experiences

Over the last few years, the internet has undergone a tremendous amount of fundamental change in its landscape, and we are now entering into a new reality with today’s Web. This change is driven by five major trends:

Social – The Web is much more social and much less anonymous than ever before. As an example, many sites and applications allow users to authenticate using shared / common identities provided by Facebook and Google.

Personal – While the internet is continuously expanding in terms of ubiquity, at the same time, it’s becoming much more local and much more personal in terms of user experience.

Mobile – the growth of mobile access to the internet is rapidly expanding. Access from tablets and phones has long since exceeded that from desktops and laptops.

Internet of Things (IoT) – The internet is no longer just websites and applications. Consumer devices of all kinds from beacons and thermostats to digital assistants are now connected.

Digital Natives – We now live in a time where our children have had access to to extremely powerful computing and connectivity their entire lives.  As they become decision makers we must realize that their experience and hence their expectations are vastly different than our own.

Each of these trends is a significant development in user experience in their own right. However, these trends feed and reinforce one another in a way that’s accelerating change and adoption across all trends.

The very way we communicate with and understand our customers is changing, and when foundational change like this occurs, those who recognize the change and move quickly to adapt have the most to benefit. Adapting to these important changes should be on your near-term road map.

Let’s take a look at each of these trends in more detail to get a deeper sense of reasoning and urgency for change.

Social

Social Media is ubiquitous now, with Facebook reporting over 1.8 billion active users, Snapchat at 100 million users and Twitter users estimated to exceed 315 million. With these numbers – combined with the fact that studies show that while only 14% of consumers trust traditional advertising, 78% trust peer recommendations. Social communication is personal, emotional, timely, relevant and propagated amongst peers – it’s easy to see why social is so important.

Personal

We all know that over the last twenty five years the Web has made the world a much smaller place by knitting our global communities together through an increasingly ubiquitous network. This trend continues today, but on a whole other level. The internet is increasingly being used to deliver the activity, news, reviews, sales and other relevant data and services that are occurring and are available to us right in our immediate vicinity. All this information is being delivered right to us in real time through our mobile devices. While the world may be getting smaller, our personalized experience is growing larger.

Mobile

There are 7.4 billion people in the world, of which, 6 billion of us own an internet-enabled mobile device of some kind. In-short, almost everyone in the world is connected with at least a basic mobile device. Additionally, 1 third of the world’s connected users have at least 1 or more smartphone or tablet capable of delivering extremely rich digital experiences.  Competitive organizations Uber, Lyft and many others are leveraging this connectivity to change the way business is done.

Internet of Things (IoT)

The Internet is no longer about websites and apps accessed by computers and mobile devices. Our cars, the stores we shop in, the devices in our homes and all kinds of devices throughout industry are constantly connected and communicating with other devices and systems via the internet.  We call this new reality the Internet of Things (IoT.) Even at this “early” stage in 2017, there are some 20 billion IoT devices connected. IoT is almost certainly the “next” mega-trend for the internet. Pages and apps are rivaled in volume by APIs. Human users now share the web with “Robots”.  The “Next mega-trend” is in fact already upon us. IoT opens a universe of new capabilities and user experiences as well as new challenges.

Digital Natives

Anyone who has a “tween” or teenager today knows that we’re already living a new evolution of the population. From birth, our children have grown up with an extreme level of connectivity and computing power. “Computing” is unbelievably fast, highly visual and tactile. Connectivity is ubiquitous. The applications they’ve grown up with are highly interactive, social and personalized. They don’t know anything different. A new kind of user is born. Businesses that don’t adapt quickly as this group comes of age as the next wave of consumers and employees will lose big to the companies that that do.

Meeting the Demands of the Era of Engagement

Each of these trends reinforces the others, and fuels further adoption and drives innovation. It is these technologies – and the behaviors and capabilities they foster – that have brought us to a new era, which Forrester calls the “era of engagement”. This is a new reality where the distinction between on-line and offline is becoming ever more blurred and the experience ever more immersive.

Driving these trends are people – our friends, leads, customers, critics, and fans. This is our audience and the other half of the conversation. And it’s no surprise that in today’s reality – that is, in the age of engagement – they want to participate and expect us to engage them on their terms – on their schedule, in the context of their location, in their language, and optimized for their device.

Your audience has also become accustomed to a personal experience, and they expect a personalized, coherent and consistent customer experience regardless of whether they are in your brick and mortar store, on your Facebook page, or on your website. To effectively tackle this challenge of serving a mass audience with limited resources, enterprises require strategy and effective tools to help get the job done.

Does Traditional Web Content Management Get Us Where We Need to Go?

Traditional Web Content Management (WCM) solutions are focused on building websites, landing pages and blogs.  As we’ve seen, today’s challenges go well beyond these demands. Web Experience Management (WEM) provides us with the toolset to take on this otherwise daunting challenge. The capabilities of WEM allow you to create, manage, and deliver dynamic, targeted and consistent content across various online channels including your website, social media, marketing campaign sites, mobile applications, and more.

In short, it takes a lot more than a traditional Web CMS or Web Content Management (WCM) can provide to meet these needs.

Key Principles of Experience Management

Before we get too technical let’s take a step back and ask what kind of guiding principles can adopt that will help us meet the challenges of the “Era of Engagement.”

  1. Great experiences are designed, built and delivered by a multidisciplinary teams.
  2. New data and channels can spring up at any time.
  3. Time to market is king and the platform that enables the first mover is the king maker. Agile approaches and shorter delivery cycles are extremely important!
  4. Great experiences are relevant and relevancy drives value.
  5. Technical architecture matters and ultimately defines the limits of what is possible.
  6. Simplicity is paramount. True simplicity comes from the separation of concerns and good architecture rather than specific technologies, vendors and shrinkwrap.
  7. Today’s experiences exist anywhere and everywhere.
  8. Experience is a journey rather than an interaction. Customers and users expect each interaction to leverage previous interactions.
  9. “One size fits all” is a fallacy. Each organization has its own unique needs, existing skill sets, and back ends.
  10. Openness is key to innovation at scale.

Translating Principles to Technology

Based on the principles above we start to get a clearer picture of the kind of technical architecture we need:

  1. A platform that is content first.  Content must be cleanly separated from code and presentation so that it can be reused and consumed across multiple channels.
  2. Foundational support for dynamic personalized experiences. From the structure and retrievability of the content to the amount and types of data you can store about your users, to the complexity of the rules you can write; personalization is an architecture concern, not a feature.
  3. Strong support tool and process for both content creators and developers.
  4. An open architecture that favors innovation with scale, security, performance and performance.
  5. True independence between content creation / management and delivery.  Content authoring and content delivery, while closely related, they are really two very separate concerns.  At scale, publishing needs to be both push and pull. Truly decoupled architectures align best with today’s needs.

Choosing a WEM Platform

Most people choose a CMS based on long check list of features and a demo of the authoring tools.  While checklists and demos are very important they don’t get at something much more fundamental, and in the case of the challenges we face, important and that’s architecture.  Architecture matters.   While many CMSs pass the checklist-demo gauntlet, nearly every CMS solution, regardless of what they claim, is an evolution on WCM and is ill-equipped for the Era of Engagement and beyond.  The proof is in the architecture.  Since so many CMS solutions out there claim to handle WEM but fail to deliver architecturally let’s dig in to some of the issues:

  • Most CMS platforms “couple” authoring and delivery.  While this is ok for some use cases it has a number of limitations:
    • Authoring and delivery often require unique security integrations.
    • If authoring and delivery are coupled in the same database, work-in-progress content is at risk to a security breach.
    • Coupled systems demand that authoring and delivery components share the same Service Level Agreements (SLAs) and scale out.  This significantly complicates the architecture and increases the total cost of ownership.
    • Most coupled architectures have no native PUSH support for content deployment which means they only support PULL style publishing (content rendered as HTML and JSON) and do not easily publish to disconnected / external systems via APIs.
  • Almost every CMS out there uses RDBMS database and JCR backed content.  This approach leads to a significant number of problems and constraints:
    • Scaling relies on clustering and replication and is difficult and clunky.
    • While clustering and replication schemes within a data center are approachable, globally distributing the topology via clustering and replication is whole other level of hurt.
    • Because code and content is stored in a database (in some cases just code) it’s extremely hard to innovate quickly because it’s very difficult to move code and/or content between environments and through the development process.
  • Many CMS’s are built on poor technology choices that ultimately slow the rate of development, deployment and kill innovation:
    • PHP a great example of technology that’s widely used in the CMS space.  The issue with PHP is that when it comes to heavy lifting or integration it breaks down.  Most PHP platforms like Drupal or WordPress require Java backed capabilities like Solr as soon as the going gets tough.  Making the right technology choices avoids work-arounds and leads to more simple, more cost effective and more maintainable infrastructures.
    • Older technologies like JSPs, Sling along with proprietary development and theme frameworks have huge learning curves or require hard-to-hire skills due to their niche application.
    • Approaches like war files and even OSGI are heavy deployment technologies slow time to market dramatically.  Scripting offers a much better approach for most functionality.
  • Most CMS’s have the wrong approach to user data. Storing user data in a traditional database doesn’t work at scale with today’s international regulations.
    • Many countries have on soil data requirements.
    • Many applications need to be able to access user data — but only see what they need to see.
    • Real personalization often requires a tremendous amount of data which in some cases must be analyzed in real time.  Traditional RDBMS doesn’t fit the bill.
  • Most CMS’s treat personalization, contextualization and localization as a feature rather.  They are not features. They must be part of the very fabric of the platform in order to succeed at scale.  Only the most basic use cases can supported unless these are treated like architecture rather than bolted on features.

Crafter CMS to the Rescue

Crafter CMS, a modern open source, Java based Experience Management platform is architecturally different than all of these other solutions — which means it can deliver different results.   Crafter is a complete and comprehensive WEM application built on top of leading open source technologies like Spring, Solr and Git – that provides multi-channel digital experience management through a rich user interface and a high-performance content delivery system, while providing content creative and development teams with the real tools they need to craft amazing personalized digital experiences for their customers.

Crafter CMS consists of thee major applications – Crafter Studio and Crafter Engine and Crafter Profile.

Crafter Studio provides all the content management services and integrates with repositories like Git, Alfresco and other CMIS based platforms to enable authoring, management, and publishing of all content. Crafter Studio provides a comprehensive set of user-friendly yet powerful features for managing and optimizing of experiences.  

Crafter Engine provides high-performance content delivery services that can power any type of Web or mobile application. It consumes content published through Crafter Studio and provides developers with the foundation for quickly building high-performance, flexible Web and mobile applications. Crafter Engine provides out-of-the-box integration with numerous data sources and application services. A key feature of Crafter Engine is its ease of integration. Modern WEM applications must integrate with one or more enterprise systems or third party services. Crafter Engine can easily be integrated with other applications such as CRM and sales force automation, marketing and email campaign management, and other enterprise systems required for optimizing the Web experience for your audience.

The management and delivery of content is decoupled and separate, allowing each system to be optimized for its purpose, audience and scalability requirements. Multi-channel publishing is naturally supported, and mobile devices and applications are enabled by means of both native device support (iOS and Android) and HTML5 support.

Crafter Profile provides a secure and scalable platform for storing, querying and analyzing user data at each interaction in your customer journey.  As it stands, data privacy concerns and international regulations are extremely complex and getting more complex with each passing day.  Crafter Profile leverages MongoDB and can store user data of any type and volume can be stored, the data is globally distributable to meet on-soil PII requirements. Further, Crafter Profile offers “Big Data” processing and analysis to the delivery tier to drive true personalization.

Content First

Crafter CMS completely separates content, code and presentation.  Content is captured and stored as XML and other static assets (images, videos, PDFs, etc) in the repository.  By leveraging a file based, XML approach, content is easily moved between environments and systems for work processes (e.g. translation) and is easily published to/for any kind of content consumer.

Extreme Scalability

Performance and scalability are an architecture concern.  If you have the wrong architecture you’re forced to use work-arounds like CDNs or build replication based science projects at the data layer.  Crafter avoids these by getting the architecture correct from the start.  Crafter Engine is a high performance Spring MVC based application that can render dynamic, personalized content in any format within milliseconds. Crafter Engine a shared nothing component that does not rely on external databases.  By leveraging local in-memory databases, fast disk and local Solr, Crafter Engine provides the proper foundation to build a cloud scalable, elastic globally distributed infrastructure.

Personalization in the Core

Crafter CMS treats personalization as a part of the architecture rather than a bolt-on feature. Crafter Engine and Crafter Profile combine to deliver a platform for high-performance personalization at scale with complete scriptability, security and regulatory compliance.

Truly Decoupled

Crafter CMS is a decoupled CMS that separates authoring and publishing capabilities into their own subsystems in order to achieve the many benefits discussed above. Crafter CMS makes it easy for authors to create, manage, and deliver content in any format from RESTful APIs/JSON to HTML5, and even virtual and augmented reality via AFRAME. So for modern digital experiences that must be delivered across many channels, Crafter CMS provides a decoupled architecture combined with Content as a Service capabilities.

Built for Innovation

To be truly innovative you have to be great at both building and delivering.  What good is a platform that performs well but is hard to update or a system that’s easy to develop for but is hard to deploy new features on?  Crafter CMS is built on today’s leading open source technologies like Java, Spring, Groovy, Freemarker, Solr and Git.  This means your developers don’t need to learn a vendor specific stack to get started.  The right technologies make all the difference.  Crafter CMS combines the integration power of Java with the speed of scripting (via Groovy for controllers and Freemarker for templates.) Further code related assets like templates, CSS, Javascript etc in are stored and deployed from Git.  This means your developers work locally with desktop tools if they want, and can leverage their standard DevOps process and tools to move features and functionality forward to production.

Conclusion

There have been major revolutions in technology like the industrial revolution, the amazing growth of the web 1.0 and many others throughout history that have changed the way we work and live — but there has been no changes like the kind of change we see unfolding now.  The key difference is: the the number things changing at once,  the pace at which the changes are occurring and the fact that all of the changes feed and reenforce one another’s momentum.

To deal with this new challenge and the pace at which it is advancing you will need to think differently and arm yourself with new ways of working, new architectures, new technologies and new tools.  Old guard and rebranded WCM solutions are no match for the future we face. With the growth of social, mobile, the Internet of Things and the coming of age of digital natives we must evolve, innovate and be able to adapt much more quickly in order to survive. Proper architecture and solution design will play a much bigger role in driving success than simple features. Crafter CMS is open source WEM project and platform that was built from the ground up and has an architecture designed for today and tomorrow’s digital experience needs.