System to build embeddable progress bars and widgets.

[manoj_zyxware]

Hi,

We are planning to implement a system to build embeddable progress bars and widgets based on the entities provided by CiviCRM - like Contribution pages, mailing lists etc.

The new widget creation interface will be similar to current CiviCRM widget creation interface for Contribution page. We plan to implement this as a new extension to CiviCRM.  Using the new interface user can create progress bar which draws value from a formula including values from one or more contribution pages, rather than being tied to a specific page. The formula allows user to enter an arbitrary starting amount, goal amount, and current total raised.

For example, for the progress bar we'd like to display the total raised by one contribution page, as well as 10% each of two other contribution pages, plus an arbitrary starting amount.

Also this new interface allows to create campaign widget which may contain image or text or donate button or progress bar (created above) or newsletter subscription field.

Workflow:
1. CiviCRM user clicks the button to create a new widget or progress bar
2. If it is a progress bar, create the formula that defines the current amount, and also set the goal amount.
2. If it is a widget, select the campaign and elements required.
3. Edit the embed code generated as required, for example to change style (Only for CiviCRM user. Not for end-user, who embed the widget in their site.)
4. Preview the final item.
5. Publish it by copying and pasting the embed code onto a Web site, and also distributing the embed code to people who will embed it on their own Web sites.

We wish to contribute back this work and to be maintained further. What will be the preferred mode of development?
In CiviCRM extensions, we found native modules and CMS modules. We use CiviCRM with Drupal. Will it be better to implement it as a Drupal module which uses the CiviCRM api to get the required data or implement it as a native CiviCRM extension?

[totten]

Sounds like an interesting idea. Glad you're looking to share it!

We wish to contribute back this work and to be maintained further. What will be the preferred mode of development?
In CiviCRM extensions, we found native modules and CMS modules. We use CiviCRM with Drupal. Will it be better to implement it as a Drupal module which uses the CiviCRM api to get the required data or implement it as a native CiviCRM extension?

I'd vote for a native extension (although I'm a bit biased). To be more balanced, let's look at the trade-off. With a Drupal module, you get access to all of Civi's APIs/extensions as well as Drupal's APIs/modules. A Drupal module has more options to build on. (And Drupal has some good tools like "Views.") Of course, as you build on top of more components from more sources, it becomes harder to maintain/collaborate:

• When looking for users/collaborators on a Drupal+Civi module, you can share/collaborate with anyone who combines D7 with Civi -- but WP, Joomla, D6, & D8 are incompatible. (Among Civi sites, D7 is currently ~60% of the install-base.) By contrast, Civi extensions are intended to run on any CMS.
• When dealing with maintenance to support new releases, a Civi extension is mostly concerned with new releases of Civi. However, a Drupal module needs to deal with new releases of Drupal *and* new releases of Civi. (Crudely: more dependencies implies more upgrade risk.)

There are times when it's appropriate to do a Drupal module -- for example, if your knowledge/skills/experience are biased towards Drupal, or if there's heavy cross-over between your Civi code and another Drupal module (e.g. organic groups), then definitely consider a Drupal module. But if you're mostly dealing with Civi data / Civi UI, then it's better to do a Civi extension.

[manoj_zyxware]

Hi Totten,

We decided to build the Widget Creation Interface as native CiviCRM extension since it is worth developing competencies in building extensions for CiviCRM and as you said there isn't any heavier crossover between our Civi code and another Drupal module, as we only deal with Civi data and UI.

Also, thanks a lot for your valuable suggestions.

[jagadees_zyxware]

Dear friends,
We successfully implemented the CiviCRM "Widget Creation Interface (WCI) Extension" which is available at https://civicrm.org/extensions/civiwci with AGPL license. Please take a look and report any bugs found.
Thanks
Jagadees
Zyxware Technologies

[Michael McAndrew]

Hey jagadees_zyxware,

Nice work - it would be great if you wanted to blog about this so bring your work to a wider audience - maybe include a couple of screen shots and a smaall tutorial to help people understand what you have done.  You might also think about including that in the extension documentation (or copying it from the documentation if it exists already).

Cheers,
Michael

[jagadees_zyxware]

Thank you Michael.
I will do that.

[vimaljoseph]

The civiwci extension is updated with various bug fixes and feature additions. A blog post regarding this is published at http://www.zyxware.com/articles/4506/zyxware-contributes-civicrm-extension-for-free-software-foundation-fsf-membership-campaign
The extension is currently used by FSF for their annual fundraiser campaign. You can see the progress bar widget at https://my.fsf.org/donate and http://fsf.org

[totten]

Cool. If you tweet about it with @civicrm, then they'll retweet the link - or, if you want, we could crosspost on the civicrm.org blog.

Nitpick: The article mentions a prequisite of "CiviCRM Version 4.7.x or above" -- that seems like a typo considering that we haven't released 4.6.alpha1 yet. Maybe that should be 4.4.7 or 4.5?

[vimaljoseph]

Thanks for pointing out the mistake. Corrected and tweeted. Please feel free to cross post the article on CiviCRM blog. Thanks for the support and guidance. We want more people review the code and help us improve the extension.

Thanks,