atw: Re: austechwriter Digest V10 #42
- From: Bill Parker <bill@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- To: austechwriter@xxxxxxxxxxxxx
- Date: Mon, 27 Feb 2012 17:37:14 +0800
Gee that's a strong word - obsessed. What else is there to do in what is
nearly a monopoly market?
Bill
On 27/02/2012, at 5:25 PM, Daniel Oster wrote:
> If technology should not be our master, why are so many tech writers obsessed
> with MS Word?
>
>
> Sent with Sparrow
>
> On Monday, 27 February 2012 at 5:10 PM, FreeLists Mailing List Manager wrote:
>
>> austechwriter Digest Sun, 26 Feb 2012 Volume: 10 Issue: 042
>>
>> In This Issue:
>> Re: Vale technical writing?
>> Re: Vale technical writing?
>> Re: Vale technical writing?
>> Mastercard Technology moments.
>> XML More
>> Re: Vale technical writing?
>> Re: Vale technical writing?
>>
>> ----------------------------------------------------------------------
>>
>> From: "Christine Kent" <cmkentau@xxxxxxxxx>
>> Subject: Re: Vale technical writing?
>> Date: Sun, 26 Feb 2012 20:28:28 +1100
>>
>> It's a bigger issue than even Tony is saying, and I see XML as a step on a
>> path rather than a destination.
>>
>> Publishing failed to grasp the significance of the changes being brought
>> about by technology and is going broke fast. Those changes are not just
>> about the tools used. For example, in publishing, it is not just about
>> putting a novel into a format for a reader. It is about questioning if, as
>> a society, novels are morphing into something else, and if so, what?
>>
>>
>> When you try to convert anything you have written for paper format to some
>> kind of on-line format, you realise that you have to change what you want to
>> communicate and the way you communicate it as well as the tools you will use
>> to communicate it through. The form IS, to a certain extent, determining
>> the function.
>>
>>
>> My personal learning on this level is that everything I write must be in
>> screen sized bites, no matter what I might prefer, and my suspicion is that
>> we have bred and trained a generation that is only capable of both
>> structuring and decoding information that IS in screen sized bites.
>>
>>
>> While there are still "old school" people who read novels, who can read
>> manuals particularly for high level technical information, and who do learn
>> something in a classroom, there will be some need for materials produced the
>> way we produce them now, but many of us are approaching retirement age and
>> when we are gone, what will best serve the generations following us through?
>>
>>
>> I personally have no idea where this will end with both technical writing
>> and instructional design, but I do know that the current forms for both are
>> culturally archaic, in that much of what we do serves little or no real
>> purpose. We all know the door stop jokes, and we also know that much of the
>> training we deliver does not result in well trained users of whatever. I
>> would not be expressing Tony's certainty that XML is the future, but I am
>> certain that the past is not the future.
>>
>>
>> I wish is could be. I don't much like this new world. But I imagine we are
>> stuck with it.
>>
>>
>> Christine
>>
>>
>> From: austechwriter-bounce@xxxxxxxxxxxxx
>> [mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Margaret Hassall
>> Sent: Sunday, 26 February 2012 12:46 PM
>> To: austechwriter@xxxxxxxxxxxxx
>> Subject: atw: Re: Vale technical writing?
>>
>>
>> Hi Geoffrey and Austechies,
>>
>>
>> Sounds like a great talking point to me, and I'll probably ask Tony some of
>> those questions at the presentation (when I hear more than just the
>> outline).
>>
>>
>> But I think the issue has been around for a while - even before XML and DITA
>> arrived. For a long time we have had the "content is king" versus "quality
>> or crappy content" versus "but it needs to be formatted" arguments (TECHWR-L
>> archives contain hundreds of posts on this and similar topics).
>>
>>
>> Good format can help usability, readability, and make content far more
>> accessible, and crappy content is NOT better than no content at all. But I
>> have seen way too many people so focused on getting a format to work that
>> they run out of time to get the content right. Their hand-crafting produces
>> good looking documents but is their content up to standard and can it be
>> re-used?
>>
>>
>> I now have to deliver information in many different channels - old fashioned
>> PDFs for traditional user guides, online help (CHM, webhelp), wikis, and now
>> I'm looking at eReaders and their various formats. My first efforts with
>> eReaders sent me back to hand-crafting. With new delivery formats coming
>> about all the time, I don't think we have time for hand-crafting any more.
>>
>>
>> And output is not the only issue: I have to build many documents using input
>> from a wide range of people - I'd like to streamline this workflow as much
>> as possible. I often undo their careful tweaking so that I can use their
>> content with other work.
>>
>>
>> What I'm looking for from the presentation is to find out if tools have
>> evolved enough so that they will allow me to concentrate on the CONTENT and
>> workflow without having to worry too much about the formatting. Like the car
>> drivers of old, I think it is a fair question to ask if I'd be prepared to
>> put up with a simpler look if it meant my information could go further.
>> While the output may not be as "whizz-bang" as I can create with other tools
>> at the moment, this doesn't mean it will always be like that.
>>
>>
>> While I agree that delivering information to people that is relevant,
>> readable, and usable is an overriding technical writing goal, surely we
>> should always be looking for ways to make that process more efficient.
>>
>>
>> I'll be at the talk, and happy to discuss this further.
>>
>>
>> Margaret - wearing her Tech Writer hat, but acknowledges her President, ASTC
>> Vic hat as well.
>>
>>
>>
>> On 26 February 2012 11:33, Geoffrey Marnell wrote:
>>
>> Hi austechies
>>
>> Some of you will have received, as I did, an invitation to attend an ASTC
>> presentation by DITA evangelist Dr Tony Self. Here is the outline of the
>> presentation Tony intends to give, exactly as received in the invitation:
>>
>> <snip
>>
>> ...
>>
>> ...>
>>
>>
>> We write to impart practical information to people who need it, and in ways
>> that maximise their uptake of that information. That's our overriding goal
>> as technical writers, and it's why most of us do fuss about issues of
>> readability and usability. So why should we adopt any technology that limits
>> us in our ability to meet that overriding goal? Technology should not be our
>> master; it is the needs of our readers that is paramount.
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> From: Bill Parker <bill@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>> Subject: Re: Vale technical writing?
>> Date: Sun, 26 Feb 2012 19:42:44 +0800
>>
>> Christine,
>> I wonder indeed why "old school" sounds derogatory ( I know you did not mean
>> it that way) but it just sounds as if the march of high tech tech is leaving
>> some of us behind. Well, I protest. In my previous post about offshore
>> engineers and scientists in the FPSO area, XML is about as far from their
>> daily lives as a snowball in Karratha.
>>
>> I work in another area as a volunteer ( bush fire brigade) and recently
>> chaos has reigned because some clever salesman has "sold" the idea of
>> changing radio comms from VHF mid band to VHF high band. Why? Because we can
>> and "it's the future". Now we have a far more complex system that both
>> serves well and fails spectacularly. And this on the fire ground!
>>
>> My take on this is that culturally archaic stuff works. We are reaching the
>> stage when technology rules and the blokes who need it to work on the ground
>> are stuffed.
>>
>> If somebody says, why not XML? I might say, let's get the sentence structure
>> right first and not get tied up in the arcane.
>>
>>
>> Bill
>>
>>
>> On 26/02/2012, at 5:28 PM, Christine Kent wrote:
>>
>>> It’s a bigger issue than even Tony is saying, and I see XML as a step on a
>>> path rather than a destination.
>>> Publishing failed to grasp the significance of the changes being brought
>>> about by technology and is going broke fast. Those changes are not just
>>> about the tools used. For example, in publishing, it is not just about
>>> putting a novel into a format for a reader. It is about questioning if, as
>>> a society, novels are morphing into something else, and if so, what?
>>> When you try to convert anything you have written for paper format to some
>>> kind of on-line format, you realise that you have to change what you want
>>> to communicate and the way you communicate it as well as the tools you will
>>> use to communicate it through. The form IS, to a certain extent,
>>> determining the function.
>>> My personal learning on this level is that everything I write must be in
>>> screen sized bites, no matter what I might prefer, and my suspicion is that
>>> we have bred and trained a generation that is only capable of both
>>> structuring and decoding information that IS in screen sized bites.
>>> While there are still “old school” people who read novels, who can read
>>> manuals particularly for high level technical information, and who do learn
>>> something in a classroom, there will be some need for materials produced
>>> the way we produce them now, but many of us are approaching retirement age
>>> and when we are gone, what will best serve the generations following us
>>> through?
>>> I personally have no idea where this will end with both technical writing
>>> and instructional design, but I do know that the current forms for both are
>>> culturally archaic, in that much of what we do serves little or no real
>>> purpose. We all know the door stop jokes, and we also know that much of the
>>> training we deliver does not result in well trained users of whatever. I
>>> would not be expressing Tony’s certainty that XML is the future, but I am
>>> certain that the past is not the future.
>>> I wish is could be. I don’t much like this new world. But I imagine we are
>>> stuck with it.
>>> Christine
>>> From: austechwriter-bounce@xxxxxxxxxxxxx
>>> [mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Margaret Hassall
>>> Sent: Sunday, 26 February 2012 12:46 PM
>>> To: austechwriter@xxxxxxxxxxxxx
>>> Subject: atw: Re: Vale technical writing?
>>> Hi Geoffrey and Austechies,
>>> Sounds like a great talking point to me, and I'll probably ask Tony some of
>>> those questions at the presentation (when I hear more than just the
>>> outline).
>>> But I think the issue has been around for a while - even before XML and
>>> DITA arrived. For a long time we have had the "content is king" versus
>>> "quality or crappy content" versus "but it needs to be formatted" arguments
>>> (TECHWR-L archives contain hundreds of posts on this and similar topics).
>>> Good format can help usability, readability, and make content far more
>>> accessible, and crappy content is NOT better than no content at all. But I
>>> have seen way too many people so focused on getting a format to work that
>>> they run out of time to get the content right. Their hand-crafting produces
>>> good looking documents but is their content up to standard and can it be
>>> re-used?
>>> I now have to deliver information in many different channels - old
>>> fashioned PDFs for traditional user guides, online help (CHM, webhelp),
>>> wikis, and now I'm looking at eReaders and their various formats. My first
>>> efforts with eReaders sent me back to hand-crafting. With new delivery
>>> formats coming about all the time, I don't think we have time for
>>> hand-crafting any more.
>>> And output is not the only issue: I have to build many documents using
>>> input from a wide range of people - I'd like to streamline this workflow as
>>> much as possible. I often undo their careful tweaking so that I can use
>>> their content with other work.
>>> What I'm looking for from the presentation is to find out if tools have
>>> evolved enough so that they will allow me to concentrate on the CONTENT and
>>> workflow without having to worry too much about the formatting. Like the
>>> car drivers of old, I think it is a fair question to ask if I'd be prepared
>>> to put up with a simpler look if it meant my information could go further.
>>> While the output may not be as "whizz-bang" as I can create with other
>>> tools at the moment, this doesn't mean it will always be like that.
>>> While I agree that delivering information to people that is relevant,
>>> readable, and usable is an overriding technical writing goal, surely we
>>> should always be looking for ways to make that process more efficient.
>>> I'll be at the talk, and happy to discuss this further.
>>> Margaret - wearing her Tech Writer hat, but acknowledges her President,
>>> ASTC Vic hat as well.
>>> On 26 February 2012 11:33, Geoffrey Marnell wrote:
>>> Hi austechies
>>>
>>> Some of you will have received, as I did, an invitation to attend an ASTC
>>> presentation by DITA evangelist Dr Tony Self. Here is the outline of the
>>> presentation Tony intends to give, exactly as received in the invitation:
>>>
>>> <snip
>>> ...
>>> ...>
>>> We write to impart practical information to people who need it, and in ways
>>> that maximise their uptake of that information. That's our overriding goal
>>> as technical writers, and it's why most of us do fuss about issues of
>>> readability and usability. So why should we adopt any technology that limits
>>> us in our ability to meet that overriding goal? Technology should not be our
>>> master; it is the needs of our readers that is paramount.
>>
>>
>>
>> ------------------------------
>>
>> Subject: Re: Vale technical writing?
>> From: James Hunt <jameshunt@xxxxxxxxxxxxx>
>> Date: Sun, 26 Feb 2012 23:30:06 +1000
>>
>> The XML guru Norman Walsh once wrote (in
>> http://norman.walsh.name/2004/12/07/webarchPdf) as follows.
>> "[W]eb browsers suck at printing. Never mind the fact that some browsers do
>> a better job than others, they all suck. And CSS is never going to fix it.
>> Did you hear me? CSS is never going to fix it. There are lots of programs
>> that can produce more or less nice looking pages. TeX is an historical
>> favourite, as is troff. More modern tools include various desktop publishing
>> packages. In the XML world, the obvious tool is XSL, the Extensible Style
>> Language, not the Transformation language. ¶
>>
>> "It's important to realise, however, that XSL is an incomplete answer. You
>> see, XSL is a constraint language. In XSL, you can specify how large the
>> pages are, how many columns they have, the sizes of fonts, and a myriad
>> other parameters. What you don't specify directly are where the page breaks
>> necessarily occur, or which words get hyphenated, or where exactly any of
>> the actual marks are going to wind up on paper. ¶
>>
>> "The XSL Formatting Objects (FO) document is input to a formatter, a
>> composition tool that renders marks on paper, typically these days in the
>> form of a PDF file. Producing quality printed output is devilishly hard. Of
>> all the various sorts of software systems I've encountered, a formatter is
>> hands down the hardest to implement well. ¶
>>
>> "There are several commercial formatters out there that do an adequate job.
>> There are also a few free formatters that do a someone less adequate job. I
>> desperately wish the quality of the free formatters would improve, but see
>> the previous paragraph." ¶
>>
>> =========
>> The problem remains as Walsh stated it eight years ago. It is not possible
>> to produce from an XML--tagged document a PDF file that follows the
>> typographical conventions applied to books. Browser--printed documents are
>> rough-and-ready at best.
>>
>> XML is fine for web sites, where low standards of typographic presentation
>> are acceptable, but we need a lot more than that for print. I know it is
>> customary for XML evangelists to do a little hand--waving and claim that
>> printed materials are just too old--fashioned to bother with any more, but I
>> do not find such propositions convincing. Printed books have been around
>> since 1450 or so, and the form has evolved greatly and will continue to
>> evolve. There is still a lot of life left in print.
>>
>> XML will not take us anywhere.
>>
>> The emperor has no clothes, and the empire has no tailors.
>>
>>
>> JH
>>
>> ------------------------------
>>
>> From: "Warren Lewington" <wjlewington@xxxxxxxxxx>
>> Subject: Mastercard Technology moments.
>> Date: Mon, 27 Feb 2012 08:44:12 +1100
>>
>> Buy iPad: $700.0
>> Buy file sharing app: $2.00
>>
>> Share files from mail for response: Free.
>>
>> Create file using windows on iPad hard drive: Too easy.
>>
>>
>> Look on Wassa's face when it was complete? Priceless...
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Subject: XML More
>> From: Bill Parker <bill@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>> Date: Mon, 27 Feb 2012 09:30:35 +0800
>>
>> Dear ATWs more on the XML issue from another newsgroup - real world stuff :
>>
>> "The .xml file is the result of an export from a database run only on
>> Windows machines. It was ( and still is being developed) by IT people at the
>> Antarctic Division, and is a requirement by the Federal Gov to be completed
>> while undertaking marine mammal observations during offshore seismic
>> operations. ...
>> We have to complete this database daily with a huge amount of info from
>> environmental, operational and sighting effort and cetacean observations. It
>> is a pain in the neck to be frank as I am used to the elegant simplicity of
>> Filemaker Pro!!"
>>
>> Thanks to all for your offers and advice on other programs to use. I will
>> try them and do have filemaker as well. I guess it is my lack of knowledge
>> on what .xml is and not having to use it before that has stumped me.
>>
>> I have tried importing the file using both Textedit and Excel 11, but the
>> format that is presented once loaded just doesnt look right (based on what
>> the data looks like in this database).
>>
>> Just tried with FMPro 11 and it shows a box asking me to 'specify an xml
>> data source'. Now this is where Im stumped!!"
>>
>>
>> The interesting thing ( to me as a Mac user is the reference to Windows, but
>> note also that FileMkaer Pro works across platforms very well.
>>
>>
>> BIll
>> ------------------------------
>>
>> Date: Mon, 27 Feb 2012 13:41:26 +1100
>> Subject: Re: Vale technical writing?
>> From: Howard Silcock <howard.silcock@xxxxxxxxx>
>>
>> I'm glad Geoffrey brought this topic up and find my self pretty much
>> sharing his reaction.
>> What concerns me most is that our profession is being invaded by
>> 'technical' people who know next to nothing, and care even less, about
>> language and communication, while they fancy themselves as experts in XML
>> or PHP or whatever is the current fad. I don't have any objection to
>> single-sourcing or ePublishing or other kinds of online documentation -
>> provided *the author* is involved and makes the key design decisions about
>> his or her work. I found it really chilling to hear a talk at the last ASTC
>> (NSW) conference in which the speaker described how the web designers go
>> about grabbing what they delight in calling 'content' from anywhere and
>> re-using it to make their site look fancier and to show off what *they* can
>> do. One way they got 'content' was to grab the subject-matter experts and
>> interview them, then transcribe the interview, probably using Dragon
>> Naturally or some other automated transcription tool and, lo, there was
>> their article! Who needs to actually *think* about what goes into a
>> document, after all, let alone how to make it easy to digest and
>> understand? Now, *there's* one good reason to have accreditation for our
>> profession - to keep out these Neanderthals!
>>
>> If I'm producing single-source documentation, I'm designing it for each
>> output form, with the needs of that audience in mind, using conditional
>> text to care of those different audiences. Some of these 'Neanderthals'
>> wouldn't even have a clue how to tailor a document for an audience - 'oh
>> yes, we can take this document and convert it to HTML; what do you mean it
>> was written for end users and we're giving it to administrators, it's
>> content and it fits the title, isn't it?'
>>
>> Howard
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 27 February 2012 00:30, James Hunt <jameshunt@xxxxxxxxxxxxx> wrote:
>>
>>> The XML guru Norman Walsh once wrote (in
>>> http://norman.walsh.name/2004/12/07/webarchPdf) as follows.
>>>
>>> "[W]eb browsers suck at printing. Never mind the fact that some browsers
>>> do a better job than others, they all suck. And CSS is never going to fix
>>> it. Did you hear me? CSS is never going to fix it. There are lots of
>>> programs that can produce more or less nice looking pages. TeX is an
>>> historical favourite, as is troff. More modern tools include various
>>> desktop publishing packages. In the XML world, the obvious tool is XSL, the
>>> Extensible Style Language, not the Transformation language. ¶
>>>
>>> "It's important to realise, however, that XSL is an incomplete answer. You
>>> see, XSL is a constraint language. In XSL, you can specify how large the
>>> pages are, how many columns they have, the sizes of fonts, and a myriad
>>> other parameters. What you don't specify directly are where the page breaks
>>> necessarily occur, or which words get hyphenated, or where exactly any of
>>> the actual marks are going to wind up on paper. ¶
>>>
>>> "The XSL Formatting Objects (FO) document is input to a formatter, a
>>> composition tool that renders marks on paper, typically these days in the
>>> form of a PDF file. Producing quality printed output is devilishly hard. Of
>>> all the various sorts of software systems I've encountered, a formatter is
>>> hands down the hardest to implement well. ¶
>>>
>>> "There are several commercial formatters out there that do an adequate
>>> job. There are also a few free formatters that do a someone less adequate
>>> job. I desperately wish the quality of the free formatters would improve,
>>> but see the previous paragraph." ¶
>>>
>>>
>>> =========>
>>> The problem remains as Walsh stated it eight years ago. It is not possible
>>> to produce from an XML--tagged document a PDF file that follows the
>>> typographical conventions applied to books. Browser--printed documents are
>>> rough-and-ready at best.
>>>
>>> XML is fine for web sites, where low standards of typographic presentation
>>> are acceptable, but we need a lot more than that for print. I know it is
>>> customary for XML evangelists to do a little hand--waving and claim that
>>> printed materials are just too old--fashioned to bother with any more, but
>>> I do not find such propositions convincing. Printed books have been around
>>> since 1450 or so, and the form has evolved greatly and will continue to
>>> evolve. There is still a lot of life left in print.
>>>
>>> XML will not take us anywhere.
>>>
>>> The emperor has no clothes, and the empire has no tailors.
>>>
>>>
>>> JH
>>
>>
>> ------------------------------
>>
>> Subject: Re: Vale technical writing?
>> From: James Hunt <jameshunt@xxxxxxxxxxxxx>
>> Date: Mon, 27 Feb 2012 15:58:45 +1000
>>
>> I think I'll have another bite or two at this one…
>>
>> Most XML-based writing systems are used by the military and their dependent
>> corporations, and those systems usually reflect the military mind quite
>> well. Writers are considered to be rather like soldiers, are given no scope
>> for originality in presentation, are required to use a fixed tag set, and
>> are allowed no control over the final appearance of the work.
>>
>> Large XML-based systems enforce the military model of writing very well.
>>
>> I have observed that ex-service technical writers are quite happy, as a
>> general rule, to work under these conditions. But, as I have observed
>> elsewhere, a significant number of writers regard these working conditions
>> as an "Israelites-in-Egypt" situation: in slavery, endlessly making
>> identical bricks in an obscure corner of a military-industrial complex.
>>
>> A significant part of our work satisfaction comes from the preparation of a
>> final product: the visual appearance of our product is important to us. If
>> we lose control of the design of the final product, we also lose some level
>> of work satisfaction.
>>
>> A good writing system automates most formatting decisions, but allows for
>> local overrides. Planning the design of a document so that local overrides
>> are minimised is one of our skills: one that XML proponents seem to discount
>> entirely. Recognising where a local override is necessary, and carrying it
>> out efficiently, is another skill. XML proponents often exaggerate to the
>> point of parody the extent of local overrides in non-XML documents. Most
>> overrides in Word and FrameMaker documents, for example, seem to be just
>> forced page breaks and extra vertical spaces -- hardly dramatic stuff, and
>> not any sort of reason for eliminating local overrides completely.
>>
>>
>> JH
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> End of austechwriter Digest V10 #42
>> ***********************************
>
Other related posts:
