Saturday was a pretty interesting day for me. I got a chance to visit the offices of Google Chicago, I met the Chief Data Officer for the City of Chicago, made some interesting new friends, and entered my first ever hackathon. And the best part… my team won!
I originally heard about the hackathon through the city’s Twitter feed and quickly RSVP’d through their Google Plus page. While, I’ve heard of a “hackathon” before, and witnessed the judging of one at SXSW last year. While I’m not a skilled programmer by any stretch of the imagination, I did meet a few User Experience designers sign up for the Nike hackathon I had visited. So, I went into this with only a vague sense of what to expect, knowing full well I might be a little in over my head.
Mostly I was looking to learn a few things, make some connections in the Chicago development community, and maybe get some free lunch out of it. And to ensure I had some help, I invited my friend from my department in school, Karl Statz, even though he was graduating from school this week and was probably pretty busy.
I left super early because I was unsure about the trains on the weekend, and in my enthusiasm, turned out to be the first person there… participants and sponsor alike. So after a quick coffee run, I came back and quickly staked out a spot in the middle of the room with the most amount of outlets available (power move… literally and figuratively) and in convenient reach of the donuts. Shortly after I sat down, Donncha Carroll sat at my table. We made some small talk for a while, when Karl arrived. He couldn’t figure out the space age coffee machine in the mini kitchen, so I went back to suss it out and met up with Keith Weisberg, a newly minted Googler headed across country from the University of Indiana to Silicon Valley. He heard about the event on Twitter too and wanted to pop his head in. When we came back to the table, Cathy Deng (another recent grad, this time from Northwestern) was sitting with us.
Pretty shortly after we all settled in, (around 10am) we heard from representatives from the Mayor’s Office, Chicago’s Chief Data Officer Brett Goldstein, and the Chicago Police Department describe the purpose of the event: to promote development using the city’s latest open data initiative: the Chicago Police API. This interface allows for anyone with an application connected to the police’s servers to post data. The idea behind freeing up this information to the public is that it opens up one more channel of communication between the CPD and the community. Some of the things you can view using this API included:
- Community concerns
- Crime statistics and locations
- A list of “Most Wanted Individuals”
- Calendars of community events.
So, the potential to make things was pretty broad. They made it pretty clear they were looking for applications centered on mobile and smartphones, and laid out the sort of things the API and the back end could and couldn’t do. And then they put us all to work. They didn’t really divide us up into teams or really offer a strict structure to the event other than they would check back with us in about five hours for group presentations and judging. Some groups had organized themselves before they arrived, and some folks were already coding away before the speakers were even finished. Karl, Donncha, Cathy, Keith and myself were all seated together, looked at each other and more or less shrugged and said, “Hey, let’s be a team?”
Right off the bat, we were collaborating pretty well, brainstorming all kinds of things. Karl had an idea for some kind of heat map. Donncha had a notification idea. I had some crazy conceptual idea of a stock ticker with weighted crime scores for every neighborhood… but it was a hard thing to sell with only a couple hours to work. It was Cathy that thought of simplifying the process of reporting something to police, and Keith that had thought of pictures. (I think… we moved pretty quickly at this point.)
From there, the pitch became “Instagram… but for crime.” Which I registered in my head as “Copy Instragram’s user flow as much as possible.” Mostly because we’d be working with learned user behaviors that several photo sharing apps already use. This idea proved to be especially relevant because as Cathy point out, the current online system for reporting concerns was pretty complicated. As a matter of fact, it could probably be used as a textbook example of “UX anti-pattern.”
Fleshing Things Out
Unfortunately, at this point, Keith had to take off. But by this point, we had a pretty clear plan for what we were going to do as a team, and we forged forward.
It was at a panel on “Guerilla UX” I sat in on with Brynn Evans and Krista Sanders from Google’s UX team and Fred Beecher from the Nerdery where I learned to not even touch a computer when planning things out. Instead, I grabbed a sketch pad and started in on a quick six to eight sketches in five minutes to plan out the core user experience. This is a great tool to start because the time limit forces you to quiet your inner editor (which, considering the heroic amount of caffeine I had ingested that morning was actually pretty hard to do) and it makes you consider ONLY what’s important to accomplish a simple task. If you’re trying to build a “swiss army knife” of an app that solves everything, this technique probably won’t be much use. But if you’re focused on doing one thing and doing it well, it’s great because it forces you to find some clever solutions in a short amount of time.
The basic “user narrative” we were going for was this:
- Citizen witnesses a concern, such as an abandoned car, a streetlight out, or loitering on the corner.
- The citizen/user opens up the app.
- A quick picture of the problem is taken.
- The citizen then has the option to add a note describing the nature of the issue.
- Once sent, the citizen has the option of providing their contact info for a follow up or skipping that and submitting their concern anonymously.
- After the photo/note/contact info is sent, the application can scrape the photo’s metadata for a date, time, and an X and Y coordinate and submit that data to the police as well.
Storyboarding helps me think through the process.
Now, are there other issues we would have to address? Sure. Legal issues such as privacy weren’t directly addressed. And the system is probably open for “trolling” and abusing the process. But the limited amount of time available kept us focused on accomplishing a simple task (taking a picture and sending it) and thinking about delivering a “minimum viable product” by 3:30. And we wanted to encourage the public to report their concerns and empower them to interact with the police in a new way.
While I worked on building out the wireframes into a medium fidelity with Balsamiq, the Dev team (Donncha, Karl, and Cathy) started chugging away at making something to demonstrate. There was a variety of skills across a lot of different platforms, and at first there was some discussion about what/how to build.
- Donncha is an experienced Adobe Flex developer who has started to dip his toe into Objective C/iOS development.
- Karl often works with Microsoft platforms, but has built mobile applications for school projects and has recently had exposure to Python/Django and Ruby/Rails as well.
- Cathy studied mathematics in school and is probably the strongest coder of all four of us. However, her exposure to mobile platforms (which the police officers stressed pretty heavily in the intro) was limited.
Oh, and I should mention, we all basically brought every computer we owned, and in some cases, the kitchen sink as well.
(Not pictured) Karl’s Blue Gene/P with high speed optical network and my Colecovision.
So with DOZENS of possible platforms, and lots of overlapping Venn diagrams of experience, we settled on Donncha working on the front end with Xcode for iOS 6 off my wireframes and mockups, and Karl and Cathy providing API and back end support. Karl described it as “pair programming at its finest.”
The weird thing was, there wasn’t a ton of discussion about it, it just kind of fell into place. I knew Karl coming in, but we hadn’t really collaborated on this level before today. So for a group of strangers off the street, we actually worked pretty well together.
During the brainstorming process, we figured we would have a user flow for reporting without a photo. So while we didn’t have to worry about Instagram’s “filters,” we did have to figure out some way of getting the user to input actionable data for the police to work off of. In hindsight, I feel like I wasted a little bit of time worrying about this in the user flow. I think this is something we could add to the core experience of the app later, and if we go forward with this as a team, I feel keeping the first big iteration of the app focused on the “photo submission flow” rather than splitting our attention with another internal app process would be the first thing I’d fight for.
The first challenge we ran into in the coding process was the requirement for posting a report to include a categorization for either “Gang Activity, Prostitution, Narcotics, Troubled Building, or Other.” While we focused the app more for reporting the “Other” category, we had to have some sort of drop down option (which Xcode didn’t support, but the devs quickly improvised something) to include with each submission. I quickly mocked up an option for this while I was working in Balsamiq, because this day was pretty much about “learning as we go” rather than adhering to any kind of strict plan.
Another difficult problem we had to sort out was the fact we couldn’t pull off the idea of scraping the metadata off the photo with the limited experience we collectively had with Xcode. So we sort of jury-rigged a process where the app would pull the GPS data from the phone when the post was sent rather than have that data tied to the photo itself. It’s not perfect and it wasn’t elegant, but as this was our team’s first hackathon, we didn’t know what to expect and just wanted a geolocation feature somewhere in the app to take away the barrier of figuring out where the concern was located from the user. I had worked a “Change Location” flow into the wireframe due to respond to the change and Donncha was able to implement the new functionality.
Xcode turned out to be a good choice of platform. I had originally pitched an HTML5 app (because this was an environment both Cathy and I felt comfortable contributing code for), but it really didn’t offer the user interface that lent itself to such rapid development. Plus, it allowed us to test locally rather than wrestle with too much server stuff. Karl and Donncha were able to make a functional prototype rather quickly and testing it both on the laptop and on the phone turned out to be fairly easy for some hackathon rookies.
Our hosts, Google and the Mayor’s Office, were amazing. These were some very smart and talented folks, and they gave up their Saturday to help a bunch of developers solve problems. The room (we used Google’s cafeteria) was comfortable, the wifi excellent, and as I mentioned earlier I was able to swoop down on the largest cluster of power outlets I could find. The event page had over a hundred RSVP’s, and every table in the room looked like it had people at it, but based on how many donuts, sandwiches, chips, and pop they provided, they either expected a bigger turnout or they were super hospitable.
It was a “competition” but both the hosts and other attendees were all really friendly and willing to share what they were working on, even helping us with feedback and code help in some cases. It wasn’t an aggressive environment and it really felt like everyone was working together to solve a really complex problem with some shiny new tools.
From a user experience design point of view, the members of the Chicago Police Department floating from team to team proved incredibly valuable. I keep up on the news in Chicago, and I care about my community, but I have to admit before the event, I never really considered things from the police’s perspective. Having ready access to them to ask questions, pitch ideas to, and get feedback on how citizens actually interact with them really helped me shape the user narrative and improve the application’s design. My ideas of what police do is mostly shaped by what I read in the news and what I’ve seen on “The Wire,” but I left having a much greater appreciation for the job the CPD does for this city. Officers Lucy Moy, Jonathan Lewin, and Rick Pelinksi made it a point to check in on all the teams and helped us all shape our project.
Presentations and Judging
3:30 came around earlier than we thought, and we were encouraged to start moving up to the front for group presentations. The first group that went up had a really functional texting app that sent notices to users on local CAPS (Chicago Alternative Policing Strategy) events and local crime notices.
Next up was Derek Eder with “CAPSure“, which was a simple, functional, and easy way to find local CAPS meetings and communicate with your local police force. I was impressed with how well the app worked and if I had a vote, I would have voted for this one.
Another thing that made me jealous of Derek’s presentation was he had a short, punchy, and memorable name for his app. In an improvised moment right before we were up to present, we nicknamed our app “CAPStagram” (Please don’t sue) to drill home our borrowing of some of Instagram’s photo sharing features combined with the CAPS program. It helped to make clear what we were about right as we got started.
Now, before we sat up front for the presentation, we sort of planned out amongst our team to present as a group, with myself giving a short two sentence pitch, Cathy demonstrating the problem we wanted to solve, Donncha with a tech demo, and Karl answering any follow up questions.
We only got one question, from Brett Goldstein from the Mayor’s Office. I was so nervous, I honestly don’t remember what he asked or what we said. And I think I ended up talking over Karl (sorry buddy) because I have a terrible habit of moving my mouth when I’m nervous. And I have no idea why I was nervous… as a group we were all pretty inexperienced at this and just wanted to see what a hackathon was like.
The rest of the groups that came after me kind of ran together. By now I kept thinking about what we showed off, how we could improve it if we just had some more time, and what we could do different.
Some of the other things I do remember from the other groups:
- “Map That Trap”‘s team was huge and they demonstrated an ambitious app with a complicated back end, and had some strong ideas. Problem was, my feeble little mind couldn’t pay attention. By this point, the caffeine and adrenaline had worn off and I was tired.
- One guy working all by himself managed to make a really elaborate iOS app implementing almost all of the API. While I was researching ideas in the morning, I came across NYPD’s mobile app, and this guy’s app seemed to be more fully featured than even New York City’s offering.
- A team from the School of the Art Institute had a really cool concept for a streetlight that turned green based on crime data in the immediate vicinity. Having just graduated from SAIC’s rival from down the street, Columbia College, I wanted to not like it, but the hardware gadget nerd in me found it to be awesome and probably the most imaginative idea at the hackathon.
After the presentations, the officers and city representatives went in the back for a few minutes when a couple of folks came up and congratulated us on our app. Elliott Ramos from WBEZ even came by our table and started to interview us, but we were cut off when the judges came back and asked our team, the texting team, and the guy that wrote that one big app by himself to come up. Brian Fitzpatrick announced the third place winner (The lone guy), and then the runners-up: the texting team. I reacted by getting the biggest grin on my face. We won! I was just happy to be there and I couldn’t believe our scrappy little team of rookies pulled it off. We were awarded a Chromebook (which Donncha earned with his dedicated coding skills and a gentleman’s coin toss between him and I) and went back and wrapped our interview with Elliott.
Elliott asked us all why were there and why civic hacking mattered to all of us. I felt a little callous admitting I was just there to build out my professional network and face a new challenge, especially when Cathy shared that earlier in the week she was introduced to using open data to help people at a meetup earlier this week and was moved to participate in our event. It made me feel good I helped clear a path of communication between the police and the community they serve. I was pumped from the experience, and I probably talked Donncha’s (who graciously gave me a ride back north) poor ear off all the way home.
I was going to spend this week working on drumming up some freelance work and polishing some other side projects I was working on, but I’m excited to get back together with my team. We already found some space to get together, and I’ve got some more interaction ideas to bring to the table. I’m looking forward to seeing what we can do with our little idea, and we’re technically not even really at the “feature selection” point yet.
So maybe I got lucky with my team, but I take some pride in looking around the room listening to the other group’s presentations and noticing our team really had a solid foundation in good usability principles from the start. To other UX designers out there, I’d recommend popping into hackathons because I definitely felt like I contributed to my team despite my lack of mad programming skills and I’d like to think having a simple, clear focus on the usability side contributed to our win.
And to other beginners, sometimes not knowing what’s expected of you helps. As Cathy put it:
Went to my first hackathon today & our team (all first timers) won! Moral of the story: more n00bs should be willing to hack
— Cathy (@cthydng) May 11, 2013
UPDATE: Here’s Elliott Ramos’ writeup on WBEZ’s tumblr.