Dave Wooldridge wrote:
Brendan Murphy also wrote:
When I started looking at help systems, my main goal was to have
a maintenance free cross platform system. That's a pretty tall
order. I looked at (and bought) UniHelp and it is a fine product
for what it does and is well suited for cross platform usage, but
fails miserably when it comes to creating maintenance free help
files. I tried it on a couple of products, but gave up on it. It
is not a productive system.
What I think Brendan means by this (based on feedback he has sent
us in the
past) is he is looking for a help system that he does not have to
reconfigure settings every time a new version is released that he
wants to
integrate into his apps. He wants a component that he can replace
in his
app with the latest version without having to constantly tweak the
configuration code for.
While that used to be the problem with the old 1.x versions of
UniHelp, we
actually listened to his feedback awhile back and radically changed
the
architecture of UniHelp 2 last year to utilize a more modular class-
based
framework, so that upgrading to the next release of UniHelp does
not require
any code tweaking. For example, we just released UniHelp 2.1 and
replacing
it in your apps requires only swapping out the old classes for the new
classes -- no code has to be updated.
But it sounds like Brendan stopped using UniHelp before the new
UniHelp 2
system was introduced. Of course, his UniHelp license still works
with
UniHelp 2 if he ever wanted to revisit using it in his apps. ;-)
What I meant by UniHelp/HelpLogic not being a productive system is
that I as a developer want to spend my time efficiently. I don't
want to be writing html code, I want to write "content". This is
the Achilles heal of UniHelp/HelpLogic in that it is not a turnkey
system that lets you form start to finish complete the
documentation without having to write a single line of html code.
In order to do that with UniHelp/HelpLogic, you need to buy GoLive
or Dreamweaver and there is another $400 added to the price. On
top of that, since the UniHelp/HelpLogic and GoLive are made
by separate companies, there is no guarantee that the output by
GoLive will be properly rendered by UniHelp. So you are walking on
eggshells between the two tools.
A long time ago I specifically suggested to Dave that they need a
built in a WYSIWIG editor in HelpLogic that can guarantee output
that will work in UniHelp. Then you would have something special
in HelpLogic. As it stands now, it is a lot more work than it is
worth to use UniHelp/HelpLogic. If you enjoy writing html code,
then go for UniHelp/HelpLogic. If productivity is your main goal,
then you must consider other solutions.
Apple's Pages word processor is about the best solution for
creating documentation except for the fact that it cannot create
PDF bookmarks. It makes "you" the documentation writer efficient
since it is a word processor and it works better than Microsoft
Word! I have used MS Word for years and it has become a confused
mess because of feature bloat and poor GUI implementation. So I
have decided to live with the limitation of the lack of PDF
bookmarks in exchange of being happy as a documentation writer. So
if there is any Apple employee out there reading this, PLEASE add
the ability to make PDF bookmarks based on the TOC.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
