Hacktucky event results in five new products made for Kentucky
This year, the Society For News Design hosted its first hackathon event in conjunction with the annual workshop. Organized by Chris Courtney, a developer for the Chicago Tribune apps team, the event shipped five new products that were created in just over 24 hours.
Meet the teams
Missy Wilson shares how it was made:
The first step was to figure out a problem that people in Louisville face. It took awhile to find one that also had associated and usable data we could dig into and start using. We also struggled a bit with localizing our project since none of us are from or especially familiar with the area.
We eventually wound up thinking about the river and how it could affect people here. We found live data feeds for the river level and could determine when a flood would occur, and we decided to use Safari alerts to reach people since floods are an issue people want to know about immediately. We also realized that Louisville sits in a seismic zone and faces a range of natural disasters, so we expanded the alert application idea past solely floods.
Yuri made an API that uses if statements to pull information from the current weather data online about various natural disasters, so other developers can use and access the information. If the field did not equal “There is no alert in Kentucky,” the API indicates that there is a disaster of that category. That information feeds into a dashboard that shows the current conditions and the four possible disasters we focused on — floods, earthquakes, severe weather and tornados. A blank circle appears if they’re not occuring, and a warning sign appears if they are.
We had to take the XML files and scrape the data in Code Runner to pull out the information we needed about each type of disaster by decoding it into the JSON format and drilling down into the categories to find what we needed. For earthquakes, we pulled the magnitude and location. For floods, we pulled the current river level and levels from the previous few hours. Those were some of the variables we used to make funcitons.
We used those functions and if statements to determine if the disaster is occuring. If, for example, the river level is above 23 ft, the flood alert template would be called upon.
The disaster categories are also assigned indications of how severe they are, so if there are multiple occuring, the most severe would be pulled and shown to users when they pull up the app.
In the end we didn’t have time to do the Safari notifications, but we implemented text notifications instead.
Diane Hawkins shares how it was made:
In the beginning, our team had to take several steps: brainstorming, identifying a problem, field research, planning and designing the website and the unveiling.
Step 1: Brainstorming The team agreed that we would design a passport system for Kentuckiana kids between ages 5 to 12. This system, which would use the same API mapping program as Foursquare, would allow kids to explore their hometown and collect stickers. Kids love stickers!
Step 2: Identifying a problem Kids need to learn about the amenities of their hometown.
LouPass is a website that is also mobile accessible, which will allow kids and parents to check into local attractions and be rewarded with a “badge of honor.” The site will help to make Louisville a fun place for families to explore and experience. This site is local, but it has the potential to be designed in other cities.
Children can earn a badge for each visit to the Louisville Zoo, Louisville Slugger, Frazier, Muhammad Ali and Speed Art museums. They will be able to create their accounts with existing accounts via Facebook and Twitter. This also is a fun way to introduce kids to using a passport. They will be able to download the stickers to print out or get from local venues.
We started with a base of popular sightseeing attractions such as Muhammad Ali Center, Kentucky Museum of Art and Craft, Joe Huber’s Family Farm & Restaurant, Louisville Slugger Museum & Factory, Belle of Louisville, Cave Hill Cemetery, Kentucky Derby Museum, Kentucky Science Center, Riverfront/Belvedere, the Parklands and Louisville Mega Cavern.
Step 3: Planning the site For the webpage, an API is needed to access the user information. The site would also give venue history and frequency. For example, if parents take their kids to the Ali Center once, they will be awarded a badge, which they will be able to print. The badge would give kids an incentive to support local communities and venues.
Step 4: Field Research The biggest challenge is to attract parents. They will be the ones who will check in at venues for their kids, unless children have access to smartphones or iPods. Most importantly, parents will be the ones who will encourage kids to learn at the facilities. They also will be mostly responsible for helping kids to collect the badges and record the check-ins.
We talked with a few parents and the Ali Center who seemed interested in the program. They, too, thought it was important to encourage kids to learn beyond video games and texting.
The appeal is that it’s a treasure hunt. Once the kids begin collecting the badges and wearing them to school, that will generate word of mouth. Kids can wear the buttons or badges on their book bags and post them to their laptops, lockers or jackets.
The venues would be encouraged to participate in the badge program and they could sell them for an additional .50 cents of the price. LouPass would be driving traffic to the family-friendly outlets.
On Saturday the team designed logos for each category: arts (easel), business (horse), sports (bat), civics (historic building) and culture (boxing gloves).
Each logo next to the category is the sticker/badge the kids will be able to collect. Rebecca programmed the site to make sure that users can print out the stickers.
Step 5. The Unveiling Larry and Daniel presented to the judges. The team agreed to hand out sample stickers to the judges and the audience at the unveiling, which was held at the Muhammad Ali Center.
Rick Epps shares how it was made:
The road to creating our Kentucky Bourbon Flight app started with lunch Friday at The Dish on Market. Our team members met each other in person for the first time, and once introductions were made, we got down to brainstorming. We talked briefly about some of the Louisville city information that was available on the local data portal.
The brainstorming conversation, however, quickly led to drinks, and what better drink to discuss sitting in a Louisville restaurant than bourbon. We decided that an audience exists for an app that could help people decide which bourbon best suits their taste.
We stumbled into a great resource when the waitress gave us each a book called “The Urban Bourbon Trail Passport.” It is a pocket-sized book that lists each restaurant in the area that serves bourbon, and where each distillery is located. This book provided a starting-off point for finding resources in order to get the information we need.
Once lunch ended, we went our separate ways before reuniting for the start of Hacktucky. Once Chris Courtney’s introductions were finished, our group began its 25 hours of hacking.
Zeke suggested that we talk through our purpose before we dive into writing any code. This idea was a wise one, as it helped us hone in on our content. We started by sketching our ideas on a white board. We identified the purpose of our app.
1.) We established who our target user is. This person is most likely a visitor to Louisville. Other potential users are people in town for racing, as well as for college students that have turned 21 and want to experience bourbon tasting or the first time.
2.) The user wants to determine which bourbon best suits his or her tastes. This includes which flavor they prefer, and what price they are able to pay.
3.) The user might travel to the nine distilleries in the area, or he or she might stay in Louisville and sample different bourbons at area restaurants.
We then narrowed down our focus for the app. We debated including directions to drive to each area distillery, and restaurant information. But we decided other sources already provide that information. So we turned our focus to helping users determine which bourbon they would like.
Users of the app will be presented a question about whether or not he or she likes a particular brand of bourbon. Their preferences are recorded, and a bourbon profile is created for the user. Two “yes” votes will direct the users to certain bourbons, while two “no” votes will direct them away from certain brands.
The time the user spends answering preference questions resembles the Pandora music listening experience, where the user gives songs they like or dislike a “thumbs up” or “thumbs down.” We think this gives the user a more enjoyable experience while providing the information needed to generate a bourbon profile.
Information about each brand of bourbon’s taste, aroma and finish was used to create recommended bourbon profiles for each user.
When it came time to do the heavy lifting, Zeke and Pattie wrote the code for our app. Alli provided the design architecture and graphics, while Rick helped with research gathering and organization.
In the end, we believe we have created an app that will enhance the user’s bourbon drinking experience. We have create a virtual taste test for bourbon.
You can see the app version of Kentucky Bourbon Flight on Alli Berry’s website.
Claire Lindsey shares how it was made:
To be in the city and not of the city provided the context for our approach to this challenge. What opportunities might we look for as visitors to Louisville? Frank, Adam, and myself asked ourselves not about problems or existing issues which we felt far away from, rather about the opportunities the city provided us with.
As a visitor to Louisville from places near and far, it seemed natural to wonder what historic resources the city had to offer. Kentucky itself has a wealth of historic resources, ranking 4th in the nation for the number of historic properties listed on the National Register of Historic Places. Naturally, Louisville is home to many of these properties, with around 400 nationally recognized historic places. With the allotted 24 hours to develop a website, our team decided to explore some of the many historic landmarks in the Derby City.
Historic preservation provided our team with an interesting lens to look at the City and one that residents can get equally interested in. Historic preservation programs have kept Louisville’s downtown vibrant, visitors entertained, and enhanced the character of the city as a whole.
The City of Louisville has made their public sector as open and transparent as possible; an increasingly popular governmental effort to nourish the minds of their citizens and visitors with information galore. In an effort to retain the City’s mission to share information and encourage exploration of the inner-workings of the City, we developed Historically Louisville.
Utilizing the City of Louisville’s Open Data Portal, we discovered just a piece of the information pie shared with the public. Our project referenced various national and federal datasets. In an effort to provide residents and visitors alike with an entertaining, and enriching website that introduces and educates
Meet the winner
Liz Spangler shares how it was made:
The team had an idea to create a website that not only provided local events and how to use the local bus system to get to them. The service would also send you a text message five minutes before you to need to walk out the door to be able to catch the bus on time. It’s meant to be a simple and spontaneous way to get to know the city, while increasing ridership on the not-so-oft used public transit system in Louisville.
The city recently released real-time GPS data for its bus system. We pulled that data an incorporated it with directions provided by Google Maps. This allows users to know exactly when the bus is coming, not just when it’s supposed to come, thus cutting down wasted time at bus stops.
The website is built responsively.
Ultimately, we produced a product that is truly useful to the people of Louisville. Despite having only one developer on our team, each of us learned a lot and contributed throughout the process.