Editors are very hard to keep happy. From where I stand, most of my direct interaction points with our customers are usually System Administrators, Architects and/or Developers.
These people are "easy" to satisfy when you're dealing with a system with so many Enterprise features and extension points as SDL Tridion. The questions or scenarios I get asked to expand on will typically boil down to either something that Tridion does already, or something that we can extend Tridion to do.
I have however found the hardest Tridion user of all. The content editor. And that person, my friends, is none other than myself.
Since August last year I started publishing (with Bart Koopman's help) a weekly review of all activities that are in anyway Tridion-Community-related. The schema for this content, as you may expect if you look into it, is rather simple and made up of a few RTF fields alternated with some (limited) taxonomy and multimedia links to the images displayed.
So far nothing abnormal. Content creation is relatively painless, since I have my RTF and I put in it whatever I want.
The problem is when I start thinking about what to do now that I beat my own expectations and this weekly review is becoming an actual important starting point of every week, and there's quite a lot of data in it begging to be mined. To start with, I will need to start archiving this data in an easy to browse archive. Having all content together will eventually become unwieldy (some may argue it's already the case).
The 2nd problem is my own demands on my own data. I want, for instance, to rapidly know which week was the busiest week (week with the highest number of links to blogposts/content). Well, I can't, because I'm using RTF.
I also wanted to do a "Top 10" for the great people in the community that contribute so much every week. Again - almost impossible to do other than counting manually, since the content is in RTF.
Next, I may want to dig into all posts that relate to Event System. Or Deployer Extensions. Or Storage Extensions. Or WCF. You catch my drift, right?
What's the solution?
The solution is in making the Editor's life a living hell. Instead of the ~15 minutes it takes me now to create a weekly review (mostly it's Bart), it will probably turn into an hour long exercise at least. Every entry mentioned in there should actually be its own component, and this component should be classified by Author, Publish/Creation Date, Topic(s), Source. I would normally have no problems presenting to my customer the fact that if you want your content to be rich, YOU need to enrich it.
But it hurts when the customer is me...
4 comments:
Maybe start thinking not to manage this data in a CMS anymore but treat is as large-data and store it in a database, then have a page read that and style. This way you can add 'records' / occasions at the time they are seen, not once a week, and in futere automate this somehow. This circumvents the SDLT GUI which is made for content editors, not data typists :)
I wondered how much effort went into these posts. I (we) appreciate the news and links!
Ingmaru has a point. Could you flip the problem around and treat it as a data mining or SEO exercise?
On the content making side--has anyone created a "split component here" type extension? I'd love to be able to "automagically" break a large set of content into pieces. This might be handy when revisiting large content chunks.
hmmm, some kind of splitcharacter sounds interresting, have to prevent the 'parameter missing' we used to have in vb function calls, as we have no technical 'schema' securing data integrity :)
Thaanks for this
Post a Comment