I guess I'll toss my 0.02 in here...
I think the frustrations here are echoed amongst pretty much most of the
pre-PTC user base.
I don't envy the task for Arbortext developers to maintain a publishing
engine that has to satisfy so many organizations with disparate
requirements. But page fidelity is important, irregardless of whether
or not people use looseleaf publishing. In our case, we do not, but we
do have to create a PostScript of every page we produce, just in case a
reprint is ever needed, because we can't count on the stylesheets or the
publishing engine producing the same results 3+ years down the road.
The page "rippling" causes problems, even for those of us who publish at
an MRU level, just for the act of trying to generate LEPs and TOCs
alone.
One thing that's been pointed out is the frustration with "bug fixes".
Some bugs live on for several years. Bugs to some of the user base is
generally-accepted behavior to others. I just went through this with
our last upgrade (5.1F, which we'd been using since 2004, to 5.3 M040
just this year).
Tested 5.3 M020, which had a bug with floats that, in certain cases,
could cause images to appear in the output in an order different than
how they appeared in the markup. So the fix was promised for M040.
Tested as much as I could, didn't find anything overwhelming (still had
to make some FOSI adjustments to "restore" certain behaviors). Rollout
comes and goes, and I find out that spellcheck now flags two words in
two cells as one word (I never thought to test the spellchecker. The
more you know...). Start pouring through release notes, to find M040
included a "fix" to flag words in inline markup. I don't know who asked
for this, but I know after all the testing and rollout and the work put
into this upgrade, that the "fix" (which is a set option that allows for
selecting either spellcheck behavior) is in M060. And don't get me
started on what happened to the "userulehook"...
After reading over release notes for 5.4 and M010, there seems to be a
lot of busted stuff that isn't getting fixed until M020, but I'm not
entirely sure what's going to break with that release either.
Perhaps this would be a subject for the TC committee meetings? Can
PTC/ATI communicate upcoming changes (like SPR#s) prior to/during
development of the updates? Is there a feedback loop available for
others to get a general idea of what is being requested and how they are
prioritized? Maybe a heads-up before hand could help organizations plan
up front, or at least see if a fix they have been waiting on is going
into an M0X0 release that will break something else...
The user base seems to be all over the map, as far as production
software versions go, from Adept 9 on up (I think I saw someone talking
about upgrading from Adept 8 this year). All the nice new tools and
features and add-ons are nice, but it sounds like there's a good portion
of the user base that just isn't satisfied with the toolset in its
current state to upend their integrated environments to move to it. If
those folks can't see enough value in the evolution of the product to
make the effort to upgrade (and in most larger shops, it's QUITE an
effort), that's (IMHO) a red flag that PTC still doesn't understand
Arbortext's target market. Or that the target market they envisioned
having when they bought Arbortext didn't have room for those of us
already there.
I thought the whole idea of the Arbortext TCs was to get developers
talking to users and vice versa, and giving the user community that
actually uses the tools some input to guide future development. So far,
other than semi-annual meetings, the ATI TC has remained pretty quiet.
Another TC topic:
"What do you want?" No agenda, just ask us what we want, and write it
down. Most of the TC meetings are directed in a particular direction
(technical illustration), at a particular product, or for a particular
method (DITA/S1000D). Things get asked for offhand, outside the scope
of the meeting topic (I'm guilty of this), and I don't know if these are
getting traction.
-A tool/widget-builder for XUI
-A better method for developing CCF files
-A new DocArch (DCF editor?)
Cheers...
-Jason A. Buss