Improving Zipcar’s User Interface
.I’m on a big Greasemonkey kick at the moment, and have decided that I’m going to make a small project of improving Zipcar‘s user interface.
It’s not a terrible web interface, but there are things about it that irk me. The main one, that I really want to fix, is the fact that in their standard search mode you only see five cars at a time. When scanning for availability, you really want to see more than that.
It should be relatively easy for me to use asynchronous requests to get results for more cars and to push them into the DOM on the initial page. I’ve started on this already, but annoyingly ran into some bug that I haven’t been able to figure out (possibly because I should be asleep).
I’m also probably going to exclude some cars from consideration, or add an option to do so, because some cars (like the Volvo S40) I just never want to drive.
I’m going to try to improve on their location functionality, by making it much easier to add locations. I don’t use this myself, but my friend Brian mentioned it, and it seems like it might be an interesting problem to tackle.
In a less challenging vein, I’m going to add plain text links (that can be accessed using TypeAheadFind, or FindAsYouType, or whatever it’s officially called now) to things I use often—the dynamic menu they use is annoying and doesn’t allow for opening links in new tabs.
Apart from the location feature, the rest look like reasonable goals, ones that might make my zipcar.com experience smoother. I love the fact that I can do this kind of thing without any access to their source files…
Update: I wrote the “more cars” Greasemonkey script. The bug I ran into because I should have been asleep was due to my not realizing that if you add a tr element to a table, you’re actually moving it to the new table and out of its old table, so its old table’s array of rows will be reduced by 1, and this will do screwy things if you’re iterating through it at the same time.