Visit the forum instructions to learn how to post to the forum, enable email notifications, subscribe to a category to receive emails when there are new discussions (like a mailing list), bookmark discussions and to see other tips to get the most out of our forum!
So... Our team culturing surveys hold a lot of useful data. As we start upgrading aspects of the website, we need to start transitioning these surveys into more general-case "Profiles" that will plug into the new systems being developed. A few these including.
MAKE: Projects - Skill certification
True Fans Viral Videos
Game Layer Badges
CiviCRM / Experts database.
Forums (if we ever relaunch them)
Location Mapping for local chapters (find a True Fan near you!)
There's a lot of valuable data in these team culturing forms. We just need to make it more accessible. On this, we have two volunteers!
Thomas Levine is a designer who has offered to translate this data into more accessible formats. He'd like to have access to the raw xml files (or the original database dumps) of the surveys so he can experiment with his designer magic.
Urs Riggenbach is a web coder currently in transit back to Sweden, but on his visit through Factor e Farm, expressed a strong interest in helping upgrade our team culturing sections into more of a social network "Profile" type system. he seemed to want to help on the backend.
Could we start swapping the information needed to get these guys to work?
What I am afraid about CiviCRM is that it will not allow me the flexibility and it may take a lot more time to design the platform in a way we want. Am I wrong with my fear? Can you comment on it?
- First: I think we should use a framework for every page/mini--site/web-adventure we create. The reasons are exactly the same with this that with the entire OSE project: make the things standard, replicable, open-source, modular, etc. If we don't do it in this way, we depend on the person who create the "site"at the first time, it's difficult to collaborate several people at the same time, difficult to maintain, it has lower security, less documentation, and the quality is always lower because the collective intelligence of a framework community is always higher than individual intelligences.
- Second: I think we need a CRM (Constituent Relationship Management). This is a contact database with some added utilities to work with the contacts. The OSE interested people is becoming huge. How are we going to manage all data related with this people? In an Excel sheet? (...) CRM solutions make possible to manage donations, bulk mails, classify contacts, make reports and a lot of things more. There are several open source CRM out there. We can evaluate them. For me, CiviCRM is the best: (extracted form the official site) "web-based, internationalized, and designed specifically to meet the needs of advocacy, non-profit and non-governmental groups. Integration with both Drupal and Joomla! content management systems gives you the tools to connect, communicate and activate your supporters and constituents". A wrong decision at this point is a lot of work after. For example, who is going to migrate the Team Culturing data to a database to make data useful through data-mining?
@Nikolay: Some concepts. CiviCRM (or any other CRM) is an admin tool to manage contacts, not a framework to make web pages. For me one of the advantages of CiviCRM is that it's possible (necessary really) to install it as a Drupal or Joomla module to interact via web with your contacts. For example, it's better that each contact has a profile page where he/she keep his/her data up to date that do it by yourself as a database admin. Or its better to link microfunding web pages with CiviCRM database to permit each person to fiil their data in our database directly. About flexibility, you can do the same as with php and html, maybe with a little more work but with a lot of advantages. There are an initial learning curve, but then it could be as easy as any other solution with the advantage that you get an standard and modular system.
If CiviCRM is the choice, from 19 of July I'm free to work on MicroFunding proposal if you want.
I was really thinking pictures and graphs, generated automatically from the XML or database dump. I can start doing things before I know what platform we're publishing things to; automatically integrating the resulting files into whatever platform we use should be easy.
A potential side effect is that this might help me understand the wiki dump format such that I'll be more able to write interfaces to connect it to the other formats Chris mentioned.
Nikolay, i suggest we use the public i.t. Categ of our forum. Only if we get low value messages, then i can move the discussion to the private i.t. Forum category.
On Sat, Jul 16, 2011 at 1:49 PM, Thomas Levine <thomas.levine> wrote: > I was really thinking pictures and graphs, generated automatically > from the XML or database dump. I can start doing things before I know > what platform we're publishing things to; automatically integrating > the resulting files into whatever platform we use should be easy.
But we'd have to import the surveys to Drupal or CiviCRM before we could use this. And it looks like these depend on well-structured data and can only make simple charts.
I don't know what to devote 1-2 hours to yet but my Aegir/CiviCRM hosting system only takes 15 seconds to spin up a new CiviCRM 4.0 / Drupal 7 instance.
Most of what is being discussed seems to be software for managing user profiles. I don't think I really understand what we want or what you think we want, and I also just want to make pretty graphs. Here's some of what I've been thinking about.
Okay I'm starting to see what could be done. I may be jumping the gun by assuming we should build right now in Drupal 7 / CiviCRM 4, but starting at least with the concept of CiviCRM 4 as middleware, I think the things to figure out on this track for whoever's interested are:
- What are the current things that need to be created in principle in the CiviCRM system (Membership type, Contact, Payment type, setting up recurring donations http://forum.civicrm.org/index.php?topic=18676.0, etc.) if you were to use CiviCRM manually as an admin - What are the Drupal hooks (hook_form, etc.) and CiviCRM API calls (something like this maybe http://svn.civicrm.org/civicrm/trunk/api/v3/examples/ContactCreate.php) in order to embed a membership form like in the mock-up pages, which is basically like an automated (from the admin point of view) way of adding contact/contribution records to CiviCRM
I'll be looking into this more when I have time but I wanted to put my thought process out there in case someone had any immediate thoughts.
Looks like there's a fair bit of support for Drupal now.
For anyone who doesn't know it well, there are tons of contributed modules for capturing user data, integrating with civiCRM, customizing user profiles, integrating with Javascript, Flash or png graphing libraries (the JS or Flash options could be interactive), integrating with payment processors and free mapping service apis (for location activity maps). The bulk of the work I suspect would be glueing the pieces together, then designing and refining the user experience.
If folks are happy to go with Drupal, I'd be willing to draw up a list of modules the project could use and liaise with Nick and others for setting up a versioning system with shared access. I've not done much team based Drupal development, so I'm all ears for how best to make it work.
I cannot continue further with Drupal, because Vann said:
"civicrm will b for internal use only as a crm, not for public access. it has an api and we'll hook into it using a platfrom TBD."
Vann is doing currently the main site and we have to coordinate all this with him. He is the person from FeF with whom we should coordinate our actions.
Just to be clear, if a front end general user (.e.g a True Fan) entered some data on the site that was being managed with the CRM, that data could still automatically be logged into CiviCRM, but via the Drupal front end, with appropriate data validation. Similarly, when a general user wants to view a chart, or map of related activity, the underlying data will be drawn straight from the CRM, via the Drupal integration and any other 3rd party services (e.g. google maps) and displayed to the user in the format they're expecting.
Obviously it would be useful to agree on what pieces of user data will be common to the whole OSE system, to avoid duplication and related issues.
We probably don't need to decide or know what the front end is going to be done in to figure out what API calls are the right ones to make to CiviCRM to set up an html form with rolling microdonations and a selectbox of giving levels as appears in the mock-up.
I'm just trying to figure out how to set up a rolling donation first from the admin and then as CiviCRM API calls.
About versioning this middleware component, probably there shouldn't need to be any development on the CiviCRM components that are used as the middleware to whatever front-end facing system we use, although development of the front end could of course also be done in Drupal and that would have to be versioned (as opposed to built from a script---Sarapis Foundation will be documenting more on how to use the libcloud script we're using (https://github.com/mig5/aegir_ci) to deploy Aegir (http://www.aegirproject.org/) on Rackspace (or presumably the cloud of your choosing, though this is untested) and how Aegir can in turn be used to deploy pristine platforms for a wide variety of Drupal makefiles, including the CiviCRM 4.0 makefile we're using.
And either way it'll probably be good to make a script for whatever FFMPEG type Audio/Visual stuff that allows users to do voiceovers on the videos, since that's an important component.
Still, I'm definitely curious to hear Vann's thoughts on the front end framework as well as the middleware (where in that case it seems we have consensus on CiviCRM, right?).
I extracted the skill and global village question responses. I didn't do any proper learning-based natural language processing yet, but here's a fun result: Of the responses to the global village question, 45 contained the word "yes" and 40 the word "no" (case insensitive).
They should be here, but gitorious isn't responding very nicely right now.
I'll probably try identifying the nouns in the skill responses and generate a tag cloud.
Interesting. The word "Missouri" doesn't appear on my profile at all. Relying on a DOM object location using CSSSelector seems rather brittle to me. What do I need to fix in my profile to have this come out right?