Last night I had the opportunity to visit the Vancouver Museum (or, Museum of Vancouver) to attend a lecture featuring three presentations about bicycle parking. Titled "Park This! Inspirational and Effective Solutions for Bike Parking" short presentations first showed implementations worldwide, then the second more generally addressed bike parking as a public issue, and the third discussed Vancouver's experience specifically.
The Vancouver Public Space Network (VPSN) took photos of the event and the subsequent Velo-City museum tour. As I sarcastically predicted, bike parking was inadequate for the event (1, 2, 3, 4, 5, 6).
Park This! presentations
Richard Campbell presented first, showing and telling about other cities' ideas to make it easy for cyclists to leave their bikes behind while they go about their business. Considerations for good bike parking in cities are, he says: length of stay, cost, available space, demand, customers, and security.
Rough notes on the cities he covered, each of them, in the presentation, each illustrated by a photo:
- New York City: covered bicycle racks, with information on how to lock a bike
- Portland, Oregon: bike parking on the street, temporary curbing, prove it's successful
- Melbourne, Australia: Parkiteer at the rail stations, enter with a smart card, sign up for a particular station, take care of the station
- Boston, MA: Alewife Station, chain link fencing, security cameras, smart card which you can use for transit
- San Francisco: e-Lockers: smart card, 5 cents per hour, at transit stations and downtown areas
- Spain: Bigloo, which is a turntable tube, smart card
- Amsterdam - bike parking near train station
- Zutphen, Stationsplein, the Netherlands: stairs with ramps to roll bike down, repair shop, double level parking
- Spain: Biceberg: bicycle vending machine, smart card
- Japan: Eco Cycle, vending machine, holds
- Chicago: Millennium Park Bicycle Station, with showers, changerooms, segway rentals, bike tours
- Freiburg: Café Velo, bike tours
- Barcelona: My Beautiful Parking, verticle hanging (cheaper) or racks
Adrian Witte presented next, discussing the issues surrounding bike parking generally. 20,000 bike trips in 1994 increased to about 55,000 in 2006, which still only accounts for 3.5% trips of all modes in the city. Adrian asked if road builders think of parking, why can't bike path builders?
How can bike parking be used to increased cycling participation?
back to basics: good design
- visible
- accessible
- secure
- easy-to-use
- convenient
- plentiful
Valet parking checks all the boxes.
use of technology
- electronic locking systems
- advanced stacking: above or below grade
integrate with other modes
- make it competitive with automobile travel
- widen the circle: 5 minute walk vs. 5 minute cycle
- smart cards, bike lockers, bike stations, bike rentals, car share, transit
- car share: locate cars vehicles with convenient bike parking
public bike system
- removes parking need, transfers security from bike owner to rental provider
Summarizing, Adrian said that tried and true design principles, embracing technology, integrating with other modes, trying different angles to solve the problem help in establishing a bike parking system in a city.
Stephanie Doerksen of VIA Architecture (also of the VPSN) brought the to Vancouver specifically, observing that bike parking made for cycle-friendly streetscapes. In 1995, the parking bylaw amendment required bike parking to new developments. In 1999 the city created a comprehensive biking plan, making more bike parking available in commercial neighbourhoods. In 2009, there's still a shortage. She mentioned VPSN's visual audit of bicycle parking, and her photos showed bikes locked to objects other than those intended for bike parking.
Stephanie noted that the city is thinking of replacing parking meters with a different payment system, and that they have the opportunity to replace the physical parking meters with bike parking poles. It would be easy and efficient, not requiring a change to the streetscape. Other ideas include converting a parallel car stall to bike parking, such as on curbs in Portland and angle parking. 12 bike parking spaces, she says, for each car parking space.
Panel Discussion/Questions
At the panel discussion afterwards, the audience and the presenters discussed bike parking around Denman and Robson. A question arose about parking for bikes with trailers for groceries & kids. Another audience member remarked that bike parking not a sexy issue: bike stations have been successful, but take up space. Later, an audience member made the connection between bike racks and street furniture: they can lead to a sense of order to the street, but Vancouver does not seem to have uniformity like in Toronto.
Addison Berry, aka @add1sun, presented about her experience as documentation lead for the Drupal content management system project the other day at the Writing Open Source conference in Owen Sound. In her role as chief cat-herder, she found that the most difficult people aren't poisonous. Instead they just don't know how to communicate with the community, and they need to translate where they're coming from to the way the community operates. It's hard work, she reports, to turn them into a contributor. She referred the audience to the "Poisonous People" presentation by the Subversion people, as yet unwatched by yours truly.
Addison talked about religious wars that occasionally break out. That is, the crux of the issue is more important than the resolution, and often leads to inaction. She also discussed the differences between recruiting in the corporate world and recruiting in the open source world. For private companies, they hire a skillset that they can filter for by listing the job requirements, either explicitly or implied. In open source, she says, you have the skillset first and you work with it. Many cats scratching their own itch, hence the herding to get them to scratch the community's itches too. The people you get working on a project have a rich background, both in terms of skills and life history. Skillsets include a lot of non-technical backgrounds in open source (Addison has an anthropology degree, for example, and my education is in political science).
Drupal has a large mass of documentation, and Addison is trying to whoop up energy in managing the base of existing documentation for Drupal 5 and 6 while gearing up for writing the documentation for the upcoming Drupal 7.
Open source has a natural passion that brings people together. Showing the example of a rowing team on her slide illustrated the need to hire a coach to tell them when to row. Herding involves keeping lines of communication open and opening up new ones as well as banging on pots about documentation. Instead of telling people what they can do, empower them by including them in the conversation. Addison, as leader, knows what she won't do and has so far been able to find people who will. Tracking metrics around the documentation—answering a question I had before I had the chance to ask it—Addison is not interested in, but she found someone who is. Many "soft-skills", such as facilitation, have come in handy even if the person with the skill does not claim membership in the software community. Also universities and their students have found time and energy to contribute usability testing as part of course credit or as part of their graduate studies.
Letting go and getting out of the way: Addison wanted the vision to be perfect, but quickly understood that she can't lead the charge or drag it out all the time: instead she recognized the need to let people run with things and support them. Letting people to trust you that that's the right direction.
In a week, I will attend the Writing Open Source conference in Owen Sound, Ontario. I'm excited to meet some of my colleagues in the field of open source documentation, having written the bulk of the support materials for Bryght, the Drupal-powered hosted service. I'm particularly interested in meeting those working to document open source tools other than Drupal, to gain some perspective on what's out there and what's needed.
Writing documentation was my first task at Bryght back in 2004. I recall spending part of that Christmas break furiously jotting down the important steps to creating dynamic and community websites. This included checklists, instructions and descriptions of module settings and how people could take advantage of them. The initial push of documentation made the subsequent job of supporting customers easy: instead of each time having to explain how to do something, I quickly pointed to the documentation, either through a link or a copy & paste. Along the way I even heard from non-customers thanking me for the handy references. After the second time someone asked we documented the answer. (We even wrote documentation after the first time someone asked a question.) Sometimes it didn't work, and sometimes the documentation wasn't all that great or hard to find. We allowed comments and opened the forums and listened to feedback when what we wrote didn't make a whole lot of sense. That's the experience I'd like to share with the conference, and I'd like to hear of others' experiences in making complex software more understandable.
After the weekend conference, I'll spend a couple of full days in Toronto proper, getting some much needed distance from Vancouver. I'd like to meet with some of the Toronto Drupal heads, and others I know (but haven't met) from other online communities I'm part of. Sadly, my favourite baseball squadron, the Toronto Blue Jays, play on the road in late June. Surely a local pub will have the games in HD?
