Hi all,

I took the liberty of changing the title because we are not only talking
about writers anymore. We are talking about automating a process of
publishing the same content in any device the publisher (owner of the
content) he wants.

Some people in this round table believe that by structuring content the
problem is solved, period. 

I would like to say that although I believe that technically I could
make a system (I've done it) that could put this in practice that point
is that the constraints that would have to enforce both to writers and
designers, overall the editorial would far outweigh the benefits of this
concept. After the technology is installed you would see people trying
to circumnavigate how the system works in order to have things done the
way they want it (and have not stated in the beginning or simply thought
that it was an acquired fact) then soon one would start thinking why
have they bothered after all, period.

Structuring Information for Device Independent Publication System
-----------------------------------------------------------------

Schematizing Content 

First there is a difference between Structuring Information in order to
store content in a device independent format ready to render (XML) and
Structuring Information to describe meaning to help searching,
organizing and locating information (Semantic analysis). These are
totally different things that the pnly thing that they have in common is
XML because the objective is totally different.

Structuring information in XML towards device independence is made by
placing the so called Tags within the text in order to work as handlers
for template engines to be able to discern one peace of text from the
other in the context of the document being rendered (humm long
sentence). This identification is needed so that different visual styles
for each peace of text can be applied automatically by a machine. 

Tagging Schemas are modeled in order to encompass the most common visual
design patterns that may need to be applied over the content when
producing and publication and publishing it on a device (paper, PDA,
ITV, Phone, Web, Email, PowerPoint Presentations etc). Pretty good
studies have been made within the realm of technical writing to identify
the tags most used and needed (DocBook XML Schema and other SGML
Schemas). Nevertheless compromise start precisely here in the sense that
if certain tag is not there (in the schema and then in the document
compliant with the schema) then you will not be able to render a peace
text as you may need in the future. 

Depending on the type of publication this pre-built schemas may be
applicable, the problem is that when it is not applicable
straightforwardly (which happens in all sorts Magazine designs,
Marketing Brochures, Text-To-Speech automatic processes, Some Books,
Videos, DVD's, etc) you are on your own. That is, you may be in a
position of trying to predict what is very, very hard to predict. 

Critical problem #1 - When one can't predict what should be in the
Schema, most editors solve this problem by simply not using it and
resort to common practices that implied cutting and pasting content (no
write once anymore) directly into the editor (Pagemaker, Presentation
Editor, Video/Voice Editor, HTML Editor, whatever) that they use to
model the design of the final publication.

Working with images

Developing and maintaining a Schema of Tags used to structure text is
not even the most critical problem within the realm of Structuring
Information for presentation. Content is not made only of text, but
often Images are used a accompany speech (text). To keep the Document
Format independent the use of Images within a document must be declared
in such way that does not cover design, but this is easy. The problem is
that at the time of publication images must be put along with the text
in such way that complies with the design framework defined. Not all
images are placed following the same pattern, one put inline with the
text (warping text around), other in the back of a text, other on left,
other on the right, top bottom etc. This, depending on the type of
publication may be difficult to predict. This is not to mention that
some images nee to be "worked" before publishing it in a device
according to its constraints (this "re-writing" content again). The
point is that the relevance of Images must be tagged by the author and
that may not be compatible with the design practices of the magazine.
Who speaks about images can speak about animations.

Critical problem #2 - When one can't predict the relevance of images in
order to encompass design practiced, most editors solve this problem by
simply not using it and resort to common practices that implied cutting
and pasting content (no write once anymore) directly into the editor
(Pagemaker, Presentation Editor, Video/Voice Editor, HTML Editor,
whatever) that they use to model the design of the final publication.

Writing for Multiple devices
----------------------------

Certain devices such as mobile phones do provide constraints that may be
impossible to present the publication all together. One can solve this
problem by simply providing a part of the content say 10 lines of text
("for more information go to the website or buy the magazine"). 

Critical Problem #3

But then again cutting text automatically is not fail proof. To this,
certain editors decide to write a small summary specific for the medium
or set of mediums (this rewriting text)

Other device may be able to present all text but not some multimedia
objects including images. But then one need to check if by taking an
image of all speech is still coherent (things like "As you can see in
the picture" kills it"). 

Critical Problem #4

If yes, then the speech needs to be rephrased or simply not published in
order to cope with the faulting object.

Certain devices like for example a DVD, CD or even a Web Browser can
hold presentation engines that allow interactivity (even Presentation).
Written text is not interactive by nature, so quite often the text is
augmented with information to provide user interactivity (not just
links). 

Critical Problem #5

This augmentation may mandate the text to be "worked" in order for the
engine to cope with it and provide common interactivity facilities.

Repurposing content is a very subjective process. For instance if I cut
and paste a peace of text of this post and put on a presentation I'm
repurposing part of this document. 

Critical Problem #6

The problem is that one may probably need to rewrite it. Even if not
rewriting there is no possible way of doing this in an automatic way or
maintaining the consistency of information in a automatic manner. But in
one way or another I'm publishing part of the content.

Dealing with mass printing engines
----------------------------------

Ouch so many things to say and so little time.


Dealing with authors - Writing Structured Content
-------------------------------------------------

Today one would need to adopt new editors in order for authors to write
this kind of documents (investment $$$). Furthermore, they need to be
trained and proactively monitor the proper usage of tags (change
management, more $$$). 


Critical Point #7

Anyway this can be done but the problem is that intertwining the hassles
that this gives by itself with the other critical points is this worth
it? That is, after spending lots of $$$ in productivity tools, schema
development, training authors, monitor usage of schemas etc, what if in
the end the content needs to be cut and paste to cope with the specific
channel anyway?

Don't forget that "Writing Once, Publish Anywhere" are advocating that
you do not need to rewrite, cut-and paste or delete content whatever the
device one is publishing to. In other words, less effort with greater
gains. Here is where the cost savings are. So basically any issue
defeating this concept means increased expenses.

There is so much more to say, I can at least list more 10 critical
points showing that this concept is dead on arrival in most cases. Those
explaining why implementing technologically this process may turn to be
more expensive the less technological forms (mix of standard human
oriented practices). For instance this is why the so called WebVan
company went backrupt but this is another story.

This is not to say that in certain situation this does not work. For
instance, in technical literature and such. But one needs to analyze if
actually one wants to publish anywhere? In most cases the ideas is to
publish in two or three channels.

For instance when one writes a book for sure wants to publish on Paper,
perhaps on a PDA or even on a Web Site. But for that matter one can
simply use the plain old HTML with certain policies in the middle (but
it's not hard).

I'm glad to reply comments off list.

Best regards,

Nuno Lopes
Independent Consultant

PS: My text is long because I have little time to write it shorter while
not compromising what I want to say.


--
http://cms-list.org/
trim your replies for good karma.

Reply via email to