CiviCRM Community Forums (archive)

Useability, sure, marketing, not such a big problem as it's being made out to be here.  But the biggest problem is lack of positive word of mouth from folks who are building CiviCRM sites.  Drupal is beating Joomla because it's developers love working with it and adding to it and extending it and evangelizing for it.  How can CiviCRM do this?  It will take a big refocusing that will change the project totally.

As someone who has struggled actually trying to implement a large project with civicrm, what is :scary: is that the developers have focused on new features for the next version rather than bug fixes for the current one.  With bugs only being fixed inthe next release that isn't out, combined with the difficulty of upgrading to the next release -- combined with the general impenetrability of the code compared to Drupal  you get a situation where I can't fix my bugs myself, I can't upgrade out of the problem, and I can't stay where I am because its broken.  The word "stable" in a civicrm release has meant "llittle to no fixes provided" which is not "stable" but rather "dead".  Not suitable generally for wide deployment. 

CRM is hard.  You need a boatload of features before people will even consider you. Yet, you need to be rock solid  reliable before they trust you with their data that is their bread and butter.  A balance needs to be found.  This project has NOT been an example of balance.  We've been barelling along adding features to beat the band, but not making sure everything works, interroperates, is a useability dream and upgrades silky smooth to the next rev.  Provide that and the community will grow as people learn your product and learn to trust you with their data and business processes.  When the community grows and people are raving rather than ranting about how CiviCRM is to work with, you'll be surprises how things take off. 

Basically, with the 2.0 release the whole train has to slow down and focus on growing a community around releases and allowing new features to be added organically rather than leaving the community in the dust to hit the next crazy roadmap point at the expense of supporting the folks that are actually trying to run a site on your product.  Create some APIs for those new features and spin off some folks to build new features and invite third party folks to write for it.  But please, lets take care of the people using the product to try to set up real, working, sustainable sites today.

I'm downloading the 2.0 release.  I'd love to be able to start fresh here.

On curufinwe's post --

1) I'm tempted to agree with your point about not shoring up the base before creating new features. I say tempted, because when I see CiviGrant and CiviPledge getting attention as new features, there's a part of me that says "I wish we could focus on fine tuning and streamlining the core, CiviEvent, and CiviMember, before digging into new territory." But I also understand that some of those new pieces have come through consulting projects, and thus have basically not interfered with core development. I think the concern is that development energy will start tracking off in these different directions when it seems there's room for improvement with the core features. I've mentioned earlier, but will say again, that the one area I would like to see work done with the core and "core modules" (contribute/member/event) is with streamlining and making more efficient the end user experience. Everything works very logically, but sometimes it takes just a few too many clicks to get where you need to go.

2) As for fixing current releases vs. releasing new ones -- I'll vouch for the core team that they are VERY responsive to bugs reported. Have you visited the Jira issue tracker? It's slightly overwhelming. But they plow through those things, prioritize effectively, and chip away at bugs regularly. And the development cycle for new releases is way ahead of any software you buy off the shelf, or any other open source project of this size that I know of. So although they might not be releasing a ton of bug fixes to existing versions, they're usually cranking out a new release every 3 months or so -- which is probably faster than most bug fix releases are prepared in other software.

3) As for upgrading -- my experience with upgrading has been pretty smooth, from 1.7 through 1.9. The recently released version (2.0) has some significant structural changes that make the upgrade process more challenging. But prior to this major release, upgrading has been pretty straightforward from my perspective. What challenges have you faced?

Finally -- I've got to stick up for Joomla, since it's taken some hits in recent posts... 

As with any open source project, Joomla is an evolution. v1.x was a baby step away from the Mambo project. It had issues. Lots of them. But overall, it was a stable and very functional program. v1.5 was basically a complete, total, code rewrite. It didn't add a ton of functionality, but it did clean things up tremendously, and provides a much stronger, more efficient, and more extendable code base moving forward.

Joomla is the most widely used open source CMS in the world. It has the largest user community. The number of extensions available far outdistance what's available for Drupal or other CMS's. Yes -- many are amateurish. That's not the point. The point is there are a ton of outstanding extensions, and obviously the structure of the core software is such that it invites extension developers.

From an end user experience, even an honest Drupal developer will admit that the user interface, terminology, and content flow, is much easier to grasp in Joomla. That's the main reason why I embraced it as my CMS of choice. I was building sites and handing them over to relative non-techies. I needed to know that they were going to be able to get their arms around the software and be able to begin creating content without needing a lesson in php or software development.

And for the record, based on forum participation and downloads, CiviCRM actually has a LARGER following among Joomla users than Drupal users. Yes, maybe there are more active developers among the Drupal users, but let's think why...

Drupal is more difficult to develop a site in (partly because of advanced controls such as acl/taxonomy) >>
Larger organizations require some of those features >>
Those larger organizations have site developers on staff, or the monetary resources to budget big dollars for development >>
Those developers have the monetary and staff resources to advance the CiviCRM pieces of the project as part of the larger project >>
Thus CiviCRM sees more development contributions from the Drupal side of things.

(I'm almost finished with my rant, I promise...)

I work with smaller not-for-profits, who don't have any website developers or IT people on staff. Joomla+CiviCRM is a GREAT fit for them. But, my ability to handle or sponsor CiviCRM development as part of some of these projects, is limited. I wish it wasn't. But it is.

Now these smaller orgs are exactly the audience that needs a product like CiviCRM the most (I'm not saying it's not a great fit for larger orgs -- just that these smaller orgs are the most needy).

So speaking from experience, and trying get a wide angle lens on the situation, perhaps this is why things are the way they are. Perhaps. Then again, maybe I'm just on my Joomla soapbox, and have no idea what I'm talking about. Won't be the first time that's happened. Just ask my wife.

Sorry for the long rant. I needed to get that off my chest. Thanks for listening.

-Brian

ryan:

thanx for such a detailed reply. much appreciated. I'd just raise a few points (sorry, this post turned out to be way longer than i expected) to give folks a better idea of how we decide and where we come from. We are open to suggestions on how to improve the process given our current resources and

1. Building CiviAwardsDinner (lets assume its a substantial project) vs restructuring search / search builder: We would build CiviAwardsDinner if we think it is useful to some percentage of the community. However if it is building CiviAwardsDinner basically funds a significant part of the release, realities of open source and financials dictate that we'll do CiviAwardsDinner over restructuring search. Yes to some extent this is plain wierd, but we need to hit some financial goals too

2. Feedback drives future releases: I would say that at least 50% (possibly a lot more) of the ideas for new  features / fixes / improvements come from the community. This means that the more folks talk about how to improve things (and potentially spec it out etc), the more likely we will consider it seriously for the next release. We've had a lot more interest in CiviEvent over CiviMember and a lot of cool suggestions. So we've been focussing on improving CiviEvent recently. (it also helps that most of the improvements are incremental additions rather than major code / schema changes). Both those components generate way more feedback / patches than search / search builder.

3. Helping out the community improves your karma: I think human psychology dictates that we pay closer attention to folks who are present and active in the community. We listen to them more and pay a bit closer attention to their requests and needs

4. Frustration among some larger projects out there: We have heard about it, but have not figured out what we can do to help minimize / mitigate it. Some / Most of these projects (that we are aware of) have been deployed via consulting firm(s) and the feedback is mainly indirect / none. Some of it is probably hype/sell to meet the RFP needs, a couple have been seriously underbid to get the RFP (i.e. we refused to subcontract any part of the work for the amount involved). But basically, I don't think we've gotten a lot of feedback about the experience (which to some extent started the blog post and this thread). Would be great if you could get some other members who have been frustrated to speak up and let us know about things we can and should change to address and fix the balance.

5. API's: This is a topic that we've been flailing about for some time without really making a lot of progress. I think we need to sit back and readdress this in a early 2.x release and figure out what the goals/scope is. IMO, trying to overlay a procedural API on top of our OO code is not a great thing (since we dont use it, we dont really test it). Unfortunately we have not gotten a lot of feedback from the community on this. Our last email to the dev list about this got very few responses (http://www.nabble.com/Feedback-Needed-on-Future-API-Development-td12892117s15986.html#a12922002)

6. Rapid release cycle: this is a thorny issue for all open source projects. Every year, we think that we'll slow down a bit, but the world moves at a pretty fast rate. A great example of this is CiviCRM v2.0 does not support Drupal 6 / Joomla 1.5, which means that we need to come out with 2.1 in the next 3-4 months. The nice thing about a interconnected world is you can use a lot of external pieces. The bad thing about it is there some piece in your universe that is changing at any time (some of the drupal and joomla point release have messed us up, which necessitated a pretty quick release). Overall in 1.x i dont think are upgrades were very difficult / introduced lots of change. 2.x is the first release which has done so.

7. Finally if you can be a bit more specific on: "I backed off further when I found a lot of basic stuff working alright -- but in a roundabout,  clumsy way that shows the features aren't being used day to day to manage large sets of data by the develpers..   So, searching, exporting, updating.  Basic DB stuff that a CRM shouldn't hide too far away, or make too laborious."

thanx

lobo

Great thread. 

First, I think Civi is pretty much amazing, an OS project for people doing good works, supporting multiple CMSes, among a not particularly tech-savvy audience..  Wow!

But, I think that maybe the Civi guys spend too much time inside the software, and not enough time with users, or at least empathizing with real users.

I spent 3 hours + this morning trying to get a stripped down CiviContribute to take money through any payment processor, even without membership, receipting, and honor of .  I had this working under Drupal in 2.0 B1 in minutes, and there was a demo Contrib page.  I don't know what happened to the demo pages in Joomla.

There are a lot of little things:
1) Better Help on SMTP setup and Payment Processor configuration, real help that tries to help.  You can't present a field like "API URL" to this crowd without some kind of information.  I also noticed that in 2.0 B1 for Drupal, there is a help balloon on Payment Processor Type that pops up when you click the little balloon, and says "more help is here -{Link}", then disappears when you try to move the mouse to click the link.  Almost perversely cruel.

The SMTP fields could benefit from some help.  Like, "This can be any valid email account || This has to be the cPanel login on your domain.  Usually, this is just the username, i.e. admin, not admin@domain.com, but sometimes you need to put admin+username.com....", and "usually, the default, localhost will work, but...." - some kind of guidance from the people to whom this stuff is so simple that it is unworthy of Help, for those of us for whom it is not trivial or obvious.

I breezed through Chemical Engineering on open book tests, so I know how to use reference materials, and I find Civi's "Help" to be improving, (and have made some improvements in the Wiki), but still weak.

2) When Forum admins answer with: "There are a bezillion posts about how to solve Invalid Key" that should raise a lot of red flags.  A) Why? and B) Why are the error messages not more helpful? and C) Why are so many users having such a hard time finding their solution among the "bezillion posts"?  How many person-hours are being lost?

3) Why are there no default profiles?  How many thousand person-hours are we wasting every year as we all re-define Person or Volunteer, etc.

4) SugarCRM (among others) does a good job with their web based installer, that seems to check a bezillion things- PHP version, database version, etc., and reports back red/green/critical/STOP errors that are actionable.  Something like that should be possible for Civi, even if it's a separate PHP file that has to be run.

SugarCRM has wizards for complex, multi-step tasks like setting up an email campaign, where dependencies are made clear.  There are a lot of posts on the forum where people have spent hours, only to find that they hadn't set up their SMTP Settings, which leads back to my first point.

5) On the same note, there may(?) be some interdependencies between components and/or payment gateways and PHP versions, etc.?  Something about PayPal and PHP 5.25 - I know these are complex issues, but how about a simple polling mechanism that allows one to pop up some kind of feedback...Like on the Payment Processor screen: "Hey, 54 users have reported that Authorize.net works great, 14 have said that X processor sucks, and besides, you are running PHP 5.2.5, which is known to conflict with processor Z"

Overall, it plays like a D&D game, where one has to gather clues, and slips of paper, chain CiviMail, the occasional gold coin, etc., and then encounter a HostingWizard, and utter just the right questions in just the right sequence......

It may actually be a service to the community to take away some options, i.e. "somehow" refuse to install when the PHP version, etc. are not supported, if that's possible.

Another option is to use something like RPath, and to distribute complete Virtual Machines that run under certain virtualization environments.  I just signed up for Xen Reseller hosting for $40 a month, so that's already much less than dedicated, and actually below Civispace pricing, and heading toward shared hosting pricing.

Thanks!,
Ken

We do think that PHPList is a great open source project and has excellent mailing list capabilities. Rather than "borrowing heavily" for the PHPList code base which has its own development and support cycle, we would prefer a community contributed integration module which links phplist and civicrm together. This makes it a bit easier to maintain in the long term.

I'm not sure how simple/complex this integration is. There has been at least one attempt to do this integration (by CivicSpace in the v1.2 or so) and it was quite challenging from a support perspective (i dont know the exact details).

Would be great for you / someone from the community to step up and try to make the integration a reality.

lobo

For users who need mailing list capabilities and are on shared hosting it is such a simple thing to use something like PHPList that the extra mile you require CiviMail users to travel is simply a mile too far.

For that matter, since PHPList (an open source project) can so easily do all the reporting and tracking functions that CiviMail does without the special email addresses and whatnot I do not for the life of me see why it is necessary in CiviMail. For that matter, I don't understand why the CiviCRM project doesn't simply borrow heavily from the PHPList project code to rewrite the CiviMail component in an easy to configure and, frankly, more powerful way.

Don't take me wrong, I love phplist and that's a great project, but that's very unlikely that you can run any mailing on a list of several 1000th of contacts on a shared shoestring hosting (I've learnt the hard way, with several of my clients being suspended because heavy usage).

As for the bounce handling, it doesn't catch properly all the contacts (not phplist fault, but VERP works better).

Unfortunately, PHPList isn't made to easily fetch the contacts from another database format (eg civicrm), the only half easy solution found is to duplicate and synchronise the email contacts between two independant databases (and that's not that simple nor 100% reliable)

Otherwise, I agree with you and some features are easier to use on more advanced on phplist.

X+

I am not an experienced CiviCRM developer or big user for that matter, and not even an OpenSource big user either. But, I will tell you in one sentence what the tone of this whole thread is:

You need a front end website that targets "business people", customers, not technical folks !

Several of the threads have mentioned it, including Brian's posts, and some others. If you take a look at some commercial companies' websites such as http://www.interwoven.com/, who are not really huge but have some market niches you will see that the audience of the site is the "customer". In their case, business folks in Financial, Legal and other industries. But you can tell what their product is used for from the website front page and the visitor can also do some deeper research as to what options they have without being too technical.

I am really familiar with Interwoven's products and they don't tell you on the front of their website all the issues customers have with their products, and let me tell you that some of their products are scarier than CiviCRM. If you notice, the technical links are always buried along the menus under support, knowledge base, etc. Even the word "Knowledge base" sounds positive. I don't want you to turn away the technical folks as those are the one who make and grow your knowledge, but they don't need to be the front end for the product!!!

You are running a business, even if it is non-profit, or opensource, you still make decisions as those running commercial companies. In your core you might have some difference in the way you treat customers, or products, but at a high level you are really competing with those large companies.

One of your most important assets is your website and this should reflect and attract more "customers", business people, non-profits, etc. Make the issue of CiviCRM being scary a back ground issue.

You can start by not burying the write ups from your current customers in a thread on the forum, put them right up front in the website and re-do the website to target those small, medium size and large customers that browse the web looking for products ! Get folks like Brian and others who implemented some larger organizations to help in writing those. It took me about twenty five minutes or so to write this post, I don't consider myself slow on the keyboard and I am sure Brian and others here are as fast or faster, it shouldn't take them too long to write those small "commercials" for the benefit of a product they like.

One of my best examples, sorry to bring over some of the words that I don't see in any of these posts, but I think it is a good example for your problem: Microsoft's Windows killed IBM's OS/2 in 1992 or around there, not because of OS/2s technological problems, but because Microsoft was very good at Marketing their software. OS/2 was a more superior OS than Windows 3.1, but the one who knew how to market it was the one that came out winning!

I support Open Source products openly and I am a large proponent of those products, but I have been in IT for twenty plus years and the one that pays the bills is always the one that makes the money for the companies I worked for. So, those are the ones you should target with your product, they will pay back in the end to fix those who think CiviCRM is scary.

I also think you have an awesome product, with some need of marketing and case studies in the front page of the website ! Take out all the technical jargon from the front page and put it all under Support or Help, but don't mention it on the front of the website!

Sorry for repeating the same idea with multiple paragraphs, but I think you need to close this thread and get to working on this now. You have other threads and posts for users to write up their "features" or issues !

IMHO!

Jose