The User Advocate

A couple days ago, the Contra Costa Times wrote a front-page article about BART providing more information about the train arrival times in many different formats – pager, email, web, phone, telepathy, etc. – and how excited riders were to get the information. One was quoted: ‘”I had to park way far away today and I had no idea when the next train was coming,” Munzell said. “If I heard something that said seven minutes, I would not have had to jog here.”‘

He’s right, but it’s the wrong problem. Look at the BART director’s quote, and tell me what’s being overlooked here…

“It’ll reduce the time you have to wait for transit or allow you to just keep doing what you’re doing for longer instead of rushing to wait on a platform for the next train or bus,” said BART board Director Bob Franklin of Berkeley. “I think it will make transit overall more convenient.”

Errr… no, it won’t. You’ll just know how long the wait is.

So another rider: “A lot of times you get here and your train is just leaving. It’s kind of frustrating.”

OK, let’s solve that problem instead. Your train just left and you missed it. What’s the best way to make you feel good?

Provide another train.

The problem with BART is the disconnect within the system’s directors and the system itself… between moving riders conveniently – their stated goal – and moving riders in bulk, which is what they keep addressing with policies to increase ridership and with goals to get cars off the road. Those are good goals and worthy of working toward, but not the ones that they tout.

So then solve the problem: run trains more frequently so when you miss a train, the next one is right behind it. This is the same theory as the London Underground uses in the heart of the city, and when I commuted on that I never cared if I missed a train. There was always another one 2-5 minutes away. BART should run every 5 minutes.

To do this, budget will always come up. The right answer is to then cut routes, always synchronize transfers, and only run two sets of trains – Concord to Daly City and Richmond to Dublin/Fremont. All stops are covered by those two routes and if you are going between routes, you transfer.

“Wait!” you say, “I was going Fremont-SF and now I have to wait longer! Not fair!”

Not so. You arrive just after work, at 5:07pm. You’ve missed the train and have to wait 14 minutes to catch the 5:21 train. If they ran every 5 minutes, you would have an equivalent turnaround with a transfer at 12th Street. The same travel time of 45 minutes, either way.

It also makes all people going on one route 5-10 minutes faster, and everyone who needs to transfer today go more quickly. Everyone wins, riders get happier, and BART gets more riders because the service is more reliable. More riders, and maybe they can add that direct route for commute hours.

Now that’s a solution BART should consider.

I live near the Bay Area Rapid Transit (BART) station and take it to work many days each week. I appreciate their system and how economical the ride is, but their customer service needs work.

I’m not even talking about the people – they’re quite nice, though thinly spread. I’m talking about the systems that support the riders. Here are four examples of problems, with a possible solution that addresses them all:

1. Fare machines – they aren’t always working, and when a number of people arrive simultaneously there are never enough. This includes the few ‘Addfare’ machines, which are always needed the most right when a train arrives at the station in order to get out of the station. The congestion as people race for them is a problem.
2. Discounted tickets – they’re sold at remote vendors for a small (5%?) discount off the face value. The key issue is remote vendors. For people who depend on mass transit and travel the system daily, it is an unnecessary burden to go to some other place to get tickets. Especially when vendors run out and you can’t buy it on your schedule. I know, they don’t want to sell too many or it cuts into revenue – but you’re hurting the very people you’re trying to bring intothe system. How does this increase ridership?
3. Ticket gates – they are slow and tickets misfeed, especially the thicker discounted tickets. I’m sure it is thicker to make it survive the additional trips since they are higher values, but it doesn’t make them easier to feed into the machine.
4. Tiny tickets – you always end up a ticket with less than a ride’s worth and have to figure out how to dispose of the balance. There are donation programs for these tickets, but BART steadfastly refuses to accept more than one ticket and add them together for a ride. Again, I’m pretty sure they are counting on people throwing them away and/or ignoring them so BART gets to keep the revenue for no effort. They only make two places available for combining the tiny tickets, so one has to travel quite a ways to get them combined.

So what’s the answer? Fastrak for people. Get some tiny RFID dongles like Mobil Speedpass and give each frequent rider an account.

• Riding becomes easier (more riders=more revenue!)
• No congestion at the fare machines (happier riders!)
• Fewer moving parts (less machine breakage!)
• Prepaid accounts (BART keeps the interest!)
• Automatic account replenishment (no tickets to manage or purchase in weird locations!)
• Discounts for frequent riders (Maybe escalating as you spend more each month? Or have a per-month $2 minimum for the account to make up for the missing tiny tickets?)

Today I finally heard about a brouhaha that made me sad… apparently grants.gov, the site that was to promote electronic submissions of government grants, does not support Macintosh computers.

“What’s the big deal?” you ask, “After all, only 7% of the world works on Macs.”

Well, then you haven’t done the research either. 30% (I’ve heard up to 55%) of education and research folks work on Macs. It doesn’t bother me that you don’t know, but it does bother me that a grant-organization part of our government who should know doesn’t.

It’s triggering the eternal complaints of Mac marginalization, and I still haven’t heard if it works any better in Linux.  Sounds like not. There are discussions of workarounds and quips that it doesn’t even work on Windows, but the simple truth is that this could have been easily avoided if the implementers had half a clue about their requirements.

Proper design is always cheaper than fixes, and that’s my tax money you’re wasting.

So I finally gave in and decided I “needed” bluetooth, and got a Treo 650. I synced my 600, made sure everything was on my computer, upgraded the software, and synced the 650.

All my Floating Events were gone.

You may not cringe in horror at that sentence, but I did. I had a perfectly working system that compensated for the 600’s lack of alarms on the to-do list, scheduling “events” that I could check off as I finished the associated task, and they would yell at me daily until I finished them. Perfect.

Until they were gone. Left in their place was the technical representation of that workaround, a note labeled ##f attached to a regular appointment. They didn’t follow me any more, and after the first day they were slipping into history with nary a complaint.

What kind of upgrade idiocy is that?

If you build a function [Floating Events] and sell the software to users, then replace it with a different but (mostly) equivalent function [Tasks with alarms], you don’t just drop all the old data! Customer loyalty is built on ease of use and reliability (or a monopoly, but that’s a different story) and you don’t destroy or even hazard their data… ever!

How to fix it? Write a little tool that, when installed on your computer with the new 650 software, scans all appointments and copies any with the ##f into tasks-with-alarms. Don’t rely on users to do the work. I had floating events scheduled more than a year out, and now I have to track them down when the whole reason for having them was so I did not have to remember they existed!

The moral of this story? Always, always make sure you have protected your users when you provide an upgrade path or any changes.

I swear, if it kills me I will find a way to make programmers take an equivalent of the Hippocratic oath – “First, do no harm.”

Outlook, with a meeting scheduled for Thursday. and documents attached to the invite. Microsoft has carefully made it very easy for meeting organizers to publish information to attendees. So, being a digital kind of guy, I made my notes on the document in the meeting request so Outlook would bring them up at that time and I didn’t have to track another document floating around my system that I will only use once. Great!

But…

We had an emergency. No one could make it to the meeting, so the organizer sent out a cancellation. Before I even opened the cancellation, my meeting – and my notes – were gone. An all-too-helpful scheduling agent, a secretary with no brains and no conscience, had destroyed two hours of work and thought. I could not appeal, roll back, or examine previous versions. I just had to walk through the document again, wasting hundreds of dollars to my employer in my wasted time.

How to fix this? Many options, presented in my preferred order (not necessarily exclusive of each other):

1. Keep a history of all meetings (or shared anythings) so you can look at previous versions.
2. Have the software recognize when the entry has been changed and keep the changes as an additional note or some other accessory data.
3. Never, never, never remove or change information until the user says “OK”. It’s not your meeting, it’s mine. You just scheduled it.

This won’t be my last opinion on Outlook, but it is one of the gravest. Destroying data is the worst software offense I know, and this happens regularly in my office as one meeting version tromps on the previous notes.