Digital Asset Management, Enterprise CMS, Enterprise Content Management, social media

Day’s CQ 5.2: DAM and Social Collab Feast

I don’t really have much to say about this release, since watching a pre-cooked demo is not the same as getting a first-hand experience, but here it goes.

Day Software, continuing to ride the CQ 5 and CRX momentum waves,  released CQ 5.2 with new Social Collaboration (SoCo) and Digital Asset Management (DAM) applications. Not to mention some interesting multi-site and multilingual enhancements.

While marrying web content management with social media, web 2.0 and DAM is hardly revolutionary — nowadays, it’s more about execution than the idea itself.

All in all, Day did fairly well with CQ 5.2. Next time there are questions about negative numbers on the balance sheet, the answer will (still) be simple: R&D and associated product launch costs (including time per day spent on Twitter with marketing efforts).

Full article on CMSWire: Day Software’s CQ 5.2: Weaving in DAM and Social Collaboration

Lars Trieloff (Day’s product manager for collab and DAM, and the person who spent the past 1.5 years of his life on this release) proudly welcomed CQ 5.2 and shared hidden CQ5 gems he didn’t show in demos.

The first one is the workflow launcher designed specifically for CQ5 DAM.

cq5 workflow launcher

cq5 workflow launcher

The workflow launcher listens to all content repository events  and triggers the actual processing of any new asset added to the system. All event types (+other info) are clearly visible in the launcher tab.

The second one is (not pretty enough to be shown in demos, I gather) feed importer.

cq5 feed importer

cq5 feed importer

The importer is used to talk to remote sources, parse them and create nodes in the content repository. it is currently used for subscribing to  remote iCal files and in the blog tool for content aggregation.

In order to implement a new parser and importer, Trieloff  says, “all you have to do is implement one OSGi component.” And, voila, your Twitter mashup is done.

Advertisements
Standard

17 thoughts on “Day’s CQ 5.2: DAM and Social Collab Feast

  1. Pingback: Vignette Community Apps 7.1 and Managing Social Media « Irina Guseva: Random Thoughts on CMS, WCM, ECM and Other Acronyms

  2. Social Collab is an add on to the web content management that integrates user generated content in general and comes with a number of specific social applications: blog, wiki, calendar, gadget container, comments, ratings and profile management. Sorry for the terseness, typing from an iPhone.

  3. How does it do it? Having several separate applications to do all those tasks is cool, but what does the system do with UGC on a general, strategic level? Does it treat UGC the same way it treats editorial? Does it ingest UGC into the database for editorial re-use? Are these tools available to editors for internal collaboration?

  4. Strategically, Day enables allows UGC created in the run-time environment (which is typically is 2-4 cluster nodes in one to three (US, EMEA, APAC) data centers) to be “ingested” securely through firewalls into a central, internally-hosted authoring server (also clustered for high-availability) and workflowed for (a) automatic spam detection, OOTB (b) automatic cleansing of cross-site scripting, OOTB (c) automatic checking against black-listed terms, OOTB and (d) potential moderation, either before or after posting. Workflowed UGC is centrally stored with requisite audit trails for compliance, and immediately replicated out to all clustered nodes across your different geographically-distributed data centers. Setting this all up is point-and-click in the GUI. This means a user posting a comment on one clustered node in Singapore – assuming no human-intervening moderation – is within a second available in all nodes worldwide across being ensuring of autenticity, security, and safety. And because it’s all in the central authoring repo, it’s accessible via feeds and available for re-use and re-purposing.

    Would love to walk you through this in detail. We’re hosting a webinar on the 14th (see our home page) and thereafter will be posting materials to SlideShare and screencasts on our website. If want a sneak peek at the presentation and demo material for the upcoming 14th webinar, just DM me on Twitter @kevinc2003.

  5. No, it is installable software (the entire ECM platform, WCM app, DAM app, and SoCo apps along with PDF and HTML documentation) is maybe around 180MB (half docs). It’s a self-runnable JAR. That also includes the entire underlying content store. Of course you can easily install and host on Amazon Web Services – that’s what we do.

    Generally, we believe you should own your data. It makes auditability and data mining for personalization, etc. simpler … and of course makes scaling brain-dead simple (it only takes minutes to install a new server remotely and hot-join to a running cluster – you can watch screencasts on our website to see how this is done).

  6. Kevin, thank you for your response. It leads me to another question – so for every front-end server I need to buy a new server license?

  7. Yes, our licensing model is counting server instances, not CPUs, which means if you roll out an additional production server (we do not charge for QA and development servers) you have to have a valid license for that.

  8. Pingback: On Personal vs. Professional Blogging and Twittering « Irina Guseva: Random Thoughts on CMS, WCM, ECM and Other Acronyms

  9. Lars, thanks for your response and sorry for such a late follow up.
    So if I understand you correctly – you don’t have separation between production and front end servers for your CMS. Thus to scale front end, instead of throwing in cheap Apache clusters we need to throw in clusters of Day machines with will per-machine licenses?

  10. Oleg,

    i don’t think this topic is necessarily a “pain” for @daysoftware.

    I would attempt to answer your question, but I am not an expert on Day’s licensing. I’ve seen licensing models where “front-end” (content delivery) is on web server(s) and a “production” server is the actual CMS instance, where each server comes with a per-machine license. I am guessing this is Day’s approach as well.

    @trieloff doesn’t believe in blogging (as we discussed before https://irinaguseva.wordpress.com/2009/04/05/on-personal-vs-professional-blogging-and-twittering/)

    hence, slow response rates. just my guess 😉 i do have that e-mail notifications functionality for new comments though – doesn’t get any easier.

  11. Hi Irina, I especially do not believe in your comment notification e-mails anymore, because I never got one. Luckily there is Twitter to inform me that this thread is going on. 😉

    Oleg, yes there is a separation between authoring servers and publishing servers, but this separation becomes only emergent at runtime, because the installable you deploy is the same, which means less configuration headaches, a more homogenous system architecture and less overall code.

    Additionally we have a third caching layer that we call the ‘dispatcher’, which is an Apache or IIS web server with a module for load balancing between the publishing servers. If you need to scale static content, you will add additional dispatchers, if your sites are heavily dynamic, you will also add publishing servers and if you have really large authoring teams, you will add authoring servers.

  12. Pingback: Day to Ignite CQ5 CMS Discussions in Europe and U.S. « Irina Guseva: Random Thoughts on CMS, WCM, ECM and Other Acronyms

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s