A couple weeks ago the City of Vancouver launched a wholly re-built website as the online face of the city. Like many web developers in town, we knew this was coming since OpenRoad’s Gordon Ross had told us about it at World IA day, where he talked about the challenges and rewards of organizing a web experience around citizen needs instead of department hierarchies.
The re-launch generated some talk, and later the same day the price tag started to float through Twitter. Then local Old Media picked up the story. And that generated a lot more talk.
Naturally we checked it out ourselves, and had our own opinions about what we saw. Since then we’ve learned a lot more about the project from press articles, commentary by some who worked on it, and just taking the time to explore it on our own. I’ve personally worked with some of the people who worked on this site. They do good work, and I believe they did so here, too.
But there are definitely problems with the site. Problems happen on all complex projects, of course, but those we saw in Vancouver.ca are particularly instructive for both the practice of big web projects and the possibilities we see for local government and the web.
Let’s start with the big wins for the site: the information architecture was rebuilt from the perspective of citizen and employee needs, rewriting 60,000 documents and reducing them to 20,000 (with a third of the requested team size), and tying together a technical stack that sounded like the sixth circle of hell but was mandated by the RFP. These are not small achievements.
But when the site turned on, there was little to read about those achievements despite high local interest. As is often the case with design and difficult back-end technical work, those wins aren’t immediately obvious and pay off over time. Without the differences between new and old made clear, many people, including those experienced in big web projects, jumped into dismissing the price as bureaucratic excess. The city, with the help of key vendors, have caught up to that vacuum of information somewhat since the launch, but the first impressions tainted the project in minds of the people who have to buy into it.
Lesson: re-launches of any appreciable size deserve content about what changed and the thinking behind those changes. People want to know, even if they don’t understand the complexities, that their taxes are being well-spent. Producing and highlighting that kind of content isn’t hard to do, so there’s not much excuse.
Let those who have not debugged on production or done hot fixes on launch day cast the first stone. With that in mind, we can overlook bits of breakage. But two weeks in some really obvious problems persist on the homepage alone despite apparently easy fixing.
For one, the menu for a whole top level category (News, Calendar - yes, with the comma) appears empty. The headings are clickable, but compared to other menus in the navigation it looks broken.
For another, the map at the bottom of the page has hover region bugs that make it look like UBC is associated with a neighbourhood clear across town. Again, not that hard to fix, but it sits there untended.
The more you look, the more you notice: images to show the digits of city services phone numbers, an unusually low quality of the page code, the ginormity of the photo carousel compared with somewhat cramped typography. It adds up to feeling quite raw, and unready, that it launched too early. Combined with the lack of information about the re-launch, that first impression kind of pushes you towards a negative first impression
Lesson: Launching something requires project and product management, and it doesn’t look like those were balanced in the decision making about when to go live. You can have everything in the plan marked complete, but if someone can’t make the call that it doesn’t feel ready there’s a risk of a poor first impression.
We can’t imagine a job where we don’t consider mobile from the start. But we start our projects now, in 2012, while Vancouver.ca started almost 3 years ago. The site is somewhat workable on mobile, but not in any optimized way. This is what the project team took the most heat over in public dialog after the launch. Even if you could accept the $3 million price tag, the lack of attention to mobile is surprising.
The reaction shows how expectations around mobile have changed since the city’s website budget was approved, but official responses to this criticism have been disappointing. One reportedly pointed to legacy tech while others mentioned limited resources and one (laughably) that it wasn’t necessary.
We wondered about this, and after a half hour of hacking in some 65 lines of CSS Tylor got a reasonable mobile version of the homepage working. We get that this is just hacking at the browser level, and the same code wouldn’t work for the whole site, but we don’t think it would have taken a lot for basic mobile accommodations. But big projects have a way of making these things hard to see, if not impossible to act on. The CSS can be downloaded here if anyone is interested.
Lessons: Long projects need contingencies to cushion against technology and cultural changes. If they can’t afford the contingency, they should be smaller projects. Also, we have to stop letting mobile not be part of the game just because of budget. Reducing the overall scale of a project to make mobile work is a trade off that pays real dividends.
We admit we had quick reactions to what we heard and saw on launch day. We had a bit of quick fun with the reported $3 million cost and the lack of mobile support ourselves:
Ok we laughed at that. But a lot of the talk we saw was kind of disappointing. It’s one thing to question a pricey web project, but another to float primitive breakdowns of that cost exclusively across developer salaries and pull magic numbers out of the air about how much it should have cost.
If we want to move big organizations into more open, more nimble technologies and development practices, we can’t pretend that pricing is as simple as spreading a budget across developer salaries while throwing out licensing costs in exchange for ‘free’ open source tech: where would these developers sit? Who writes the content? Who procures the infrastructure?
These things cost money, and on a big project they can cost a lot of money. If this is how the web development community reacts, we only fuel tragi-comically uninformed commentary like that on The Province website. And then we wonder why people have a hard time accepting the costs of projects we bid on. And the cycle continues.
Lessons: The bigger a project, the more costs will be hard to understand without looking deeper. We’ll all look better if we aim for thoughtful over emotional commentary. That said, people complain when they care, and for all the criticism about the project the people who worked on it have to realize that fundamental truth: people care about this, they care about their city, and they want both to be great.
In the initial wave of chatter some complained that Drupal, WordPress and other open source tech would have lowered costs, and suggested that involving more local industry engagement would have helped… somehow.
Maybe. Open source is many good things, but it is definitely not free to make it suit your needs. Like all software it takes talent and time to make it work, and both aren’t cheap. But would asking the opinions of a bunch of web industry members really do much good? We believe strongly in building from vision while keeping ears and minds open, so it’s hard to believe that having an ongoing local web roundtable would do much.
But with a city project you can’t help wonder how that energy, that willingness to contribute could have shifted the project from building for a city to building with it. We see one untraveled road that we hope will create a way in for Vancouver’s web talent without becoming a free for all. The key lies with an existing resource that keeps growing: open data.
City of Vancouver has a respectable amount of open data about everything from water fountains to trees to garbage collection schedule zones.
We imagine of a city website that includes a curated library of web apps built by independents and agencies on open data: visit the website, choose apps that do something with city data of interest to you, and use those apps within or independently from Vancouver.ca to deepen functionality and personalization without the city having to anticipate and build for every need themselves.
You could call it an app store for a city. And we can believe that people would contribute that kind of work because they already do. There are plenty of projects already using that open data for fun and good will (like our own This Is Our Stop which uses open data from TransLink). The hard part, getting people to build stuff, is already happening. What those works can use is a way to find larger audiences, and something with the gravity of Vancouver.ca could do that and make itself a world leader in forward-thinking local governance.
Vancouver.ca is a big project for a city and a huge one for web development practices and technologies. That something with so many people and moving parts involved makes it to the light of day at all is an achievement. While the difficulties the site faces are problematic, there’s little doubt that the rebuild puts Vancouver.ca on a better foundation. Here’s hoping that those early problems are resolved soon, and that the site really finds its feet as a central online piece of civic life.
Continue the discussion on Twitter @DenimAndSteel
Back to Blog Back to Home