Posted by jdcreativity on August 29, 2008 at 6:22pm
I might be in a position to initiate a regional database for PEG Access stations in my neck of the woods. Given the work that is being with CiviCRM, Mapping Access, and the KDI PEG work - does anyone have any suggestions on how to approach this task using Drupal tools? What questions do you think I should be asking myself at the outset to get the most out of this project? What is the most effective use of Drupal/CiviCRM in this instance? Can it be done on the cheap as a single person project? What does it sound like to you?
Jason
Comments
IMO
That's great that you're thinking about taking it on. Here's some of my thoughts learned from my experience with MappingAccess.com. I tried to loosely organize them:
Project Management:
1) Make sure you're framing it to yourself as a communications/outreach project, not a technology project
2) Be able to proactively dedicate 1-2 hours a week to developing the project. By proactive, I mean use that time develop the project on a consistent and ongoing basis regardless of whether other people are pinging you about it.
3) I really would have liked to have separated the technology development from the outreach/communications with MappingAccess. It was difficult for me to be solving technical problems and then switching gears and trying to sell it to people. It's very different sides of the brain and I would have loved to have a sidekick so we could keep those roles somewhat separated.
4) It really needs someone who can be the public, driving face of it. I think you would benefit from a committee (as they could help with fundraising---probably their own if necessary---and outreach and even ideas and motivation), but you would need to keep them well managed.
Planning:
5) You need to figure out your audience(s). Who will be pulling data out, and who will be putting data in. What is the different needs/wants that go along with those audiences?
6) Purpose: Based on the audience, what information will you be collecting, and how do you want it to be used. How much is statistical (40% of stations area comcast franchisee) vs. practical (can I check out a camera). As I discovered with Mapping Access, it's really hard to collect statistical data since so much is based upon local policies---a first step might be to figure out what the common elements are of an access station (which I know you've asked before)
7) What are your standards for data: comprehensiveness (what is a realistic goal for % of stations for which to have data, and how extensive do you want them to be in filling out the fields), freshness (what is an acceptable expiration date for data), accuracy/legitimacy(how much do you want the data to be trustworthy?/what are the expectations for vetting it?)
Drupal:
8)Everything looks like a nail: Are you positive that Drupal is the right answer?
9) User vs. Node: What paradigm will you be storing this information under? MappingAccess stores stations as nodes, which can be created or edited by any user; this is because that's the easier way to make it community maintained (IMO). With something like CiviCRM, I don't know if this is possible---or of it's possible to make the process newbie friendly.
10) Workflow: I usually think of things as Google Analytics type Goals. What is the end actions that will take place (creating a user, entering station information, finding a specific station from a search, making statistical inferences), and what is the path/funnel that will take them through it and the visual and explanatory cues that will keep them from being lost. Drupal makes some things simple, and some things very difficult.
11) Upgrade paths: Moving Mapping Access from flexinode to CCK was one of the most painful things I've ever done with Drupal. If you see this as an evolving project, KISS methodology is key to flexibility and not painting yourself into a corner by using lots of niche modules/functionality.
Life advice:
12) How will it end?: Before starting any extensive web project, I think it's always important to map out how it will end. Obviously you can't think of every contingency, but you should at least explore the main possibilities (donated to someone else to maintain, rolled into another project, archived, shelved, left to languish until your webhost complains that they are disabling the database because it's being slammed by spam), and how, in that event, you can make the very best of the situation.