CiviCRM is scary?

[JuliaKM]

Dave --
Thanks for setting up the forum. The next time I hear someone complaining about the difficulty of CiviCRM, I will send them there. Also, if you ever need help developing a usability web survey, please let me know. That's what my education is in.

Lobo --
CiviSMTP is a great option, but for a company where all other aspects of server administration are done in-house, it is sort of a tough sell.

--Julia

[Donald Lobo]

Julia/Brian:

A few comments on CiviMail:

1. Yes, setting up CiviMail as currently exists is a task for a good sys admin. There are lots of dependencies and version issues to be aware of etc.

2. One of CiviMail's goals was to allow a large org to blast an email to 100K+ contacts relatively quickly (in a couple of hours or so). That meant choosing high performance native components. I do not think we can get anywhere close with PHP's built in mail mechanism. To some extent this is not what a smaller organization is looking for with CiviMail

3. Both Drupal and Joomla have newsletter components to send out email that are significantly simpler and easier to install etc. I think it would be great for some folks in the respective communities to step up and contribute an integration module that links the two. Reinventing the wheel does not seem right in this case

lobo

[FatherShawn]

CiviCRM is not scary - it's complex because it is asked to manage a number of tasks.  Now I did teach math and pascal programming 20 years ago and have always been the tech geek - the guy people call for help - among my friends. That may effect my perceptions...

It does seem to be fairly labor intensive to import properly import and configure our data set, however.  We have hundreds of households, each with from 1 to 6 individuals.  It is taking some time to edit each individual contact, select "Use Household Address", select the proper household, save, repeat...

Then there will be the membership statuses to build in CiviMember and the parent/child relationships to connect.

Until pledges are implemented, we will have to continue to use our desktop database in parallel, but I believe it's worth the effort as our members would really like to have an online member directory.

If ever find time to retool my old pascal skills into php skills, I'd happily work on deeper integration with Joomla! Lobo is right - there is no reason to reinvent the wheel.  In fact, if we can just write CiviCRM to update Joomla's user table when an email address is changed, then the newsletter components that are out there would be great for us smaller orgs.

[Donald Lobo]

fathershawn:

can you please file an issue for update the joomla email address when civicrm email is updated and we'll fix it in 2.1

Due to the way joomla is structured, there is no easy way for us to know if a joomla email is updated (i.e. there is no equivalent hook system in joomla). so the above sync will be just a one way sync (from civicrm -> joomla)

lobo

[dalin]

One other thing that likely discourages adoption --

To be effective, I really think some work needs to be invested in making CiviMail more accessible on a shared hosting environment. The reality is that a lot of not-for-profits that are looking at CiviCRM need to be able to implement the broadcast email functionality, and due to limited budgets (and limited server needs), are using shared hosting.

-Brian

Making CiviMail easier on shared hosting is not going to make everything all rosey.  If you are sending mass email from a shared host whether through CiviMail, or your CMSes newsletter module, you will be very lucky if the majority of the mail doesn't end up in the receivers spamboxes.  The reality of being on a server with hundreds of other sites, or even 50 sites, is that someone's mass-mailing, whether or not its legitimate, will have got your server on a blacklist.  Even if your hosting company gives you a dedicated IP, that's only used for http, not mail.  And given that you don't have control of the server, you are unable to utilize standard spam prevention techniques.  The only way to get around this is to have a dedicated virtual server.  Or, for much less time, less effort, and less money, you could use CiviSMTP.  

Note: I have no affiliation with the CiviSMTP service, other than one of my old clients utilizes their services.  

[matthewpetty]

I have thought long and often about starting this topic...

#1) Joomla sucks (I've used it a lot). You have to pay for the the great modules and their framework is crap compared to Drupal. Besides, the community thinks a bridge is the best route. You should continue to produce the standalone version and let them have at it.

#2) The Drupal community is actively discussing CiviCRM integration. Something like a simplenews, og2list, and CiviCRM groups mashup will happen this year. Continue to support CiviCRM as a Drupal module. Integrate Drupal profile fields with CiviCRM profiles better, and allow Drupal's profile module to manage the main profile of CiviCRM and vice versa.

#3) CiviMail is great for what it is planned for (VERY large mailings). That said, almost every group who uses it doesn't need that scalability. Make it an option to use php's mail with http for tracking.

[Donald Lobo]

1. lets avoid a debate on Joomla/Drupal in this forum. There are other places to do so.

2. A module / code to integrate drupal profiles better would be great. It is not on our roadmap for the near future. I do think there will be a few good integration modules in 2008. Depending on Views 2.0 flexibility, we might even be able to integrate with that. Again, we hope the community will step up and contribute most of it.

3. v2.1 will allow people to use sendmail (though our support for this will be minimal). HTTP tracking is already there for all actions. We will obsolete the mail links in a 2.x release. The only "mail" functions which we currently do not have a good solution for is: bounce and reply-to (neither of which can be done with http, since they are mail protocols). If we figure out a easy way to handle this, we can avoid the whole amavis/postfix install complexity we have now

lobo

[matthewpetty]

You're right, this is not the place for a Joomla/Drupal debate. I should have been more specific. Here's what I meant: it is scary hard to use CiviCRM in a feature-rich Joomla environment, and that meme contributes to the whole "CiviCRM is scary" idea.

Small organizations don't need to track bounce and reply-to. Just direct everything with intact headers to a specified email address and let a person handle it in their mail client. To do that now, you have to manage a catch-all with a good spam filter.

[Andrew Perry]

We use Joomla! for the majority of our client websites because it is relatively easy for clients to manage the content, and Drupal would be scary to them.

Because of the current ACL issues with Joomla!, however, we often install Joomla! as well as Drupal, and both CiviCRM components in the same DB, so that client staff don't have to be Joomla! website administrators to access CiviCRM's admin features and we can use more granular access permissions.

I think that it is important to look at keeping CiviCRM available through both Joomla! and Drupal because I suspect that many of the people who find CiviCRM scary would also find Drupal scary.

[petednz]

Have been wondering how to input on this debate. Background is i am a non-techie project manager working with a political group, and (I hope) I tend to think from the client rather than the code side of things. Marketing and communications  has been a key part of my background. And I am very keen to see CiviCRM fly high.
That said, after 9 months with a 0.5 developer on board we are still getting our set up fully implemented - maybe we just aren't very good at it  but yes I would say it is scary - and it has surprises tucked away (such as, if i understand  http://forum.civicrm.org/index.php?topic=2664.new#new properly, we can't use online renew - yet - for our recently imported existing members).
So I have been flat-footed several times as I have assured our client that certain functions will be 'almost certain' features that will be a no-brainer to implement. (And now I am getting worried about CiviMail not being such a straightforward component but we may surprise ourselves yet)
Another surprise was not being able to export data that had both our contacts membership details and some of our custom data (you know, we want to be able to have our 'branches' what's happening with members in their area in terms of renewals and expiries - and ok we are sorting that by BIRT - but it has lead us in to several 'why on earth not' discussions with our patient/trapped client.
So, what can I suggest that might increase the 'CiviCRM is easy/great' commentary and reduce the 'CiviCRM is scary' noise.
What might help people better understand what they are letting themselves in for would be to construct some hypothetical case studies - with different needs/backgrounds - and provide some indicators as to which of them are going to have
- smooth as
- regular, or
- patience-testing
experience with setting up CiviCRM.  And which of them are going to have high 'backend' development requirements and which can be largely done by intelligent enthuisiasts.

It seems from what I read that using Civi to set up the CRM for a new, mostly web-based, campaign group would be an enjoyable experience. (Well, put it this way, I am looking forward to working from a clean sheet at some point).
For those who are working from complex situations I think there may need to be some more documentation/support that would create something along the lines of an 'audit' of the existing data, structures and relationships that exist, and that would point to just how smooth or tricky the implement might be.

And I echo the point of needing to think about how the 'interested user' can be nourished.

And ... I have no idea how budgets work in this set up, but having somebody interview some of the missing 'case studies' may be the best spend of (non-existent?) PR dollar.

[Donald Lobo]

This thread is pretty good, so lets keep it going

I'd like to encourage people (especially folks who have been around for some time) to also think about:

What can you do to help CiviCRM and in the long run make CiviCRM less scary? Some things that are at the top of my list include:


• Have you contributed a case study to the CiviCRM Showcase: http://forum.civicrm.org/index.php/board,4.0.html. If not, please consider doing so now. Yes, all of us are super busy and promise to do it the next time (which in many a case never comes
• Have you helped scratch your favorite itch? have you contributed code that has made life simpler for you and others? While we have a great user community, our developer community seems fairly small. the amount of code we get back is fairly minimal (quite close to zero).
• If you are not a developer, have you helped fund your favorite missing feature? We've added quite a few things in the core release due to folks stepping up and funding them? Can you convince your client that a feature in core is significantly better than a hack now?
• Do you take the time to read and respond to other people's forum posts and problems? A helpful and supportive community reduces the fear factor (IMO)
• Have you downloaded and tested the 2.0 beta? If so, have you posted on the forums regarding any issues you encountered? Did you retest with the next beta?
• Have you helped with the CiviCRM documentation? In areas which you thought were confusing or cryptic?

The above and probably a lot other things help the community and us a fair amount. Please consider contributing back in some form/shape

[Donald Lobo]

Peter:

a couple of questions regarging the GP NZ process:

1. Was there an evaluation / analysis ever done of: "This is what GP NZ needs" and "This is what CiviCRM does"? A couple of things u've mentioned have been missing features for quite some time (limited export for components, offline membership).

2. Would be great and instructive for everyone involved for you/chris to document the process and things that GP NZ is going thru. It will fill in one of the "missing case studies" in our non-existent PR budget

3. Here's a rough old report on our financials: http://civicrm.org/node/115. In 2007 (and hopefully 2008), large consulting gigs have helped us move the platform forward

lobo

[harrstar]

Hi,

just stumbled across this thread and want to give my viewpoint to it.

We do 100% joomla sites because of ease of use for the end user and the availability of tons of extensions. For this specific client we needed a solution covering online membership and event sign up. Of course we could have made some pages and connect it to paypal express and would be done. But : I personally prefer to use solutions that are already there, I don't want to re-invent the wheel. So, I did my research and found civicrm in February 2008, installed 1.9, ran into a couple of issues with paypal, installed 2b5 and have it now (with help of Master lobo) up and running. Was not to complicated (but the mailing part is still to come, fortunately on a vps). Should not forget to mention that this was my first civicrm setup.

The organisation using it is a non-profit soccer club in Florida (galactics.org, 25 or 30 staff). As they usually have memberships and other contributions / event fees coming in from other sources than online we decided to use civicrm as a tool to handle the online part. The point is, non-profit or not you still have to do accounting which also includes your expenses. They anyway need an accounting system, so they are not tracking all their income through civicrm. And fees they get at the gate are just to much overhead to enter into civicrm.

My point here, even with a small organisation like this one it was more efficient in the long run to install civicrm than do hand-made pages. This way they can setup their own event page(s) without the need of a developer and have a nice backend to manage the online clients. In the future they might even run all their (recurring) memberships through it. What sold them to use civicrm was the possibility of being able to setup event, membership and fundraising online pages w/o developer.

I know somebody might say thats not what civicrm was made for, just use xxxxx and that would work. But using civicrm they have the possibility to grow into these right now quite big shoes (civicrm). And they learn using it. Bit by bit, not overwhelming all at once. No major import, etc..... And that lifts user acceptance.

And they already love it (i did only do the major setup and testing the page contens was done by them).

Just my 2cts

Harry

PS : So far I personally love civicrm. Fairly easy to setup and easy to manage.

[Donald Lobo]

Speaking of contributed code to make various aspects much easier and "scratching your own itch", a long time user (jesse) has adapted/modified/written a drupal module that uses civicrm as a data source to send out newsletters. You can read more about this here:

http://forum.civicrm.org/index.php/topic,2684.0.html

This is a good alternative for folks who would like to avoid installing CiviMail. It also shows how much the community can help by combining and coming up with solutions that solve some issues for them and a few other folks too . It also avoids us having to change CiviMail to suit the needs of smaller orgs.

Now, I'm waiting for a joomla newsletter component that uses civicrm for the mailing list

lobo

[mcsmom]

I don't think it's scary at all IF you get it properly set up for your users.

For me what is scary about civicrm  is doing upgrades . 

I think the challenge of getting an install into Joomla! is the biggest issue for wider adoption in the Joomlaverse. I don' t use civimail (overkill for my needs) but I would indeed love to have a nice integration of a normal joomla! newsletter component with my civi database. But once you have it installed, it's easy to use, easy to write instructions for etc. I'd love to see more front end integration, but I have no problem making modules to display cividata if I want.

What I'd like to see maybe on joomlacode maybe  is a bundled package with civi pre installed.  I've thought about doing it a lot of times, but now that AGPL has been approved maybe I will look into it again.