Chris L Keller ...

Text

What I learned back at BuildMadison and in making CitySolver…

Back in September I had the chance to participate in an event called Build Madison, a weekend event that brought tinkerers, hackers and idea people together to build things.

At the event, myself and Paul Klemstine and another took up the challenge of building on a pitch to come up with a way to submit quality of life issues — graffiti, potholes, sidewalks in need of repair — to the city of Madison from a mobile device. Pictures were a must, as was the ability to add a user’s location.

CitySolver

The Build Madison pitch also positioned this project as something that would tie in with the city’s existing “Report a Problem" infrastructure.

Paul and I developed had a good time hacking together a project we called City Solver… It could aspire to be more — a foundation for an open-source See, Click, Fix or a tool for smaller municipalities — or less and left to lessons learned, of which there were many that apply to many things I find myself involved in on a daily basis.

  1. From different angles and perspectives keep asking, “Is this a problem that needs to be solved?”

    The original pitch wanted to tie an application into the city of Madison “Report a Problem” system. Needless to say that is an exponentially difficult task, and one not easily tackled by a hackathon team with 24 hours to work with.

    And nevermind that the city of Madison has a comprehensive website that city residents can use to report specific issues and wasn’t looking to extend the system in the manner the pitch stated.

    Finally, I knew that Open Data was on the horizon in the city, as the city council had recently passed an ordinance that would let information start following for developers to use.

    In the end, our project ended up with a couple prizes from the event, and I had the chance to meet with city officials on two occassions to discuss CitySolver courtesy of Eve Galanter, a former city council member who pitched the project.

    The conversation were fruitful as we were able to gain some insight into future city plans in this “Report a Problem” arena, some of which include mobile access and user feedback that we had in mind.

    And as soon as the Open Data starts following, real problems might be made available to develop around.

  2. Know who else has “solved” or attempted to “solve” this problem.

    Had in been better in touch with the work being done by Code For America, I would have known that developers have open-sourced similar crowd-sourcing applications and made code available that we could have built upon.

    That said, as an intermediate beginner, building something myself was very fufilling and helped increase my confidence about what I was capable of learning.

  3. Spend more time on knowing the following:

    • Who are your users?
    • What are their needs?
    • What can we do for them?

    Some advice from Code For America’s Kevin Curry helped focus ideas on this project further, when he suggested the following after I posted to a Google Group:

    The key element of your plan is residents working together to close their own tickets. That’s significant. I think you should base everything off of that and make it totally obvious this is not a tool for reporting problems about the city that only the city can fix.

    To Kevin’s point, after thinking more about this project as something “long-term” I was able to come up with the following:

    • City residents have the power, know-how and — I believe — a want to work together to solve some common problems.
    • That said, that power and ability is limited when a distinction is made between a resident’s fence that is in disrepair, a street with potholes and a malfunctioning street light.
    • Success in building a coalition-based platform might best come if based around a singular idea.
    • Privacy is a real concern and offers a very real hurdle to overcome when considering the idea of neighbors reporting on issues with neighbors.
  4. That last one is a biggie, hence even if everything at this point is coming up roses, would anyone use this thing?

    There are privacy aspects to keep in mind, and very real hurdles to overcome when considering the idea of neighbors reporting on issues with neighbors. For instance, “Thank you, I’d like to repair my broken fence, but I’m without work and my wife is sick and I haven’t made the time, so thank you for posting a photo of it online with your brutish comment.”

All that said, what follows are the bullet points from the BuildMadison presentation.

Build Madison Presentation Bullet Points

CitySolver

City Solver is a multi-device platform that allows everyday citizens to submit information about quality of life issues and problems they feel a municipality could or should address.

Whether using a web app, a native Android app, or their laptop, desktop computer or tablet, city residents could send images and descriptions of these issues and opportunities.

A rating system is Phase One of furthering the platform to allow neighborhood residents to band together to solve issues or to clean up the neighborhood.

Features

  • Native Android app pulls geolocation and user information to auto-populate data fields, and sends photo and photo location to a database.
  • Thumbs up and thumbs down ranking of issues to gauge interest from others.
  • Interface thats works on devices and browsers.
  • Photo uploads work on Android and laptop, desktop web browsers. Photo uploads will be possible for users on iOS 6 Safari.

CitySolver

Wishlist

  • Coalition building. Sign up to band together to fix this problem.
  • Use geolocation of an issue to query against aldermanic districts to add more context, or partner with OpenBallotBox?
  • Allow user to submit information via SMS
  • Use email to submit information.
  • Full screen map with geolocation to find issues near you.
  • Filtering & Search.
  • Admin view of database to assign issues, mark as resolved or not feasible and communicate back with user if needed.
Text

As a beginner I see so much advice in this simple statement…

Text

Quick snippets from building off LA’s most dangerous intersections map

tl;dr - Google offers a Streetview static image API, which will render a streetview image — if it exists — when given a latitude/longitude pair. Using this feature seemed like a good add on this map app of “dangerous intersections,” which is on a new responsive project template developed by SCPR’s Sean Dillingham. We also found a code snippet that will keep the centerpoint of the map when the viewport is resized.


Back in October — before I started at Southern California Public RadioKim Bui began asking the audience what they viewed as the area’s most dangerous intersections.

To date, the map has pulled in more than 140 submissions from across the Los Angeles Metropolitian area, including more than 100 in the maps first week of existence.

Kim and I were able to breathe some new life into the presentation when — a couple weeks back — the city of Los Angeles began to take steps to make 53 intersections it identified as “dangerous,” safer for pedestrians.

I took the newspeg and new information as an opporunity to move the map away from a Fusion Tables embedded iframe map to a “new for SCPR in the last month” project template that is responsive. While we’ve been able to kind of get an idea if the audience and the city are on the same page when it comes to the dangerous intersections, I think we’re still exploring the possibilities here.

Most dangerous intersections in Los Angeles

Looking at the map now, I think adding the ability to guide the user through the city’s ranking of intersection would be a helpful enhancement for the user, where through a table or a slider or simply links in a div. I also need to get better at where and how information is presented. Most of my data map mashups — indeed most of all data map mashups I guess — follow a similar pattern, so there’s also some room to play and learn there. And I’d like to create a re-usable style for the Google form on which we gather user submissions.

A couple fun experiments with this map did lead to some learning however. For instance, I didn’t realize Google offered a Streetview static image API, which will render a streetview image — if it exists — when given a latitude/longitude pair. On advice from Eric Zassenhaus we added this to the map presentation, so that when a marker is clicked, an image approximate to that intersection is returned. Not all work as well as others, but more is added than subtracted I suppose.

Using the API is pretty straightforward; it’s just an encoded URL string inside an image tag, which makes it easy to manipulate and added data from user input or from a dataset.

When combined with a Fusion Tables layer click event in the Maps API like this:

 google.maps.event.addListener(cityCrosswalkLayer, 'click', function(e) { jqueryNoConflict('#toBeRemoved').html( '<img src=\"http://maps.googleapis.com/maps/api/streetview?size=300x300&location=' + e.row['Lat'].value + ',%20' + e.row['Long'].value + '&fov=90&heading=235&pitch=10&sensor=false\" />'); }); 

You’ll get something like this when the user clicks a map marker:

W 8th St & S Alvarado St in Los Angeles

This presentation also includes a short little code snippet I found that will true the map’s centerpoint as the window is resized. Minor stuff I know, because with responsive design the centerpoint is set when the page loads and screen size is determined, but should a user flip from landscape to portrait — or vice versa — this can keep a thing from becoming a thing.

Including this is ultra simple. The function is simply:

// function to maintain center point of map function calculateCenter(){ center = map.getCenter(); }; 

The function can then be called in the same function that creates the map:

google.maps.event.addDomListener(map, 'idle', function() { calculateCenter(); }); google.maps.event.addDomListener(window, 'resize', function() { map.setCenter(centerLosAngeles); }); 

In this case, centerLosAngeles is a variable for my starting centerpoint specified in my map options.

Text

Mother Jones, Slate open up a couple stunning datasets related to gun violence

In the wake of mass shootings this year, and the journalism that followed, Mother Jones has opened up a dataset of mass shootings in the U.S. between 1982 and 2012. Included are a spreadsheet of the incidents, and a spreadsheet of the weapons used. You can read more about it here.

Meanwhile, Slate has partnered with the Twitter account @GunDeaths to create “an interactive, crowdsourced tally of the toll firearms have taken since Dec. 14” — the date of the mass shooting in Newtown, Conn. that left 26 dead.

Of course, this data is incomplete. Not all reports get caught by @GunDeaths’ news alerts or his followers. Suicides, which are estimated to make up as much as 60 percent of gun deaths, typically go unreported. Nevertheless, we at Slate want to assemble this data as best we can.

Slate too has opened up the data and made it available for download.

Text

Link: Anyone can do it. Data journalism is the new punk

1) This is a dataset

2) Here’s another

3) Here are some free tools

NOW BE A DATA JOURNALIST

OK, it lacks a certain 1976 grittiness, but the theory is there. You don’t have to be a developer or a coder to be a data journalist.

When I first read this back in May I thought I was reminded of a Greg Linch post, or “three-chord song for journalists,” a phrase I used in a project pitched during last summer’s Knight-Mozilla Journalism Learning Lab.

I certainly didn’t think for one second that I was less than three months away from being approached about, interviewed for and offered a position as a data journalist.

Reading it now, and in combination with this thought-starter from Heather Billings and the resulting conversation…

…I am more convinced than ever that while I have learned that I can learn how to find solutions to some elementary things, in order to “graduate” into someone who practices a “craft” in this field I will need to double down on time and practice and time and practice.