I just installed MT 3.1 Quickpost on my laptop’s browser (well, one of the browsers). I used it to start this post. Nice feature, I guess.
Anyway, I’m in St. Louis, enjoying Multnomah’s presentation on CMS’s–lots of good questions and ideas. Mostly I’m get a comfy “hey, we did that right” feeling about where we’re going with MPOW.
Good points about evangelizing ahead of time for end-user buy-in. I have started introducing users to some of the changes, but I think I can go farther and begin saying, “you know those features you asked for? They’re coming soon!” I’ve done that with individual questions about the site, but not as a broadcast.
Some good points about personnel reclassification. One of the nifty features about the new CMS is how it will automate and streamline our browsing structure. However, this will also take a job–what we call “topic work,” or assignment of new records to places in our browsing structure–that now sits in somewhat of a silo, and is a task done after the editing for the week, and redistribute this work into the editorial workflow. This is where it belongs, but it changes who is engaged in the process and how the work is done. We have some time to get comfortable with the changes (not three years, like Multnomah!), but they are changes nonetheless.
I say bring on more chocolate. Chocolate is the world’s best change management tool.
Needs assessment: makes the point that we need to assess not only what is bad–but what is good. One thing our current CMS does better than many packages I’ve seen is support a rigorous editorial workflow. That’s the kind of thing we’re adding to the software being adapted for our use.
Vendor evaluation: making sure it’s a good match… build “use cases” into your RFP. I think I did that, in a way, by describing our activities. We’re fortunate in that everything we do is Web-based so we are pretty well familiar with our Web activities.
Good discussions about organizations that don’t have a workflow for their content production… but boy, do we have workflow.
“Does the management actually know what a CMS is?” In traditional library settings, it was often difficult to get high-level admins to grasp new technology. Fortunately, in our lil’ organization, I am the high-level admin. But (and no disrespect to the presenters, who are doing a great job) I don’t think you have to teach your stakeholders what a CMS is. You have to teach them what a good SITE is, and convince them that you need tools to get from A to B.
Iterative development–well, for me that goes without saying. But I love the presenter’s comment about “Big Bang” implementation methodologies. Be afraid… be very afraid.
Timeframes: in May, I saw us migrated in September. Well, I think the new LII may be under the Christmas tree, if we’re lucky. Who’s the hold-up? We are, within LII, because due to some adroit programming skills of our software team, it is worth our while to do some major topic page development before we migrate, even given how arcane and laborious it is to create these topics. I just love this new biographies page by Tom “TurboTom” McGibney… it’s typical of the creativity and excellent librarianship done by Jennifer, Wendy, Pat, Maria, and Tom.
The control issue… We as a group will lose a little of the creative control we’ve had over individual pages, and that has driven a lot of the content reorganization. But we will not miss the laborious hand-hewn work that goes into these pages, and we’ll gain a lot more functionality and efficiency. As the presenter just noted, quite a bit of the “creative control” is mere drudgework–copy-and-paste HTML coding, etc. I always get amused when I show our site to non-library technical people, who are aghast we would put all that labor into manually-created browsing pages.
I am realizing also that in some ways our migration is a pretty easy one, because even though we long ago outgrew our current CMS, we at least have some structure, and our content is in small flat files with good record structure. All these folks with their huge Web sites made of hand-created code folks feel so proprietary over… I get dizzy just thinking about the internal fights/stonewalling/meetings some of these libraries must have.
In a section called the Big To-Do List, the presenters have again returned to the issue of changing roles. I think it’s significant this has come up at least three times today. I wonder if my own role in the organization will change? I bet it will, in ways I can’t anticipate.
Communication also came up again: internal press releases, memoing, meetings, show’n’tells… all essential.
“The CMS project ends up not being much about the CMS itself.” Well said.
Open source factors to consider: what are your current staff knowledge levels? What about initial and recurring licensing costs? What about vendor independence? Future maintenance issues?
The speaker made some common logical conclusions about open source. If one more person tells me open source is “free,” I may have to rip off my clothes and run screaming down 101. Open source is great. Open source needs support and maintenance like anything else. If long-range planning is a key issue, then you have to look at open source with the same hard questions: who maintains it? What do you do when it breaks or you need new features? (And that’s not my last word on this issue.)
They just brought up keeping your development, testing, and production environments separate. — Amen, brothers and sisters!
Posted on this day, other years:
