asking who’s using a CMS, satisfaction.
wacky graphics showing a messed up navigation system.
slide with teeny tiny font. she’s lost her microphone, and she’s not not quite loud enough. hey, she’s asking and now holding the mic…I can hear her!
what it can’t do: write the content (sounds silly, but…. ah, it sounds like our issues with the workforce dev people.), convince reluctant content providers to use the software, set up a workflow/process, stop mission/scope-creep. or do anything about web site governance.
content is the weak link, either missing or duplicative. or just bad writing. providers who don’t know what the hell they’re doing or are too busy. knows just enough to be dangerous. turnover problems. (the longer I work in this biz, the more I see problems as being social rather than technological.)
treat it like a publication, but expected that it’s *always* up to date.
in a perfect world, you’d have writer-editors.
q: but I missed it…oh, who decides on the info arch? (she called it a “no-brainer” but it’s not when you’re trying to develop it…what she meant is that it’s a nobrainer that you need one, but not to create.) should be created by a team. (gah. committees!)
her freaking slides have too small text and she talks too fast.
give web projects equal priority & budget with print.
design should take back seat to content, standards, accessibility.
“dynamic running calendar” — our calendar is crufty and weird, but it does work for that, at least.
she keeps coming back to that one point: keep content managers focused on content not design. but HOW? also suggests outsourcing programming project “black holes” — odd.
mentions the Krug book. that’s definitely the classic of the genre.
I wish I’d gone to take a nap instead of this, esp since my hands are just tweaking out.
asked if people had web governance, and I don’t know what she means by that term. I think there was a question about governance committees with people who don’t know anything…you’re doooooomed.
switched to a guy; dude he has a loud voice.
Veen quote; but of course. this is all part of the CMS meme of the day.
they have a home-grown CMS.
cmswatch, which I haven’t followed in a while.
he’s going to be covering requirements definition. again with the tiny font, reading his damn slides. nothing annoys me more.
don’t start by researching features of exisitng products. interview users/stakeholders, once you know who they are.
6-9 months from starting analysis to selecting a product, if you build your own, give 20%-40% of dev time to analysis.
I’ve been warping off from the presentation…boring boring boring. Victoria, Aus., cms requirements definition report/tool, tho, that might be worth looking into.
there’s a lot of info on their site, but the presentation isn’t all that engaging. or maybe I’m just too brain-dead.
susan mentions a book called “software requirements”