From my Twitter DM

Allow for different filters including no filter over the images used.

The filters are actually critical to the legibility of the text. The colors I selected also tie into the campaigns brand styleguide and create consistency between the generated images, so I'm pretty hesitant to allow users to meddle. I'm also concerned that too many options and sliders on the generator will just lead to fewer people generating images (the paradox of choice).

My hunch is that the real reason people don't always like the image is because some source images are too dark or too bright, which result in a mostly blue or mostly yellow result. I think the correct fix here is to create either two sliders for brightness & contrast, or a single slider to control the gamma curve. I'm pretty confident this one slider will let people dial in the image to be the correct balance and fix this issue overall.

Requirements:

• On the preview interface, a new slider that controls the gamma of the background image
• New variables allowing that data to be passed along to the HTML generator

For very small towns, DataUSA doesn't return any data for "Median income". In these cases, recover gracefully by hiding those fields, rather than showing a $0 value.

I get lots and lots of requests for state level output. I designed the app not to do this, for this reason I shared on Reddit:

I chose not to design the app to generate state-level data, as it's a lot more difficult for people to comprehend. Most states would bring in billions every month, and that's such a large number it's unfathomable for most people to process. Also how excited do you get for that money to go to someone hundreds of miles away?

By focusing on towns specifically, and featuring images of local main streets, my hope is that people understand how that money is likely to stay in their community, as people spend it on car repairs, daycare, local organizations, etc. The goal of this campaign is to help them understand that this money supports them, their neighbors, and the small business down the road that could finally expand with a few more customers in the door.

That being said, this request comes up a lot. A suggestion on Reddit was to allow states, and if it is a state, to change the language to be:

By giving every adult $1000, Andrew Yang wants to invest $", [NUMBER], "million into the communities of ", [STATE], " every single month.

To implement this, it would require:

• Modifying the dataUSA results to allow results for states, not just places
  • Unfortunately this would invalidate the autocomplete cache and require us to hit DataUSA with more requests
• Modifying the template engine to allow for a new parameter: geo_type. Currently the only value we filter for is place, this would require allowing other values, including state, and potentially others like county, etc.
• Auditing the whole codebase for assumptions that this would break

This might make #5 more difficult as well because it doubles the amount of testing needed for that idea.

I don't know why but some cities have a poisioned cache. Examples:

• https://everysinglemonth.org/index.php?action=process&city_name=Bonanza%2C+UT&city=16000US4906920
• https://everysinglemonth.org/index.php?action=process&city_name=Monowi%2C+NE&city=16000US3132550
• https://everysinglemonth.org/index.php?action=process&city_name=Little+Grass+Valley%2C+CA&city=16000US0641789
• https://everysinglemonth.org/index.php?action=process&city_name=Willow+Canyon%2C+AZ&city=16000US0483475
• https://everysinglemonth.org/index.php?action=process&city_name=Hobart+Bay%2C+AK&city=16000US0232550
• https://everysinglemonth.org/index.php?action=process&city_name=Monowi%2C+NE&city=16000US3132550

The software should notice that it doesn't have values that it needs, and then either try to query the API again, or fail gracefully, and then push a notification to the dev using push(). Right now it proudly shows a city with zeros everywhere.

I assumed this error would only appear if DataUSA was overloaded with requests. Someone reported that it can be consistently reproduced by searching for "Inman, SC"

https://everysinglemonth.org/index.php?action=process&city_name=Inman%2C+SC&city=16000US4535755

Right now the app only generates a single square image. From my Twitter DM:

If you could create a Printer Friendly template, something appropriately sized for an 8.5x11 piece of paper with optional b&w and with additional details about selected Yang policies

I've also heard other requests for business card sized as well (3.5 x 2").

Some thought needs to be put into the UI of how this would work. Should users just operate with the square preview, and once they click save, all possible sizes are generated at the bottom?

An alternate approach would be to have tabs or radio buttons beside the preview allowing users to change the preview in realtime. In that case, it would presumably only generate the size they selected.

This is a significant rearchitecture of how the backend works now. Everything from the code pipeline to the file structure for exports assumes there would only be one export per city/image combo.

From a Twitter DM:

A way to easily get these images to be printed up as sticky notes through vistaprint or other providers

I've searched into Vistaprint along with a lot of other providers and can't figure out how to do this, but I think it's really important. I wish that they had an endpoint where I could prefill information and a URL to the generated image, but I haven't found any online printing vendor support this programatically.

If we can find one, then it would be great to have a "print now" button after the image is generated that would direct users to the third party print provider with dimensions & image data prefilled.

Problem: Each PNG image is around 1MB. I think a comparable JPG should be more on the order of 100kb.

Solution:

After the exporter creates a PNG, it should then run a script that converts that PNG into a JPG image, and saves it into the the exports/jpg directory.

Then the output shown to the user should be the JPG when it renders the image, and also the permalink URL it gives to viewers.

Lastly, the homepage images of most recent 8 should be updated to be the jpg images.

Similar to #15, but with the autocache data.

Some results from the DataUSA API are Cloudflare captcha screens. Be better about detecting these and failing with a "please try again later" error.

Should be a new variable in config.php that gets included in the site output via header.html

We should have some kind of system to prevent a runaway bot from making requests on the site and depleting the Zenserp API quota.

This could be a multi-pronged approach:

• Rate limit requests from a given IP address
• If the number of requests made to the API exceed a certain number per minute/hour, notify the sysop and/or give people a "try later" message

Particularly because we've cached ~7,000 cities already, API requests should be increasingly uncommon.

Example:

I haven't really looked into the cause of this. The best way is to look at the HTML file that's been generated. In this case, the PNG is at
https://everysinglemonth.org/exports/png/16000US0629000_7a402b.png
So the corresponding HTML is at
https://everysinglemonth.org/exports/html/16000US0629000_7a402b.html

Loading that HTML page, I see one error in the console, which is potentially the issue:
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.icloud.com/photos/ with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.

Maybe it's because the image it refers to (https://share.icloud.com/photos/0X6Kx7sZNh9CKbneiVI_yIfiQ) is not really an image, it's a web page.

Searching for that same city on ESM, I don't even see how they found that particular image. So this could use some more digging around.

Either talk broadly about UBI, Humanity Forward, or else active bills to support.

Users are starting to game the system and put rogue HTML characters into the search box.

This is probably a simple matter of running html_entities() on any user input before it is allowed to propogate further through the code.

The app currently fails if it can't find a town matching their search query. Example:

Sorry, we could not find a town named Oroville washington

In this case, the code should remove the last word and attempt searching again, presenting this list of choices to them on the error screen. In this case, by stripping the last word and searching for simply "Oroville" would return the following choices from our API provider, one of which is the correct answer:

Oroville, CA
Oroville East, CA
Oroville, WA
South Oroville, CA

In some rare events, an error code 101 is thrown to the user when they try to view results for their town. Currently unsure what the cause of this is.

I received a suggestion to have a Spanish language version of the app. I think the move would be to host languages at $lang.$baseurl. For example, https://es.everysinglemonth.org. Then some code near the top of index.php would identify the language from $_SERVER['REQUEST_URI].

Because the $lang variable will be used to determine file paths later, we should whitelist languages that we know we have. For now, that could be as simple as:
if($lang != "en" && $lang != "es") $lang = "en";

We'd move the contents of templates into templates/en. Any other copy (like error messages) presented to users should be moved to new template files. Update do_tempate() to pull the correct templates based on the global $lang variable.

Any code that reads or writes to the exports directory should instead point to exports/$lang.

Once this is done and working, then we can duplicate the contents of templates/en -> templates/es and recruit some help translating the language.

Unfortunately this will result in more duplicate work if we are to ever modify templates in the future. For the moment I think this is preferable to building a whole new language engine, given that we're not likely to do many translations at this point.

Certain results from DataUSA include the word "(balance)" and it's pretty ugly. Just search for "balance" on everysinglemonth.org and you'll see a lot of them. Here's a good example:

Louisville/Jefferson County metro government (balance)

It's a low priority item, but I think the move would be to add some logic into get_meta()

Stripping out any use of "metro government" and "(balance)", and then running that through trim() to remove any whitespace from the beginning or end of the string.

From an email sent to [email protected]

I'm an active Yang Gang volunteer involved with multiple initiatives, and I have a suggestion that originated through a recent conversation in the Basecamp group: in order to appeal to conservatives who might view the term "giving" as too closely aligned with "undeserved welfare", how about changing the wording to the following:

"Andrew Yang wants to invest $N into Town every single month through a monthly $1,000 Freedom Dividend for every adult US citizen."

This would eliminate the term "giving" and be more palatable or intriguing to more people of other ideologies. It would be great if you could consider this change, thank you!

Considerations: making sure the phrasing of the language is still condusive to an asthetically pleasing typography, that key words appear at the right place in the text, and that there isn't too much text.

Hi. Reddit Yang Gang here. Not a U.S. citizen myself but I love the ideas of Yang and believe that our world will be MUCH better if he gets elected. Thank you so much for your website!

Here's something I came across when I was using the website.

The input box is pretty long and overlaps with the "SAVE CHANGES" button, which is not ideal.

Instead of hardcoding the size of the input box, I would suggest changing the style to width: 100% or something like that. :)

Ideally a push notification to the operator, and a blank list of results for the user.