the web content & experience management evaluation … · jive mindtouch – exo interact...

JIVE

MINDTOUCH

–

EXO

INTERACT

– ZYNCRO

HARMON.IE

KINVEY

SERVICE2MEDIA

JULYSYSTEMSXAMARIN

CORONA LABS

SPRINGMOBILE

SOLUTIONS

USABLENET

–

– KENTICO –

INGENIUX

DOTNETNUKE

JOOMLA

MODX

OMNIUPDATE

EPISERVER

PROGRESS/SITEFINITY

TERMINALFOUR –

MAGNOLIA

GX SOFTWARE

EVER TEAM

SPRINGCM

M-FILES

HYLAND

ALFRESCO

SDL

SALESFORCE

EMC

ORACLE

WORDPRESS

The Web Content & Experience Management Evaluation Report

Excerpt of Comprehensive Product Evaluations

Sample Edition, Sample License

Web Content & Experience Management Sample Edition, Sample Licensei © Copyright 2016 Real Story Group.

All Rights Reserved.

Adobe

Atex

CCI

Contentful

CoreMedia

Crafter

CrownPeak

DotNetNuke

Drupal

Episerver

e-Spirit

eZ Systems

GX Software

Hippo

IBM

Ingeniux

Joomla!

Kentico

Magnolia

Microsoft

MODX

OmniUpdate

OpenText

Oracle

Perfect Sense

Plone

Progress Software

SDL

Sitecore

TERMINALFOUR

TYPO3

Umbraco

WordPress

Vendors Reviewed

This list of vendors reflects the contents of the full report. This excerpt only contains OpenTextTeamSite.

Vendors Reviewed

Web Content & Experience Management Sample Edition, Sample Licenseii © Copyright 2016 Real Story Group.


Table of Contents (from the full report)

Part 1: Executive Summary

Part 2: Universal Scenarios: The Key to Comparing Technologies

Part 3: Strategic Considerations Dissected

CMS Product Comparisons

Legacy Platform Vendors

IBM: Web Content Manager

Microsoft: SharePoint Server 2016

OpenText: TeamSite

OpenText: Web Experience Management

Oracle: WebCenter Sites

Upper-Range Platform Vendors

Adobe: AEM Sites

CoreMedia: CMS

SDL: SDL Web

Sitecore: Experience Platform

Mid-Range Platform Vendors: Roll-Up Comparisons

Atex: Polopoly

Contentful: Contentful

Crafter Software: Crafter CMS

Drupal: Drupal

Episerver: Episerver CMS

GX Software: XperienCentral

Hippo B.V.: Hippo CMS

Perfect Sense: Brightspot

Plone: Plone

TYPO3: TYPO3

Table of Contents

This table of contents reflects the contents of the full report. This excerpt only contains OpenText: TeamSite.

Web Content & Experience Management Sample Edition, Sample Licenseiii © Copyright 2016 Real Story Group.


Mid-Range Product Vendors

CCI: Escenic

CrownPeak: CrownPeak CMS

e-Spirit: FirstSpirit

eZ Systems: eZ Enterprise

Ingeniux: Content Management System

Magnolia: Magnolia

Progress Software: Sitefinity

WordPress: WordPress

Simpler Product Vendors

DotNetNuke: DotNetNuke

Joomla!: Joomla!

Kentico: Kentico CMS

MODX: Revolution

OmniUpdate: OU Campus

TERMINALFOUR: Site Manager

Umbraco: Umbraco CMS

Part 4: Advice, Pitfalls, and Best Practices

Table of Contents, Cont.

OpenText: TeamSite

1 Web Content and Experience Management Sample Edition, Sample License

© Copyright 2016 Real Story Group. All Rights Reserved.

Subsequent to introductory chapters, summaries, and ratings charts, we provide in-depth evaluations of each product we evaluate. These evaluations provide details about the strengths and weaknesses of the products, provide insight, and explain the ratings. Below is an excerpt of our evaluations; each product is reviewed using the same criteria.

OpenText: TeamSite www.opentext.com

I. Vendor at a Glance

Specsheet OpenText:TeamSite8.1Summary

Geography Global

What’s New • Acquired by OpenText from HP along with other former Interwoven tools

Strengths • Broad platform support matrix, and decent hooks into other vendors' commerce and portal servers, including nice preview features

• Product focuses on marketing-oriented managers' needs • Emphasis on “branching” renders it well suited for large, mostly static sites with numerous

content authors and owners • Optional content targeting module is well elaborated • Optional mobile module supports adaptive design strategies • Company can boast decent integrator channel and vibrant developers' extranet • OpenText will likely continue to support legacy versions

Weaknesses • A complete solution requires licensing multiple products and will complicate your architecture, infrastructure, staffing, and budget

• Underlying platform is nearly two decades old; both the architecture and API are quite Byzantine, with higher risk of product extinction

• Managing content deployment, synching, and debugging still remain complicated and a source of frustration for developers and sysadmins

• Company's major bet on IDOL technology for various supplemental services has proven to be complicated and proprietary

• Exceptionally proprietary system requires above-average developer and sysadmin effort — particularly if you license a non-standard LiveSite dynamic delivery environment

• TeamSite competes with two other WCM tools at OpenText and is unlikely to see much R&D going forward; it’s not dead, but it’s not really alive, either

OpenText: TeamSite



App Platform Mixture of C++, JavaScript, and Java, with occasional legacy Perl, and the optional LiveSite delivery environment runs in standard Java appservers like JBoss

Licensing Complex mix of server modules and contributor seats, plus optional modules

Ownership Public (NASDAQ: OTEX)

OpenText: TeamSite



II. Summary • Like its longtime competitor-turned-sibling OpenText WEM (former Vignette),

Interwoven’s TeamSite Web CMS product emerged early to become a venerable player in the WCM space — only to be acquired as part of a larger rollup under Autonomy. Then Autonomy in turn was acquired by HP in October 2011 for a whopping $10.3 billion. TeamSite lived uneasily at HP, which then sold it to arch-competitor OpenText, where it will likely see a graceful death.

• TeamSite’s history dates back to the mid-1990s. Interwoven differed early on by developing slick editorial and website management features atop a relatively simple, file-based repository. However, even after a slew of its own acquisitions, Interwoven could not keep up with its nimbler competitors, and in 2009, search vendor Autonomy completed its acquisition.

• Neither Autonomy nor HP ever seriously refactored the technical underpinnings of the TeamSite/ LiveSite platform in existence for nearly two decades — although HP proved to be better at bug fixing than Autonomy ever was. In any case, customers find it highly difficult to align TeamSite’s architecture with contemporary standards and performance expectations. In addition, you may need multiple packages for a complete solution, whereas simpler tools may bundle diverse services into one product. Thus, you are bound to deal with an installation that is very complex and difficult to extend and maintain without major engineering undertakings. Upgrades of any kind will continue to prove very difficult — even by the standards of this industry.

• HP did make some minor enhancements, including the content targeting and templating. The release of version 8 brought mobile add-ons and a new site-management interface. The reality is that most of these are adjustments around the edges. The core platform remains a developer-intensive conglomeration of proprietary code and methods that only a limited number of people belonging to an esoteric TeamSite guild could fully understand.

• We could tell you about TeamSite’s potential scenario fits, but why bother? OpenText already sells two other WCM tools, and likely just plans to milk support revenues from TeamSite.

• At RSG, we have searched in vain to find happy TeamSite customers; you have little compelling reason to join their ranks. TeamSite has been on a long death march, but after prolonged illness, it has finally found a decent hospice. We expect the platform will be well-treated at OpenText. Just understand it will be palliative care, with no emergency life-saving measures.

OpenText: TeamSite



III. Background • Interwoven launched TeamSite in 1995 and like its direct competitors, the vendor

built or acquired a bevy of across-the-broader enterprise content management tools. Interwoven expanded into new, adjacent areas like asset, document, and collaboration management. All of these products went to Autonomy in its 2009 acquisition of Interwoven, and thence to HP in 2011.

• In 2015, HP itself famously split into two companies: HP Enterprise and HP Inc. Interestingly, TeamSite — as part of “HP Engage” — did not end up in the Enterprise group, but with the “older” Printers+PCs sibling. It was a poor fit there, and HP ended up selling it to OpenText in 2016.

• Within the TeamSite family, you can purchase a variety of corollary products and optional modules, though many licensees consider them quite quite essential.

• TeamSite SiteSearch: TeamSite ships with repository search; if you need SiteSearch, you’ll turn to add-on modules based on IDOL technology.

• OpenDeploy: This is a code and content promotion tool. We have never seen TeamSite implemented without it.

• TeamSite MediaBin: This is a relatively well-established, web-focused DAM product, now living under the TeamSite moniker.

• LiveSite: This consists of a dynamic delivery module that is explored in-depth below, along with personalization framework LiveSite Targeting.

• TeamSite Mobile: This is an adaptive, design-oriented tagging and emulation server, OEM’d from Trilibis.

• Some products can be combined nicely (particularly TeamSite and MediaBin), but understand that (among other differences) several of them have widely varying technical specifications. For example, some modules run inside a Java application server, while others (like TeamSite) have components that are freestanding servers on their own. MediaBin runs only on Windows and customizing it requires ASP/.NET skills. It’s all very messy as a group. Other parts of TeamSite are not organic and are based on acquired products such as the website testing and “optimization” service from former Optimost.

• A long-awaited version 8 came out in Q3 2015, although customer uptake appears to be rather slow so far. A fix-patch followed in short order. Version 8 brought more substantial improvements to the editorial functionality, including slicker mobile authoring, a new site-management interface, and a slew of improvements to LiveSite. Version 8.1, released in Q1 2016, improved MediaBin and Google Analytics integrations, among other tweaks.

OpenText: TeamSite



IV. Scenario Fit Consider staying with TeamSite if it is already working effectively for you; we don’t recommend that you license it anew under any circumstances.

Use Case Rating Analysis

Simpler

Basic Digital Marketing 0 This is overkill for this scenario.

Online Communities 0 TeamSite has no tools for this scenario.

Digital Workplace 0 TeamSite is not suited to this scenario.

Campaign & Microsites 0 LiveSite has some useful services, but you wouldn’t want to use a heavy platform like TeamSite for this scenario.

Informational Sites 1 This is overkill for this scenario, though TeamSite can support very large static sites.

Complex

Multilingual Digital 0 TeamSite has no tools for this scenario.

Advanced Personalization 1 There are some reasonably good targeting services, but not they’re not easy to deploy or test.

Omni-Channel Engagement 1 In theory, the decoupled architecture and XML-based content should support this, but TeamSite offers little support.

Mobile-Optimized Experiences 2 There are some nifty mobile features — if you license the optional third-party module.

Content-Enriched Applications 1 The decoupled architecture should support this, but TeamSite’s frameworks are too dated to work with modern web applications.

OpenText: TeamSite



V. Strategic Considerations Strategically, the situation with TeamSite is a mess.

Consideration Rating Analysis

Vendor

Vendor Professional Services 1 Historically, service haven’t been bad, but the future is unclear under OpenText.

Customer Support 1 The support is decent, albeit somewhat under-experienced.

Strategy 0 The typical OpenText strategy is to milk maintenance revenues.

Viability & Stability 0 This is a dying — and therefore high-risk — platform.

Product

Technical Modernity 0 TeamSite possibly has the oldest codebase in this report.

Roadmap 0 There is nothing major on the horizon.

Value for Money 0 TeamSite is way overpriced for what it does.

Ecosystem

Channel Professional Services 2 A small but dedicated and experienced channel persists.

Community Strength 1 The community is small, but still ticking.

Third-Party Add-Ons 0 There are no add-ons.

OpenText: TeamSite



VI. Technology Services: Considerations & Drawbacks The short story is that it’s old, proprietary, and Byzantine. The longer story is that it’s an initially promising approach that’s built on XML with a decoupled architecture. However, it has not been updated and it has become a confusing mess over two decades.

“This is not your typical J2EE application. It's more of a one-off and it’s like a client-server; you need experienced TeamSite architects to configure and sustain it properly.”

Findings Impact

Technology, Administration, and Security

TeamSite boasts an impressively broad support matrix. It runs on Windows, Linux, and Solaris, along with many different flavors of relational databases. However in recent versions, HP came to encourage Linux. Note that while the Java-based components

This is not your typical J2EE application. It's more like a one-off and it’s like a client server; you need experienced TeamSite architects to configure and sustain it properly.

TechnologyServices

Administration & Security

Threat Prevalence 3

Authentication & Authorization 3

System Reporting 1

Multisite Management 2

Cloud Services 1

Performance 1

Development

Configuration & Customization 1

Integration & Extension 1

Content Modeling 2

Templating 1

DevOps 1

OpenText: TeamSite



Findings Impact

can run on nearly any J2EE appserver that supports Beans, the core TeamSite engine, written in C, can only run on simpler, 32-bit hardware.

TeamSite is not simple to install. Under the hood, there is no new or standards-oriented technology, and given multiple products and configurations, the typical installation of all the various modules in a production environment is measured in days — not hours.

Customers report that this can be particularly tricky with upgrades, since the TeamSite license gives you only 48 hours to run two versions concurrently.

When you install TeamSite, a typical configuration consists of the following two environments: 1. Development Server: This is the place to create new applications and websites. It consists of: • TeamSite with SitePublisher: SitePublisher

provides a visual interface for creating sites, navigation, adding components, and so on

• OpenDeploy: Used to copy code and content from the development server to the runtime server

• Administration Console: Where you administer TeamSite as well as OpenDeploy

• Other components: Application Server (JBoss), Interwoven Registry, and the SDK

2. Runtime consists of: • LiveSite Display Services (LSDS): This is to

deliver content from TeamSite/ SitePublisher • LiveSite Content Services (LSCS): The runtime

version of LSCS • OpenDeploy: The receiver component of

OpenDeploy • Application Server: Tomcat is used • Repository: Based on IDOL search index TeamSite’s close neighbor LiveSite is an optional experience management product — a kind of portal itself, except it is really a one-off, Java-based framework, and not really a formal portal platform.

Monitoring all of the modules and services becomes extremely complex. An experienced architect told us, “Installation is a nightmare, with too many services to monitor. I was tired of monitoring the log files when something didn’t work.” Integration with HP’s ill-starred IDOL search framework was particularly fraught with each new release, although the main problems around event queues may have been resolved with version 8. Note that you may end up with quite a few databases and schemas with components like LiveSite, TeamSite, reporting, and others expecting their own database. On the plus side, clearly separating management and delivery in a decoupled framework makes it easier to deploy selected elements to the cloud as part of a hybrid strategy.

Its decoupled nature allows TeamSite to support a variety of dynamic delivery approaches. This can be tricky to set up, but it works. The product accesses a separate webserver where you load your JSP/ ASPX/PHP interpreter, and TeamSite loads your customer presentation template into its rendering

This has enabled highly distributed enterprises to control some aspects of content management separately, while allowing individual units to run their own website environments.

OpenText: TeamSite



Findings Impact

engine to give a complete preview for authors in decoupled environments.

In TeamSite vernacular, websites or parts of websites are known as “branches” or “sub- branches.” Each branch has multiple Workareas (where authors create content), a Staging Area, and Editions. TeamSite does not use a database to store content (except in the delivery tier when you use LiveSite), but rather, a proprietary file system-based repository. In TeamSite’s “virtual file system (VFS),” contributor’s Workareas and Editions contain a copy of every file that comprise the site.

Editors seem to like this approach, and branching tends to ease the maintenance of very large sites. However in the past, customers have found that the system tended to top out at about 800 folders. The product’s file system architecture is getting old, and it seems to take comparatively longer to make system-wide modifications. OpenText claims that recent overhauls now base the architecture off its IDOL technology. That’s only partially true. IDOL indexes content in the management and delivery tier, but many of the APIs and actions rely on file management and file-based configurations under the content.

If you license LiveSite rather than rolling your own dynamic front-end, you have two architectural options for delivery: • LiveSite Display Services (“LSDS”) – This

assembles and delivers XML components and fragments using XSLT.

• LiveSite Content Services (“LSDS”) – This is where content gets stored in an IDOL search index with all its extended attributes, and then queried via Web Services; you need to use this approach for LiveSite’s personalization and targeting features.

Customers have also told us that IDOL repository corruption happens frequently, which requires re-initialization of the indexes; this problem appears to have been stabilized a bit in version 8 (test carefully). You can embed LiveSite tags into other Java applications, which means you can insert TeamSite-managed content without having to use LiveSite as the principal aggregation platform. Still, you’ll find it comparatively more proprietary and non-standard compared to other Java-based WCM tools in this report.

Authentication is accomplished through real-time look-up to either an LDAP or Active Directory repository. If an administrator wants to add a new user, she can query that repository first.

This is a strength of the platform. For large implementations, user management can be delegated to local managers. Also, administrators can create custom roles, and users can have different roles across different branches or sub-branches, which is very handy for extranets and microsites.

TeamSite has a reputation for running slowly once the number of contributors reaches into the hundreds and beyond, or when content types become reasonably complex. A key shortcoming here is that since TeamSite is not architected as a purely J2EE platform, your systems engineers will not have recourse to the well-known scaling and performance tuning methods available in

Recent versions have resolved some bottlenecks, but concerns of performance issues continue to be whispered (and occasionally hollered) among major customers. In any case, test and test again, using high volumes of throughput, to ensure that the system will handle your loads.

OpenText: TeamSite



Findings Impact

those environments. The core TeamSite install essentially runs as a freestanding server (32-bit only). That was the only way to build it seventeen years ago; it seems quaint now.

Development

The most important thing to know here is that TeamSite employs a one-off architecture. To the extent that the product is driven by a large set of heterogeneous configuration files, understanding what went wrong, and where, can puzzle even the most experienced TeamSite developer.

One byproduct of this is that monitoring and debugging become very difficult, evoking terms like “black magic voodoo” among TeamSite developers. You can get close to the metal, since extension and advanced customizations are achieved by creating POJO components with XML definitions, but there’s no real ecosystem of such components and customers find the systems unusually developer-intensive.

All of TeamSite’s APIs for templating and workflow are based on JavaScript and XSLT. (For backward compatibility, the vendor still supports the use of Perl for scripting.) In recent years, it emphasized XSLT-based APIs. While XSLT is more standards-based than some former methods, most other WCM vendors have dropped XSLT as a templating environment over the past decade.

The reasons for transitioning away from XSLT are well known in the WCM world. These include: • An unusually steep learning curve and a shortage

of advanced skills among developers • A tendency to mix logic and layout • An inability for business people to make simple

changes and other related stresses on your development processes

• Lingering performance concerns

For integration, TeamSite officially counsels using the Java APIs (or alternatively, you can select Web Services wrappers).

Some developers have complained that the APIs are buggy as well as impenetrable, and it is difficult to access and integrate data content from other repositories at the TeamSite tier. This is not a good content integration platform.

To push content — and all artifacts — from TeamSite to LiveSite or some other delivery environment, you use “OpenDeploy,” which is a highly sophisticated code and content promotion tool with many options and configurations. Customers tell us it’s the source of many recurring frustrations. “Painful in all respects,” opined one developer. For publishing and deployment, you can: • Promote HTML files as static pages or snippets to

reside on a webserver file system • Create output templates to “bake” static HTML

Deployment of this kind is always tricky, and you’ll need an experienced architect here — ideally a developer familiar with the sophisticated and sometimes beguiling Interwoven deployment routines. The principal challenges are to synchronize different types of content objects: image and other binaries within file systems directories; the content object store; and the underlying metadata repository (which is bound to the content objects on the file system and may need to be mapped to a database). You can avoid mapping by using LiveSite Content

OpenText: TeamSite



Findings Impact

files by transforming the underlying XML repository • Transform and push content items into a database

(always tricky) • Transform and push content to the LiveSite

repository (an IDOL index)

Services, which is a NoSQL repository and is schemaless. However, if you want to publish to a relational database, mapping is required.

Figure 1. TeamSite building blocks.

OpenText: TeamSite



VII. Content Services: Considerations & Drawbacks Content services has historically been an area of strength for this product, even as some of its interfaces have become rather dated. The platform can effectively support large teams in collaborative environments if they each have dedicated areas or sites. If you need to comingle people and content more creatively, TeamSite starts to get very creaky.

“Developers have had to create bizarre workarounds to establish relationships among content elements. In general, TeamSite is not a good platform for scenarios involving heavy component content reuse.”

Findings Impact

Editorial

The TeamSite standard user interface presents a fairly streamlined, if somewhat old-fashioned approach. The UI is organized in tabs and is helpfully based on roles.

The idea is that content authors won’t be exposed to all existing functionality, rather only to the features that are pertinent to their job roles.

ContentServices

Editorial

Overall Usability 2

Authoring & Transformation 2

Tagging & Taxonomy 2

Content Reuse 1

Media & Document Management 2

Repository Services 3

Page Management 2

Lifecycle

Workflow 2

Globalization 1

Archiving & Compliance 1

OpenText: TeamSite



Findings Impact

You’ll find another interface that is available, but is not used (or demo’d) as often. It is the preexisting “Content Center” Professional Edition UI that is oriented more toward power and technical users.

On the downside, it still requires Java applets, at a time when most WCM vendors have eliminated them due to support and reliability issues.

Both TeamSite interfaces are just frameworks. You can modify them using a nice combination of CSS files and XML configuration files. The config files enable you to hide, change, or add most core functionality from within the CMS.

It’s not quite a templating system, but it’s handy.

The interfaces utilize some nice IDOL functionality. In particular, when you are viewing a specific content item, you also see “related files,” which lists other content items that are used by it, as well as who is using that specific content item.

This is particularly useful when you need to delete or expire content. You can also view similar, existing content, which aids in content reuse.

With respect to content contribution, the authoring experience depends on what type of content you’re editing: unstructured HTML or structured XML. For the former, you can use your own HTML desktop tool and import the files, or you can use Interwoven’s browser-based editor, which now embeds the lightweight “TinyMCE” widget.

It works well enough, but test TinyMCE with newer browser versions, especially IE.

For structured content, developers create forms (Data Capture Templates, or DCTs in TeamSite-speak) for users to enter content into XML files called Data Capture Records (DCRs). These are discrete assets and give TeamSite a file-management feel for the author. There is no business user interface for generating new input forms for new types of content.

Note that the appropriate DCT needs to live inside each branch where it defines a content type. In other words, there is no enterprise-wide management of structured content types, which is a fairly glaring omission for a product at this tier.

The “Experience Studio” interface provides an additional interface for content entry as well as for designing websites. You can drag and drop various components into pre-existing layouts or create new layouts. Each component fills a particular slot on the page. Managers can set personalization rules, access limits, and caching rules at a component level. The Experience Studio interface provides an in-context environment that includes mobile emulation; you can author as if you were delivering directly to a mobile device.

The interface is new and evidently a bit buggy, but it’s a step in the right direction.

OpenText: TeamSite



Findings Impact

Content reuse within TeamSite remains tricky, and it’s difficult for authors to reuse content outside of their particular “branch.” Although TeamSite stores DCRs as native XML, it provides few native tools to assemble and relate content together.

Developers have had to create bizarre workarounds to establish relationships among content elements. In general, TeamSite is not a good platform for scenarios involving heavy component content reuse.

TeamSite has particularly strong versioning features, allowing visual reconciliation of branched documents and parallel site development through individual or team work areas. The version control system enables this via several different gradations of content locking for different editorial situations that might require multiple contributors working on the same assets.

This is very handy for large-team collaboration.

TeamSite does a decent job handling metadata. It comes with a slick interface for managing nodes in a drag-and-drop environment. However, as with content types, taxonomies are bound to specific branches (think specific websites).

This means that you can’t do enterprise-wide web taxonomy management — unless you license additional IDOL modules, which can be difficult to configure and integrate with TeamSite.

Lifecycle

TeamSite’s workflow capabilities are reasonably sophisticated. There is a rich task inbox, good notification about jobs, and a useful internal reporting function. The workflow tends to suffer from a surfeit of clicks and excessive jargon (“target node”), which has inhibited adoption for some. On the plus side, TeamSite has always been strong at task-based workflows, including enabling managers to assign tasks without any content payload — something a surprising number of competitors don’t allow.

Some workflow benefits don’t come “out of the box.” Plan for substantial customization and find developers who have gotten inside the workflow engine before; it is powerful but complicated — and somewhat buggy. “Large workflow projects mean lots of ways to do things and lots of ways to get in trouble,” one developer concluded.

OpenText: TeamSite



Figure 2. TeamSite’s iPad app provides some basic web publishing on the go.

OpenText: TeamSite



VIII. Experience Services: Considerations & Drawbacks For experience services, OpenText will point you to the “LiveSite” quasi-portal module. LiveSite is surprisingly functional, but like most of this stack, it’s fairly one-off and proprietary.

“TeamSite suffers from a dearth of connectors to Marketing Automation providers, though it has some decent integrations now with Webtrends and Google Analytics.”

ExperienceServices

Delivery

Multichannel 1

Mobile 3

Structured Data 1

Engagement

Segmentation and Personalization 2

Social Media Integration 1

Campaigns 1

Community and UCG 2

Analytics 1

Testing and Optimization 1

Extras

Site Search 2

Online Forms 0

Add-On Modules 1

OpenText: TeamSite



Findings Impact

Delivery

By default, LiveSite generates ugly, non-standard URLs. Out of the box, LiveSite URLs look like this: http://acme.com/sites/guide.page?variable=something. However, they can be “massaged” into regular patterns via a vanity-URL feature that allows an administrator to set up a particular directory (e.g., /campaignXYZ/) for marketing purposes.

This is different from a more broad-based URL rewriting system for friendly or semantic URLs. Thus, each page needing redirection must be set up separately. There is no programmatic way to generate friendly URLs from existing metadata — and no manual approach built into the editorial process to name pages — like you would find in almost any other modern Web CMS package.

If you license the separate Mobility Module (additional fee), the mobile preview is quite good. The module (OEM’d from a vendor called Trilibis) provides tags and device detection to support adaptive design, or what is sometimes called “server-side responsive design.”

This is an additional cost, since the TeamSite reference implementations are not responsive by default, and it is quite complex to make them so.

The Mobility Module has a nifty utility (also from Trilibis) to output an entire microsite as a native (actually hybrid) app.

The truly native bits are a thin layer.

Engagement

For personalization, there’s a separate targeting service that comes bundled with LiveSite that can associate rules to content, which is based on data (such as customer data from a CRM system, metadata on the page, visitor behavior, referrer, and other attributes).

Creating rules is fairly simple, but it takes a bit more work — and training — to put them into action. You bind a rule to a “slot” in SitePublisher that is preset to render according to a rule. Configuration management around reusable logic could present challenges that we’re not sure the vendor has fully considered.

TeamSite suffers from a dearth of connectors to Marketing Automation providers, but it has some decent integrations now with Webtrends and Google Analytics.

The product suffered here under HP’s fantasies of trying to create a digital marketing suite of its own.

OpenText: TeamSite



Extras

As a quasi-portal, LiveSite ships with 100+ starter components, for things like blogs and slide shows.

Some customers have found these a bit thin and have asked for more reference implementations to see the code in action. On the other hand, when sufficiently trained, marketing staff at some large customer sites have come to value the fine-grained control over interactivity that these components — and LiveSite more generally — can afford.

OpenText has no ecosystem of third-party modules. If you don’t like what ships with LiveSite, you have to develop your own.

For site search, you employ IDOL — now rebranded as SiteSearch — or another best-of-breed search engine depending on how you publish your website.

IDOL costs extra and is probably overkill for most site-search needs. It’s best to look elsewhere.

Figure 3. Setting up conditions for targeting rules in TeamSite. It is unlikely your marketers will find this task (and interface) easy to use.

OpenText: TeamSite



IX. Conclusion TeamSite was already showing some age when Interwoven sold it off, and the platform continued to fall behind amid Autonomy’s strange, almost fetishist attention to IDOL integration. Overall, when you look at TeamSite’s usability, architecture, features, implied development models, and overall vendor approach, you feel teleported back to the 1990s. It’s a Frankenstein of a platform that only an avowed TeamSite guru could love.

HP claimed renewed investment on the engineering side; however, we only saw more floors added to a building that badly needed an overhaul of its creaky foundation.

TeamSite salespeople will tell you that the fact that the system has never been significantly modernized is actually a plus, since its customers have never gone through a major rewrite. This is inane and false on the face of it, since this developer-heavy — and quite proprietary — framework has left many customers forked from the upgrade path and languishing on an un-dead version of the platform. HP made the platform more readily upgradeable going forward, but that feels like too little, too late.

Every year we search for a happy — or at least contented — TeamSite customer; we can never find one. The fact that this platform continues to get top-right rankings in nearly every major analyst quadrant speaks more to the attractiveness of TeamSite demos and the gullibility of busy analysts (not to mention Autonomy’s and now OpenText’s very, uh, persuasive analyst relations). More than any other product in this report, TeamSite leads to chronically unhappy business users and developers.

To be fair, OpenText should prove a responsible enough owner; if you are an existing TeamSite customer, you need not rush to exit. However, if you are a new prospect, we see no compelling reason to license this platform. In our opinion, TeamSite would require a nearly complete rewrite to gain any credibility as a modern contender.

Need to compare this to another tool you're considering? Log on to your RSG account and use our tools.

If you have hands-on experience with this product and wish to share your feedback, please write to us at [email protected]. All customer input is kept confidential.

https://www.realstorygroup.com/Tools/

Web Content & Experience Management Sample Edition, Sample License20 © Copyright 2016 Real Story Group.


To Order and Access Immediately

Buy and Download Immediately• Purchase a one-time, complete download of the entire Web Content & Experience

Management report at: www.realstorygroup.com/Purchase/

• If you are looking for a comprehensive solution, subscribe to the Web Content &Experience Management research stream to get all the same evaluations, plus freshupdates throughout the year, other content geared around the technology lifecycle, anddirect access to our experts to answer all of your questions. To learn more, go to:www.realstorygroup.com/Subscribe/

Contact Us

Contact [email protected] or call +1-617-340-6464 to acquire the research via purchase order in lieu of a credit card or to ask about our multi-report savings.

Sales & Customer Support

N. America: 800-325-6190

Int’l: +1-617-340-6464

UK: +44-2033181911

To Order and Access Immediately

https://www.realstorygroup.com/Subscribe/

https://www.realstorygroup.com/Subscribe/

mailto:info%40realstorygroup.com%20?subject=

Web Content & Experience Management Sample Edition, Sample License21 © Copyright 2016 Real Story Group.


Testimonials

Testimonials

“I wish I had found your Web

CMS Research six months ago.

The ‘Pitfalls to Avoid’ section is

worth its weight in gold!”

Georgeann Elliott Moss, Director of Internet Publishing, Dallas County Community College District

“I think The Web CMS Research is well

worth it. Information is always key to good

decisions; don’t skip that step! It’s also

surprisingly well written and not as dry as

you would expect. I have an IT background

and also a writing (English Literature)

background, so I very much appreciated

the balance of charts, tech info, and plain-

speaking, good old sentences!”

Paul Whittle, Web Manager, Memorial University

“The Web CMS Research was the roadmap

for our entire CMS selection process. It truly

provided a basis for understanding what

we should look for and expect in a CMS.

Above all, since we used the report as our

guide, we are more than confident in our

CMS selection. If we had to go through the

process all over again,

we’d still rely as heavily on this report

as we did the first time.”

Michele McDonald, IT Project Manager, University of Oklahoma

“This excellent research has saved

weeks of work reviewing the marketplace

to enable a tender to be sent out to just a

handful of potential vendors in record time.

Well done.”

LMartin Beake, ITT Consultant, 2Sys Limited, Malmesbury, UK

“For any digital agency, helping

your client choose the right CMS is risky —

get it right and you’re the hero, get it wrong

and you compromise your entire interactive

strategy. Real Story Group’s WCM

evaluations strengthen our understanding

of the true weaknesses and strengths of

all the major CMS platforms, enabling us

to make expert-validated recommendations

to our clients with confidence.”

Bill Barbot, Founder, Threespot

“The Web CMS Research allows me

to save time and obtain a far better

understanding of the market.”

Leon Rudd, Head of eInitiatives, Siemens (Milton Keynes, UK)

the web content & experience management evaluation … · jive mindtouch – exo interact...

Documents