Comparison of Activity stream modules [#1279696]

There's a comparison of Activity stream modules in the "Similar module review' group: http://groups.drupal.org/node/15207 .

@IceCreamYou, it would be great to get the key areas of that chart filled in :).

My goal here is to better understand the differences between the major modules and, where possible, try to get the various sharp minds working on this problem working together as much as possible.

So far, myself and Stalski have been filling data in the chart.

Thanks!

Comments

Comment #1

IceCreamYou CreditAttribution: IceCreamYou commented 15 September 2011 at 05:13

Status:

Active

» Fixed

I don't think that chart does a good job of capturing the things that actually make the modules different from an end-user's perspective. I also find it really hard to see what's going on when editing that document -- just looks like an unorganized jumble to me -- disadvantages of not having a WYSIWYG editor. :-( Also that chart looks like a mix of new and very outdated information.

Acquia and Thread wanted Activity Log built for basically these reasons / to meet these requirements:

The stream needed to be fully dynamic (to allow directly commenting/liking on the related content, and so that messages changed/were deleted when the related content changed/was deleted). This requirement alone left only Message as an existing contender; Activity is only static and Heartbeat was not designed to be dynamic so its substitution is limited and expensive. Message has no caching, so it's not highly scalable.
The UIs for Heartbeat and Message were too confusing because they require using two different interfaces in separate locations to create one activity message template, and because the interfaces are just hard to understand. (I never was able to get Message working after playing with it for ~2 hours. It took me about an hour to figure out Heartbeat, and I've tried it before in previous versions.) We wanted to use only Rules for the admin UI to simplify everything.
Similar activity messages should be grouped together. Only Heartbeat supported this.
None of the existing modules were set up in a way that would make it possible to support email digests. The fact that Activity Log supports this also means that it is trivial to make it support other formats (e.g. for alerts, or for media types like print / mobile).
There was an additional "extra" request that "important" activity be bubbled up to the top of the stream, which only Activity Log supports (in various ways).
There needed to be an upgrade path from Heartbeat (for Acquia) and Activity (for Thread).

Additionally, I wanted to build a module that was completely and thoroughly extensible without requiring any modules to integrate with it explicitly. That meant using Rules as the (only) admin UI, Views as the end-user UI, complete configurability of events/conditions/viewers/templates/languages through the UI... and I wanted it to be ready to go out of the box, which meant default message templates and default styling for consistently good-looking streams. The other activity modules have various deficiencies in these areas.

Here's a comparison chart of the situation right now (September 15th, 2011 -- I don't intend to keep this updated) to the best of my knowledge:

	Activity Log	Activity	Heartbeat	Message
Approach to setting up activity messages	Rules actions	Custom editor based on core Actions	Rules actions combined with a custom editor (two steps)	Rules actions combined with a custom editor (two steps)
Dynamic messages (tokens evaluated on display instead of at action time)	Yes	No	Partial	Yes
Allows comments on statuses	Yes	Partial (separate module, not directly integrated with FBSS)	Partial (separate module, not directly integrated with FBSS)	Yes
Allows "liking" anything	Yes	No	No	No
Number of integrated modules	Anything that supports Rules	Must explicitly support Activity	Sort of supports modules that integrate with Rules but it's hard to get them working without explicit integration	?
Support for bubbling up interesting content	Yes (via Radioactivity integration)	No	No	No
Scalability	Dynamic with intelligent caching	Non-dynamic	Non-dynamic OR partially dynamic with no caching	Dynamic with no caching
Regeneration of activity messages	Yes	Partial (modules must directly support the API)	No	No
Configurability through the UI	events/conditions/visibility/templates/languages/grouping/caching	templates/languages (caching not necessary)	events/conditions/templates/grouping	events/conditions/templates/languages
Supports grouping similar messages	Yes (by acting user, target entity, or both)	No	Yes (by target entity)	No
Ready to go out of the box	Yes (default templates and styling)	No	No	No
Users can disable seeing certain types of activity in their streams	Yes	No	No	No
Supports email digests	Yes	No	No	No
Supports alerts	Planned	No	No	No
Approach to displaying activity messages	Views	Views	Custom	Views
Ease of use	Good	Very good	Confusing	Confusing
Internationalization	Yes (additional fields in the UI)	Yes (additional fields in the UI)	Sort of (uses t() on user-inputted strings)	Yes (i18n)
Templates exportable	Yes (Rules)	No	Yes (Rules + CTools)	Yes (Features via Entity API)
Automatically poll for new activity*	Planned	No	Yes	No

* The modules that don't support polling for new activity can do so via other modules like Views Hacks. FBSS supports automatically updating all of them when a new status is posted by the current user.

Feel free to update that wiki page as you see fit.