My name is Mark Farmer – until last Friday I was the web redesign manager at the ROM (I recently accepted a position with Intuit Canada as social media manager).I’m here to talk to you about my experience with open-source software at the ROM.I’ll mainly be talking about our largest project to date, a content management system (‘CMS’) implementation.I’ll talk about how we made the decision to go open source, how we made the case for it, and lessons learned.I’ve been asked to speak for about 15 or 20 minutes, and then have a Q&A at the end, so please feel free to pick my brain at that time. I think that’s going to be a lot more valuable than me talking at you for 20 minutes.
The ROM is Canada’s largest museum, founded in 1912 (the first building actually went up in 1914). Its been added on to four / five times since, most recently the Michael Lee-Chin Crystal.Ramping up to their 100th anniversary celebrations.About 1 million in-person visits per year.About 2.1 million online visitors per year.33 galleries.Hundreds of staffHundreds of volunteers.Over 6.5 million objects on display and in storageMaybe about 1700 web pages (not counting dynamic content such as calendar events)
That’s a lot of content to manage.That has the potential for a lot of headaches.So, how does one even begin organizing that much content?
That kind of content, that kind of complexity requires a content management system (a CMS), which allows us to do a variety of things:For the ROM, the most important thing it does is allow non-technical users to upload content without going through the bottleneck of the web designers in our new media department.Previously, if someone wanted content updated or uploaded, it had to go into a queue and be scheduledDoes anyone operate like that right now?Every experience any frustrations with that? Ever wish you didn’t have to go through that funnel?Going through that kind of funnel is time-consuming and sometimes doesn’t happen at all if the web designers are busy, if there’s another project they’re working on, and so on.A CMS overcomes that limitation by allowing non-technical users to enter content directly into a database, which creates web pages dynamically from this information. This, in turn (it is hoped) allows more content to be uploaded, updated more frequently, and managed more efficiently.In the ROM’s case the hope is also that this will allow curators to create their own content and engage with the public through it.That’s especially significant when you consider the kind of content the ROM creates.
And we do have awesome contentOur goal is to be able to connect our curators directly with the public through that content.That connection is essential to create the kind of relationship the ROM needs with the public in these challenging times: by leveraging all the stories and the tremendous content that exists in the museum and that we create every day.
A CMS does a lot of other things for us tooAllows us to cross-purpose and cross-connect content across disparate areas of the website using taxonomies.That enables the proverbial “Create once, publish many times” philosophy to come to fruitionLecture for dinosaurs exhibitionCreates a virtuous circle of contentAllows seamless multilingualism.Cross-platform because the content is coming from a central repository: mobile, laptop/desktop, tablet, potentially even kiosk-based platforms.Greater accessibility. This is crucialDoes the phrase AODA mean anything to anyone? How about WCAG?Accessibility for Ontarians with Disabilities Act / Web Content Accessibility Guidelines.These are the standards you have to adhere to in 2012 if you’re a publically-funded institution, and to a lesser extent, a private one.By having greater standardization and control of the presentation layer, a CMS can help you meet these kind of accessibility requirements.In short, it gives us greater control over the content: to manage it, to update it, to schedule it, and so on.But the number one reason to implement a CMS is to connect the subject matter experts in the museum with the public, to give the museum the ability to drive traffic, create interest, develop relationships and conversation, and ultimately to show the public why we are or can be an important part of their lives.
Took a look at several different options.Custom-buildSomething the Australian museum did.Build it in-house yourself from scratchHire someone to build it for you from scratchOff the shelf solutionOpen sourceLicensedWent through an extensive analysis, planning and discovery phase to enable us to begin to answer this question. Which was probably inevitable and necessary, given the scope and size of this project.
To give you some idea of the scope and size of this project visually, here is one page of eight of an early version of our migration spreadsheet. It’s 130 rows long and 20 columns wide. It’s grown since then in complexity. And that’s to plan out the content migration.So to help us with the project, we’ve been working with agencies in New York & Ottawa on the design, construction & migration.Migrating hundreds of pages, several databases, several legacy systems, Raiser’s edge integration, real-time third-party ticket purchasing, connecting to multiple payment systems and so on.
So to benchmark what to do, we spoke with something like 30 different organizations and agencies – these are just a few of them.Asked them about their product or about the product they chose and their experience of the process.But is the choice of CMS that important?Some of the literature I’ve read of late seems to indicate no. It takes a contrarian attitude.I beg to differ – it can be a significant input of time and effort to set up a CMS and database, migrate content, create themes or templates, tune performance and so on. So I do think you should give it careful consideration.If you’re hosting in-house you’re also likely looking at a hardware purchase. That’s a significant decision and a significant cost.If you’re going with a licensed solution, especially if it’s the same third party that hosts the site, you’re likely signing a contract that can span several years. That’s something to consider. Also, if your host is your service provider, it’s worth considering that they make get cranky and difficult about exporting or even releasing your data if you decide you want a copy, especially if it’s part of a decision that involves switching service providers.So I don’t think the sticking point is, is the choice of CMS all important? I don’t think it’s all-important. But it can kick you in the butt in ways you can’t predict, so it’s worth thinking about carefully.For us, there was one sticking point, which was the migration of existing custom functionality. That’s the functionality required to run our online calendar, donations system, programs purchasing, group visit reservations and so on.Luckily it was recommended to us very early on that it would be a good idea to go with a framework instead of just a straight-up CMS.That decision to go with a framework ended up giving us the flexibility we needed to port over and accommodate all the custom programming and legacy systems that we have. If we hadn’t selected a framework, it probably would’ve been extremely difficult to accommodate all that custom code, even the systems we’re just reskinning instead of migrating. So in that sense, the selection of CMS was very important for us.
So we decided on DrupalPowers something like 1.5% of website in the world.It was the only CMS that nobody had anything bad to say about.It’s a framework as much as a CMS, which gives you ultimate flexibility, but which also means there’s more work up front.We needed that flexibility to accommodate, not only the existing functionality we needed to port over, but also internal stakeholders. You never know where the scope is going to take you, so having the flexibility of a framework vs a constrictive CMS may be more important than you think. And as the needs of your internal stakeholders evolve, it’s handy to have a framework that can evolve with them, even over the lifetime of the project.Drupal is very powerful, and it may be more power and flexibility than you need or think you need.But that flexibility can be really important when you run into a CMS that can’t accommodate some of your edge cases.Less powerful, less flexible CMSs may be difficult to work with for those kind of edge cases. I’m thinking of Joomla or Wordpress, for example. If you have a relatively simple site without much customized functionality, they may be perfect fine for you.Another advantage of Drupal is the community behind it and the transparency in security. This means that you benefit from the work of hundreds of thousands of people behind the scenes, developing the software.If there’s a security exploit or something like that, it gets found out, communicated and fixed that much more quickly.Another real strength is its modularity. Thousands of modules being developed, some by and for specific industry verticals such as museums, being re-submitted back to the community.
Selling it to the C Suite can be a bit of a wrenchSometimes don’t understand how something that’s ‘free’ can be the best optionOr, they don’t understand that it’s not really free, that there are costs involved.A big part of selling it is talking about the mitigation of risk, which centres aroundThe size of the community and the support it can offer – real peace of mind.Security concernsFlexibilitySolidity……and so on.
It also helps to know that you’re in good company. The C Suite likes that.
Never, ever run a web project in waterfall.Gantt charts drive a web project the same way a hood ornament drives a car. Management loves them, but I’ve never seen a project plan that hasn’t evolved dramatically from where it started.You can’t predict the unknown.Each web project is idyosyncractic and unique. You don’t know how long a lot of the things are going to take until you try.Focus on the business outcomes and objectives, not the software. Never lose sight of why you’re doing something.This also means you should focus on getting things to market as soon as possible and not piling them all up for some big launch at the end.Deliver results in iterations. Re-integrate lessons learned back into the process.Limits risk.Enables flexibilityAllows you to re-prioritize as scope or priorities or directions changes, which (over the course of a two-year project like mine) can be significant.Those learnings are like money in the bank for your project.It’s all about the peopleInternal stakeholdersRelationshipsEvangelists & enthusiastsTry to bring the expertise in-house, but recognize that people leave, so don’t make it the be-all, end-all.
A little about us flickr.com/photos/jdbsound/3559755771/sizes/l/in/photostream
• Adobe • Ontario Science Centre• AGO • Oracle• Australian Museum • Percussion Software• Balboa Park Online Collective • Playground Digital• British Museum • San Francisco MOMA• Canadian Museum of Civilization • Smithsonian• Civic Actions • Smithsonian NMNH• EpiServer • Squiz Software• Indianapolis Museum of Art • The Working Group• Imperial War Museum • V&A• MOMA • V51 Consulting• Museum Victoria • Whitney Museum• National Gallery, Washington
Lessons learned • Never, ever run a web project in waterfall. • Reduce complexity • Focus on the business outcomes and objectives, not the software. • Deliver results in iterations. Re-integrate lessons learned back into the process. • It’s all about the people. • Try to bring the expertise in-house, but recognize that people leave.