I never thought I'd be writing under this title, but tweeting definitely has its uses. I was recently at a conference in Budapest where several members of the audience were tweeting from their cell phones. At the same time, the conference organizers were showing the tweet thread on the screen behind the panel. Great idea. Unfortunately, the tweeters mainly limited themselves to reporting to the outside world some key points being made by the panel.
This is where I got frustrated. I had several substantive comments to make on various things that the panel were saying. For example, this was a discussion on the subject, "Has Translation Technology a Future?" and one of the panelists asked herself whether technical writers had tool standards and how they used them, only to have another tell her he was certain they did. It's frustrating to have the parallel activity of technical writer and to know that aside from ISO 9000, they don't, and that standard is too sketchy to be of any use. As for authoring itself, the best they have is an architecture, DITA, and approaches like info-mapping. That would have made a perfect tweet, and would have livened up the debate.
Maybe next time I'll be equipped.
vendredi 27 mai 2011
jeudi 26 mai 2011
SDL LiveContent 2011 Death of Technical Documentation as we know it
This catchy SDL marketing release title (see http://is.gd/qc8yhG) has cost me a certain amount of time.
First of all, reading the release whetted my appetite for more information. So, I followed the SDL link to read the white paper and a case study. Frankly at the end, except for one brief phrase hidden in a mass of verbiage, I wasn't very much wiser. Was LiveContent a tool, a framework, a platform, software as a service or what? In terms of the technical documentation that you would write and publish using it, was it single sourcing, a structured authoring environment, minimalism, a content value chain or what? Is it web-based, client-server, a content management system, component content management or what?
I quickly learned that SDL considers it to be nothing less than a paradigm shift. I wonder how many products have made that claim in the last twenty years? The main white paper was perhaps the most informative of the three documents. However, in SDL's depiction of the supposed paradigm shift, publishing technical information before the shift would have only taken place in siloes, each impervious to the other. These siloes are presented very convincingly as if this view of things is the only one that could possibly be true. Trouble is, it isn't the only one. It's an exaggeration of just one tendency out of many, and one that I doubt ever existed in such an extreme form. We learn, for example, that Product Marketing, Product managers, technical writers and support personnel wrote respectively, specifications, design information, product documentation and support information, all for varying publics.
This does not correspond to my own experience at all. Technical documentation can come under the remit of the CTO or of Product Marketing, or can be split up under the aegis of the various product managers. Support identifies documentation errors and gaps, and communicates them to the technical writing team, which corrects them or extends the documentation. Nothing like setting up straw dogs to prove your point, is there?
Obviously, publishing technical information has been gradually moving in the direction sketched out in the white paper for years. So, although there are certainly trends in technical documentation, the existence of a paradigm shift is far from obvious. Certainly, any shift, whether a radical one like a "paradigm shift" or a gradual one, relies on far more than - as suggested in the SDL marketing material - tools.
Tools alone, without methods and procedures, mean nothing. They allow us to implement our methods and procedures, but nothing more. And trying to use them without solid methods and procedures that are reviewed on a regular basis can lead to catastrophe.
Given the industry trend and the time scale that it's taking place in, it will come as no surprise that SDL LiveContent is only one solution out of many. There are also Bluestream, Componize for Alfresco, DITA Exchange built on top of Sharepoint, Ixiasoft's TEXTML server and DITA CMS? Interestingly, each solution takes a different approach. This could well mean that one of them may offer tools similar to the ones that you already use, thereby reducing the learning curve.
In this context, what is LiveContent's USP? Identifying and explaining the USP from a technical standpoint should be the goal of any white paper, and the case studies provided along with it should support this
message clearly. Not to do so and, at the same time, to make radical unsupported claims is to oversell. A very risky tactic indeed. Since SDL acquired Tridion a few years ago, they have had the potential to be a leader in this area. If they have indeed realized this potential, let them communicate their leadership to us clearly.
First of all, reading the release whetted my appetite for more information. So, I followed the SDL link to read the white paper and a case study. Frankly at the end, except for one brief phrase hidden in a mass of verbiage, I wasn't very much wiser. Was LiveContent a tool, a framework, a platform, software as a service or what? In terms of the technical documentation that you would write and publish using it, was it single sourcing, a structured authoring environment, minimalism, a content value chain or what? Is it web-based, client-server, a content management system, component content management or what?
I quickly learned that SDL considers it to be nothing less than a paradigm shift. I wonder how many products have made that claim in the last twenty years? The main white paper was perhaps the most informative of the three documents. However, in SDL's depiction of the supposed paradigm shift, publishing technical information before the shift would have only taken place in siloes, each impervious to the other. These siloes are presented very convincingly as if this view of things is the only one that could possibly be true. Trouble is, it isn't the only one. It's an exaggeration of just one tendency out of many, and one that I doubt ever existed in such an extreme form. We learn, for example, that Product Marketing, Product managers, technical writers and support personnel wrote respectively, specifications, design information, product documentation and support information, all for varying publics.
This does not correspond to my own experience at all. Technical documentation can come under the remit of the CTO or of Product Marketing, or can be split up under the aegis of the various product managers. Support identifies documentation errors and gaps, and communicates them to the technical writing team, which corrects them or extends the documentation. Nothing like setting up straw dogs to prove your point, is there?
Obviously, publishing technical information has been gradually moving in the direction sketched out in the white paper for years. So, although there are certainly trends in technical documentation, the existence of a paradigm shift is far from obvious. Certainly, any shift, whether a radical one like a "paradigm shift" or a gradual one, relies on far more than - as suggested in the SDL marketing material - tools.
Tools alone, without methods and procedures, mean nothing. They allow us to implement our methods and procedures, but nothing more. And trying to use them without solid methods and procedures that are reviewed on a regular basis can lead to catastrophe.
Given the industry trend and the time scale that it's taking place in, it will come as no surprise that SDL LiveContent is only one solution out of many. There are also Bluestream, Componize for Alfresco, DITA Exchange built on top of Sharepoint, Ixiasoft's TEXTML server and DITA CMS? Interestingly, each solution takes a different approach. This could well mean that one of them may offer tools similar to the ones that you already use, thereby reducing the learning curve.
In this context, what is LiveContent's USP? Identifying and explaining the USP from a technical standpoint should be the goal of any white paper, and the case studies provided along with it should support this
message clearly. Not to do so and, at the same time, to make radical unsupported claims is to oversell. A very risky tactic indeed. Since SDL acquired Tridion a few years ago, they have had the potential to be a leader in this area. If they have indeed realized this potential, let them communicate their leadership to us clearly.
mercredi 11 mai 2011
Nullius in verba
In a question session after a very interesting key-note speech on terminology at a recent conference, someone asked a question about term bases in machine translation. I made the point that machine translation has been around for a very long time, and that its vogue today is mainly due to Google Translate, a tool that does not implement linguistic resources such as grammatical rules and term bases. During the networking event of the same day, someone who considers himself a great expert on translation technology came up to me to tell me that I was quite wrong. A Google executive supposedly told this expert at a conference in Australia that Google Translate uses terminology. Of course, this statement could have several interpretations:
1. you can obviously feed glossaries to Google Translate as two files one in the source language, and the other in the target language, and tell Google Translate that they're translations of each other;
2. you can compare statistical analysis of parallel texts with statistical terminology extraction programs.
What you can't do, is assume that, like some other machine translation tools, Google's purely statistical algorithm has a terminological loop that compares texts that it is translating to more complex terminological information (such as information on field, genre, grammar, use etc.) or grammatical information.
In fact, the person who contradicted me, and who apparently held this exact view, failed to provide any context. Can we assume that the reported statement was a marketing ploy, i.e. it's better to be all things to all people, if you can? I suspect so. In any case, my answer at the time was that we would just have to agree to disagree. My answer today is the motto of the Royal Society: nullius in verba, i.e. take no man's word for it. And by the way, Google is so unconcerned by debates between the statistically-oriented and the linguistically-oriented schools of machine translation, that they don't even attend the professional conferences in this field (see "Why the Machine Translation Crowd hates Google"). Why should they? What they have realized is that their huge resources of data - from web sites to books - along with their resources in terms of computing power (thousands of servers around the world), put them in a unique position to do statistical machine translation. In other words, machine translation for them is a way to generate another revenue stream from their data and their infrastructure. So, take no man's word for it.
Actually, to return to the subject of marketing, taking someone's word for something when that person works for a software company, is highly risky. Even within the same company. Years ago, I worked for a CAD/CAM software publisher. They set out to develop and market a state of the art design tool to try to take the lead in the industry. At a meeting where the development team presented the features of the product, they used animation to show what Designer, the new product, could do. The marketing team was impressed. So that's Designer, they said. Yes, answered the development team. The trouble is that neither of them meant the same thing: the marketing team thought that they had seen the finished product in action; the development team actually meant that it was their as yet unreached goal. This misunderstanding led the marketers to oversell an as yet non-existent product. A serious mistake that they paid a very high price for in the end. So, really, in technical areas, take no man's word for it.
1. you can obviously feed glossaries to Google Translate as two files one in the source language, and the other in the target language, and tell Google Translate that they're translations of each other;
2. you can compare statistical analysis of parallel texts with statistical terminology extraction programs.
What you can't do, is assume that, like some other machine translation tools, Google's purely statistical algorithm has a terminological loop that compares texts that it is translating to more complex terminological information (such as information on field, genre, grammar, use etc.) or grammatical information.
In fact, the person who contradicted me, and who apparently held this exact view, failed to provide any context. Can we assume that the reported statement was a marketing ploy, i.e. it's better to be all things to all people, if you can? I suspect so. In any case, my answer at the time was that we would just have to agree to disagree. My answer today is the motto of the Royal Society: nullius in verba, i.e. take no man's word for it. And by the way, Google is so unconcerned by debates between the statistically-oriented and the linguistically-oriented schools of machine translation, that they don't even attend the professional conferences in this field (see "Why the Machine Translation Crowd hates Google"). Why should they? What they have realized is that their huge resources of data - from web sites to books - along with their resources in terms of computing power (thousands of servers around the world), put them in a unique position to do statistical machine translation. In other words, machine translation for them is a way to generate another revenue stream from their data and their infrastructure. So, take no man's word for it.
Actually, to return to the subject of marketing, taking someone's word for something when that person works for a software company, is highly risky. Even within the same company. Years ago, I worked for a CAD/CAM software publisher. They set out to develop and market a state of the art design tool to try to take the lead in the industry. At a meeting where the development team presented the features of the product, they used animation to show what Designer, the new product, could do. The marketing team was impressed. So that's Designer, they said. Yes, answered the development team. The trouble is that neither of them meant the same thing: the marketing team thought that they had seen the finished product in action; the development team actually meant that it was their as yet unreached goal. This misunderstanding led the marketers to oversell an as yet non-existent product. A serious mistake that they paid a very high price for in the end. So, really, in technical areas, take no man's word for it.
Inscription à :
Articles (Atom)