Part 1: Why I am Dropping TCS and FrameMaker
Joseph Lorenzini
jaloren at gmail.com
Fri Nov 1 21:40:07 PDT 2013
I had originally offered to share my story offline with anyone who is
interested. However, the outpouring of interest (i think 30 or 40 people
emailed me) and the urging of several to post this to the forum has changed
my decision. So here it is.
For those on the FM list, I suspect the formatting in this email is going
to get stripped out and make it hard to read. Just email me if you want a
copy that's easier to read.
Note that I am actually going to have three posts because of how long this
will be. One that discusses why I am dropping FM and TCS, another about why
I chose Flare, and then a final post that describes how I converted from FM
to Flare.
Before I proceed, I should note that everything I am expressing here are
my own opinions and experiences. This is based on my use case and what
worked for me. Some or all of what I have written may not apply to you or
your work situation. I don't want anyone to think that I am criticizing
their choices. I am not passing judgment on you and how you do technical
communication. I am just sharing my story because I think it may help some
people with their work.
To summarize what I am going to talk about (because I am afraid this will
be quite long):
- My Business Case
- Why FM failed to meet that Business Case
- Why Not RoboHelp?
*SECTION 1: Business Case*
When you have a reasonably large documentation set (approximately 50 pdfs
and 3,000 pages), changing the tool you use and how you and your team
author content is an expensive decision, especially in the short term. Off
the top of my head:
- the up front conversion cost is going to be at least 160 hours (1
month) or more of work even with automation tools. In all honesty, if you
aren't budgeting for at least one person to work full time on conversion
for 4 to 6 weeks, then you aren't being realistic.
- training on the new tool for all the people in the tech pubs department
- training SMEs on how to do reviews with the new tool
- cost of the software itself (usually going to be at least a couple
thousand dollars) and that's on the low end
- learning and implementing a new publication process
- Localization costs -- Among other things there's a risk that the
translation memory can no longer be used as is.
I am sure I have missed others. When you add up all the hours and money
spent, you are easily talking about a 10,000 to 15,000 dollar investment.
I needed a compelling business case that would *justify *that investment.
And with that let me start with the following customer complaint. I am
paraphrasing.
*You have so many PDFs. I have no idea, which PDF I should look in for the
information that I need to know. I have to download a huge zip from your
website, open each individual PDF, and then do my search in that PDF. Can
you please just give me a single place to search for and find what I am
looking for?*
*
*
And then there was another problem that the PDF deliverables were causing
customer support. Frequently, customers would open up tickets about a
problem they were having and it would turn out that this issue was 1)
covered in one of the PDFs 2) would resolve the customer support ticket.
The customer support person then had the burden of trying to hunt down this
information or asking me where it was. The customer support team in other
words had a similar complaint as the customer: we want an easy way to find
a particular procedure or section and then provide that content to the
customer.
It became clear to me that:
1. No one had a desire to or would read the PDFs as a book i.e. a linear
narrative. Technical content is boring, people are busy. They just want to
get the information that they need to get their work done. They are
completely uninterested in reading a 400 page user guide from end to end.
2. The *only *thing someone wanted to do was have a google search like
facility that would search all the content and then return the information
they wanted.
3. The idea that people don't read end user documentation is not true.
If it was, then no one would be complaining about their inability to find
content. The fact that they are searching through the documentation
indicates a desire and a need they think documentation can fulfill.
4. They want something that is fast to search, easy to access, and easy
to view content.
5. And what they were searching could be boiled down to the following
two questions: What is it or what does this mean? And how do I do that? In
other words, concepts and procedures.
Hmmmm, did someone say topic based authoring? Well, if they didn't, I did.
If I switched to topic based authoring (which of course would mean a
significant restructuring and rewriting of legacy content) and I provided
all content in a single package, then that would address the usability
complaints raised by customers and customer support.
Right off the bat this would reduce customer support costs (less time spent
resolving a ticket at a minimum) and increase customer satisfaction. In the
medium term, that may actually justify the costs right there but when I
considered the limitations of FrameMaker to implement topic based authoring
and the other costs the current FM publication process imposed, then it
became a slam dunk case for dropping FM.
And before I move on, here were some other requirements I had:
- The tech pubs is a small team. At most there are going to be 3 writers
and typically it would be 1 or 2.
- Contractors will be frequently used.
- Budget is extremely constrained -- we couldn't afford a solution that
was six figures.
- We need a tool that is easy to onboard and train someone to use in one
to two days.
- We wanted an easy way for people, including, SMEs to review and
generate content even if they weren't technical writers.
*SECTION 2: Why FM failed to meet that Business Case and Other Problems*
*
*
I have used FM since 7.2. I am currently on FM 10. I highly doubt FM 11 in
any way addresses my criticisms but anything is possible.
*
*
All my content is in unstructured FrameMaker so some of my criticisms may
not apply to structured FM. But that was irrelevant to me since I would
rather chew off my arm then deal with the complexity and cost of trying to
convert over to structure (it would have been prohibitive and yes I
analyzed this in detail).
The topic based authoring business case was the key forcing function that
got me off FrameMaker but there a lot of other problems that contributed to
my decision to jump. If it was just the topic based authoring issue, then
this decision would have been much harder. So lets dive into the many ways
that FM has slowly been driving me insane.
*Ahem FM=Books=PDFs*
So first of all, can someone do topic based authoring in FM? Yes, but only
at great cost and pain. The FM data model is a book model. For pete sake,
it literally has a file called a *book* where you are supposed to add
chapters to it. Everything about FM is geared towards and encourages book
based authoring. Topic based authoring in FM is like shoving a round peg in
a square hole. And nothing illustrates that more, then this: FM can only
generate a PDF of the source content.
So could someone create one or more FM files with a set of topics and then
generate a humongous PDF from it.....Sure, I guess. I am just not sure why
you want to. Furthermore, by putting everything in a PDF, this severely
undermines one of the most useful attributes of topic basic authoring --
topics are short and digestible. Even if topics are segmented by headings,
from a user point of view it looks like one undifferentiated blob in the
PDF. I could go on but I really doubt anyone who isn't Adobe is going to
argue that FM is a good tool for topic based authoring.
And even if you ignore the profound limitations in authoring topics in FM,
how does one avoid the final deliverable? PDFs are a terrible way to
provide topic based help. There are a multitude of reasons that when
someone says "topic based authoring" they are almost always referring to
some sort of online help where the source content is XML. PDFs are books.
The bigger the pdf, the longer it takes to send, read, and search. And of
course are friend the PDF is certainly not updateable in real time or
otherwise. HTML help systems are a series of topics that are searchable,
are fundamentally more scalable, and can be hosted server side.
*And speaking of the cost of PDFs....*
Way before my time, I had heard that much earlier versions of FM were
supported on Unix and that these versions supported PDF batch processing. I
have dreamed of this functionality for *years *on windows. Lets talk about
one of the least favorite parts of my job: publishing PDFs. The following
are all manual steps that must be done for each FM book.
1. Changing conditional tags for appropriate product edition and then
updating changes in all files - 3 minutes
2. hiding or showing certain FM files - 1 minute
3. updating variables for appropriate product edition and then updating
changes in all files - 3 minutes
4. check to make sure PDF options are set correctly - 3 minutes
5. update book - 1 minute
6. print pdf through acrobat distiller - 10 minutes (low end...can be
as long as 20 minutes for large books but i am being charitable)
7. Post processing steps -- change the PDF filename, switch the PDF
title to show bookmark, commit PDF into SVN etc -- 5 minutes
So lets do some basic arithmetic. 3+1+3+3+1+5+10= 26 minutes for a book. I
have 50 books so that means it will take 1300 minutes or 21 hours to
produce an entire documentation set. In other words, it takes 2.5 days to
generate a documentation set for one product. But it gets better, I have
multiple products that I generate the documentation set for. Due to
branding and legal names, even though the content is identical in many
cases I still have to generate a document with different variables and
conditional text set. So I have 3 products, where each product takes 2.5
days to generate a doc set for. That means it takes over a *week *just to
generate all the documentation for a single release. In addition, my
company follows the Agile SDLC, so I get to do this every 3 to 4 months. So
in a single year, I can expect that someone would literally have to spend a
month's worth of time *just *generating PDFs instead of oh i don't know
actually writing content!! And that's the ideal situation with someone who
is familiar with the complex, manual process for generating the PDFs. The
beauty of this process is its really hard to train and highly error prone
so its not like this can be offloaded to an inexperienced tech writer or a
contractor, who would inevitably screw it up. It means that a highly
experience senior tech writer has to do it.
And now in theory there may be one or more custom FM plugins or even an
ExtendScript that could be developed to automate this. But I view that as
an unacceptable option for the following reasons:
1. The cost would be significant -- if the contractor is competent he or
she would surely charge thousands of dollars
2. The cost would be ongoing -- every time an upgrade of FM is needed
that plugin would most likely need to be refactored.
3. The plugin becomes a SPOF in the documentation process. If the person
who wrote the plugin either is no longer working or passes away, then you
are SOL until and unless you find someone else to support it.
And finally note this: *I am spending a month of man hours generating PDFs
for an end user who does not want them.*
*The FM GUI is a clunky and Administrative Tasks are Painful*
*
*
This is unfortunately just a catalog of ongoing grievances that I have had.
One or two of them eh whatever but they really start adding up.
- Typing words in a FM file? That's easy enough. Applying paragraph
styles and character styles okay fine. But everything else? Dear god its
awful. I find the pods hard to navigate and use and the fact that a lot of
the fields aren't resizable or small doesn't help. And hoo boy has anyone
looked at the colors dialog box lately? That's just plain scary. The key
issue i have with the GUI is that doing any type of administrative task or
clean up is a 1) slow 2) multi click process in a 3) gui that makes it hard
to see what it is you are doing.
- The import process!? Why must it be unidirectional. I can get stuff in
but its impossible to get stuff out without manual effort. Accidentally
imported 5 variables into 25 files? Oh well, go manually remove each one.
And of course that applies to just about anything you choose to import. And
yes I know there are plugins to address some of these problems (i dearly
love the bookvars plugin for example) but that's just it: FM could handle
this stuff much better but it just doesn't.
- How does one know if files need to be cleaned up? FM reporting
capabilities are not suited for that at all.
- Of course if the template changes, then that means manually updating
that change in every FM file that you have. Central control of the look and
feel of all the files is non-existent in FM.
- The search!!? Why in gods name can't they support regex,
*especially *since
the stinking files are binary and using an outside search facility isn't
available?
- Remember how ExtendScript was supposed to save the world and automate
any and all administrative tasks? yea, its buggy and slow and it causes FM
to crash. And oh yea the documentation is HORRENDOUS. If you want an API to
be used by someone, you need to explain how to use it. I can only assume
that Adobe thought it would be a good idea to have an API and provide
documentation that failed at doing such basic things as DEFINING WHAT THE
BLASTED OBJECTS ARE!! Maybe I am just being silly but when you have an
object in a JavaScript API, it would be wonderful to know what it is and
what someone might want to do with it. And oh yea examples.....an example
of how to use the object....oh well one can only dream.
- The Integrated Help System Is An Abomination. If you select the help
button, you LITERALLY wait at least 15 to 20 seconds before it loads (i
know because I timed it, I had originally thought FM was freezing/crashing
for some reason). Then, once loaded, it takes forever to 1) navigate,
select, and load a topic from the TOC and 2) perform searches. I suspect
the slowness has to do with the adobe air format and its insistence on
having internet access to pull things from adobe servers. CHM may look
uglier but its way more functional then this piece of garbage. And to add
insult to injury, the actual content in the helps system is atrocious.
Physician heal thyself.
*Having source content in binary, proprietary files is problematic.....*
For a variety of reasons.
I used to store my FM files on a NFS. The network latency was awful and
forget about using VPN. So migrating FM content to SVN brought me relief
from that....but it meant storing binary files in SVN and to that I just
say yuck. Forget about SVN diffing or blame and all the other useful things
SVN can only do with human readable files.
Because they are binary its pretty close to impossible to feed the FM files
into a batch processor that can chug through the files to remove, modify,
or add formatting or text. And yes I know about MIF. Yes, I know I could
first go through the process of converting them to MIF, and then either
learn MIF (cause learning a proprietary, complex standard that is dying off
sounds like fun) or purchase a plugin or program to parse the MIF data for
me. So yea, that could work orrrr FM can stop using a binary, proprietary
format and just use stinking XML. And no I don't care about structured FM
or authoring in DITA, I just want the FM files to be XML documents full
stop.
And oh speaking about MIF. Fun fact: When someone does localization work in
house, that person literally has to save the files to MIF before doing the
translation and then save them back to FM after the translation is done.
The cost of file conversion adds up over time. Yes I know a plugin could
mitigate that problem but not completely relieve it. But it ticks me off
that I even have to consider a plugin because Adobe can't be motivated to
have the files in a open source, human readable format. And oh yea, did I
mention that if they were XML documents, a translator could import the XML
in and out of their translation tool without doing a file conversion? Its
almost like having source data in human readable, open source, well-defined
and structured format makes processing that data easier....who would have
thought!! </end snark>
*I dreamed a dream that FM never crashed..*
And then I wake up to the sad reality. Every release becomes more unstable
than the previous. FM 7.2 was rock solid. FM 8 was pretty good. But then
hoo boy did things go downhill with FM 9. I suspect the instability got
introduced when they revamped the UI but frankly why the crashes happen
don't matter as much as that the crashes are in fact happening and they
happen a lot.
I author FM files locally on my computer (remember SVN) and configured FM
to automatically save the files every minute. And yet the crashes can
sometimes happen so frequently that I still end up losing data. The worse
part of the crashes is that they don't seem to happen for any rhyme or
reason, there is no clear pattern that says if I do X then I should prepare
for a crash. Its random but frequent so that's fun. And yes I googled, i
checked forums etc I was unable to ever find anything to resolve the
problem. And yes I am fully patched etc. Trust me I have been through the
whole debugging thing. No luck. The best I have found is to reboot my
computer and cross my fingers.
And I'd rather drink battery acid than deal with Adobe Customer Support, I
learned my lesson the extremely hard way with that one.
*FM Reviews and Track Changes: Buggy, Clunky, Manual, and Time
consuming....whats not to like?*
So subject matter experts. We know and love them. They have the knowledge
that we need to impart to end users. They are the ones that validate what
we write is technically accurate and complete. And how pray tell does that
work with Adobe FrameMaker as the authoring tool?
Well here's the best workflow that I know of:
1. SME authors content in MS word or wiki.
2. tech writer extracts said content out of the input format, strips out
formatting, and manually copies the input in as pure text.
3. tech writer than manually reformats the content to conform to FM
paragraph styles.
4. Using the input from SME as a starting point, tech writer writes up
the entire feature.
5. Tech writer generates a PDF from FM source.
6. Tech writer uses acrobat professional to enable commenting in acrobat
reader on the pdf.
7. SME puts comments in acrobat reader and then sends the PDF back to
the tech writer for review.
8. Tech writer manually goes through each comment and then copies or
modifies the content in FM based on that comment.
So here are the major problems that I have with this workflow:
- Significant amounts of time are spent by the tech writer to *just *deal
with importing and reformatting content from the SME input into FM
- putting large numbers of edits in adobe acrobat is painful, slow, and
tedious for the SME. Yes, 10 comments isn't that big of deal but imagine
dealing with 300.
- For the tech writer, going through each comment in the PDF and then
manually making that change in the FM source is doubly painful.
Yes, I know about FM track changes and I know that FM supports the ability
to import comments from PDF into FM. The problem is that comment import
process is a buggy mess that doesn't actually work and has a high tendency
to crash framemaker, corrupt the document or both.
What I want is the ability for the SME to 1) author in the same environment
as the tech writer which means there's no more formatting/import/conversion
step for either the SME or the writer and 2) be able to use track changes
that are similar in functionality to MS word. FM track changes are nothing
like that and they are a nightmare to use when conditional text is also in
the same FM source. And oh yes TT causes FM to crash. And because TT are a
problem, its hard for a tech writing team to review and comment on content
that other people have authored in FM.
*The FrameMaker and RoboHelp Integration: The Best of Both Worlds if
Neither World contains Topic Based Authoring*
*
*
*So okay, someone might say (probably Adobe), we get that people don't
just want PDFs and that online help systems are really useful and much
better suited for topic based authoring. However, can you really say that
no one wants/needs PDFs? You know what you need? You need to be able to
satisfy both audiences: those that want PDFs and those that want a help
system. Plus, do you really want to deal with conversion to a new tool and
lose FM's powerful and reliable paragraph styling. I mean my gosh, you'd be
certain to lose FM amazing autonumbering capabilities and have to deal with
THE HORROR!!! HTML numbering. Nooooo don't do it!!! So obviously you
should author all your content in FM and then use RoboHelp to import your
content from FM and convert it into HTML pages. *
So a couple problems with this argument for the integration. First,
consider this argument:
*
*
*We get that people don't just want printed documents. They also want a PDF
because it would be convenient to just download a file or access the file
from a CD. However, can you really say that no one wants/needs printed
documentation? You need to satisfy both needs.*
*
*
And that's why everyone still produces printed documentation to this
day....oh wait. In fact, plenty of people could die happy never interacting
with another PDF again and do. Some people only use PDFs because tech coms
may not give them the option to consume the content in an alternative form.
And more to the point, even if it is true that some people would like it in
a PDF, there's more to this analysis than just the preferences of some
customers for a particular output. Among other things, there's the cost of
producing PDF content. Not only is it not free, its *significantly *more
expensive than producing a help system. One needs to weigh the customer
satisfaction of a subset of people against the labor and time cost of
producing the PDF content. I am highly skeptical that in the IT industry
the cost of producing PDFs is always worth it when a help system is a
viable alternative. More to the point, in any reasonably sized
organization, the documentation format, content structure, and the tools
used to author the content can persist for long periods time, way past its
sell by data, due to inertia, fear of change, cost of conversion, and the
fact that PDFs are "safe". Its a well known format that everyone is
comfortable using and while giving a PDF to a customer may not be as
helpful, its such standard practice that a customer is unlikely to complain
that much if at all. In other words, sure a PDF may not be ideal but we
have bigger fish to fry......
But there's an even bigger problem and its the idea that one can
successfully do topic based authoring through RH integration. One of the
biggest mistakes someone can make when switching to topic based authoring
is importing legacy content into a tool that slices up content into a
different topics based on the topic headings. Some people think that after
the import is done, topic based authoring is achieved and then everyone can
go home. However, topic based authoring is not a tool or a help system
output, its a way of authoring content. And the chances that legacy content
which was structured and written for a book output will somehow become
topics by virtue of being split apart is highly unlikely. Legacy content is
almost never going to fit nicely in a topic based authoring paradigm, in
fact what was once well organized content suddenly becomes incomplete, too
short, too long or insert all the problems with trying to make book content
look like topic content etc. Importing legacy content into a XML authoring
tool is the first step, making that content into topics is the next and by
far biggest step.
Now consider what the FM-to-RH integration is. All it does is convert FM
files into HTML topics. RH gives you the ability to split a FM file into
multiple HTML topics based on the heading in the FM file. However, once
HTML files are generated -- that's it. If are sticking to the author in FM
source and use RH to generate help system model, then you will link the FM
files into RH. That means the source content is always and forever
controlled by and comes from FM. Once HTML files are imported from FM, you
don't have the option of restructuring the HTML topics, re-purposing, or
rewriting topics. And the reason is that anything you do will be
overwritten by the FM source, when you update the FM book in RoboHelp. All
this integration gets you is FM content wrapped in a help system bow tie.
And if that's what you are looking for then great but its unlikely to ever
give you topic based authoring output while still having FM source that
makes sense in the context of a PDF.
And one of the reasons I know all this is because I have used this
integration since release 1.3 of the Technical Communication suite. I am
deeply familiar with how this works and that's why I can say that even if
you put aside the concerns about topic based authoring, you will start
running into a variety of extremely painful technical problems.
- Setting up the integration is extremely painful. You need to be very
knowledgeable about CSS, understand the FM data model, and grasp how RH is
going to map the FM data into a HTML structure.
- The integration is buggy and slow. It can frequently cause either RH
or FM to crash.
- The process is manual and time consuming. To convert one FM book into
a help system, usually takes at least 4 to 8 hours. This assumes you are an
expert on the process, know exactly what to, and have a well documented
procedure that you follow (the procedure will have a lot of steps I promise
you).
- Training someone on how to do this integration usually takes at least
a week and it takes a new person approximately a week or more to generate a
help system on their own.
- The more books you add to a RH project, the more unstable things
become and the more likely either RH or FM will crash and burn during an
import or update.
- The webhelp output can frequently and randomly have mangled or
extraneous formatting. The only way to guard against this is to literally
check every single HTML page. If an error is found then you must regenerate
the content and then start the checking all over again.
So lets do some more math. :) Lets be conservative and say it takes 4
hours to generate one book. That means generating a help system that
contains 50 FM books would take about a month. But it gets better. I have 3
products to support, so you can effectively triple that amount of time for
a release if I wanted to do the virtuous thing and cover all the products.
And every time another book is added, the time to generate the help system
will increase commensurately. Since this obviously doesn't scale, I
actually compromised and only generate a help for some specific GUIs in the
products. On the one hand, this means I only have to generate help for a
single book. On the other hand, this means all the other content is not and
never will be part of the help system.
And finally if someone is actually serious about doing topic based
authoring, why in the world would they bother authoring the content in FM?
Why wouldn't someone just import the content into RoboHelp and then break
the link to the FM source and never look back?
*SECTION 3: Why Not RoboHelp?*
Alright, so someone might point out that while FM is not the best choice,
why not just import FM content into RoboHelp once and then just use
Robohelp. Why wouldn't RoboHelp be an acceptable tool for doing topic based
authoring? And guess what? I agree. RoboHelp is a perfectly good tool to do
topic based authoring. And the legacy conversion from FM to RoboHelp would
probably not have been much worse than doing it with some other product
such as Flare.
So why did I end up picking RH over Flare? Especially, since the people who
originally created RoboHelp are the people who are now producing the Flare
software.
One answer is that I think Flare is just a flat out better tool than
RoboHelp from a technical standpoint but I'll get into that in detail in
the next post.
The other issues have to do with the Adobe culture, organization, and the
direction that its taking the TCS product.
*
*
So has anyone heard the term "apoplectic rage"? Adobe has provided probably
the worst customer support experience of my entire life. After having been
burned so badly two years ago, I have made a concerted effort to never
interact with customer support again less my soul enter into a pit of deep
despair and I lose all faith in humanity. I don't believe Adobe's business
strategy is in providing a good customer experience. I think they view
customer support as either a revenue generating opportunity or a cost.
The former if you have purchased a customer support contract with them.
The latter if you have not. And oh to call their contact center and
navigate through their phone tree....[shudders]
Now ....licensing. Adobe is in the process of switching over to a cloud
licensing model. Right now its optional. I don't think it will stay that
way for long. The revenue potential from cloud licensing model are huge.
Plus, I am sure the model will reduce the company's costs too. So I get
why they want to do that and that they will probably do it. But this always
inevitably gets into some type of subscription model, where if i don't pay
up on a monthly, quarterly, or yearly basis I would lose access to the
source content in some fashion. Either the program itself will stop working
or if I am forced to keep the content on the cloud, then I'd actually lose
access to the content. And then there's all these sticky legal questions
about who "really" owns the content. And on top of that, inevitably the
cloud model will impact the performance of the software because the
software is periodically going to be "calling home". I believe the start of
this will be the pricing. Adobe won't at first actually say you have to use
a cloud license but they'll start ratcheting up the cost of a perpetual
license relative to the cloud license. Then it goes downhill from there. To
sum it up, I'd rather do my documentation in notepad + then have a cloud
license.
Finally, consider the financial bind that the technical communication suite
puts Adobe in. The core products, the ones that are critical to the suite
and probably account for the majority of its revenue, is RoboHelp,
Framemaker, and Acrobat Professional. I knows that's the only reason I buy
the suite. FrameMaker is dying and lives on only because of all the legacy
installs out there and the perceived need for PDF output. I have said it
many times before but I'll say it again. As long as PDF is the main
deliverable to end users, FrameMaker reigns supreme in tech comm. The
moment it does not, it will die. That moment has arrived for me and I think
its fast approaching for others.
So Adobe could make a pivot here. They could maintain FrameMaker in order
to keep legacy customers happy and benefit from that revenue stream but
focus like a laser on RoboHelp to make it the best XML authoring and topic
based authoring tool out there. Then, once enough people have migrated off
FM, they just kill FM and they are left with RH. If they did that, then I
think that RH would be just as good if not better than Flare. But they
don't because they are afraid of cannibalizing their FrameMaker users and
the consequences that would flow from that. If RH becomes good enough, then
many tech comm people will just generate help systems. If they just
generate help systems, then they don't need FM. And more to the point they
don't need or care about PDF output. If they don't care about PDF output,
then they don't need Acrobat Professional. And with that you have just
killed off the value proposition of the technical communication suite for a
lot of people. They'd just buy RoboHelp and call it a day.
Nothing illustrates this better than the fact that RoboHelp still isn't an
actual XML editor. There is no technical reason why it couldn't be, there
are compelling use cases why it should be, and yet its not. I think this
explains why I found RoboHelp to be so inferior to Flare. But this post
has already gone on long enough. I'll leave my analysis of Flare for my
next post.
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20131101/22b4ae5b/attachment.htm>
More information about the framers
mailing list