Green Car Hawaii: Creating An Ipad App

» Posted by GusHiguera on Jun 7, 2010 in Dev | 1 comment

In the short time that I’ve been at Ikayzo I’ve been fortunate to have worked on some very exciting projects including designing several iPhone applications so when a local company called Green Car approached us about developing an iPad application I was very excited. Designing for the iPad I learned is very different than designing for the iPhone and it presented our team and I with several challenges. I thought I would share some our experiences and “lessons learned” in this article where I will focus on how we went from the client’s initial concept to identifying what the functionality of the application would include and how it would work.

The client

Green Car Hawaii is the first car-share service in Hawaii and the nation’s first aimed at tourists. Their concept is that rather than rent a vehicle for whole days or an entire visit, Green Car Hawaii customers only pay for the time they use it. They make reservations on the phone, online or at a kiosk using self-service technology. Green Car is not a membership program so there are no fees to join. Rates start at about $15 per hour and include gas and basic insurance.  As a bonus all vehicles also will also come with an iPad mounted on the dash that have a custom application installed that provides a map of the Kauai area with points of interest and activities listed for the traveler’s convenience — that’s where we came in.

I want an iPad app… where do we start?

The first thing we do with any client at Ikayzo, regardless of what they come to us for is talk with them about their project and identify all the possible solutions that will best meet their needs. In most cases that entails considering both technical implementations, budgetary and time contraints. In this case the client came to us with a very specific request to create an iPad application which made things a little easier us so to start what we did was create an “Application Requirements” document that identifies all the core functionality of the application and any add-on features that could possibly be added. This is a process I’ve been using for all our iPhone customers that has worked well and in this case was also very helpful. The key things we try to identify at this stage are:

1. What will the core-functionality of the app be?
2. How many screens/views will the app have?
3. What will each of the screens/view do?
4. What “add-on” features could we add to the core functionality of the app that could possibly enhance the user experience.
5. What data/server/hardware/technical requirements will be required to develop and support the app

Once these key items are identified, the items in the “Appplication Requirements” document are then discussed with the client to make sure all their needs/requests are met.  In the following section we’ll take a look at what we found for GreenCar in this process.

Okay, so what will the app do? Creating Our ‘Application Features Menu’

So after our initial meeting with the client we learned more about what they wanted their iPad application to do. Here is their list of  their initial requested functioninality:

1. Give rental car users immediate access to a map of the Kauai area
2. Map markers on the map in 5 categories using data from a local tourism service prodiver
3. Take advantage of the iPad platform to provide multimedia content in the form of video and website views for each location marked on the map
4. App should have a music player that will play music that will be loaded on the device
5. The app should serve as a prototype of what is possible with the iPad platform and function as a base for further application enhancements

With these requirements in mind I then created a list of views for the application and basic functionality for each view. Here’s a brief summary of what I came up with.

1. Map View – plot markers of locations on a Google Map
2. Map Markers Details View – will provide details for locations
3. Map List View – will provide a list view for locations for easy browsing
4. Search View – will provide a search field to find locations by name
5. Music Player View – a music player to play songs loaded on the device

As you can see, this app was shaping up to be very simple. The music player and search you could say are add-on features but the client identified these two things as items they definitely wanted in the first version of the app. The next step then was to identify several add-on features for the application which most of the time involves a brainstorming session with our team and lots of caffeine. Here’s what we came up with:

1. Universal app (iPhone/iPad)
2. GPS Geolocation
3. Advertisement support
4. Advanced search for locations
5. Localization
6. Social media integration (FB/Twitter)

How will the app work?

With all the core and add-on functionality requirements identified I then moved on to talk with our engineers to figure out how the heck we were going to do all this. This is very important because we don’t want to promise a feature that is technically impossible or is out of reach of the client’s budgetary and time constraints. Luckily, once again,  since this application was basically a prototype it was pretty straight forward. We determined that the iPad application would be comprised of two items:

1. Front end client in the form of an iPad app
2. Static data source served from an app server on the web in the form of a JSON file

Usually in this step  if the application requires a dynamic data source we create a much more detailed list/diagram of server requirements, data sources and web interfaces.

The result… I’ll take the special and a couple of sides to start.

So once we figured out what the GreenCar app would do and how it would do it I finished putting together our “Application Requirements” document and added in how long in terms of billable hours the core functionality and each “add-on” feature would take to finish. The result is that this document ends up looking like a dinner menu that has a main course (core functions) and side dishes(add-ons). The client then has a nice overview of what their application will cost and the time and resources involved in it’s creation and picks what they want to have for dinner.  It is noted to the client though that this is a very broad general view/estimate of their project and that once they give their approval to move foward this estimate/requirements document will be refined in more detail during the next phase of the project — the design phase.