![\"](\"https:\/\/wapreview.com\/images\/nextBus5.gif\")
![\"](\"https:\/\/wapreview.com\/images\/nextBus1.gif\")
NextBus<\/strong> is an Alameda, California supplier of real time passenger information technology to the transit industry. The technology delivers frequently updated estimates of the arrival time of the next transit vehicle at a given stop. Delivery is by electronic signs, voice response systems and the Internet including the mobile web. NextBus is currently operational on 28 transit systems spread across 13 states.<\/p>\nNextBus and the other three systems reviewed have neat map-based web interfaces, with little moving bus images and roll-over bubbles calling out the names of the stops and predicted arrival times. These interfaces are fun to play with but require a computer. To me, a mobile phone interface that I can actually use out on the streets when I’m taking transit, is the truly powerful, enabling way to deliver this technology. All four reviewed systems provide a mobile interface.<\/p>\n
NextBus’ real time transit information can be accessed at http:\/\/www.nextbus.com<\/a>. If a wml capable browser is detected, a WAP1 version of the site is shown, otherwise a desktop web page appears. There is also a PDA version at http:\/\/www.nextbus.com\/wireless\/miniRegion.shtml<\/a> I find that NextBus works very well for my commute on the MUNI<\/a> in San Francisco. I have a choice of taking a bus that stops two blocks from my house or a streetcar three blocks away. The streetcar is covered by NextBus but the bus is not. Both lines supposedly run every twenty minutes but in reality are rarely on time. As I leave my house, I check the streetcar on NextBus and if there is one coming in between 5 and 15 minutes I head down to the streetcar stop and catch it, otherwise I take my chances with the bus. It is very reassuring to know exactly when the streetcar will arrive. The accuracy of NextBus is uncanny. When NextBus says the streetcar will arrive in one minute, I can always see it down the tracks a block or two away.<\/p>\n The only bad thing about NextBus and MUNI is that only 10 of the agency’s 86 lines are covered. Cost is obviously a factor. Each vehicle needs a GPS receiver and radio transmitter and of course there is the expense of the software and web hosting. An approximate idea of the cost can be gleaned from this public document (pdf)<\/a> which shows that it will cost AC-Transit, another San Francisco Bay Area agency about $1 million for equipment, implementation and seven years of operating expenses for a NextBus system covering 199 buses on 25 routes including 44 electronic signs along with mobile and web access.<\/p>\n Content: NextBus: wml<\/a> PDA html<\/a><\/p>\n Both Wheels and PACE seem to have implemented WebWatch on all their lines so it has the potential to be really useful if the reliability issues with Wheels at least were resolved.<\/p>\n Content: Wheels: html<\/a> PACE: html<\/a><\/p>\n Content: Transit Tracker: wml<\/a> PDA html<\/a><\/p>\n Content: MyBus: wml<\/a> PDA html<\/a><\/p>\n Real-time transit information is a natural for mobile use. I see these types of sites becoming very popular – to the point that eventually all transit systems will be expected to provide them. In addition, I believe that accurate mobile indication of transit arrival and departure times will drive increased transit use by making using transit more predictable.<\/p>\n","protected":false},"excerpt":{"rendered":" In Japan, where the mobile web is much more widely used than in the US and Europe, real-time transit tracking is a very popular web based mobile application. If you use public transit it’s easy to see why. I’m sure you have had the experience of waiting and waiting for a bus and wondering if it will even come. Mobile access to real-time transit arrival and departure information has actually been possible in some US cities for several years. Recently, … Continue reading
\nwhich works acceptably on most WAP2 devices. The content of the WAP1 and PDA sites appears to be essentially identical. Both mobile sites work well although the UI could be improved; there is too much drill down required to the actual real-time information. First you pick the State, then the transit agency, then the transit line, then the direction and finally the stop that you want times for. The stops are displayed as one long list for each line with no way to jump to a particular part of the list. Once you find your stop, bookmark it so you can get back to it without repeating the drilldown. On the positive side, I do like that NextBus tells you in how many minutes<\/em> the next bus will arrive, along with the current time. The other systems tell you at what time<\/em> the next vehicle will arrive, which assumes that your watch is synchronized with the informations system’s time base. Several of the other systems don’t even tell you the current time. I realize that all mobile phones have a real time clock, but checking it generally requires getting out of the browser and there is no guarantee that the phone and tracking system’s clocks are in sync.<\/p>\n![\"*\"](\"https:\/\/wapreview.com\/images\/blue-star.gif\")
Usability: ![\"*\"](\"https:\/\/wapreview.com\/images\/red-star.gif\")
<\/p>\n![\"](\"https:\/\/wapreview.com\/images\/Pace2.jpg\")
![\"](\"https:\/\/wapreview.com\/images\/Pace1.jpg\")
WebWatch<\/a><\/strong> is part of a product called TransitMaster™ from Siemens VDO. I have the opportunity to test WebWatch at the other end of my commute where I ride a bus operated by a suburban transit agency, the Livermore Amador Valley Transit Authority (LAVTA) – better known as Wheels<\/a><\/em>. TransitMaster is a an on board computerized system which provides real-time location information that is used to make automated announcements of upcoming stops and update a bus dispatching system as well as feeding the WebWatch online system. Wheels has implemented WebWatch on all 35 of its routes. The WebWatch map-based interface<\/a> requires Adobe’s free SVG viewer which only seems to work on Internet Explorer and the ancient Netscape 4. There is also a text-based desktop version which should work on most browsers although it’s not mobile friendly and requires Javascript. Siemens’s site claims that WebWatch supports mobile browsers, but I could not find a true mobile version for either Wheels or another WebWatch system at Chicago’s PACE<\/a> suburban bus system. However both PACE and Wheels have a text-only “ADA” version of WebWatch which works reasonably well on html capable phones as well as on WAP1 phones using the YesWap transcoder. I don’t have any experience with the PACE system, but I’ve been disappointed with Wheels’ WebWatch. Frequently it claims “No stops found with upcoming crossings” for all stops on all lines even though there are buses running, and in fact the little bus images still move around on the map. Of course the map isn’t available on the ADA\/mobile site – only on PC’s running IE. Another problem with the system is that the times it shows are sometimes inaccurate. I was waiting at a stop last week and WebWatch claimed the bus was there five minutes before it actually arrived. I don’t understand why the text arrival information is wrong as the automated announcements on the buses occur just before the stop as they should and are controlled by the same system. As near as I can tell the moving buses on the map are in the right places too, it’s just the text based arrival information that’s off – strange. Another issue with Wheels is that while it shows the current time on the screen, the time shown is consistently five minutes fast. In the case where my bus was late, WebWatch said the bus would arrive at 5:54 PM. The bus arrived at 5:59 by my watch which I had set to a NIST time service earlier the same day. By the time the bus arrived, WebWatch claimed it was 6:04<\/p>\n Usability: <\/p>\n![\"](\"https:\/\/wapreview.com\/images\/TransitTracker2.gif\"){kind=tracking}
![\"](\"https:\/\/wapreview.com\/images\/TransitTracker1.gif\"){kind=tracking}
Transit Tracker<\/strong> was developed in house by Portland Oregon’s TriMet<\/a> transit agency. Here is a document (pdf)<\/a> with which describes the project in considerable detail. Transit Tracker, which covers almost all of TriMet’s close to 100 routes, has a WAP1 wml version and a PDA html version that is also usable on WAP2 phones. This is a very nicely implemented mobile site. TriMet’s designers obviously were serious about creating a usable site. For one, instead of a long scrolling list of all the stops on a line, like NextBus and WebWatch, Transit Tracker divides the stops into groups (see first image for an example). Instead on 50 stops in a list that is a pain to scroll though on most phones, you first pick the general location of your stop from a short list of ten or so. Next you see another short list of the stops in that area. Another way to specify a stop is by entering a Stop Number<\/em>. The only problem I see with stop numbers is that you have to find out the number in the first place and then remember it. TriMet provides a number of ways <\/a>to find stop numbers both on the phone and on the web. To me an ideal place for stop numbers would be on signs at the stops but the TriMet web site doesn’t give any indication of this. TriMet is one of the systems that tells you when you bus will come but doesn’t show the current time.<\/p>\n Usability: <\/p>\n![\"](\"https:\/\/wapreview.com\/images\/MyBus3.gif\")
![\"](\"https:\/\/wapreview.com\/images\/MyBus2.gif\")
MyBus<\/strong> is used by Seattle Washington’s King County Metro<\/a>. The system was developed by the Intelligent Transportation Systems Research Program<\/a> at the University of Washington. MyBus’ slogan is “providing travelers with real-time transit information and making transit cool<\/em>“. The MyBus system is quite similar to Portland’s Transit Tracker in that it’s primary interface uses stop numbers. There is another interface of scrolling lists of bus stops hidden under the Help<\/em> menu. MyBus’ results page conveys quite a bit of information using very little screen real estate. This is visible in the last image. The title “5S, JAXN, 36” means 5th Ave. South at Jackson, Line 36. That’s a little cryptic for my taste but I suspect that regular users find it understandable. The rest of the screen lists bus arrivals at that stop by final destination (BeacnHil, Downtown…) and time. The “d” instead of a colon in two of the times indicates that the bus has d<\/strong>eparted. I can see where if you miss a bus it’s useful to know how much you missed it by. This feature would be even more useful if the screen showed the time when MyBus updated the screen. The screen shot doesn’t show it but MyBus indicates express buses with an “e” in front of the destination name. If MyBus doesn’t have location information for a particular bus, the colon in that trip’s times is replaced by an asterisk indicating an estimate. I like MyBus, it is a powerful interface that is quick to use but has a slightly geeky aspect to it that may put off non-technical users. Nowhere is this more evident than if you enter a non existent line or stop number, MyBus responds with a generic 404 error screen, hardly user friendly error reporting. Still I have to give Metro Kings Country and the University of Washington credit for implementing a powerful real-time information system on all lines of this large urban system. Incidentally, MyBus was recently renamed Tracker – although the mobile pages still refer to it as MyBus.<\/p>\n Usability: <\/p>\n