The User Advocate

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?)

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.

True to the detail-oriented nature of this site, I’m going to start with an interface challenge to an interface-expert company, Palm.  Renowned for their ‘two taps to anywhere’ goals, the Palm OS team has been for years focusing on ease-of-use and succeeding extremely well.  However, there is one item that could be easily fixed that has been overlooked: Contacts who share information.

We all have some – the perfect example is couples where you know both people in the relationship. They generally share the same address and the same home phone number, but their cell phones are different and their email address too.  Maybe it’s your aunt and uncle and you have records for each of their kids so you don’t forget their birthdays or emails… or it could also be people who work at the same company with the same address.
So what happens when they move?

You have to chase down every record that has the old information, and change them independently.  Or, you have to have only one record that has all of the people listed and notate their differences by hand.  Not good.

The solution? Well, I think I gave it away in the title.  Allow records to share information.  Change it once and it ripples through the links.