About

This site deals with technicalities of web development and content management systems. I also try to touch upon content strategy, ECM, DMS, and other related fields. 

I try to publish something new every two weeks alternating between topics.

Navigation
Social

Entries in ECM (3)

Monday
Mar192012

The parallels between video games and enterprise software

There are quite a few similarities between computer games and software designed for the enterprise. Ignoring gamification techniques where points, awards, and trophies are given for doing things, there's a lot of incidental likenesses between these two very different categories.

If it looks good it must be good

People will buy into something hyped enough even if it's duff. It it looks professional but is a bit odd or quirky, or even crashes frequently people will still want it. A slick front-end grabs attention and looks great in sales demos and makes a product stand out from the crowd. There's plenty of examples of good looking software that somehow didn't cut the mustard. The same is true of video games - folk want the shiniest graphics. I personally thought that Crysis was a mediocre game, but it did look great and sold well on that strength.

People will forgive quirks

Skyrim is a great example of a game that scored ridiculously highly in all the reviews and looks great but has tons of weirdness. The strangest thing I've seen was a mammoth that suddenly jerked 100m into the air then floated gracefully down to the ground. There's obviously bugs in the physics. There's also the 'dragons flying backwards' fiasco... it breaks the illusion of the game.

The same applies to more recent versions of Microsoft Office. The 'ribbon' Fluent User Interface is such a departure from the common Windows UI it's just odd to use and really hard to find functionality even now. It's been years since its introduction. Somehow the enterprise users tolerate this.

If it's not polished people won't buy

Games that don't quite look right or have strange design choices are not generally as popular as the more polished titles. In software, if there are no rounded corners, gradients, and attractive visual elements then it will be disregarded. The competition is so fierce and the selection is so broad that only the smartest, quickest, and boldest will survive.

The CMS market is quite indicative of this. There are hundreds of CMS systems, and literally dozens that are of a very high quality. Even narrowing it down using the development skills present in most in-house teams will yield more than a handful to choose from. The ones that seem rough in the demo & evaluation phase get dropped pretty quickly. This is multipled quite severely by the cost of implementing the solution.

A good title makes a difference

Names like Documentum, SharePoint, Office, SalesForce have an obvious link to their function. Tools that begin with a J are often Java based, which is a good thing if the customer is already using this technology. Titles that are short and easy to say on the phone work really well.

The same seems to apply to video games, but in a different way. Either it is easy to say, or it abbreviates or acronymns nicely. Examples include Call of Duty aka CoD. As with other software the title is often suggestive of what you have to do to use it - Battlefield 3 is obviously a shooter just as Photoshop is a photograph manipulation tool.

In both cases, sequels seem to do well whether its Windows 7 or Forza Motorsport 4.

People are willing to wait for a big name release

Gamers wait YEARS for the promise of certain titles. Duke Nukem Forever is a prime example of this, as is Elder Scrolls 5: Skyrim which was five years in the making. It's not unusual for entertainment titles to take this long.

Conversely, professional tools don't take this long. Very few companies could afford such a long development cycle, nor would it be prudent. This market moves much faster. Google+ took just over three montths to launch business pages and during this time it was critised heavily for not having a feature present on Facebook.

People will tolerate cross platform crappiness

Some games are great on consoles and poor on the PC such as Skyrim because of the console-based UI - it was still highly ranked by reviewers and in the charts. In other cases it's the other way around; strategy games are generally regarded as better on the PC because of the mouse and keyboard but people still play them with sub-par input methods.

Enterprise software generally has two parts, the server and the client. Poor quality clients in this regard would most definitely include Outlook Web Access if you try and use it in anything other than Internet Explorer - it was terrible in Firefox or Safari because it relied heavily on ActiveX controls. Lotus webmail was just as bad.

On the server side, a lot of technologies that work very well on Linux and Unix don't funciton quite so well under Windows but many will overlook this. The differences in the file system are the usual culprit.

People will even buy gear just to run it

Crysis had extremely high video graphics power to run it properly, as does Skyrim. There are many hardcore gamers who have no problem with spending serious money just to play a game. The same applies to consoles; you have to buy the hardware to play certain games when they appear on just one machine.

SharePoint is an example of this; you need to buy Windows Server to run it if you want it in-house. Most .net software also requires capital expenditure if you want to run it properly.

The other way of course is virtualisation in the form of cloud PaaS virtual machines. These too are the equivalent of hardware leasing but with much shorter lead times - don't be fooled by the marketing. You still have to spend to make them work.

Trophies are all the rage

Ok, I did say I was going to ignore this topic, but it's just too significant in the overall scheme of this article. Gamification is the art of making work tasks into games by adding artifical rewards in order to encourage and create a competitive spirit. Plenty of in depth articles have been written about this phenomenon elsewhere on the internet. Workification is adding dull tasks into otherwise exciting games for minor rewards which can help with the main objective of the game.

Both are fairly commonplace at the moment. It seems that application designers want their tools to appeal to younger audiences who have grown up with video games, and that game developers wish their product to be accessible by more mature markets who have been ground down by the menial repetitive tasks they have to perform in their daily duty. Seriously though, I have no idea why they put a pie-making minigame into Fable 3 just to earn a few shekels.

There's only a handful of genres

Think about it: just as games can be bunched together into genres like racing, shooting, platform, puzzle so can enterprise tools. Broadly speaking, there's CMS, ECM, office packages, email, server software, backup, anti-virus, security tools. I'm not going to try and define what these categories are here (maybe another time) but there is definitely a limited number of types of enterprise software.

There's usually something bolted on that is an afterthought and doesn't quite fit

Mini-games, driving sections, and character customisations are the usual culprits in the gaming world. The enterprise market has much the same, with features that nobody really uses but are needed to tick boxes. Examples of this would include complex workflow designers, half-baked integration with analytics, and social networking & collaboration features that are half measures. Gamification done wrong is just as bad.

Something unique comes along every few years

Once every few years an innovation pops up which becomes a bandwagon that all and sundry leap upon. Titles like Grand Theft Auto really changed the landscape with the blend of violence, humour, and open game world. Business tools like LinkedIn are continuing to change HR roles. Twitter has mutated marketing, sales, and customer service by giving the consumer a voice. Facebook has hooked marketing directly into peoples daily lives. None of these were predicted, nor without hindsight were they predictable.

Both force people to do things a certain way

Although the trend is for more freedom of action, there are many activities that must be done in the prescribed manner. Just as puzzles in many games must be solved by collecting the item and taking it to location X then inserting it into slot Y to open door Z, jobs must be done by opening an application, clicking on a set of buttons in a certain order, then clicking save / done / ok to complete the task. Workflows add 'multiplayer' to the mix, making the task dependent on the actions of another 'player' and enforcing more rules. Compare this to Portal 2 which has a dual player co-operative online mode where you have to work with the other person to get the job done.

What next?

There is much that is the similar, and much that differs. The key is to try to spot the trend; what aspect of gaming will creep into the workplace next? What will migrate from the enterprise into the entertainment market?

Sunday
Jan152012

CQ5 best practices for component development

Following on from my advice for best practices for developing with Adobe Day CQ5, here are some suggestions centred around component development - you should tailor these to fit your needs. They should help if you are unsure where to start. There's lots of technical documentation on the product itself and the core open source frameworks; elements of these are useful for developers, but there's scant information on methodologies or strategies you can apply when starting out. Some of this may also apply to other systems albeit with different no-go areas and so on.

Avoid copying components

Firstly, avoid modifying anything under /libs. Also avoid copying anything from /libs to /apps. There are a few reasons for this:

  1. If you upgrade you will hate yourself for doing this. Your boss and co-workers may hate you too.
  2. Changing /libs implies that you are either not going to version control it, or that you are going to. Either way leads to madness, unless you like code to go missing and have servers which behave differently or if you want to add half of the core product to subversion. 

Copies to /apps should be VERY limited for a few significant reasons:

  1. when you upgrade, you need to upgrade this code too if you want it to work or at the very minimum have the new features. 
  2. there's no way of quickly identifying these 'overlays'.
  3. if you overlay something that is key, things go sour very quickly post-upgrade.
  4. having two components with the same name in the same group breaks design mode in CQ5.4 - for me at least

Override the bare minimum

All components for paragraph systems should have a 'sling:superResourceType ' of 'foundation/components/parbase'. Development of derived components should be done using 'sling:superResourceType' where possible. An example might be creating a paragraph system that behaves differently. Say you want to make one where component display is inverted, so that new components are inserted at the top - this is a parsys with a 'sling:superResourceType' of 'foundation/components/parsys' and a customised script. There's no need to copy the whole component.

Component Organisation

A recommended structure for component definition is

 /apps/<site-id>/components/page/<component>
/apps/<site-id>/components/content/<component>
/apps/<site-id>/src
/apps/<site-id>/install 
/apps/<site-id>/widgets
/apps/<site-id>/nodetypes
/apps/<site-id>/templates/<template>

Of course, all of these are optional. Page rendering components explicitly defined in the templates are split from paragraph and non-whole-page components such as navigational bars. This is purely for the benefit of developers; it means it's possible to see at a glance if the component is used to render a whole page or if it might appear as part of a page - a useful distinction. It has another benefit, for example it allows a 'sitemap' paragraph component which lists in HTML format to exist as well as a machine-readable sitemap.xml page type for SEO - two very different things with the same name.

Composition of Page Types 

A process of decomposition into sub-scripts is applied to the page rendering code to create a solid foundation which will allow extension of the basic type into more specifc page components:

/apps/<site-id>/components/page/base
/apps/<site-id>/components/page/base/base.jsp
/apps/<site-id>/components/page/base/head.jsp
/apps/<site-id>/components/page/base/body.jsp
/apps/<site-id>/components/page/base/header.jsp
/apps/<site-id>/components/page/base/content.jsp
/apps/<site-id>/components/page/base/footer.jsp

The base component extends the foundation page, with a 'sling:superResourceType ' of 'foundation/components/page'. 'base.jsp' basically sets the page doctype, outputs the <html> tags and includes head and body. Subsequenty, body.jsp includes header.jsp, content.jsp, and footer.jsp.

Extensible Page Components

This is the minimum for a base component which is extensible. We can easily make this better by adding other override-able scripts, such as adding an analytics.jsp or a meta.jsp. From this start point we can create a new component with a 'sling:superResourceType ' of '<site-id>/components/page/base', and the only thing we need to create is content.jsp

/apps/<site-id>/components/page/twocolumn/content.jsp
/apps/<site-id>/components/page/twocolumn/left.jsp
/apps/<site-id>/components/page/twocolumn/right.jsp

This obviously a two column layout. In order to separate content from code we should create a new component with a 'sling:superResourceType ' of '<site-id>/components/page/twocolumn', which now needs no scripts at all. It will derive all configuration and code from the super type, leaving us free to change the super type if we want a different representation (so long as the paragraph systems have the same names). We can also override the two column layout if we so chose, by creating a script which does something then including the overridden script. For example, we could create a  /apps/<site-id>/components/page/contentpage/right.jsp script which displays a title component then includes the  /apps/<site-id>/components/page/twocolumn/right.jsp  script. This gives a great level of flexibility.

Content has a type

Remember that when content is being created, the component path is 'stamped' into the content so that Sling knows what script to use to render it. Always plan components so that an appropriate resource type is associated with the content. In our page example, it is much better that it is a 'content page' than a 'two column page' or even a 'base page' as the intent is that is it content. The fact that it displays in two columns is incidental, especially if in six months time a third column is added. It's much more future proof to use a layer of inheritance, but only if it doesn't add unnecessary complexity.

Favour composition over inheritance

Components is CQ5 should also favour composition over inheritance. If you want a list-image component for example, don't take a list component, copy it, and hack it to have an image. A reasonable approach is to create a new component and add the necessary components to it. When you upgrade CQ to a new version, you'll have no changes to make - it'll automatically use the new version. If you did it by creating a new component by forking code, you could find it difficult to get it working if there have been major changes to the original component.

I hope this guide has been useful. It's based on real world development practices and is the basis of any recommendation I would give at this time. 
Monday
Oct312011

NuxeoWorld

Last week I went to Paris to find out more about Nuxeo, an enterprise content management system. It seemed like a very polished product developed by a highly professional company and I was impressed by its capabilities. It’s very much geared towards Case Management and Document Management as it centres itself on workflow and processing of content items in a structured manner, with item state as a core tenet of the system.

I liked the idea of the Nuxeo Studio, a web based facility that allows changes to be made then deployed to live servers but also facilitates support of the live systems and distribution of the development effort. It also enables automatic upgrading which is a nice idea. They are also embracing the cloud with their Nuxeo Platform platform-as-a-service offering which is an intriguing proposition.

It’s a very different platform offering to the WCM systems I have implemented before, and I think this is a great niche to watch to see how it evolves. It’s a complementing system which is more about items which have lifespans and transitions between states as opposed to the web content created by CMS implementations I have done using Adobe Day CQ5, Umbraco, or Magnolia CMS.

I met some interesting people there, and I had a great evening out. I look forward to meeting you all again soon, and to the next Nuxeo event.

[photos to follow]