UI Roadmap

Kurt Raschke edited this page Nov 1, 2013 · 10 revisions

As documented in the Roadmap, the intention is to replace the existing OneBusAway UI with the OBANYC UI.

This involves two major areas of work:

  • adapting the OneBusAway TransitDataService to support the methods required by the OBANYC UI
  • making the OBANYC UI usable for generic deployment

The first part is not terribly difficult; there are only five additional methods to support, and most of them can be implemented simply by copying code from the respective OBANYC implementation. This work has been undertaken in the kurtraschke/onebusaway-application-modules repository, on the 'obanyc-compat' branch.

The much larger task is making the OBANYC user interface suitable for generic deployment.

The onebusaway-nyc-acta-webapp overlay webapp is the starting point for generic deployment; it has a stripped-down user interface which only superficially resembles the MTA branding (that is, all of the MTA-specific headers, body copy, etc. has been removed).

Other issues:

  • All vehicles are treated as buses: camsys/onebusaway-nyc#5
    • Add an extension field to the SIRI VM response which includes the vehicle type (inferred from the route presently being served by the vehicle). We will also need icons for the other modes; since we are using the AIGA bus, we may as well use the rest of the AIGA symbol signs, at least for the modes they cover. Ideally we would end up with icons for all eight of the GTFS route types.
  • stop_id and stop_code are assumed to be the same: camsys/onebusaway-nyc#6
    • Not hard to fix (fixed already but not committed?).
    • We want to display stop_code if it is available, but fall back to stop_id if necessary. This is the existing behavior of the getCode() method.
  • Agency names are not displayed: camsys/onebusaway-nyc#8
    • Work in progress to fix.
  • All routes are assumed to have both a route_short_name and a route_long_name (while the GTFS spec only requires one or the other)
    • This is easier to work around than fix, for now; if a route doesn't have a short name (or a long name), run the feed through the GTFS transformer and patch it there.
    • There are places in the UI where we really need a short name in order for it to fit; it may not be worth trying to make the short name and long name interchangeable.
  • Five-digit stop codes (exact match) mask ZIP code results from the geocoder.
    • The existing data structure does not let us return both an exact stop match and a geocoder suggestion to the UI; not feasible to fix.
  • Non-realtime arrivals not displayed in the UI or exposed in the SIRI API.
    • This is a contentious issue, but in any event the behavior of the legacy OBA UI is to show scheduled arrivals when realtime data are not available. Some agencies may not be able to deploy AVL any time soon, and for them we need to offer a configurable option to show scheduled arrivals in the UI. There is a rough implementation of this in kurtraschke/onebusaway-nyc#421d0c
  • Geocoder for OBANYC mobile UI
    • The OBANYC webapp uses the same geocoder implementation for the desktop and mobile user interfaces. This poses a problem for users who intend to use the Google Maps geocoder (without an enterprise Maps license), because it can't be used for the mobile UI (where results are not displayed on a map), but there's no way (currently) to specify distinct geocoder implementations for each UI.
  • SMS text in desktop UI
    • The SMS shortcode is now configurable, but some deployments may not be using SMS at all, so the whole thing needs to be configurable.