Developing for mobile: I thought I was screwed

Jul 18 2012

“Mobile first” … “Mobile first” … “Mobile first” …

This is the phrase that Executive Director John Clark pounded into our heads since day one of, a news site about North Carolina politics that is designed for mobile users. In fact, I occasionally hear John’s voice in my sleep, enthusiastically chanting “mobile first.”

Weird dreams aside, the phrase is vital to our project, especially in terms of the website’s design and content. Last week I, along with designer Colleen McEnaney, developed an interactive tool that allows users to enter their loan amount, interest rate and the term of the loan. The tool tells the user exactly how much money he or she will owe, translating that number into products familiar to college students. For example, if I had a loan for $10,000 at an interest rate of 5 percent and had 10 years to pay it back, I would end up paying $12,728 – or 6,364 PBRs. Crazy, right?

The idea behind this interactive is to highlight a serious issue – the true cost of college and the potential burden on the student – through a comical, personal lens. I will be the first to admit that I have consumed at least one meal that consisted of PBR and Ramen, and I am not ashamed. College students, current, future or past, can use this tool and see just how screwed they are in terms of PBR, Cook Out trays, toilet paper and, possibly the most essential, Ramen noodles.

Now, how did we take a mobile-first approach with this project, you might ask? Well, we really focused on how a mobile user would provide the necessary input to gather the desired output. In the newsroom, the consensus seemed to be that we all hate typing on our mobile devices (mostly iPhones). So, we decided to go with drop-down menus that provide the user with a specific number of options. This was optimal for two reasons: 1) it is easy and intuitive for the users and 2) it prevents the users from having to worry about the specifics of the input, like needing a number (not a word) or the specifics of their personal loans.

Also in a mobile-first mindset, the calculator provides the users with a menu that allows them to pick between the metrics, whether they want the output in terms of PBRs or Cook Out trays. Originally, we envisioned this feature as a set of tabs. However, personal experience told us that users do not like tabs, especially in a mobile environment. Thus, we designed the menu that is always visible and quickly allows the user to switch between metrics.

This project was a personal challenge because I normally design for the Web, not develop. However, in the absence of our beloved programmer Tony Mantovani, who was out of town, I accepted the challenge. With little javascript experience from a class taken two years ago, I started with Google. After aimlessly scouring the Internet for a few hours, I decided to stroll through memory lane and revisit my old Comp 110 projects, where Colleen discovered I had already developed a foundation for our current project, a mortgage calculator. While it didn’t tell tell the user how much he or she would pay over time, it did use the same three variables (the loan amount, rate and term of the loan) to determine monthly payments. After playing with this code and learning some new code, I finally have it producing PBRs when the total amount is calculated. Check it out.

P.S. We are working on a redesign of the website, so check back often for updates and be sure to write on our wall, Tweet at us or email us if you have any suggestions or feedback!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.