A Recap of Two Years of Blogging: CMS Migration, Large Site Issues, and more
Submitted by David Hobbs on 13 August 2009 - 9:48am
After a long hiatus, I plan on focusing my blogging energies back on the Hobbs On Tech blog. Looking at my posts over the last couple years on the Hobbs On Tech and WelchmanPierpoint sites (see full list of articles), I see some themes: CMS Migration, Internal CMS Product Management, and Content Re-use / Large Site Issues. As I reflect on future blog entries, I'm stepping back and thinking about what blog posts have been the most successful in my opinion.
CMS Migration
Migrating large web sites is hard. The process is also unpredictable. That said, planning can help structure your approach and reduce risks.
Of the various blog posts related to CMS Migration, perhaps the most useful is this Large Web Site Migration Checklist. After that, a couple other useful resources are:
- Five Suggestions for a Successful CMS Migration
- Why estimate? I'm not getting more resources for this site migration
Content Re-use and Large Site Issues
Large sites are different. "Large site" can mean different things, but here I mean a good deal of content (let's say 100,000 pieces of content or more) and a lot of backend integration. Obviously the management of these sites is crucial, and what I've been consulting on over the past year and a half (strategy, governance, web team, and measurement). That said, I've spent more time blogging on some issues of the details around content re-use and large sites in general. Possibly some of the most interesting have been:
- The Web Diet: How to Simplify Your Web Site
- Some details on communications: Non-technical Input on Technical Standards and Requirements and Corporate Sites and Back Channel Communications
- Some specific multilingual design issues: Interleaving languages and Administrative Title. And a very small post I wish I read when I first started looking at Unicode / UTF-8
- A couple posts on using metadata in content re-use: Beware False Precision in Tagging and Taxonomy Mappings: Be Careful When Integrating
- Lists of questions around Designing RSS Feeds and Multilingual Support
Internal CMS Product Management
Even if the desire is to use a tool straight out of the box, you're probably going to want to customize your CMS. Obviously for large sites with complex backend integration, you'll be doing a lot of this. Aside from the technology, there are the many stakeholders that need to be considered as well.
I advise that someone product manages your internal CMS implementation. This is as oppossed to project managing your CMS implementation for one-time projects (see description of the difference), so that someone is responsible for the ongoing quality of the CMS implementation (treating it as a project). They would:
- Define how the content publishing process should work
- Work with internal training, documentation, technical support, and the technical implementation teams to successfully deploy and maintain a high quality solution
- Clearly articulate the product to the internal user community, including how new features of the core product impact them (for instance, if you are using Documentum, then how changes to the core Documentum product will affect them)
- Evangelize the tool (especially for initial migration)
- Regularly interact with the user community to hear their concerns and suggestions
For more, see the full article that includes ten suggestions for internal CMS Product Management.
Next Steps
What do you think I should be blogging about going forward? Please comment on the Hobbs On Tech site or via twitter at @jdavidhobbs.
Bookmark/Search this post with
Newest Post
Recent Posts
- Thinking seriously of changing my Migration Notes quarterly newsletter to Transformation Notes - this captures web product management too — 59 min 24 sec ago
- Lots of voices chiming in on your website project? Try focused engagment: http://t.co/Xiu1StNc — 3 hours 11 min ago
Information Quality
You and your colleagues at WelchmanPierpoint are ahead of the curve when it comes to content governance. The insight and approach you recommend is valid, comprehensive, and authoritive. However, I think a shift in focus is imminent for all web workers.
The Internet facilitates human conversation, and is manifested as mostly text and visual ques. The hierarchy and order of which users experience the text/visuals is coordinated by organizational executives, designers, and information contributors. Experience is mapped as paths through elements intended to inform or persuade the user. The user, however has their own conceptual model of information they are interacting with, referencing, and updating as revised information experiences.
The quality of information experienced can be segmented and analyzed into about dozen categories (metric or KPI):
Web designers and managers usually contend with only "Composition and Organization", reorganizing, presenting, and contextualizing information assets across a wide variety of formats: Applications, HTTP sites, Marketing Collateral, Business Intelligence, etc.
The expected scope of web professionals is much too limiting, by only classifying individuals as technicians, we eliminate the recursive learning loop. The valuable information a developer discovers during the hours/days/weeks/months ruminating over the business processes you employ are generally wasted when not directly applicable to the current project task, but merely insightful as a concept. By improving the concepts for which we build organizations, processes, and products we can increase the quality, efficiency, and return on work already being accomplished. The quality of information directly correlates to a quality user experience - and vice versa during production/operation a quality: planning phase, execution phase, monitoring phase, and closing phase.
By evaluating and prioritizing why the information is important, we can optimize the message (hierarchy, order, content) for the most appropriate delivery.
Web professionals should facilitate the incremental improvement of information, with technology and creating conceptual models with abstraction and decomposition, before creating a software framework.
Ideas are much more flexible than code, and empty packages don't need decoration.
Keep up the great work,
-Ryan Gensel
twitter.com/readysetproject
www.readysetproject.com
Thanks for your comment
Thanks Ryan for your comment. I think those working on the Web now have an opportunity to grow into working on some of the broader issues you list, as well as others (such as broadly product managing the web presence of large sites for overall quality). I would also expect more differentiation among the roles people play on large sites as well (rather than the sole "webmaster").
Also, please note that I am no longer working for WelchmanPierpoint, but now consulting independently.
Post new comment