After taking into account the scope of the project and estimating what aspects of ezTransit are within the realm of possibility for prototyping, the initial goals for the development cycle were outlined:
- Only train routes - no buses or ferries
- Scaleable vector graphics
- Replicate touch interface with click & drag interactivity
- Search by station function
- Functioning QR code generation and scanning
- Dynamic route tracing using vector graphics
- Functioning journey planning algorithm (as efficient as I can make it)
- Other aspects (responsive design, tablet functionality, Twitter feed, etc.) as time allows
Unfortunately, not all of the outlined goals were accomplished during prototyping (a cohesive checklist of complete and incomplete features is provided under the "Prototype" tab). Here are most of the problems which were encountered during development, and their subsequent effects on the outcome of the prototype:
- Perhaps the biggest problem encountered was the conundrum of accessing and storing Translink's timetable data. The initial goal was to utilise the publicly-available General Transit Feed Specification (GTFS) data linked from the official Translink website, but alternate avenues were examined first (including data scraping, iframes and XML filing) before finally formatting and importing the relevant GTFS data for a MySQL database. The prospect of using SQL databases and GTFS data was, at first, incredibly intimidating and caused a severe halt to development; but this approach ended up being deceptively simple.
- The second biggest problem was that because the prototype was using raw data from a MySQL databse, I had to create an algorithm which calculated journey plans based on the information supplied. This was a case of problem-solving, mathematics, and trial-and-error (especially for my novice experience with SQL querying). The algorithm still isn't 100% efficient or accurate, but it is - for the most part - functioning.
- One of the key features I wanted to implement in the prototype was dynamically tracing the journey plan on the map using a vector path. However, because the journey planning algorithm was of top priority, this aspect of the project was constantly being pushed back. Ultimately, the amount of time I had to prototype this feature was far outweighed by other tasks and the unfamiliarity with how to approach it.
- The search function could not be implemented either due to low priority compared to other tasks in addition to time constraints.
- Problems with styling across multiple browsers and devices occurred later in development. Certain elements have a tendency to become offset depending on the viewing platform.
- MySQL/phpMyAdmin - Storing GTFS data
- PHP - Querying database, calculating journey plan, displaying information within HTML
Images & Wireframes
Click the thumbnails below to see more.