Abstract out city-specific media to configuration
daguar opened this issue · 12 comments
Going through the process of redeploying this, I'm coming to the view that it would make sense to abstract out the city-specific stuff to variables in the configuration file. The driving idea here would be to minimize the amount of city-specific material that is committed into git.
The pieces this would touch are the logo (all the PNG files) and footer.
The footer material is pretty easy to deal with (options for city logo: have folks commit, or supply a URL).
The top logo is harder: the downside to the responsiveness (which is AWESOME) is that you need to hard-edit a PNG and export a whole set in various sizes. It'd be great if the city name could be overlayed on the logo as actual text using CSS, removing the need for the PNG editing ( @akit - you have thoughts on this?)
This is a stub for initial discussion -- will propose code if it seems like we're on the same page re: the approach. (cc @Mr0grog )
@akit is hard at work on some slightly tweaked, more generic designs for SR Tracker. They're pretty similar to what exists already, but with slightly altered logos, type, and colors so that Chicago can continue to have the unique brand we developed for them last year and other cities standing up SR Tracker can use the new theme, which should be slightly customizable via configuration vars.
Awesome! I'm going to tag @migurski so he's in the loop. This kind of explicit redeploy-abstraction is really important.
Thanks @akit !
On Jun 12, 2013, at 2:03 AM, Rob Brackett notifications@github.com wrote:
@akit is hard at work on some slightly tweaked, more generic designs for SR Tracker. They're pretty similar to what exists already, but with slightly altered logos, type, and colors so that Chicago can continue to have the unique brand we developed for them last year and other cities standing up SR Tracker can use the new theme, which should be slightly customizable via configuration vars.
—
Reply to this email directly or view it on GitHub.
Thanks guys, it's great to see this happening.
Ok, so here's the direction we are tentatively going with this (feel free to provide feedback).
Home page/listing of SRs:
Detail page for an SR:
Email template:
These are functionally the same as the existing UI, but feature a slightly different logo (no "flag" theme, different typeface for the city), different typeface, different colors, and different background. Hopefully these provide a meaningful visual distinction from Chicago's existing theme.
Some notes:
- The simpler logo/city name lockup should make it easy for us to include the city name as actual text and customize it through configuration.
- The city background image will be customizable in configuration. Using an actual image here will hopefully encourage people to find something relevant to their city and use it instead.
- The primary and background colors should probably be customizable as well.
Other questions:
Should we add configuration for template/static asset paths so people can make their own templates without having to fork the repo?
Looks excellent, great work @akit. For now forking the repo seems fine to me, if it’s clear exactly where the templates would need to change.
Do you see a need for an “Anytown, USA” sample data feed to host for this?
For now forking the repo seems fine to me, if it’s clear exactly where the templates would need to change.
Cool, that's good feedback to hear. I think it's pretty obvious (there's a templates folder), but the README could probably do with a note about it.
Do you see a need for an “Anytown, USA” sample data feed to host for this?
Up til now we've mostly just been pointing to http://servicetracker.cityofchicago.org as an example, but I suppose we could host an instance ourselves. That would at least be up-to-date with the code! I imagine we could still just point to Chicago's API (I don't know of anything generic we could use).
Yeah, #41 is going to be a whole other complete and utter mess. Given that people want some basic configuration options for redeploying, I'm having a hard time thinking of what would even be a sane approach to handling that issue. It absolutely requires someone writing some Python code. I think I'm willing to let it lie until someone is actually hitting a problem caused by it.
I like feedparser’s approach to this issue, though it would require a ton of work: “You should not be forced to learn the differences between these formats. Universal Feed Parser does its best to ensure that you can treat all feeds the same way, regardless of format or version.” Let it lie, until we see some new future desire for this come up.
Well, now that I’m back in-country and in possession of a computer for the first time in more than half a year, I’m coming back around and looking at this. Does anyone still have a strong desire/interest in making this redeployable? Is there a lot to gain here or should this whole “City Customization” milestone just be dropped/left alone for now?
@Mr0grog I'd recommend waiting for the demand on this. It seems like new Open311 uptake has trailed off a bit, and so it might not be immediately valuable to abstract this stuff out.
That said, maybe put a big honking call-to-action in the README for people looking to redeploy this in their city? (Maybe a link to this issue asking people to chime in and say they want it?) That way you can wait on the work until there's some real concrete need that's been gauged. Whatcha think?
It seems like new Open311 uptake has trailed off a bit, and so it might not be immediately valuable to abstract this stuff out.
Yeah, that’s kind of what I was thinking might be the case.
maybe put a big honking call-to-action in the README for people looking to redeploy this in their city?
That’s a really good idea. Doing it now.