Hello all. One of the goals we discussed at the GM meeting last night was to create a prioritized list of our systems, website, and software needs. After we create and prioritize this list, we can then figure out how to go about creating the systems involved and (eventually) integrating them. It's important to note here that at this point, we're talking about *what* we need the systems to do, and not how they should be implemented.
Last night we identified a few key areas where our systems need improvement:
**Party data storage and management**
The SFGP currently uses a very large, very disheveled FileMakerPro file set as our database. This database tracks (or attempts to track) SFGP members, volunteers, donations, sustainer signups, and a host of meta-data. The FMP database that currently exists is inadequate in several areas: (1) it doesn't adequately use the realtional capabilities of the software so it's nearly impossible to query (2) the data design is quite bad: there are duplicate fields, the tables and fields don't match the needs of the party (3) the database as currently used is a file database: people make a copy of the file, move it to another computer, and edit the copy (4) as far as I can tell, there is no backup strategy for the database. (5) the interface isn't quite usable (6) There are few permissioning and security considerations: we need different levels of access for different missions (e.g. we don't want to allow off-the-street volunteers to delete records).
**Communications: email lists and discussion boards**
I believe we're currently using the web-based system on sfgreenparty.org to do mass mailings. We've encountered problems with this system, but I'm not sure of other limitations or complaints. Ultimately, we would like to allow the list members to self-administer their email preferences.
As for discussion boards, we currently have a rudimentary system on the site. Some people do use them, but as I see it there are several problems with them: (1) many Democrats are using the boards to flame the Greens with the whole "you elected Bush" line of crap. (2) the boards currently allow anonymous posting and don't have moderation features (a la slashdot). (3) the boards are currently implemented in a proprietary technology (EML) that make them very difficult to change
**Communications: Web site calendaring and issue notification**
We currently have a database-driven site that allows people to update news items and events. We may want to discuss potential improvements (both cosmetic and functional) to the site.
If anyone has another area of improvement to add (or an elaboration on these three), please feel free to post a follow-up. Once we are relatively satisfied with our list, we should then determine who should work on what and how we should proceed.
Joe
Last night we identified a few key areas where our systems need improvement:
**Party data storage and management**
The SFGP currently uses a very large, very disheveled FileMakerPro file set as our database. This database tracks (or attempts to track) SFGP members, volunteers, donations, sustainer signups, and a host of meta-data. The FMP database that currently exists is inadequate in several areas: (1) it doesn't adequately use the realtional capabilities of the software so it's nearly impossible to query (2) the data design is quite bad: there are duplicate fields, the tables and fields don't match the needs of the party (3) the database as currently used is a file database: people make a copy of the file, move it to another computer, and edit the copy (4) as far as I can tell, there is no backup strategy for the database. (5) the interface isn't quite usable (6) There are few permissioning and security considerations: we need different levels of access for different missions (e.g. we don't want to allow off-the-street volunteers to delete records).
**Communications: email lists and discussion boards**
I believe we're currently using the web-based system on sfgreenparty.org to do mass mailings. We've encountered problems with this system, but I'm not sure of other limitations or complaints. Ultimately, we would like to allow the list members to self-administer their email preferences.
As for discussion boards, we currently have a rudimentary system on the site. Some people do use them, but as I see it there are several problems with them: (1) many Democrats are using the boards to flame the Greens with the whole "you elected Bush" line of crap. (2) the boards currently allow anonymous posting and don't have moderation features (a la slashdot). (3) the boards are currently implemented in a proprietary technology (EML) that make them very difficult to change
**Communications: Web site calendaring and issue notification**
We currently have a database-driven site that allows people to update news items and events. We may want to discuss potential improvements (both cosmetic and functional) to the site.
If anyone has another area of improvement to add (or an elaboration on these three), please feel free to post a follow-up. Once we are relatively satisfied with our list, we should then determine who should work on what and how we should proceed.
Joe
-
Re: SFGP IT and Site Priorities
Fri, December 26, 2003 - 9:30 PMGood start! I agree with Rob somewhat that we need not try to plan everything out before doing anything, we should volunteer to take charge of things as we agree they are needed and just do it. The Site itself, beautiful as it is could use a lot of revision to move it towards better functionality. Rob has a lot of ideas for this too, but here are a few:
1. The blank space at the top right and on the margins should be utilized.
2. There should be an area of highlighted (prioritized) articles that isn't just locked in at the top of the normal column as it is now, so people can see right away both that there are recent articles at the top of the regular column and there is a separate area, maybe with just a headline and description(skip the date, author and source maybe), for older articles that are still very important. So if Matt won the mayors race 2 weeks ago, it's still prominent, but not in a way that makes it look to a frequent visitor that there's no new news since then.
3.The events column needs a lot of reformatting, and I'm not sure of exactly what would be best. But I think Action items should be kind of separate from Green or like-minded events. There is also an awful problem that came from nowhere a few months ago that made it so if you revise an event and leave a date or time field blank, it won't stay blank, it will put in 0000's. also if you had a picture, it often gets cut off at a certain length in the title field when a revision is made.
4.The title of the top news item always gets split and carried over onto the next line unless you use <nobr> tags.
As far as the e-newsletter, it would be dope if there was an easy way to put together and send html email, as an option people could choose.
As I have little expertise, I can't jump on any of this, but I've got lots of basic experience editing the site and sending the newsletters and will continue to make suggestions for making the SFGP IT and Site the best resource in town.
Peace,
Paul -
-
Re: SFGP IT and Site Priorities
Wed, December 31, 2003 - 6:55 PMPaul, I somewhat disagree with the idea of simply letting people run with things. In my years of experience with software projects, that type of anarchy has usually resulted in disparate, unreliable systems that require a ton of maintenance (usually by their creators) and are difficult or clunky to use. In short, you end up with something not unlike what we have today.
That said, there is a degree of merit to letting people take initiative on things. You just need to agree on a set of basic goals (in software parlance they are called requirements) that actually fulfill the needs of the organization. This is especially critical for data projects like our database revamp. The same is true of most other projects.
What I fear with the listserv project is that someone will build something out that works on their server, but won't run on whatever OS or server is available to us when we put said listserv system into production (BTW - relying on someone's home DSL line to host a publicly-facing listserv machine is not an option in my book). That's why portability should be a key requirement of the listserv system. I also fear that administration and subscription to/deletion from the listserv might end up being difficult if we do it wrong. We've all seen how difficult open source software can be for users. I've seen listservs that require 4 or 5 steps from users to get subscribed or unsubscribed. I'm hoping to avoid that here. That said, John-Marc is the go-to guy for the email project.
Perhaps we should create another sub-group for web site improvements? We're stuck with another proprietary system (EML) there, so improving the dynamic stuff might be difficult. But doing cosmetic improvements shouldn't be too hard. Would you be interested in taking responsibility for that?
Joe
-
