which is better: strct or unstrct fm for docs >200 pages

[m_93]

Background:

• there is discussion in my department regarding merits of working in structured vs unstructured for large docs, say over 150 - 200 pages; specifically, a new set of docs for Project X is coming through that will be worked on mainly by people Not familiar with strct fm, which means definite ramp-up time
  
  
• I've been working in strct fm for about a year however my docs are typically only about 60 pages long. I'm a proponent of working in structured fm however am not going to be on Project X
  
  
• two of the Project X team are familiar with strct fm. They are strongly recommending staying in unstructured. Their reasons include ramp up time for new writers and issues regarding working with imported table content (assigning paragraph tags to each entry, etc.)

Would really like to hear experiences of people who use structured FM for long docs as I can only speak to ease of use in shorter-sized documents.

Would like to hear advisability of staying in unstructured or not...Please advise.

Thanks!

[Russ Ward]

Hi m,

Structured FM is superior for nearly any kind of manually-authored document. Those who say otherwise are generally not familiar with structured FM, even though they may claim otherwise. Having said that, it is possible that a 200 page file could cause performance issues, especially if you have a complex EDD and/or a slow computer. Also, 200 pages is too long for XML import/export, even with a simple EDD and a fast computer. You didn't say whether that was a requirement, but it is something to think about even if not right now. Whether or not any of this presents a showstopper for you, I wouldn't be able to speculate... you would just have to do some experimentation. I can say for sure, though, that if it were me, I would find a way to break the content into smaller files before I would put up with unstructured documents.

Ramp-up time for structured FM really shouldn't be that long for a competent technical writer. All things considered, it is easier to use than unstructured.

Russ

[m_93]

>All things considered, it is easier to use than unstructured

I hear you and completely agree.

Am trying to build the case for doc development in structured for the upcoming project. Unfortunately the largest doc developed in house, at 278 pgs, is by one of the two people on Project X who are not keen on sticking w/unstructured therefore my voice (have produced most # of strct fm docs in last year) is not so loud due to short length of my docs.

Will see if anyone else writes back with their experience of strct fm in long docs and will also post issue to other forums...any forums you'd recommend regarding this issue. The inhouse team will be more inclined to listen to a nonAdobe strct fm person on this issue...

Thanks though very much for your input.

[Art Campbell]

If it was me, the key determining factor(s) would be whether it's new documentation and the preference of the writers on the job.

If it's bringing forward legacy doc and updating it, I'd keep it in unstructured and plan on converting at some point in the future.

If it's new doc, I'd lean more toward structured, assuming that's where the entire corporation is headed. It's easier, IMHO, to outline and set up a bare document by creating a structured framework and then filling in the content, especially if the writers are learning structure. However, people learning a new tool (structured) are likely to take 20-25% longer for the project than experts because of the learning curve and ramp-up time.

But in the end, the preference of the writers who have to do the work and bring it in on time would be the trump.

[Russ Ward]

Art,

Perhaps. On the other hand, I'd say that if the writers prefer to use obsolete tools, then perhaps they should be writing somewhere else. To be sure, where I work, there is no time to spin our wheels dabbling with old technology. There will be some investment of time, of course, whether you can pin it down to 20-25%, hard to say... what is easy to say, though, is that this investment will repay itself many times over from the efficiencies it will bring. I don't buy that "no time to learn" argument, because the lack of knowledge is what keeps one bogged down with busywork in the first place.

Russ

[Michael_Müller-Hillebrand-basb]

I created structured templates plus full XML round-tripping for some clients throughout the last year. In both cases some books have 1000+ pages. They work in structured FrameMaker until a version is finished. Then they save the full book as XML and have many benefits from it:

• The XML goes to translation (and translated XML opens back up as a full book (takes a few minutes)
• The XML is stored in a version control system
• The XML is used to create other outputs (like a consistency report)

So they are saving as XML only if there is a benefit.

In another project we plan to use a hybrid approach: During editing individual chapters can be saved by different authors as XML for version control purposes, only when publishing time has come they will use the book features.

Based on this the size of documents is of minor importance when considering structured publishing.

- Michael

[Russ Ward]

Hi Michael,

With all due respect, I disagree with this statement:

>>

Based on this the size of documents is of minor importance when considering structured publishing.

When I get an XML file that imports upwards around 100 pages, it takes 5 - 15 seconds just to open. That translates into minutes when you have a large book. Furthermore, when a single file grows to several hundred pages, it can take a minute or more just to open. This is with a pretty speedy computer and a very simple EDD, less than 30 pages. So, while I agree completely with all of your other sentiments, I have found that XML import/export is unworkable for long files, for general authoring tasks anyway. Of course, structured files that live in binary format are much less prone to these difficulties.

Russ

[Michael_Müller-Hillebrand-basb]

Am 08.03.2010 um 22:11 schrieb Russ Ward:

With all due respect, I disagree with this statement:

>>

>> Based on this the size of documents is of minor importance when considering structured publishing.

Hi Russ,

I obviously wasn't clear enough, because with »Based on this« I meant working with FrameMaker documents and saving as XML only when useful.

- Michael

--

[TarunGarg_TG_]

For building up your case for structured FM and the plan is to use DITA, you can refer to the blogpost & demo on

"Leveraging Unstructured FM Knowledge for Authoring DITA content"

Regards,

Tarun Garg

Adobe FrameMaker Engineering

[Van Kurtz]

I will add my experiences...

We work with and create many documents in the 300-400+ page range, in structured FrameMaker, and have no problems. If you keep the documents as FrameMaker files, then page count and document size has little or not impact on whether one should use structured or unstructured. The BIG advantage to structured documents is that the write does not have to remember formatting rules, such as which paragraph style goes to which paragraph; the formatting is all done by the EDD and the template. In a large project, using structured documents helps to maintain consistency of formatting across the document set. Also, cutting and pasting, as well as moving elements around in the structure view, is easier because it is easier to select whole elements than trying to decide exactly where a section ends, for example.

On the XML issue, be clear what Russ and Michael are talking about. If you save and open your files as FrameMaker files, file size has NO impact. At any time, if needed for OTHER purposes, you can save your structured files as XML, as Michael does.

On the other hand, Russ works in an XML workflow, meaning that each time he save his files, he save them to XML. Then opens the XML files. It is THIS back-and-forth XML workflow that can slow things down. If this type of workflow is not needed in your case, then there is nothing to worry about.

DEFINITELY push for using structured FrameMaker. As mentioned by others, a seasoned tech writer should be able to handle the change. One writer here, who had used unstructured for decades, found it relatively easy to learn structure. It is NOT a major problem....or learning curve.

[Lynne A. Price]

I routinely edit structured books that are several hundred pages long (and

set up applications for people in varying environments to do so). I have

edited single structured files as long as 1400+ pages. I use structured

FrameMaker for almost everything I write, even single-page letters.

Reasons often given for use of structure include:

1) Satisfying a requirement for XML delivery

2) Promoting consistency across a document set and within a document

3) Enforcing some of an organization's writing standards(such as requiring

an introductory paragraph before a figure or prohibiting lists with a

single item)

4) Allowing access to various XML tools

In addition, a properly designed structured environment simplifies many

every day editing tasks (some of which Van has already enumerated in this

thread). Some others are listed in

http://www.txstruct.com/papers/FrameUsers02.productivity.pdf.

Are the Project X writers already familiar with FrameMaker? If so, it

shouldn't take more than about a day for them to learn how to work with

structured documents. (Feel free to contact me off-list for information on

a self-study course on structured editing for users with are familiar with

the original FrameMaker user interface.)

The other concern you mention is assigning paragraph formats to cells in

imported tables. How are the tables created? How are they imported into

FrameMaker? Are they dynamically updated or is the content static once they

are inserted into the FrameMaker documents? Maintaining the formatting

within tables should be no more difficult in structured FrameMaker than it

is in unstructured FrameMaker. Formatting options may be specified in

attributes rather than paragraph/table formats, but the same table

capability is available in both user interfaces. Depending on how the

tables are created, in fact, using XML and XSLT along with a structured

environment may make it easier to move the data into FrameMaker.

--Lynne

Lynne A. Price

Text Structure Consulting, Inc.

Specializing in structured FrameMaker consulting, application development,

and training

lprice@txstruct.com http://www.txstruct.com

voice/fax: (510) 583-1505 cell phone: (510) 421-2284

[Russ Ward]

I use structured FrameMaker for almost everything I write, even single-page letters.

Lynne, I wouldn't be surprised if you use structured FrameMaker for your grocery list.

Russ

[Lynne A. Price]

Russ,

I confess. I don't do the regular grocery list in FM, but I do have my

Thanksgiving shopping list in FM, and it's unstructured. It's organized by

aisle in our favorite store. I make a copy every year, delete the items we

happen to have, and off we go ...

--Lynne

[Lynne A. Price]

Russ,

I should have responded more seriously to your remark. One reason I use

structured FrameMaker almost exclusively for my own writing is that I tend

to rearrange content often when I am writing and it is easy to drag

paragraphs around in structured documents. Operations such as moving items

into and out of sublists and breaking up sections into subsections or

combining subsections into major sections are much easier in the structured

environment. Furthermore, in a template where list numbering uses a

different autonumber for the first item in a numbered list than the second

item, in a structured environment, I don't have to remember to change

paragraph formats when I reorder list items.

Sometimes I will even edit an email message in structured FM and then

copy and paste the content into a message.

--Lynne