How I Built a News App

Covering a conference is hard, especially for a developer. My job was to make something compelling but also useful. It’s easy to be flashy; it’s much more difficult to make something that people will use. This is how I approached this problem and created ONAmusic.

A week and a half before the conference, I was assigned to cover the Atlanta music scene for visitors. Initially, I had pitched a pick-your-own-ending interactive that would allow conference attendees to pick which concert they wanted to attend and return to them a list with restaurant selections corresponding to the genre of music and location of the music venue.

I had no idea how to make this. I didn’t even know where to start. But honestly, that’s not the point. For me, the trick to making something cool without killing myself is to aim much higher than what you can actually feasibly create. That way even if you end up with something half as great as what you had originally planned, it’ll still be pretty cool.

Even though I knew that this app probably wasn’t going to work like I had pitched, I still felt overwhelmed by all of the pieces that I would need to get working. Pushing me forward was the knowledge of having all of the raw materials to help people escape the hotel and experience Atlanta. I started small. My student newsroom mentor, Jeremy Bowers of NPR, had given me some restaurant data a few days before so I started trying to print the data we needed from the restaurant JSON to an HTML page.

I wrote some code, got nothing. Wrote some more code, got some errors, got something, but still wrong. When it came down to it, I spent an entire day writing broken code and had nothing to show for it.

That’s when I decided to shrink the scope of my app even more. After I came to terms with my limitations and the time constraints of the deadline, I pitched a slightly different project with a list of events and artists with maps and video. It was definitely less flashy and cool. But it was more useful and easier to navigate.

With my new pitch OK’d by the team, I needed to build a list of local music events. The obvious next step to me initially was to pull that data from a music API. Unfortunately, there aren’t a lot of well-documented APIs that list local concerts, and the ones that are out there didn’t have everything we were looking to list. So after some consultation, I decided to make my own data set.

Using Google Docs and some local concert websites, I compiled a spreadsheet of events, artists, dates, links to ticket sites, and a video of each artist from YouTube. Jeremy wrote a python script to convert the spreadsheet from CSV to JSON. This left us with four JSON files: three-star restaurants, four-star restaurants, five-star restaurants and our weekend concerts.

After some more discussion with Jeremy, we decided to combine these files into a single file that contained a list of events. Each event had a venue with an address and a distance from the hotel, as well as a list of nearby restaurants. We decided on this structure because it matched the structure of the app we were building. The code to handle this transformation is written in Python, and you can see it here: https://github.com/jeremyjbowers/ona13game/blob/master/data.py.

Now that we had our data merged and organized, it was time to start talking about what our app was actually going to look like.

Sketching and User Experience

I took another shot at the javascript to print events from our JSON file to the page — and it worked! But one problem with building sites from scratch is that after you spend two whole days getting everything to print on the page, you start thinking that anything on the page looks awesome because of the lengthy process it took to get there. I was glad to have Emily Chow of The Washington Post to help me make it both beautiful and useful.

Within hours of arriving at the conference on Tuesday, Emily and I sat down and started sketching out how we thought the music app should look. We came up with the idea of cards for each artist playing this weekend that could be sorted and displayed by day. As a user interface device, cards are little blocks of information that are stackable and easily digestible — basically fancy text boxes. In addition to the cards, I thought that video was important to play up the musical aspect of the app.

We decided to go with pen and paper prototypes. It might feel easier and more techy to sketch your comps in Illustrator or Photoshop, but paper is easier to throw away and faster to cycle through iterations of page layouts. After we sketched several rounds of layouts, we decided on one and started building the front-end of the site with HTML and CSS.

Beyond just making the site look slick, we also had to think about how someone might use it. Without the time to do user testing or analytics, we decided to assume the persona of an ONA conference attendee bored on Thursday night using the site. Am I looking at the video first, or the concerts? Do I know this particular thing is a button or link? What is the best way to display this video player? Would bolding or underlining the text make it clearer? Did this help me find a concert to go to? The answers to these questions lead to fixes that can make a big difference.

One issue we ran into right before we launched the site was the fact that people might not know to scroll down the page. Easy solution: a very obvious button at the top of the page telling them to look at the concerts.

As part of our decision-making process, we asked ourselves: What kind of device are people using to access this site? We decided that this application would need to be easy to use on a small screen. Before we even started this project and were throwing out ideas over email, Jeremy, Emily and I talked about the importance of mobile accessibility among our users. Jeremy said that for conference-goers, our site would be RODH: Responsive or it Didn’t Happen.

Responsive design isn’t as scary as it sounds. We used the responsive CSS framework from Twitter called Bootstrap, a template that made this app responsive with very little math. It’s built on a twelve-column grid that allows elements to stack as the page is shrunk. It will even scale your images if you put the right class in the image tag! Bootstrap also comes packed with code for other things we didn’t really use, like navigation bars, buttons, sidebars, banners and more.

Lessons Learned

To put it bluntly, this project was difficult. I’m relatively new to code having only been working with it for a year, but if I have learned anything, it’s that the best way to learn is to bite off more than you can chew. You probably won’t be able to complete the project in the way that you initially expect, but you’ll always walk away with new skills and a better understanding of whatever programming language you’re working in.

When I signed on to the ONA student newsroom this year and saw that Jeremy Bowers and Emily Chow — two people I’ve admired since I entered the field — were going to be in here with me, I knew that I could probably suggest a script to take us to the moon and they’d be willing to help. How often do you get to spend a weekend working side-by-side, learning and practicing your craft with your career idols? Not only that, but everyone else in your field is watching, too. No pressure.

Before I left for Atlanta, I was encouraged by my professors and peers to pitch something wild. I figured that the worst that could happen was that they could say no and give me something else to do. At the end of the day, even though what we built is almost nothing like what I had initially suggested, we ended up with something even cooler and more functional.

I asked for a lot of help throughout the making of the project. And I got it. I’ve found that sometimes, it’s better to be stubborn and trek through your project without having someone standing over your shoulder teaching you. Other times, when you’re on a tight deadline and you have resources available, don’t be afraid to ask for help.

Building things on the Internet, for me, is like running a marathon. While I’m doing it, it totally sucks. Everything hurts and there are highs and lows with few wins along the way. But when it’s done, I feel like the smartest, proudest programmer in the world. I don’t just finish projects, I win and conquer them.