I guess I have said it enough times - I am in a rather privileged position within the WCM space, as I get to see a lot of what really is implemented by our customer base (mostly in the highly regulated financial industry), I get to play with magic crystal balls, and I get to hear about what experts and analysts think content people should be doing now, and in the future.
And I admit, I am extremely confused, because the pieces don't fit together.
Let me try to explain what I mean with this.
On the one hand, we have simplicity. The people who select WCM systems (please note that I am not saying "Content Editors") want a "Facebook-like experience" creating content. They want the simplicity of WordPress or perhaps Blogger (which I use) when creating content.
On the other hand we have compliance and content governance. People want to control content life cycles, trace back the origins of content from its inception to its inclusion on a given page, to its transformation into a Call To Action on the home page, to its decommissioning a year later into the "outdated content" bin.
And finally, on the last hand (yes, I know those are three hands, get someone to lend you one), we want content re-purposing and targeting. We want content that can be used across all channels - Web, Email, Digital Signage, Facebook, Twitter, IOS/Android Apps, Google Glasses and what not.
And this is where I get confused.
Simplicity means one thing - less flexibility. Sure, you can make very reusable content with WordPress, but then you're putting the onus onto your editors to use the correct html mark-up for your content. I agree that a lot can be achieved with some smart plug-ins, but how do you prepare for the next channel that you don't know about yet? And especially, how do you create truly "re-formattable" content when you want simplicity, which by its own definition mixes content and layout?
And governance. Governance is impossible without metadata. Usually, it requires metadata about your metadata (ever tried defining a release policy linked to content models?). Again, sure, we can try having your editors enter that metadata in their simple-to-create-content web tool. Doesn't look so simple anymore, does it?
Creating content that can be re-purposed for various channels, including those that don't exist yet, and allows for personalization is where the whole thing falls apart in my view.
How can you have content that was simple to create - web based, WordPress like interface, loads of drag-and-drop widgets and SEO optimizers and navigation managers and whatnots - and have that content still comply to a strict schema, like those specified in schema.org? Sure, you can look at semantic engines - like Apache Stanbol - to help your editorial team get their content right, but how is that going to help you determine which headline to show on your iPhone app?
Don't take me wrong, I'm not trying to say that creating content should be hard - on the contrary, it must be easy. But creating content that can live beyond the constraints of a web page requires thinking beyond drag-and-drop and easy-to-use (actually, having to use your mouse when creating content is a terrible thing and completely breaks the flow of work) - you have to think about content modularity and new delivery models.
My view on the future of content is that layout and look-and-feel will disappear, and consumers of your content will care about nothing else than the content itself, the layout will be based on their preferences and their own metadata, with smart apps - in whatever is the device-du-jour - taking on the task of formatting that content for display. Don't think RSS, think Open Data+schema.org.
So, unless I'm terribly wrong (which is always possible and known to have happened many times), the emphasis on Customer Experience Management requires more content structure, not less. And more content structure, today, means that editors must have an abstract view of content, focus less on how it looks and more on how it's structured, so that the context in which the content is displayed can adapt to the customer's expectation. And to do that, we have to think beyond pages and re-think content as individual entities that can be manipulated and formatted for display in whatever device or app the customer may chose to consume it in. And that my friends, is against the view that content editing should be a simple, word-editing-like experience. Just like word editors were built for a world in which your main goal was to print that document once it was finished, many WCM tools out there are built to publish web pages, and web pages will be just a tiny fraction of how content is consumed in the future... (just like the number of people that actually print documents once they're finished with their editing).
Também conhecido como .nuno, Nuno Linhares, Nuno Pereira, Matthaus... enfim, escolha um! This weblog may contain content in both Portuguese and English. Try freetranslation.com if you can't read both...
Showing posts with label wcm. Show all posts
Showing posts with label wcm. Show all posts
Sunday, July 07, 2013
Saturday, February 11, 2012
SweetEdit
I've spent the last week in SDL's office in Amsterdam with some of the Tridion masters (including Alvin Reyes and Mihai Cadariu) for some knowledge transfer from R&D regarding our soon-to-be-launched re-vamped, re-thought, re-designed and re-super-improved SiteEdit 2012.
As typically happens in this type of Knowledge Transfer, the information flow always goes both ways - we learn from R&D on what the tool is expected to do while showing back to R&D how we expect it to behave under the blueprint abuse that we constantly put Tridion through.
And while it was clear that the tool is still in development (a couple of buttons were not enabled yet on the build we used) it was also clear that what is in place really works amazingly well.
I really don't even know where to start when it comes to SiteEdit, there's just so much being added and/or modified that it's hard to start.
So I'll start with the simple improvements I've seen.
Absolutely amazing and surprisingly stable and fast. Can't wait for it to come out.
As typically happens in this type of Knowledge Transfer, the information flow always goes both ways - we learn from R&D on what the tool is expected to do while showing back to R&D how we expect it to behave under the blueprint abuse that we constantly put Tridion through.
And while it was clear that the tool is still in development (a couple of buttons were not enabled yet on the build we used) it was also clear that what is in place really works amazingly well.
I really don't even know where to start when it comes to SiteEdit, there's just so much being added and/or modified that it's hard to start.
So I'll start with the simple improvements I've seen.
- Defining Page Types (a prototype from which you can create a new page) is as simple as checking a box on _any_ existing page.
- Adding an image to Tridion's "content library" is as simple as dragging & dropping it into your existing library
- SessionPreview architecture shows changes to pages dynamically without the need to republish the page or any of component presentations (and avoiding any publishing queue bottleneck).
- The whole wording of this interface is much user-friendlier than Tridion's language in general, which tends to be very technical - Content instead of Components, "Edit everywhere" instead of "Edit parent"
- Ability to associate component templates with page templates - so that users will only see the options that make sense to use in any given page - and present these to the user as "Content Types"
Editing a "shared" component:
Selecting a page type for a new page:
Editing Content:
Selecting an image from the library:
Absolutely amazing and surprisingly stable and fast. Can't wait for it to come out.
Sunday, March 27, 2011
Rants on Tridion implementations
Those of you who know me, and work/worked with me, know that my job is not always an easy or necessarily happy one. In a nutshell, I tend to tell customers that "if you see me walk into your project, it means you're in trouble".
So, if you're about to start implementing Tridion, and you don't want to see me walk into your project to fix it, here's a few things to remember:
Before you try to do XYZ with Tridion, try to do it without Tridion. Seriously, if you don't know what the expected output of a page is, how do you expect to write a template that "does" it?
If you think you know WCM and therefore learning Tridion is a non-issue, think again. Then re-think. And a year later re-evaluate what you know about WCM. If there is one thing I can tell about Tridion and the other WCM packages available, is that Tridion IS different - and customers buy the software for those EXACT reasons that make it different. If you're planning to implement Tridion just like you would [insert random WCM package here], then why don't you go implement [random WCM package] instead? Many times I've heard things like "We're not planning to use BluePrinting", "why can't I just create pages" and "feature XYZ should be out of the box" (this last one is my favourite, since everyone wants XYZ done differently, but out of the box anyway). The higher-up people that made the decision to buy Tridion were likely triggered to do it based on Blueprinting, Component-based content and the extensibility points offered - not because they thought the implementation team likes those concepts.
Stop being a language zealot. So what if you need to understand Java for deployer extensions? And so what if you need to use c# for Event Systems? It's not as if programmers care about that? You should care functionality and complete API, not what language. If language _really_ is an issue for you, then write your own mediator, there's even a sample for that in the documentation.
Make sure you understand that you will always need 2 types of people in your development team: Web designers and programmers. Web designers will not do a good job writing templates, and programmers are typically bad web designers. It is one of the best features of the product that both teams can work together by focusing on different template building blocks. So use it.
Think before you do anything. This should be a no-brainer, right? Some examples...
Everyone wants to implement SmartTarget, but it is OH-SO-RARE that people actually know what they want to do with it. Developers don't get it, they think they could have done everything themselves through code (missing the point that this is exactly what SmartTarget is about).
Audience Segmentation? You need to know the _current_ audience before you start segmenting it.
And I could go on ranting, but enough negativity for today. Here's how I tell people to learn Tridion.
OK, enough ranting for the day, happy thoughts and enjoy implementing Tridion. It is an amazing piece of software, and once you get it, you will think differently about WCM systems.
So, if you're about to start implementing Tridion, and you don't want to see me walk into your project to fix it, here's a few things to remember:
Before you try to do XYZ with Tridion, try to do it without Tridion. Seriously, if you don't know what the expected output of a page is, how do you expect to write a template that "does" it?
If you think you know WCM and therefore learning Tridion is a non-issue, think again. Then re-think. And a year later re-evaluate what you know about WCM. If there is one thing I can tell about Tridion and the other WCM packages available, is that Tridion IS different - and customers buy the software for those EXACT reasons that make it different. If you're planning to implement Tridion just like you would [insert random WCM package here], then why don't you go implement [random WCM package] instead? Many times I've heard things like "We're not planning to use BluePrinting", "why can't I just create pages" and "feature XYZ should be out of the box" (this last one is my favourite, since everyone wants XYZ done differently, but out of the box anyway). The higher-up people that made the decision to buy Tridion were likely triggered to do it based on Blueprinting, Component-based content and the extensibility points offered - not because they thought the implementation team likes those concepts.
Stop being a language zealot. So what if you need to understand Java for deployer extensions? And so what if you need to use c# for Event Systems? It's not as if programmers care about that? You should care functionality and complete API, not what language. If language _really_ is an issue for you, then write your own mediator, there's even a sample for that in the documentation.
Make sure you understand that you will always need 2 types of people in your development team: Web designers and programmers. Web designers will not do a good job writing templates, and programmers are typically bad web designers. It is one of the best features of the product that both teams can work together by focusing on different template building blocks. So use it.
Think before you do anything. This should be a no-brainer, right? Some examples...
Everyone wants to implement SmartTarget, but it is OH-SO-RARE that people actually know what they want to do with it. Developers don't get it, they think they could have done everything themselves through code (missing the point that this is exactly what SmartTarget is about).
Audience Segmentation? You need to know the _current_ audience before you start segmenting it.
And I could go on ranting, but enough negativity for today. Here's how I tell people to learn Tridion.
- Get yourself a development environment to play with.
- Find your way into the Tridion Developer Forum (via Customer Support).
- Get yourself enrolled into a Technical Training. Really. It will open your eyes and save you a lot of time.
- Read the template implementation guide. I am not kidding, RTFM can do miracles for you.
- Now implement a simple, one-page site. Make sure all content is translatable via blueprinting, and editable via SiteEdit.
- Once that's working, implement the multiple language versions of that site.
OK, enough ranting for the day, happy thoughts and enjoy implementing Tridion. It is an amazing piece of software, and once you get it, you will think differently about WCM systems.
Sunday, February 13, 2011
Tutorials and Copyright...
I'm having a bit of a conundrum here. I wrote a few quite extensive Tutorials on Tridion 2011 which I want to make public via Tridion World but I can't understand if I'm infringing copyright or not.
Let me explain: In these tutorials there are very detailed, step-by-step instructions with loads of screenshots. My goal here is to make sure I don't ever again get basic questions like "what do I need to install for Tridion to use an Oracle database back end?" or "What are the Windows 2008 R2 Roles I must install?".
Of course, having Tridion screenshots is NOT copyright infringement, because I work for the copyright owner and I would be distributing it via the copyright's owner website. I am allowed to create those screenshots and empowered to distribute them via Tridion World (but I am not allowed to distribute it via my own website, even though many other people do that and we don't seem to care much about it).
The way I see it, I can't really distribute the Oracle Client installation screenshots, or Windows 2008 install, or the SQL Server 2008 R2 installation screenshots.
And if I remove those screenshots, the tutorials are not as detailed as I need them to be.
Anyone out there with suggestions? Should I contact the 3rd parties (Oracle and Microsoft mostly) and ask for their approvals?
I'll figure it out...
Update: found some info on Screenshot copyright in general and Microsoft guidelines for screenshots, and it looks like I'm in the clear, since I do not modify any of the screenshot content, do clearly identify it as being from an Oracle or Microsoft product and don't do anything evil with it.
So, new tutorials to show up soon in Tridion World
Let me explain: In these tutorials there are very detailed, step-by-step instructions with loads of screenshots. My goal here is to make sure I don't ever again get basic questions like "what do I need to install for Tridion to use an Oracle database back end?" or "What are the Windows 2008 R2 Roles I must install?".
Of course, having Tridion screenshots is NOT copyright infringement, because I work for the copyright owner and I would be distributing it via the copyright's owner website. I am allowed to create those screenshots and empowered to distribute them via Tridion World (but I am not allowed to distribute it via my own website, even though many other people do that and we don't seem to care much about it).
The way I see it, I can't really distribute the Oracle Client installation screenshots, or Windows 2008 install, or the SQL Server 2008 R2 installation screenshots.
And if I remove those screenshots, the tutorials are not as detailed as I need them to be.
Anyone out there with suggestions? Should I contact the 3rd parties (Oracle and Microsoft mostly) and ask for their approvals?
I'll figure it out...
Update: found some info on Screenshot copyright in general and Microsoft guidelines for screenshots, and it looks like I'm in the clear, since I do not modify any of the screenshot content, do clearly identify it as being from an Oracle or Microsoft product and don't do anything evil with it.
So, new tutorials to show up soon in Tridion World
Subscribe to:
Posts (Atom)



