Posts about Technology

Airbnb, for example, lets you rent out your apartment when you're not there for extra cash, and makes it possible to find a much more affordable place to stay in busy cities where there aren't that many hotel rooms.

Regulations, however, often don't really account for individuals renting out their own stuff. They usually assume that anyone providing such services is a company that does so as its business, and can undergo inspections, file for permits, and so on. Plus, these regulatory processes try to ensure that the products are safe and healthy, that nobody's getting scammed, and so on.

The new-style collaborative consumption startups are solving the consumer protection problem in a bottom-up, social-media way: people rate buyers and sellers, and a strong reputation replaces a regulator's review. This is what eBay did to give people confidence in buying things from strangers instead of from stores or established catalog companies.

There are the occasional horror stories, but then, regulators miss things, too. But Airbnb is illegal in most cities, and some cities are cracking down, often at the behest of the hotel industry or neighbors who don't like strangers coming and going. Mainly the transactions happen outside the law's blessing, it's making buyers and sellers happy, not causing a lot of trouble, and eventually cities will probably adjust laws to come to terms with it.

What does this mean for ride sharing? Taxi rides are a particularly heavily-regulated area, with powerful driver lobbies that want to restrict the supply of rides. They weren't happy about Uber, and really won't be happy with ride sharing.

Plus, regulators have some legitimate fears. Cars can be really dangerous. Is it important to give people assurance they're riding in a safe one? You're under the physical control of another person. How can we be sure that person isn't going to do bad things? A woman has accused an Uber driver of raping her; police investigated, but prosecutors aren't pressing charges.

Are these roles the government should play? With Uber, many people argued that regulators ought to ensure the driver is well trained, properly licensed, and not a threat. They should ensure the car is safe and well-maintained. But don't regulate the prices, since people can choose to ride Uber or not and don't need the government to decide how much it should cost.

Now, ride sharing companies are essentially trying to take the next step. Must the drivers all have commercial licenses and commercial vehicles? Or can we let anyone sign up to give others rides? Can the companies, like SideCar, self-regulate?

Certainly it's in SideCar's, and Airbnb's, and Uber's interest to be sure everyone is safe. SideCar has extensive safety information on its site. One theory is that these companies will make sure it's safe, or else go out of business. After all, it's easy to spread a bad experience on Twitter, so even a small number of problems could earn the company a bad reputation.

The DC Taxicab Commission isn't ready to embrace this. Having just created regulations for sedan drivers that regulate much less than they are used to, they'll need more outside pressure if they're going to let ridesharing get an even lighter regulatory touch. And should they?

I've often watched DC Department of Public Works (DPW) employees in the morning picking up trash in the alley. There are two guys riding on the back of the truck and one driver. Once in the alley, the two employees who jump off the back of the truck methodically empty the supercans into the truck, while the driver slowly trundles the truck down the alley.

What if the driver had a dash-mounted tablet with a program similar to the one the BID workers have? Perhaps he could quickly note things like illegally dumped furniture, potholes, or broken supercan lids.

With a program like the one the BID has, these DPW employees could be an early-warning system for the department, hitting a button to record the location of any of these issues that DPW would have to deal with. It seems like this could be an efficient way to asses problems that the department would need to deal with anyway. The increased workload could be connected to a bonus system of sorts. Drivers that find the most legitimate problems that need to be addressed could receive a commensurate pay increase.

In addition, perhaps some of the features in this program could filter down to the DC311 app in a future update.

This is actually a problem I hear often. A family friend moved to DC a couple of years ago, for a job at PriceWaterhouseCoopers in Tysons. The Silver Line was still a few years off, but he wanted to live in a vibrant, urban neighborhood. Where should he go?

The bus maps are daunting to decipher. It took me a couple of hours to really puzzle through the combinations and cross-reference it with my general knowledge of housing prices in various neighborhoods.

Boston-based AutNo tries to help by putting rental listings and trip planning together in one interface. You can view available rentals (it doesn't have places for sale, yet), click on one, and see transit directions to your office or another location you specify.

The about page reads:

AutNo is the first apartment search designed and developed specifically for people without cars. For the first time since the automobile was invented, the percentage of Americans who drive to school or work is on the decline. Gas prices are skyrocketing and automobile carbon emissions are contributing to global warming. Commuting and living without an automobile is the way of the future for many people. AutNo is dedicated to helping these people find apartments.

It will also show driving routes to work, too, if you want them.

You can narrow down results by price and number of bedrooms. A future feature that would be helpful is to also let people restrict the searches by travel time. That way, you could say that you want a place under $2,000 a month that's no more than a 45 minute trip to work, or whatever.

Basically, combine this with Mapnificent:

And, at the risk of sounding like a broken record: this is why open data is valuable. A transit agency might build a great app, but they're never going to build a mash-up of real estate data and transit data. When it's easy to put transit routing into an app, you not only can build apps that give people transit routing, but tools and apps that combine transit routing with almost anything else.

Update: I hadn't know it, but WalkScore actually has this exact Mapnificent-style feature. You can filter apartment listings by transit distance to a point:

However, when you click on an apartment, WalkScore does not show you the transit routing with trains and buses you would take, while AutNo does. Without that information, people won't as easily learn which buses might work best for them or be able to judge whether a location is really likely as acessible from transit as the system says.

It would be best to have both at once on the same site; as it is now, I'd recommend that people use a combination of both tools for their search.

This is obviously frustrating to infrequent riders who load up funds ahead of time for when they ride, or use automatic loading to ensure their card is never low on funds. But the automatic or remote loading may not work.

This happens because of the way the (fairly outdated) SmarTrip system works. When you add funds to your SmarTrip card online or automatically, the funds don't appear in your Smartrip account immediately because your balance is actually stored encrypted on the card rather than on a computer.

Adding funds online sends an instruction to the SmarTrip system to watch for your card. The next time a faregate or bus farebox reads your card, it will have information about what you added, and will load the funds onto your card.

The load instructions get copied to faregates and bus fareboxes throughout the system, but because these machines are not in constant communication (like bus fareboxes), it may take several days for the instructions to reach a farebox you use.

But Barbara waited more than a few days. What happened? She wrote:

I called SmarTrip, and they didn't have a plausible explanation: All I learned was that this could happen "with infrequent use of the card." What the heck does that mean? It shouldn't matter how frequently I use the card—it's my money on there, it's just not in my bank any longer, it's on their card!

Here's what's going on. The faregates have their list of SmarTrip cards that are waiting for new funds already loaded online. Unfortunately, the outdated faregates have limited computer memory (that fact restricted peak-of-the-peak, for example). They can only store so many load instructions.

Spokesperson Dan Stessel said:

Each target [the SmarTrip computer system in the faregates] can hold a maximum of 85,000 auto loads. When that number is exceeded, the system has to localize, meaning the system will send your auto load purchase to every station you've used in the past month.

Furthermore, based on the SmarTrip customer service response, it sounds like if you load online but then don't use the system soon after, newer load instructions may crowd yours out.

Either the Ballston gate had the instruction and Foggy Bottom did not. (Barbara said that she lives in Arlington, so Ballston is probably the station she uses most.) Alternately, once Barbara loaded her card at a machine and then entered the rail system, the central system retransmitted her load instruction to the faregates. Then when she exited, the gate at Ballston knew to add her funds.

This whole mechanism of getting the load instruction onto the faregates ahead of time is fairly messy. It would be better if, when you went onto the system, the faregate could just check your balance with a central server, but the faregates don't have a high-speed, always-on connection to a central server to accomplish this.

WMATA is studying new fare payment systems. Any new system ought to fix this irritating problem, but it may be quite some time before a new system actually comes on line.

Meanwhile, it might make sense for more infrequent riders to use the vending machines, especially if they let their cards get very low.

UberTaxi

I've recently been trying out Uber's new UberTaxi service, which calls regular taxis rather than black car sedans. You can see how far away the nearest taxis are from the app, and easily request one.

The best elements of Uber's service are that the cabs are in very good shape, compared to many DC cabs, and when you get to your destination, you just step out without worrying about money at all. Uber emails a ride receipt with a map of your trip so you can be sure you weren't swindled.

I've used it 3 times, from home to a destination downtown, then back from downtown, and another late night from an area near downtown. Even though I could have often walked a few blocks to find a cab, using Uber the cab came right to me; only one time did the cab have any trouble, when I was at the Wilson Building (1350 Pennsylvania Avenue) and he had to call to figure out which side of the building I was on. But he was easily able to call, so the Uber system clearly makes it simple to work out these kinds of confusions.

Uber charges an automatic 20% tip, though one driver I spoke to said Uber keeps all of that as their fee. Update: Erik Weber (now working for Uber) says this is incorrect, and 100% of the tip goes to the driver (though the driver does pay Uber an undisclosed amount).

UberTaxi is only available inside DC right now, while its original black cars can pick people up in the suburbs. There seems to be little reason not to pick the taxi mode over the sedan mode, unless you really want extra luxury or there aren't taxis around. (For example, on a recent trip to Uber's home of San Francisco, coming back to the hotel from the ballpark neighborhood, there were sedans but no taxis.)

Taxi Magic

When I need a taxi to National Airport, I've been using Taxi Magic, which lets you request a DC Yellow Cab, Arlington Red Top, Montgomery Barwood, or Alexandria Yellow Cab. You can also pay by credit card, though you take the step of paying from the cab (or pay the driver directly).

My experiences with DC Yellow Cabs via Taxi Magic were not so great, so I've been calling Red Tops instead, which work fine. Taxi Magic lets you request a cab for a time in the future, which is good for airport rides. The one thing that could be better is that when the taxi arrives ahead of time, as it often does (that's a good thing), the system calls you and you can press a key to tell the cab you're on your way out. But if the cab is 15 minutes early, it'll just keep calling every couple minutes.

myTaxi

myTaxi launched late last year; it is affiliated with car2go and has been doing cross-promotions for people to use both services.

I started to download the app but am uncomfortable with the fact that on Android, it wants access to all of my contacts. Android has dealt with security by making apps disclose which permissions they need, and you can choose to download the app or not. Unfortunately, a lot of apps need some fairly intrusive-seeming permissions for minor features of the app that you might never use.

There's no way to decline just one permission (and if you could, it might crash the apps unless developers always accounted for that possibility) and app developers don't have much incentive to provide a core app with few permissions and then separate add-ons you can download.

Have you tried myTaxi? What about Uber, Taxi Magic, or something else? How has the experience worked for you?

Most of the panels aren't DC-specific or focus more on national politics, but at least one looks at what's going on in our local community. "Digital District" brings together Ghosts of DC founder Tom Cochran, ANC commissioner and prolific tweeter Tiffany Bridge, Brandon Jenkins of Fundrise, Greater Greater Washington's David Alpert, and John Lisle, who recently left his post as DDOT's communication head to join DC Water. The panel is 4-6 pm on Thursday, February 20 at LivingSocial, 918 F Street, NW and will also be streamed online.

On Friday, check out "Ping My Ride: How Mobile Apps Transform Urban Living." Mark Berman of the Washington Post will moderate a panel of people from Uber, Waze, Capital Bikeshare, Parkmobile, and Parking Panda. Besides apps, the panelists will discuss open data and how sharing services are working in DC. The panel is 2-3 pm at Ogilvy, 1111 19th Street NW, or you can watch live online.

The Anacostia Watershed Society's Green Roof Networking Happy Hour is next Tuesday, February 26, 5:30-7:30 pm at Boundary Stone Public House, 116 Rhode Island Avenue NW. Environmentalists, LEED professionals, and anyone else interested can talk about sustainable development in DC.

Finally, only 2 weeks remain until the Greater Greater Wasington 5th birthday. We turned 5 on February 5, but that was the same night as the State of the District speech, so we're celebrating on our 5 year, 1 month birthday. The party is at the Woolly Mammoth Theatre Company, 641 D Street, NW from 6-10 pm on March 5. Hope you can make it!

Since NextBus is most common, some residents asked Montgomery County officials why RideOn is not part of NextBus, too. One was Evan Glass, who tweeted last May:

Note that Glass was talking about the "NextBus DC" app, the one that died this past December and, people discovered, actually wasn't from the same company as the one that provides bus prediction services to many transit agencies.

Councilmember Hans Riemer passed the question on to Ride On officials. Carolyn Biggins replied:

Recently, our staff met with a representative of NextBus to discuss products and costs. Although NextBus has not yet given Montgomery County a firm price quote, they offered a ballpark figure of approximately $55,000 per year for operating costs. This would cover a barebones system which would only have their mobile and desktop web site along with a suite of management tools. There are also undetermined setup fees, probably starting around $15,000 but possibly much higher. ...

At this point the inclusion of NextBus into the Ride On Real Time customer information product line is actively open for discussion. Feedback from our customers and industry critics point us in various directions and toward various apps; and, interestingly, NextBus is not at the top of our customer's request list.

Besides our Eastbanc/Nerds Ride On Real Time App (available for iPhone and android) which, by the way, includes integrated real time data from Metrobus, Metrorail and several Northern Virginia jurisdictions, our customers have asked us to integrate into the "DC Metro Transit App" and "OneBusAway."

We have been working with developers for DC Metro Transit App who recently responded to us with a very encouraging post about our open data: "This seems well thought out and documented. It is also nice that you can get the data in both JSON or XML [the 2 most popular formats for getting data from APIs] in a restful service [basically, a way of making APIs easier for the app developer to use]. I'll give it a try in the app and let you know if I have any questions. You guys are ahead of the curve compared to other agencies."

As you mentioned in your recent e-letter, Open Data and public/private initiatives, such as 3rd party app development, is the wave of the future—to "disrupt and create." 3rd party app development not only unleashes the initiative of the private sector but also provides varied choices for our citizens: the delivery of information in many different formats to suit different consumers with varied needs and tastes.

In developing our Ride On Real Time system, Transit Services has taken this approach, both through internal product development but also by providing its data in as many different formats as possible while trying to maintain fiscal responsibility. We will continue to work with NextBus and other vendors to try and provide Montgomery County citizens the very best in transit information and customer service.

(Notes in brackets added.)

Biggins is right. The solution to the problem of Ride On not being part of many existing apps is not to work with any particular vendor, but to provide open data in more formats.

It's particularly good to hear this from Ride On, because at first they did it wrong, and contracted with a software developer just to build them a website where people can track buses, but with no way for 3rd party app developers (in other words, people who aren't the agency or one of its contractors) to access the data.

Following prodding from Kurt Raschke, us, and others, Ride On started offering an API, and even fairly quickly improved it based on feedback from Raschke and other developers.

Why doesn't everyone just use GTFS?

In the area of transit schedules, one standard has largely emerged as the most common, and one all transit agencies ought to offer: the General Transit Feed Specification, or GTFS. GTFS is basically a set of big files that contain every single stop location and all of the schedules for the transit system. You can download it, write code to analyze it, and then do whatever you want.

There's an analogue of GTFS for real-time buses, called GTFS-realtime. However, real-time is not the same as schedules. With schedules, you can download the whole thing once and it basically won't change except every few months. With real-time bus tracking, the positions change every minute.

GTFS-realtime lets you download the entire set of bus positions as they constantly change. It's a huge amount of data. For some applications, like if you're making a live map showing buses, that's what you want. For the typical smartphone app, where you just want one bus position at a time, it's too much. That much data would overtax the user's data plan and burden the phone trying to deal with it all.

Other APIs, like the NextBus and WMATA APIs, work differently. For those, an app sends it only the very specific question it wants answered, like asking for next arrivals at a particular bus stop.

Twitter, as an analogy, has both types of APIs. For most uses, you use a more transactional API. You ask Twitter for a list of recent tweets matching a hashtag, or ask it to post a specific tweet. But Twitter also offers a "firehose" API where certain users, who have to be approved ahead of time, can get the entire stream of all tweets, everywhere.

We need GTFS-realtime AND a transactional API

Ultimately, for transit, there needs to be both. If you're building a smartphone app, it's too hard to get the firehose of all bus positions, and easier to ask one simple question. But if you're designing a real-time screen, it's a burden to ask for each possible bus and bus stop every minute; you'd rather just get all the data at once.

WMATA's API also goes through another service, called Mashery, which limits how many of these API questions you can ask in a set period of time. The intent is to keep someone from overwhelming WMATA's systems and crashing them. But when Eric Fidler was building the real-time screen demos, he found that just asking for a few bus lines at nearby bus stops every minute, his system quickly hit the limit.

Plus, since one server was running many screens at once, the more screens, the quicker you hit the limit. We kept asking WMATA to increase the limit, and they did, but for many applications these limits will quickly become untenable.

Every transit agency ought to provide GTFS-realtime feeds for those that need them. ART's vendor, Connexionz, now also offers it, making 2 area agencies that do. Others should join Ride On and ART and offer this feed as well. Often it will be the agency's API contractor that offers it; agencies that pay NextBus for bus tracking services should require NextBus to offer a GTFS-realtime feed.

What's the common transactional API?

At the same time, we need a transactional API, ideally a common one. If everyone used the same API, it would be really easy for app developers to support all of the region's (or the nation's or world's) bus systems.

Unfortunately, there is no consensus here, unlike with GTFS. Most APIs are nonstandard ones an agency's IT staff or its contractor devised. New York uses the European standard SIRI, but had to make some changes of its own, and few US agencies use that. NextBus's is pretty widespread since that company serves a lot of agencies.

What to do? There are a few solutions.

First of all, everyone could get together and try to coalesce around an existing standard. It doesn't really matter which. It doesn't have to be the best one. Most standards are pretty imperfect; we type on QWERTY keyboards, which are one of the least efficient keyboard layouts you could devise, but any effort to come up with something else has failed. There's a strong lock-in, but to some extent, it doesn't really matter; we manage to type fine.

We could use SIRI; Europe does. Or NextBus could make their API a standard. Google did this with GTFS. Google initially created GTFS, but then they stopped controlling it and let the community of developers and agencies take control. They changed the "G" to stand for "General" instead of "Google." Many standards in computing started out as some company's property, but they transferred it to some national or international committee to shepherd.

If NextBus wanted to do this, they would probably want to give it a different trademark, so an agency offering the API wouldn't be saying they offer "NextBus" (we've had enough problems with NextBus trademark confusion already). And they would need to let other agencies and developers make changes, through some process, without the company having control.

Another approach would be to not worry about this at all. It's not all that hard to write some code to interact with multiple APIs, as long as they have a few features that you need to make them interoperable, like common identifiers. In the next part, we'll talk about this.

Some other company or entity could also set up an intermediary computer system that takes in all of the data on one end, and lets app developers connect to it. It would have to get the "firehose" style data from the agencies, and can then even offer 5, 10, or 50 different styles of APIs on the other.

What has to happen for that to be possible? For one, someone has to maintain it and pay for the bandwidth. An organization like COG, or a partnership of the DC, Maryland, and Virginia state DOTs, could do it. Or, to go national, a group like APTA or a federal agency could provide it. Or, perhaps some private entity would find it worthwhile, though the amount of revenue they could make is probably limited.

But for that to happen, the agencies have to offer the "firehose" of GTFS-realtime. For that reason, while there isn't consensus around all of the APIs, our region's transit agencies can and should take one step now, to offer GTFS-realtime, as Ride On and ART now do.

There's a lot to remember to do at a traumatic time, and unfortunately many aspects of our laws punish cyclists if they make a small mistake. Without corroboration from witnesses or cameras, it's very difficult to prove what happened, and police officers often make unwarranted assumptions about a crash or don't bother to interview witnesses.

Plus, DC, Maryland, and Virginia's "contributory negligence" doctrine means that for one party to collect from the other's insurance, they have to be 0% at fault, not even 1%, and generally also have to be able to prove that.

The app lets you enter all of the relevant facts from a crash into a form, take photos to store with the report, record audio or make a drawing of the area. You can email the crash data to WABA, which can often help advise cyclists on the process. There are buttons to call 911, get a taxi, or reach police or a hospital.

A medical expense tracker helps injured cyclists keep a log of all of the costs for medical bills, medicine, and even lost wages, which they might need to claim on insurance.

Other features of the app include a guide to bicycle laws, a flashlight (which didn't work on my new Nexus 4 running Android 4.2.1), and a link to become a member of WABA.

Hopefully you will never need most of the app's features, and can just use it as a handy pocket reference to the bicycle laws. But if you do get into a crash, it'll be useful to have the app handy. Search for "WABA" on your Google Play Store or iPhone App Store to download it for free.

Ron Linton told the Post's Mike DeBonis that their approach changed because the marketplace changed:

"A year ago, when we came up with the 'smart meter' concept, it was a way to get credit cards and the other kind of technological things we wanted in the cabs quickly," he said. "We couldn't say, 'Do this,' because where would the drivers go? What would they get? Since then, there are six, seven, eight companies coming in here offering credit card services. .. They also are offering electronic reservations, which we want."

If the DCTC picks a single piece of technology, everyone's stuck with that choice, whether they made the best call or a bad one, and even if technology evolves.

In that case, doesn't this same logic apply to other features as well? DeBonis writes that Linton plans a new procurement for the system that will have "an interactive screen, GPS navigation and 'panic buttons' to hail authorities." Why should DCTC pick a single piece of technology to do this? Most of this is nice to have, but really not that central to a taxi rider's experience.

One argument for a centralized technology choice, which Councilmember Mary Cheh made when passing the original bill which mandated these credit card, GPS, interactive screen, and panic button systems (and a standard color scheme for taxis), is that taxi drivers are often not the most cutting-edge when it comes to technology. Plus, since most people pick taxis based on whichever one shows up rather than choosing a company ahead of time, there isn't really much incentive today for a taxi to install a better but more expensive system. It probably won't draw more riders.

Therefore, that thinking goes, drivers will just install cheaper systems that could work poorly or break down a lot, and DCTC would spend a lot of effort monitoring and inspecting them, when it could just pick one system and ensure a baseline of quality.

But this also closes the door to innovation and opportunities for different vendors to compete. Any contract will likely run for a number of years, during which the manufacturer will have little reason to add features or make the devices better.

DCTC could just mandate outcomes rather than means, as it's doing with the credit card readers. Drivers could just pick any screen vendor, so long as its display meets certain requirements, like showing the rider the current location and sending GPS data back to DCTC. Drivers can keep the advertising revenue as an incentive to install a screen.

On the other hand, this could mean an incentive for drivers to pick a screen that gives them the most money (maybe by being most intrusive with its ads) rather than being most useful for the rider.

What do you think is better—letting drivers pick their in-car screens, even if their incentives don't match the rider's, or having regulators pick it, which locks all cabs into a single technology for a long period of time?