Rivet Logic Blogs

Category: Marketing

The internet has revolutionized the way companies market their products and services today, and one of the biggest changes is how businesses are leveraging their websites to market their online presence. In a competitive digital world, the key to success is reaching potential customers and driving them to your website.

In a webinar earlier this year, we discussed how Search Engine Optimization (SEO) has become a top priority in today’s growing world of technology reliance on web-based platforms, and how Liferay’s newest features can be used to implement SEO-friendly dynamic pages, illustrated by a real world customer example.

What is SEO?

For those who aren’t familiar with Search Engine Optimization (SEO), it’s the process of affecting the visibility of a website or web page in a search engine’s “natural” or un-paid “organic” search results. Unlike paid search results, like Google Adwords, where you’re essentially paying for your URL’s to display in a favorable position, SEO involves the natural algorithms that sort the results.

Organizations are always trying various SEO techniques to increase high value traffic to their sites from search engines such as Google, Yahoo, and Bing. Common SEO methods include getting indexed, controlling the crawl, and increasing prominence. It’s important that your page is highly relevant to the keywords that users would use in their search for that page.

SEO Strategy Considerations

When determining an SEO strategy, there are several important factors to consider:

Controlling Meta Information

First and foremost, it’s important to ensure that all of the properties being used to describe your page are relevant and descriptive of the page’s content. HTML pages contain metadata – title, meta tags, keywords, etc. – and search engines look at this metadata through sophisticated algorithms to determine its value, which is then used to score the page.

Liferay allows users to control the metadata for each page, along with the ability for localization. For example, the US page can have metadata in English and a Chinese page could have the metadata in Mandarin in order to maximize the score.

Site Map Protocol

Another feature that search engines provide is the ability to show searching users a site map of the website directly in the search result page to help them find what they’re looking for faster. For example, if you searched AT&T in Google, you will see search results for AT&T along with the site map, as shown in the image below. Liferay has an out-of-the-box capability of pushing your sitemap out to Google and Yahoo using the Site Map Protocol.

Friendly URLs

A good SEO strategy also involves the use of friendly URLs. Your URL patterns need to be descriptive of the content. Out-of-the-box, Liferay URLs in many cases aren’t good enough as they contain a lot of URL parameters. However, Liferay allows for the creation of custom friendly URLs through the Friendly URL Mapper to solve the problem.

SEO Friendly Sliders/Carousels

Lastly, many organizations struggle with the issue of SEO friendly sliders and carousels. In a nutshell, a page rendering carousels should only have the content of the relevant slide instead of all the slides. When users perform a search, the search engine crawls through each slide and indexes it as part of the same page. The challenge is tricking the search engine into viewing each slide as a separate page, while maintaining the animation.

For example, if a user searches for something that lies in slide 3 of a carousel, and the search results take them to slide 1 where the information isn’t relevant to what they were looking for, it can cause confusion and frustration. It’s easy to see why this is something companies want to avoid as it can result in a poor user experience that could deter the user from visiting the site again.

The solution lies in the URL. By creating unique URLs for each slide of the carousel, search engines can treat and index them as separate pages, making them SEO friendly.

To maintain the proper carousel transitions between slides, the slides are linked so that a simple AJAX call back to the server allows users to view all the carousel slides. In addition, all of the carousel slides are managed in one Liferay Web content article. This way, only one slide in the carousel is rendered during rendering, preventing any false positives when search engines are indexing the page. With this solution, you can still have carousels without sacrificing the SEO friendliness of a site.

Real World Customer Example – Sensus

Sensus is a global enterprise in utility infrastructure systems and resource conservation. For its global website, products are organized in a way as illustrated in the diagram below – where sensus.com contained multiple country sites, each with multiple divisions, and those with their own product lines, each with multiple products.

However, in reality, the associations between these entities were not as cleanly hierarchical as the diagram implies. In fact, all the entities could be associated with one another, as shown in the following diagram.

This presented the biggest challenge as it meant that a truly hierarchical representation for the content behind Divisions, Product Lines, Products and Solutions could not be created. And from an SEO perspective, all this content still needed to be searchable, and needed to be in a hierarchy that search engines understood.

Templates and Page Types Are the Answer

To solve this problem, we leveraged templates, which helped content managers organize their content in a way where it’s reusable, without losing the site map and structure of the content.

Liferay’s built-in rich WCM capability allowed us to divide a page into building blocks. For example, a product line page would be divided into the following sections – overview, products, and associated solutions.

We also created page types, where a single Liferay page can display as many articles as necessary for a particular page type. For Sensus, we had page types for Division, Product Line, and Product.

What about SEO?

When addressing SEO, the answer was in the method of content delivery. We needed to make sure that content authoring and delivery were decoupled to maintain SEO friendliness of each country’s site.

We achieved this through a process where content authors didn’t touch the Liferay pages. Instead, all they had to do was create Web forms and tag each article using Liferay categories, in turn capturing the hierarchy. That way, the article can surface in various places throughout the site based on how it’s categorized, allowing content authors to maintain a single source of truth for the content and also the hierarchy in the information architecture on the delivery side. Now when search engines scan through the pages and come up with a searchable index, the structure makes sense and there’s no loss of content organization.

As a result of this solution that enables the creation of a global website with shared content, we also encountered some SEO challenges that were specific to Liferay – HTML Titles and Breadcrumbs. As discussed earlier, search engines expect a page’s HTML title to be relevant to what’s on the page. However, since we’re using page types, where each page is displaying multiple products, we couldn’t have the same title for each product page, and Liferay out-of-the-box controls the page title based on the page type. Similarly, Liferay’s Breadcrumb capability had to show hierarchy of the content.

Both of these challenges were solved through a plug-in that enabled us to intercept the HTML Title and Breadcrumb generation code and replace it with dynamic logic so that it made sense for search engines.

In summary, SEO is something that’s becoming increasingly important for all public facing sites to focus on. A key SEO success factor lies in the strategy that must be defined early on in the planning phases of a project to ensure maximum SEO friendliness, and Liferay as a CMS provides a great tool for SEO that can satisfy almost all requirements.

The internet plays a huge influential role in our daily purchasing decisions, most of the time without us even noticing as it’s become so second nature. Whether it’s checking out a restaurant menu before trying it out, checking to see if a product is available at a specific store, or seeing if a business’s solutions can benefit you, a company’s online presence can drastically affect the impression it leaves on a visitor, making it crucial to have a site that delivers an engaging and lasting experience.

In our latest case study published earlier this year, we take a detailed look at how a leading cloud services and communications company is leveraging a Crafter CMS solution to deliver a dynamic, engaging Web experience while increasing site traffic and sales leads.

Rebranding Effort For a Cloud Services and Communications Company Leads to a New Dynamic Website for a Higher Quality Customer Web Experience

As a leading, award-winning cloud and communications services provider, this organization serves as the technology ally for small and mid-sized businesses by delivering services through their private, high-bandwidth enterprise network and data centers. By shifting the technology burden to the provider, they strive to help their customers save valuable time, money and resources.

Customer service excellence has been a big part of this company’s culture since its inception, making it imperative to maintain a cutting edge Web presence. This customer had recently undergone a corporate rebranding initiative, and as part of the effort, had sought to provide a far more dynamic and engaging Web experience for its users. With these objectives in mind, it was quickly realized that there was a need for a new enterprise-class Web Content Management System (CMS) with the robust functionality to effectively address existing needs, along with the flexibility to tackle any ongoing future requirements.

Unlimited Agility Through Open Source Innovation

Led by the Marketing Department, and working in conjunction with the product development groups along with senior executives, this customer wanted to ensure the new website produced the end result they desired. They knew that with any new Web CMS solution, flexibility was a top priority – flexibility of design, using in-house resources, customization, and adapting to ongoing needs.

As an organization that works with a variety of third party vendors for their projects, this customer saw the benefits of open source when it came to flexibility in choosing future development partners when the need arose to grow the Web application with additional components. So they also sought a content management platform that was open, agile and sported a rich feature set. After evaluating a number of potential products, an integrated solution based on Crafter and Alfresco emerged as a clear choice.

Paving the Way to Serve as a Full Fledged Technology Ally for Its Customers

With the new website, this customer has seen an increase in content production and publishing productivity, and are better able to quickly respond and adapt to the data received from analytics. The dynamic content pages provide a proficient way of cataloguing and repurposing content throughout the site. Since re-launching the site using Crafter CMS, overall website traffic has increased by 9 percent while the number of leads generated have more than doubled that amount.

From time to time at Rivet Logic we get questions concerning Alfresco‘s ability to build and manage component-based websites due to its file / folder based organization. In many cases this question arises from either a limited look at Alfresco’s features (sometimes sourced from industry analyst reports that lack depth) or a far too simplistic understanding of Alfresco’s core capabilities and established best practices for web content management and dynamic content delivery.

Through this short article I will demonstrate the following:

Repository organization has no bearing on website placement of components

Primary organization in a file / folder structure is a strength and offers technical capability that differentiates Alfresco from lesser Web CMS platforms.

This article will approach this question with the capabilities of Crafter Rivet, a 100% open source web content and experience management solution built as a plug in for Alfresco. Crafter Rivet consists of two major subsystems: 1) Crafter Studio, an authoring environment built on top of Alfresco’s content repository and 2) Crafter Engine, a high performance content delivery platform which relies on Apache Solr for dynamic content queries. Crafter Rivet and Alfresco enable a de-coupled content management architecture: Crafter Studio and Alfresco for content authoring, management and workflow, and Crafter Engine for high performance dynamic content delivery. Content is published from Alfresco to the de-coupled Crafter Engine delivery stack, which is where the website application(s) runs. Once deployed to Crafter Engine, content updates are immediately available and are reflected in a high performance, queryable Apache Solr index to support dynamic content delivery. Moreover, all content is cached in memory for very low response times.

With this understanding of how the separation of content management from content delivery work in a de-coupled Web CMS platform such as Alfresco, we can now discuss how the content organization within the Alfresco repository facilitates component-based site development. We refer to content organization within the repository as the “primary organization” of the content. Crafter Rivet allows authors to build component-based websites, and place content components anywhere on the site regardless of the primary organization found inside the Alfresco repository. Components may be placed in a region of a page explicitly through drag-and-drop construction, or they may be surfaced through a dynamic query.

Explicit placement simply links the content to a page through an ID-based association, completely independent of the underlying file/folder structure. Query-driven content placement leverages a Solr-based index and returns a list of component IDs (and other attributes) based on the given criteria. And in both cases, the primary organization of the content plays no role in the ability for the content to be used in any region of any page of the website.

Within the repository and authoring life cycle, primary organization is an extremely useful paradigm. Authors need to be able to find content quickly. By putting every content item in a structured location (i.e., folder) it is much easier to find when browsing. Contrast this with the opaque database/data structure approach taken by many other platforms which offer no direct access or ability to browse for content. In general, we have found it best to remove abstraction as much as possible when modeling content. For site pages, as an example, we model these as files and folders that match the URL. Crafter Engine understands that specifically for pages, the URL and this structure are related. A change in to the folder structure also changes the URL. This is extremely helpful to authors as it maps directly to their expectation when thinking about page hierarchy in their information architecture.

Components, on the other hand, tend to be grouped by type or some other such criteria. Authors may create arbitrary folder structure to house components, forming a primary organization that enables them to quickly find and work with content. This primary organization has nothing to do with how, when or where the content will be rendered on the site. Further, Alfresco allows content managers to attach rules, policies and permissions to folders inside the repository. This is an extremely useful and powerful capability not found in may other Web CMS systems. By leveraging the primary organization of pages and components, content managers can enact specific rules for content transformation, metadata extraction, validation, workflow, and much more throughout the authoring life cycle.

As you begin to work with Alfresco for web content management you want to keep in mind that the organization of your content inside the repository and the delivery of that content are two very different things. Alfresco as a content repository is generally de-coupled from the delivery mechanism as we have seen with Crafter Rivet. Take advantage of the fact that Alfresco’s file / folder structure has many organizational and technical benefits during the authoring life cycle and has no bearing on the delivery of that content when deployed to a dynamic content delivery engine like Crafter Engine.

Last week was a busy week for those of us working on Crafter Rivet, the WEM/WCM extension for Alfresco 4.0. We’re extremely excited about this release and are busy scheduling events and demos as word is starting to get out!

For existing Alfresco WCM customers on Alfresco version 2 and 3 using the AVM based solution, we’ve put together a couple of blogs to help you think about your migration to Alfresco 4 and the core repository:

For everyone who wants to learn more about this exciting and powerful open source solution for web content and experience management that sits on top of Alfresco, the world’s most open and powerful content management platform, we’re hosting a Crafter Rivet Roadshow in a city near you in May! Come on out for content packed presentations, demonstrations, Q & A and free lunch!

In yesterday’s post we covered the fact that Alfresco stopped selling the AVM based WCM solution to new customers. Existing customers using the AVM based approach will continue to receive support until the AVM reaches end of life status. New customers looking to Alfresco for WCM/WEM capabilities who read this will naturally wonder what is the approach to WCM on Alfresco. Existing customers will want to know how to migrate off the AVM and in to Alfresco’s core repository.

As we have seen in yesterday’s post, the core repository has had the benefit of continuous innovation through which it has grown as a platform now capable of supporting use cases critical to WCM/WEM with key features like remote file deployments and form based content capture. Along with features clearly directed at the WCM use cases, the core repository is host to an amazing array of features and capabilities that make it ideal for all manner of enterprise management, WCM/WEM included.

At Rivet Logic we have made a significant investment in a web content and experience management extension to Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source, full featured application that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to covert. Just released, Crafter Rivet 2.0 is 100% based on the core repository, Solr search and Actviti workflow for Alfresco 4 CE and EE. Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.

Now that we have a background understanding of both the AVM and core repository features we discussed yesterday it is time to look at the use cases that the AVM was designed to address. We will discuss the use case and how these gaps were addressed by Crafter Rivet. Let’s get started!

Use Case: Sandboxing
As described in yesterday’s blog, sandboxing is a feature but there are use cases that drive this feature. In a Web CMS context we have times when we need to modify templates, CSS and other assets that have far reaching effects on our sites. There are three common use cases that point to sandboxing:

Development: As a developer I want to work with a template, a CSS file, a JavaScript library, etc. without worrying that the bugs I will inevitably create will interfere with the rest of the teams ability to produce, manage, preview and publish content.

Timing: On websites of significant size and complexity, there are often times when projects are created to update the look and feel of the site. These projects with future delivery dates need to be able to take place without interfering with daily publishing. Further, it’s important that the project be able keep up with on-going updates to reduce the headache of last minute merges.

Playground: Sometimes we just want to play. Sandboxes allow us to enable team members to innovate and play around without fear of impacting the live website.

It’s clear that the ability to sandbox (or branch/merge) your website code base can be pretty handy. In my mind there are several key questions:

Is the support for this use case a “must have” for my specific environment? How often do I run in to the use cases above?

What granularity of sandboxing do I need?

Many popular Web content management systems do not natively support sandboxing. In a lot of cases the need for the branch merge capability is handled through the development and deployment process. In general I think it safe to say this feature is a rather strong “nice to have” unless you have an site with look and feel components which are literally being constantly updated and where the traditional development process would add too much time to the effort.

When you do need sandboxes the next question is granularity and how sandboxes are used. The AVM UI dictates sandboxes for each user. In my experience accumulated over many Alfresco WCM engagements; is that this was too fined grained for the needs of most engagements. Most users want to work directly in context with other users. They need basic locking on individual assets to keep work safe during their edits but they don’t require an entirely separate and parallel universe. The ability to create a sandbox ad-hoc for a specific purpose maps more directly to the needs we see on the ground. In other words, a sandbox is too granular but a sandbox for a project to update the look and feel of the entire site where users could work together would more aptly address the kind of needs we see.

Crafter Rivet starts with the first finding, that sandboxing is not a “must have” feature and that in-fact when it is applied it should be done so to facilitate specific projects and specific ad-hoc needs. If you look at the way we have structured our content in the core repository you will see we have left room to support one or more draft copies of the site. In v2.0 we do not support layering in the default configuration; however, Crafter Engine, our content delivery and preview tier, is able to sit over top of multiple hierarchical stores and present them as one store much in the same way the AVM did.

Use Case: History and Reversion in a Web CMS Context
As a user, when I want to preview a version of a specific asset, let’s say a page, I want to see the page as it was on that day. That means I want to see exactly the same components and assets (images, CSS, js etc) as they were on that given day. This is a real challenge in the core repository because there is no native support linking assets together under a common version; each asset is individually versioned and the links between objects (associations) do not capture version.

Now to be honest, I have simplified the problem a bit to make a point. I said that pages, for example, are compound assets and that you are always interested in seeing their dependencies at a given point in time. This is often the case when we’re talking about images and components that are specific to the page but it’s not really the case when we’re talking about shared assets like templates, CSS, JavaScript, and shared components and shared collateral. Think for a moment about why users want to look at and ultimately revert to previous versions of content. They are doing so either:

In the short term because they have made a mistake, or

in the long term because they need to revert messaging to a previous point in time.

In the first instance there is likely to be no issue. Common assets are likely going to be the same as they where at the point in time of the version. However, in the second case, we really want to see the old content in the context of the current templates, etc. If we revert, it’s to get the older content, but we’re going to deploy it in the context of the latest look and feel of our site.

Handling versioning in Web CMS is a must have, must do capability.

In Crafter Rivet we considered these use cases fully and drew a distinction between two types of relationships. Those relationships which are page only and those which are shared commonly amongst other objects in the system. When you revert a page or any other object, those relationships which are “page only” will revert to a point in time, while other relationships that are common will continue to align to the latest version of the asset.

To accomplish this we leverage both the native versioning capability of the core repository as well as file organization and patterns. In short, we organize page-only assets in folder structures that represent the page. Page objects are given names that are based on a hash of the object to guarantee a unique name which means in effect that the versioning of the page only object is “horizontal” in the repository. By horizontal I mean that a new file path is used rather than relying on the version store. Shared objects like pages or other common assets are stored regularly and rely on the native versioning support. If you revert a page you will revert to an a state where the page points to a different set of file / file paths — achieving a solution for both use cases we mentioned above.

Snapshots
There are several Web CMS use cases that could require snaphsots and version diffs. For example, some websites have compliance related issues and thus must maintain versions of their sites so that in the event of a dispute over information communicated via the site they can easily prove what the site looked like at a particular moment in time. The question for snapshots is:

Is this something your organization must have?

And if so, is it something that the repository has to do for you?

Our experience shows that this feature, for the general market, is a nice to have. Most customers don’t take advantage of this capability. When we looked at this capability in Crafter Rivet, we decided it was not important to support natively within the repository itself. If a customer needs a snapshot every day we simply include a deployment target that would produce a snapshot.

For those wondering about snapshot rollback; our experience has shown that this particular feature is really not relevant to most customers in day to day operation. The feature has come in handy as a mechanism for bailing out people who have made sweeping changes to a site (100s of files) and deployed them with little or no QA only to find a broken website after the fact. In such a case, snapshotting a rollback is a life saver. With a click of a button you can revert 100s of files.

Crafter Rivet, by design is 100% file based. In such a crisis scenario, a simple file based backup could be used to restore a Crafter Rivet based site to a former state. In the repository, you are unlikely to desire an actual rollback. It’s more likely that you will want to keep the broken state and simply fix what is wrong and then redeploy the working site.

Moving Forward

Alfresco v4 is an incredible platform and the move to the core repository unlocks all of that capability and innovation. Crafter Rivet is a platform that made use of all of the functionality in the AVM. And with our new release, we made the move. You can as well. More importantly, if you are using the AVM with Alfresco v3 (or even V2), then Crafter Rivet is the perfect solution for your upgrade. We can provide parity for most needs with a much better user experience that goes way beyond basic Web CMS needs with the coverage of WEM use cases like integrated analytics and reporting, native mobile application authoring, preview, and presentation, content targeting and personalization, multi-channel publishing and much more. If you’re new customer to Alfresco looking for Web CMS solutions, Crafter Rivet is a comprehensive WCM/WEM solution, with features that rival some of the major players in the industry.

I was on a call today with a long time Alfresco WCM customer who would like to upgrade from 3.x to 4.x. They have been using the Alfresco WCM solution provided by Alfresco in 2006 for many years. As many of you know Alfresco’s original WCM solution is based on a technology called the AVM – Alternative Versioning Model. The AVM is a separate repository and associated user interface that was constructed to handle a number of WCM related use cases. Alfresco has since enhanced their offering in their “Document Management” repository, which now handles WCM use cases. As a result, Alfresco has now announced that the AVM will no longer be offered to new customers. In discussing the upgrade with our clients on the call today. “It’s time to move to the ‘DM’” was the most responsible message to provide. Existing customers won’t lose support over night, but eventually the AVM will hit its end of life. You want to migrate at your earliest convenience rather than procrastinating and allowing pressure to build.

It’s also important at this point to abandon the use of the term “DM repository”. DM was used to differentiate from the AVM. At this point there is only one repository. The “core repository” is much more descriptive of the architecture going forward. As Jeff points out in his blog and as I will elaborate here, there are differences in the the AVM and the core repository in terms of features. That said, features and use cases should not be confused. The core repository is every bit as capable of providing a platform for Web content management use cases as the AVM.

At Rivet Logic we have made a significant investment in a Web content and experience management application for Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source, full featured environment that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to convert. Crafter Rivet 2.0 is now based on the core repository, Solr search and Activiti workflow for Alfresco 4 CE and EE. Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.

I thought it would be helpful to share some of that thinking. Today we’ll look at the differences in these repositories and tomorrow, in a second post we’ll discuss the actual Web CMS use cases that need to be addressed and how we addressed them in Crafter Rivet. Let’s explore!

Unique Features of the AVM

The first thing I want to do is address the question of what the AVM can do that the core repository cannot. Because we’re comparing repository to repository we’re going to discuss features and not use cases. Note that for simplicity, on occasion we’ll collapse the features of the AVM repository, supporting UI and supporting integration into the single term AVM. It’s also fair to note that what we’ll discuss here are the aspects of the AVM which exposed through the associated user interface and thus applicable to customer engagements. There are features/capabilities of the AVM repository that were not fully exposed by the UI.

Sandboxing (more accurately, layering)

Sandboxing is the ability for a user to work on any asset or group of assets within the site without interfering with another user’s work. For example, a user could modify and even break a template or CSS file and no one would know until and unless the user promoted that broken asset out of their work area. For non-technical readers, a sandbox is best described as your own copy of the website. For the technical readers, you can think of a sandbox as a long running transaction — in source control terminology, a sandbox is like a checked out branch of the site.

Sandboxing is a high order feature born out a lower level feature called “layering.” The AVM is constructed of lightweight stores. Stores can be layered one on top of the other. The store on the top appears as though it contains the assets within the store layered below it. If a user places an changed in the top store it appears to over-write the asset at the same path below it. If we have a base store we’ll call “the stage area” and then a store for each user; say Bob and Alice, and both Bob and Alice’s stores are layered on top of the staging area you can see how we create the concept of sandbox. Alice can see everything in the staging area, but nothing in Bob’s store. Alice’s work is in a “sandbox.” If Alice pushes her change from her store to the staging area, Bob sees it immediately as if it were in his store.

Multi-Asset Versioning

In the AVM, versions are taken at the store level not per asset. When you place a change in the store, a lightweight version is created for all assets at that moment. Because of this, it is possible to know the state of every object at a point in time relative to a given object. For Web CMS applications, we deal with compound assets all the time. Consider a webpage. A webpage is not typically a single file asset, it’s a document that points to other documents: components, images, css, javascript, etc. When you version a page, you generally intend that entire collection of assets to be versioned along with the page.

The core repository manages each individual asset’s version history independently. If page X points to component Y there is no innate support within the version system to know what version of Y was in use at any given point of X’s history.

Snapshots / Comparison and Rollback

In the AVM you can label a version and compare one version to another. It is easy to see what files have changed. Because of this it is possible to create “diffs” from one version to another. Once you have a diff you can roll back entire check-ins very easily.

Content Forms (Now supported in core)

The AVM user interface used to support a forms capability that was not available for the core repository. The forms engine made it simple to create content capture interfaces through mere configuration. Today the core repository has a forms capability that is more powerful than what was provided for in the AVM user interface.

Content Deployment (Now supported in core)

An AVM project could be configured with remote content receivers. There was out-of-the-box support for repository to file system deployment (FSR) and repository to repository deployment (ASR). Today the core repository provides two deployment mechanisms; Transfer Service and Channel Publishing framework, which combined now exceed the capabilities of the AVM content deployment framework.

Unique Features of the Core Repository

Now lets look at what the core repository has going for it that the AVM repository and supporting UI never got around to implementing. Again we’ll look at features rather than use cases.

Rules Support

The core repository allows you to attach rules to a folder that execute based on lifecycle events and configurable conditions. This is extremely powerful and its a feature that was sorely absent in AVM.

Stronger Modeling Support

Both repositories allow us to create types and (more commonly) aspects which contain metadata. However the core repository allows for associations at the modeling layer. In the AVM, associations were kept only as paths within files. This turns out to be fine for content delivery but bad for managing the content due to move and rename operations because of the unbounded number of updates you may have to perform. Associations in files also makes it difficult for supporting user experience features in your content management platform. Users expect a platform to understand it’s assets and how they relate to one another in a way that can be quickly accessed through query. The core repository can do this innately through it’s use of associations. The AVM cannot.

Strong Transformation and Metadata Extraction

The transformation and metadata extraction frameworks integrated with the core repository greatly exceed the capabilities of the those integrated with the AVM. The AVM is only integrated with an XML metadata extraction and transformation. The core repository on the other hand has integrated support for all kinds of metadata extraction and transformation including Microsoft Office documents, images, PDF and many many more.

Powerful, Fine-grained Permissions

The core repository gives us the flexibility to create and manage user access to content in a way that best fits an individual engagement through the use of ACLs (Access Control Lists.) While the AVM was based on a similar scheme under the hood, these were never exposed through the UI and thus it were not practical to deploy on engagements. Out-of-the-box AVM exposed a few roles that could be applied broadly to the entire site in each sandbox.

API support

The core repository has much better remote API support. The core repository supports CMIS, webscripts, and RAAr. AVM only supports a remote API based on RMI.

Workflow Engine

The core repository has 3 workflow engines integrated with it: Simple, JBPM, and Activiti. Activiti is based on standards and has parity with JBPM, but incorporates a far better management console. The AVM provides workflows based on JBPM integration only.

Search

Full text search support is based on indexing. You index a store. In the AVM universe every web project was made up of many (layered) stores. It was not practical to index every store. Although you can configure individual stores for indexing, if every author in the system wants to be able to search their sandbox, you will hit obvious limitations to the approach. The core repository content has only one store which is constantly tracked by a search index which means that search is very current with work in progress. Alfresco 4 has introduced Solr as one of its search subsystems. Solr provides capabilities that greatly exceed Lucene, the indexing engine used by the AVM.

Integrations

The core repository has many integrations that allow users to interact with content on their own terms, be it email, WEBDAV, FTP, shared drive, Sharepoint and so on. With exception to the filesystem projections, these are simply not made available in the AVM.

Native support in the UI and APIs for taxonomies, folksonomies and collaboration features

The core repository has repository service and UI support for

Hierarchical taxonomies

Tags

Comments

Content lists

Making Sense of the Differences

By this time you should have a pretty good idea of how the repositories compare from a feature perspective. Two observations are obvious:

The core repository has a had the benefit of deep continuous innovation.

The AVM has certain features intended for WCM use cases that will need to be addressed in a solution that leverages the core repository.

Join us tomorrow for a blog post that will demonstrate the use cases that these features were intended to cover and how we addressed all the Web CMS use cases with Crafter Rivet using and capturing the full power and innovation of Alfresco 4 and the core repository.