Archive for June, 2007

The user interface of “personal” transit systems

Friday, June 22nd, 2007

I recently came across Joel Spolsky’s description of a usability bug in the elevators at 7WTC. The elevator tried to perform a form of “passenger clustering” to reduce the number of stops made by each elevator, but it failed because the new system doesn’t match up with the mental models of most elevator users.

The essay reminded me of why I don’t try to do lots of user-interface design. Although it’s a discipline that involves lots of code, there is much more to it than writing decent code. I can tell you if a UI is good, but I will sometimes struggle to tell you why, and what should be changed to make it better. (I find the whole task of assessing user interfaces to be uncomfortably close to Justice Potter Stewart’s definition of pornography — I may not know how to build a good UI, but I can tell when I use one.)

Joel’s article also reminded me of a much older salon.com article about personal rapid transit (PRT) in the wake of seeing The Incredibles in 2004. The idea behind the new-fangled PRT system is that you enter a station, punch in a destination, and get in a car that whisks you to your destination. It has the potential to suffer from the same sort of UI problem as the elevators, though the company’s description of the ticketing process makes it seem less likely. A PRT system is more like a taxi, which makes it less likely that users would trip over a pre-conceived notion of how things are “supposed to work.”

Interestingly, I might be able to ride the Taxi 2000 system in the distant future. I work in the Hacienda Business Park in (un-)Pleasanton, California, which is apparently considering a PRT system to link up with the BART station. On its face, Pleasanton seems like an idea trial zone for trying a PRT feeder system instead of a bus feeder system. Pleasanton is a rich, car-dependent suburb; as far as I can tell, the bus exists to get lower-paid service workers to their jobs. The shuttle bus that runs from BART to my office building is available only for limited hours, and the commutes end to early for a typical high-tech engineer whose day starts late and ends late. Mostly, though, I’m interested to see if the PRT concept works. Proponents of these systems claim very high capacity, but most rail systems that run tight headways don’t need to throw track switches anywhere near as frequently as the proposed PRTs.

Software is everywhere

Friday, June 22nd, 2007

On my recent trip to Montreal for the IEEE, I had a weird credit card experience. I went to pay with my American Express card, which has a silver magnetic stripe on the back. When the waiter brought back the check, he had an old-fashioned carbon copy receipt.

He explained that AmEx cards with a silver magnetic stripe, like my Costco cash-back card, were of a newer design, and the process for reading them caused their card processing machine to crash. The could process the new-style AmEx cards in the machine, but the transaction would crash it and they would need to reboot. Unsurprisingly, it’s not a very fast machine and the reboot time is lengthy. Therefore, while waiting for AmEx to supply a patch that fixes the bug, they were running all the new-style cards manually.

The moral of the story: all software has bugs, and software is everywhere. Therefore, expect to find bugs everywhere, even where you least expect it. (A friend who was doing research involving automobiles once told me that essentially all new automotive features are software, so it accounts for an increasing fraction of the cost of newer cars.)

A dispatch from the home network: Powerline communications actually work!

Monday, June 18th, 2007

Recently, my parents moved out of a two-story house into a condominium. The condo is smaller, but it’s more spread out. The building is also a great deal sturdier, since it’s a 13-story high-rise, instead of a two-story detached home. In the old house, a single AP in the middle of the home on the second floor covered everything adequately. In the new condo, the wireless signal was not so great around the edges of the unit, and that expressed itself most dramatically in the speed of transferring recording programs between two TiVos.

Obviously, a second AP was needed to cover the extra horizontal distance, but I needed to link them to a single VLAN in order to get communications between clients of the two APs. The condo’s walls were already finished, and the last thing I wanted to learn to do was how to fish cable through ceilings and walls. (“It’s easy,” says a colleague with the right tools, as I tell him this after the fact. “There’s a really long drill bit, and then you just snake a pull cable over the ceiling. It works even better when you’re not on the top floor of the building!”)

It turns out the problem was pretty easy to solve with powerline networking. One of the APs acts like a firewall/router for the whole condo, and feeds the second AP over powerline. A third unit connects up a computer with only an Ethernet port. I used the new HomePlug AV equipment, which boasts speeds of up to 200 Mbps. According to the Netgear’s test tool, raw link speeds are 150-175 Mbps. (I wound up selecting the Netgear equipment because it was the best industrial design in the group, and it had the least garish display.)

I have one big worry about the equipment. It works by sending the data over the electrical wire as high-frequency modulation. Most power strips/surge suppressors will filter out high frequency noise, so the units need to be plugged directly into the wall. Without protection, I wonder how they’ll fare when the power flickers in a storm. Naturally, I worry about security as well, since there is no obvious security protocol configuration that took place during my installation.

At this point, everything seems to be working. The question is whether I am brave enough to upgrade the APs to some new firmware. I am tempted to because the third-party firmware offers multi-SSID support, with different security configurations, which would help contain some of the potential damage from the non-WPA TiVos.

Getting OpenSEA off the ground

Monday, June 18th, 2007

A little more than a month ago, the OpenSEA Alliance launched. One of my first volunteer roles with the organization was to act as the volunteer “electronic tsar” responsible for many of our communications with the outside world.

Reading stories like this one from Joe Kraus about founding Excite, I can’t help thinking how lucky we were to be getting OpenSEA off the ground in 2007. Excite had to get a $10,000 hard drive that held 10 GB to demonstrate their technology. Now, $10/month hosting accounts give you access to twenty times that storage. Plus, the proliferation of open source software means that a few clicks enabled the domain registration, the content management system for our site, and electronic mailing lists. A team of three volunteers was able to put the whole communications infrastructure together in a couple of weeks of spare time while working our “regular” jobs.

At this point, one of my big personal goals is to make the organization successful enough that we can “fire” the volunteer webmaster (me).

BART says: Yes, Wi-Fi coverage is bad, but you shouldn’t be using it

Monday, June 18th, 2007

You heard it here first. In May, I wrote that the new Wi-Fi service on BART needs some improvement. My blog post was picked up by the Contra Costa Times, and here’s what they had to say about my overall impression that it’s a marginal service:

[BART spokesperson Linton] Johnson acknowledged that Wi-Fi Rail is adjusting the placement of the access points.

“At this point, this is an internal test. Although customer feedback is valuable, this part of the test isn’t designed for that. Maybe the next part will be,” he said.

One thing that I’ve learned in my career in high-tech is that early customers will work with you and help you fix just about anything because of their enthusiasm. It’s one of the big reasons why I’ve spent more than half my time at start-up companies. I’d be interested in learning more about how the trains are getting connected up, and I’d dearly like to see an wireless LAN connection that could stay up when the trains are in the tunnels. I’d also like to think that my opinions about wireless LANs might be worth something.

Bad Advertising: Our services have the “speed” and “reliability” of the London Underground!

Sunday, June 17th, 2007

In a recent issue of a tech magazine that I receive, I saw the following advertisement, which is good for a laugh. I’ve deliberately blurred the company’s name, location, and sales telephone number.

Speed and reliability don't make me think of this

The photo in the background is nice, and gives you the impression of a fast-moving train. That is, until you take a closer look at it, and realize that it is unmistakably a picture from the London Underground.

Trust me, Unnamed Company, you don’t want to associate your services with the Tube, especially its speed and reliability.

I started riding the Tube about 15 years ago. Back then, the novelty of an underground railway that went everywhere made me think it was cool beyond belief. As far as I can tell, the government has barely invested in upkeep since that time. In January, I was in London for an IEEE meeting, and I loathed taking the thing. Most of the stations are only a half-step above decrepit, deferred maintenence kept good chunks of the system from running, even during weekdays, and it takes more than an hour to cross central London if you need to do something stupid, like transfer. One day, the network was even completely shut down to to “high winds.” (Bonus points for anybody who can tell me why high winds can almost completely shut down an train system, even the underground parts.)

All that said, it could have been worse. A few days after I left London, I was on a Belfast-Amsterdam flight delayed by snow over London. It apparently could have been worse: I could have been trying to ride the tube. Here are two precious photos: TFL’s delay apology and the service update.

Security for retail wireless LANs

Wednesday, June 6th, 2007

George Ou blogged an interesting survey of retail wireless LAN security in his neighborhood, and rhetorically asks the question of whether we need another gazillion dollars in damage before the industry wakes up and does something about it. The problem is that features and convenience, as always, outweigh security.

With my current company, I’ve worked with a couple of retail stores to implement wireless LANs. One of the major advantages that stores perceive is the ability to add devices whenever it’s necessary to respond to demand. One of the classic examples that always came up was the idea of a store wanting to use cash registers, connected wirelessly, during sales or the busy holiday season to add check-out capacity.

The problem? Most cash registers don’t have 802.1X supplicants, and they run a motley collection of old operating systems that may not allow easy addition of 802.1X. OS/2 was a common operating system, but there was significant presence for Windows95, Windows 2000, and even (shudder) DOS. You just don’t have good options for using the right sort of wireless LAN security protocols. Most retail companies were either unaware of the risk, or willing to take the risk given the apparent high cost of upgrading to devices that were capable of supporting WPA.

Or, from the organizational perspective, it doesn’t help that retail stores are not monolithic entities. There may (or may not) be somebody in the IT department who understands the risks of using poor wireless security protocols, but I don’t think it’s a stretch to say that such a person probably isn’t involved in the details of picking out cash registers. It’s almost certain that the stores are not demanding features like WPA2 from their cash register vendors.

(Yes, this is one of the things that could be addressed in part by the OpenSEA Alliance and the Open1X Project.)

Interop 2007 in photos

Sunday, June 3rd, 2007

Interop ended the week before last, but Las Vegas is good enough at being angry-making that it took me a week to sort through all the pictures that I took. During Interop, my major activities were related to the OpenSEA Alliance, an organization that I helped found, and the Interop Labs, the legacy of Interop’s conference and research focus.

My favorite photo of the week illustrates why the Interop Labs is so valuable for attendees. Those of us who put it on have a staging event a month before the show, and then we arrive several days early to set up demonstrations. It’s common to be troubleshooting all the way up to the opening curtain, and sometimes even well into the three-day show. To show off open-source admission control technologies using the Trusted Network Connect architecture, it was necessary for Mike McCauley, the CTO of Open System Consultants (maker of my favorite RADIUS server, Radiator) and Chris Hessing, the Open1X project lead, to work out some bugs before the show.

Mike McCauley and Chris Hessing troubleshooting

(Meanwhile, Ted Fornoles and Tim McCarthy, both of Trapeze Networks, are in the background working on another demonstration.)

Chris and Mike are both individual members of the OpenSEA Alliance, and attended a lunch meeting the group had on Tuesday. We’re all excited about the possibilities of where we might go, but there’s a lot of hard work ahead of us. Fortunately, the group has a wide cross-section of industry representation; here’s a shot of the Extreme Networks access control demonstration area, which makes use of the Open1X project software:

Extreme demonstration of Open1X project supplicant

There are several more pictures of people involved in the group in my OpenSEA gallery.

In the Interop Labs, I was a member of the VoIP team. Unfortunately, I missed the staging event because my presence was required at a meeting in Singapore. Of the demonstrations on the floor, our scalability demonstration seemed to attract the eye of most passers-by. Here, Jerry Perser of VeriWave (on the left) is explaining the demonstration to Sue Hares of Nexthop (on the right), and one of Sue’s colleagues whose name I forget:

VoIP scalability demonstration

If you’re interested, feel free to look at the full photo gallery here.

EZ-Rider is not EZ when you lose your credit card

Saturday, June 2nd, 2007

Last week, I received a call from the bank telling me that had revoked a credit card due to fraud. Unfortunately, it was the main credit card that I use, and most automatic payments are set up to charge that card.

Almost every account update was easy. You find the service provider, go to the web site, log in (thanks for remembering everything, Password Safe!), and change the credit card. When I remembered that I needed to update my FastTrak toll tag, it turns out that I had been smart enough to store even that information in Password Safe. Total time per account: approximately one minute. Total time for all affected accounts: less than ten minutes.

Then, I got to the last item on the list: the BART EZ-Rider card. It’s still a pilot program, which means that everything is still paper-based. Therefore, I needed to (1) find the right spot on the web site, (2) learn that updating my credit card requires filling out a form, (3) download the forms, (4) find out that all the account forms are in the PDF, so print out the correct one, (5) carefully fill out the form, since not all items in the form are required, (6) send the EZ Rider service center an e-mail to let them know the form will be coming, (7) note that there is no fax number on the form, and find it on the web site, (8) wait until Monday to send them the form, and (9) hope that the information can be updated reasonably promptly, because what happens if the form isn’t processed right away? Total time to update: ask me when the process is complete.

(The major reason I got an EZ Rider is that discount tickets are not available in stations, and you’re left with a pile of sub-$1.00 tickets that are useless. If I have to specially seek out a discount ticket because of this, I’ll be mad.)

At this point, I could make an unfavorable comparison of the EZ Rider service to FasTrak (which is run by Caltrans, hardly a pinnacle of efficiency or customer service), but that would be mean, so I won’t.