Skip to content
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

Open
JoshuaDickerson opened this issue Jun 23, 2013 · 4 comments
Open

Organized campaigns #20

JoshuaDickerson opened this issue Jun 23, 2013 · 4 comments

Comments

@JoshuaDickerson
Copy link
Collaborator

Organizations should be able to contribute to an individual campaign (GreenUpVT would be an example of a campaign)

@EdgeCaseBerg
Copy link
Owner

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.

@JoshuaDickerson
Copy link
Collaborator Author

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

@EdgeCaseBerg
Copy link
Owner

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.
Now what colors do each of those markers show up on the map as? Are they all the same? Well the user probably wishes to differentiate each marker from the other since they're different types, so do we choose the colors for them? Do we allow them to specify a default set of colors like red, blue, green, purple, yellow? Specify hex values? The more control you allow them the more troulbe it will be to get your average user to create their own campaign.
From a backend point of view, we now have to parse the json config file and throw an error if it's malformed syntactically, and we also have to check it's details for any semantic issues as well. We also have to support the front end piece of selecting which marker to put down which if it's in some type of self contained scrolling list is fine, but if we tried to do it the way the elements show up now, then we'd have more trouble with trying to scale the buttons down to the right size.
Not only does this complicate the front end styling , but it also might complicate the database if we need to support any arbitrary type of marker. Each pin has to be associated with a type, which is an object, so there has to be validation on the type of marker sent and etc etc.

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.

@EdgeCaseBerg
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants