-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Organized campaigns #20
Comments
An organization running a snapshot of the ec2 is effectively running it's own campaign isn't it? I don't know if it makes sense to work this into the application itself. The only thing that really separates one campaign from the next is the front page and the types of comments and pins placed on the map. The heatmap is general enough that it would function with any campaign. If we wanted to some how incorporate an easy way to switch out those panels and such then it would be general enough to be used by anything. But that seems like a lot of work that could come after the GreenUp specific one is done. If while working on the GreenUp application we make it as general as possible then it might be easier to do. But being too general over complicates simple things. So I think that maybe we should have a campaigning application be a seperate project after GreenUp is finished. |
In essence, we are making the campaigning app. As you said above, the only parts specific to GreenUp are the marker labels, and the text on the info screens, both of which are easily set with a simple configurations file. It seems like all we'd need is to make a campaign table in the DB, and associated each datapoint collected with the campaignID. All the other work would be done on the client (options page, setup, etc). Being able to make campaigns takes a single-use GreenUpVT app and turns it into an app that could be repurposed to do all sorts of things |
I would argue that the color scheme and any green up logos we happen to associate with it would be specific to green up as well. the easiest thing to do would be to create some type of template css that configures the application towards a campaign, but that sets up the trouble of burdening the users of the application to create their own campaigns and needing a designer to help them out with that, something most nonprofits probably cant do or wouldn't want to do if there's an alternative. If we make the application theme-able with the option of providing your own custom theme, then we open up the door to developers and non developers who want to set up a campaign. My trouble with opening things up for configuration is that it over complicates something as simple as a marker color. Example: A user creates a campaign which has 5 different types of markers that can be placed on the map. This is easy for them, as they merely open up the configuration or options file and underneath a markers section in a json config file and add 5 csv's to it. This is all doable, don't get me wrong. And a great idea that would widen the appeal of the application to a broad market. But I just want to make sure that we all understand the undertaking of creating something highly configurable. Over-Generalizations are not only bad in politics but for code and design as well. I'm for creating an application with possible wide spread use, but I'm not for creating something so massive that it's unwieldy and buggy. The application, if made general enough to oversee any kind of campaign with geocentric data, must be documented well. And easy enough to use by your typical business man. |
All that being said, we could start small with configurable details such as title of a campaign, a short paragraph displayed on the front end. Then incrementally add in support for color and multiple marker types. |
Organizations should be able to contribute to an individual campaign (GreenUpVT would be an example of a campaign)
The text was updated successfully, but these errors were encountered: