Application Prototyping Tools

One of the big problems I always run into when designing apps is the flow between pages. I design the pages and then put them together. When I then put them together, I always find a couple places where the application flow just doesn’t work. What I need, among many, many other things, is a quick way to design the application flow and make sure it works correctly before I start putting a lot of work into the application. This is why I’ve developed an interest in application prototyping software.

I’ve used various application prototyping tools to do this. One that I did like was iRise. It allows you to quickly create pages with a  WYSIWYG editor. In addition, you can have a spreadsheet of data connected to the page via some simple logic. In addition, there is a clipboard to store data between pages. The biggest problems I’ve found with iRise (besides the price) is that even though it is a simplified view of the application, it still takes a few hours to a few days to create the pages and hook them together. Also, while the logic is fairly simple, it can be chained together to create some fairly detailed logic calculations. While this is nice at times, it can lead to spending more time creating some detailed logic than the situation really calls for.

What is needed at some times, such as when first discussing the project with a customer or business partner is a way to quickly throw some pages together and get buy in without spending a lot of time creating the pages and logic. This is POP (Prototyping on Paper). It’s an app (iOS currently) that takes pictures (either with the camera or from the photo library) and lets you take an area and make it a clickable button and link to another page. So you can quickly draw up basic screens on paper (or Paper or whiteboards) and then link them together for a quick and dirty application flow. It’s not useful if you’re looking for a complete list of fields on a form or are interested in the colors/fonts/layout. But as a first, initial step, this is a wonderful tool.

I’d be interested in seeing what other tools people have used for application prototyping. Are there some other tools out there that I should be looking at?

Problems with GTFS

Problems With GTFS

What is GTFS?

The General Transit Feed  Specification (GTFS) is a specification which “defines a common format for public transportation schedules and associated geographic information. GTFS “feeds” allow public transit agencies to publish their transit data and developers to write applications that consume that data in an interoperable way”. More specifically, GTFS is a set of files that give all the details about a transit system. You have the list of stations, the list of routes, the list of trips along each route, the stop times at each station along a trip and a calendar that details what days each route is active.

The Good of GTFS

The best part of GTFS is that it is a standard (of sorts) that is easily implementable for most (if not all) transit systems. So, anyone who’s interested can use the files to show the transit details for any transit system that has published the data. Some systems put the data out publicly. Some require you to sign up before getting the data, but it’s freely available in a standardized format. This has done a great job of making this data available to a wider set of people and, hopefully, making it easier to take public transportation.

The Problems with GTFS

There are a number of problems with GTFS. Some are inherent in the specification and some are part of the implementation from various agencies. So, let’s take a look at the different problems.

Specification issues

How many different ways can you specify what time a bus/light rail/train/etc stops at a station? According to GTFS, there are two. Either you can use the stop_times file, which lists the trip, the station and the arrival/departure times or you can use the frequency file. The frequency file uses the data from the stop_times file, except the actual times, and instead lists a frequency for each trip (hourly, etc) and uses the stop_times file to fill in the time difference between the different stops. I still have no idea why anyone would use the frequency file. You still need to fill out all (or most of) the data in the stop_times file, but you also need to fill out the frequency table. And when you’re trying to read the data, you have to always read the stop_times file, and then check to see if the frequency file is there for that trip as well. It makes the implementation a lot more complex for very little gain.

What stations are on a route? According to GTFS, the actual list of stops on a route (and the order of those stops) are only available in the stop_times file. This means that if you want to know just what stops are on a route, you need to look at the trips on each route and then look at the stop_times for each trip to get the list of stations on a route. However, there’s a catch, as always. Each trip has a stop sequence ID in the stop_times file. This is the enumeration of the order of stations on that trip. BUT, since a single trip on a route might not hit every station, you can’t just look at one trip to get the list of stations. Let’s look at an example with three stations (A, B, C) and three trips

Trip 1: A, C

Trip 2: A, B, C

Trip 3: A,C

So, we have three trips over three stations and station B is only used on 1 of the three trips. The stop sequence for A is (1,1,1), for B (2) and for C (2,3,2). The only trip that uses all three stations is Trip 2. But, there is no way to know that. So, you need to average the stop sequence of all the stations for the trips they appear on to determine what the correct list of stations (and their order) is. The averages of A ((1+1+1)/3), B(2/1) and C((2+3+2)/3) come out to A (1), B (2), C(2-1/3). This tells us that the correct list of stations (in the correct order) is A, B, C. But it’s a pain to do. You have to look at all the trips and all the stations and do calculations to determine this basic piece of data.

What days does each route run? Most, if not all, transit systems have different schedules on different days of the week. Some might have a weekdays and weekends schedule, others might do some routes only on specific days. The way to determine this in GTFS is the Calendar file. It has a start and end data and a list of days to mark which ones are active. This ties into the trip data to be able to say which trips take place on which days. But, as always it seems, GTFS leaves an out for a different way of specifying things. The calendar_dates files is generally used for holidays or out of service days. You can specify which days are exempt from the general schedule and what schedule to use instead. This lets transit systems say that even though Christmas is on Tuesday, the buses are running on a Sunday schedule. But, you can also put every single day into the calendar_dates file and completely ignore the calendar schedule. So, instead of saying, here’s the Monday schedule, you say here’s the schedule for December 31 2012 and here’s the schedule of Jan 1 2013 and so on for every single day. This turns a 3-5 line calendar file into a calendar_dates file with hundreds of lines.

Implementation issues

Implicit promises. Generally, if you see a field marked as an id (such as trip_id or route_id, etc.) it’s an implicit promise that it will be an integer field. Too many transit agencies start throwing letters and special characters into these fields which should be integers

Short duration. Generally, most transit schedules don’t change that often. Yet these agencies feel the need to send out files which only list the schedule for the next 3 months. And, often, they don’t send out the updated files until right before the three months are up (and too often they don’t send out the updates until AFTER the three months are over). What’s the problem with putting out a year of data at a time or a couple years. If you know something is going to change, then put it in the files. The problem comes when the end date in the calendar expires and the new files haven’t been sent out yet. Then, according to GTFS, there isn’t any service going on. An application that follows the specification will show that there is no service on those days, an outcome that isn’t good for anyone.

Finally

I don’t want to make it sound like I’m ungrateful for this bounty of free data being available for developers and users across the world. But we shouldn’t be willing to settle for good enough when there are clear ways to fix these issues. Standardize solutions, standardize fields (with types) and encourage longer duration files. These are simple things that will make GTFS more useful and easier to use for everyone.

Austin, Dallas and Hawaii

It’s been awhile since I’ve posted here. Ignore the dust and construction signs around here as I recently moved the site to a new host (and a new platform) and you’ll see some minor changes going on over the next few weeks as I finish up some last few tasks here.

Since I last posted here, I release three new apps on the iOS platform, Hawaii Transit, Dallas Transit and Austin Transit. I’ve also updated the paid version of the iOS Phoenix Transit app with bus data (not just light rail any more). The free iOS app and both Android apps will be updated soon. All the iOS apps will not only be updated with the latest light rail and bus data, but with support for the new iPhone 5 screen size.

We’re planning on rolling out some more apps this year, some transit and some non-transit. So keep your eyes open. And let us know if there is anything you’d like to see added to our existing apps.

Happy Holidays (whatever Holidays you celebrate) and have a great New Year.

Free (with ads) or paid apps

I assume most people have seen the study from a couple months ago about mobile ads. Research has shown that while ad supported apps are usually free, you can’t get away from basic economics. The ads themselves have been shown to severely impact battery usage and cause the phone to run out of battery much sooner. While, I don’t want to force people to pay for data if they don’t wish to, I do want to give people who value battery life an option. Well, actually two options.

First there is the paid versions of the Phoenix Light Rail Timetable (iTunes and Android). This removes ads and lets you save your battery for more important things.

Second the iPhone free app has an in-app purchase to allow you to remove ads. Don’t worry Android folks, I’m working on the in-app purchase for Android devices as well.

So, it’s up to you now. Free app or longer battery life. It’s yours to choose.

Bug Fixes

I’ve fixed a few bugs in both versions of the app recently and just wanted to point out what was fixed. Please let me know if you find any other issues, so that I can address them.

iPhone version 1.1
- Displayed both East and West Bound times when you are looking at a Route. Fixed to display just the correct one

iPhone version 1.2
- Fixed error with the Station information about whether there is a Park  & Ride or Transit Center at that station. A coding bug made it look like both are at every station
- Added Spanish Language support.

Android version 1.2
- Fixed bug that crashed the app when you looked at a station between midnight and 5am on Sunday mornings.

iPhone App Release

Sorry, about the delay, but our iPhone version of the Phoenix Light Rail Timetable is now available in the App Store. Enjoy and let us know if there is anything else we can do for you.

Android app release

Aleody is proud to announce the release our first app. Phoenix Light Rail Timetable is now active in the Android market. Free of charge, you can find the time and stations for the Phoenix Metro Light Rail.

Android Market
Mobile Link

Go to top