TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Documenting two similar interfaces From:Bill Swallow <techcommdood -at- gmail -dot- com> To:Sarah Blake <Sarah -dot- Blake -at- microfocus -dot- com> Date:Tue, 23 Jun 2009 11:24:49 -0400
Sit the project manager, product manager, and other project leads down
and bring this up. Ask which will be the default UI, not just when
installed, but how it will be marketed and pitched. If they want both
documented, find out if they want them in the same Help file or as two
different Help files (in which case it's up to the dev folks to point
to the right one from the right skin). As for authoring, I would push
for two different help files and single-source the content,
conditioning for classic and ribbon.
On Tue, Jun 23, 2009 at 11:15 AM, Sarah Blake<Sarah -dot- Blake -at- microfocus -dot- com> wrote:
> To save me reinventing the wheel...
>
> I'm currently working on a project where we're upgrading the UI to use a
> new 'ribbon'-style interface (a la MS Word), but users will also have
> the option to use the familiar 'classic' interface. The documentation
> will therefore need to deal with both.
>
> I'm not sure which of these will be the default; I suspect the ribbon
> interface, but I don't know for certain. And while the placement of
> functions within menus is similar between the two, it's not identical.
>
> At the moment, I'm looking at basically doing the following:
>
> 1. From Furniture > Hatstand (or Interior > Furniture > Hatstand if
> using the Classic interface)
>
> ...but the help is the approximate size of War and Peace, and giving
> double directions for each task seems a bit cumbersome, especially when
> (as seems inevitable) I'm going to have to go back through in a couple
> of releases' time, removing one set.
>
> If I have to, then I have to, but does anyone else who's gone through
> this process have any tips or suggestions? (The documentation format is
> CHM, created from XML source files.)
Available for contract and full time opportunities.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-