Single Sourcing for desktop and mobile

This forum is for Single-Sourcing your Flare content to multiple outputs.
Post Reply
flarenewbie
Propeller Head
Posts: 25
Joined: Thu Feb 16, 2012 9:47 pm

Single Sourcing for desktop and mobile

Post by flarenewbie »

Documenting an app that works on PC, MAc, iPad, and Android. IS it a good idea to use single sourcing given the following facts
a. The feature descriptions will be shorter for mobile
b. The UI for mobile is much small so feature path too will differ
c. Some features are [present only in the mobile version, and not in PC version

Required output is webhelp, which I think works on iPad also. Tried on Android and it looks file (maybe font sizes need to be adjusted)
ajturnersurrey
Sr. Propeller Head
Posts: 348
Joined: Fri Nov 05, 2010 3:30 am

Re: Single Sourcing for desktop and mobile

Post by ajturnersurrey »

In this sort of situation I have one project for deskstop outputs. In this project I condition a number of topics for inclusion in the mobile output. The mobile outputs are then built from a separate project, which imports all of these conditioned topics, and has a few of its own. That way there is some sharing, but not everything.
jmenning
Propeller Head
Posts: 50
Joined: Thu Jul 20, 2006 2:52 pm

Re: Single Sourcing for desktop and mobile

Post by jmenning »

Because I loathe duplicating work, I'd look at ways to use mobile-like documentation for the desktop app, to bring the two sets of documentation closer together. If short feature descriptions are okay for the mobile version, are longer ones really required for the desktop? Longer topics/walk-throughs/tutorials/whatevers could be conditionally excluded from the mobile version. Images could be stored in a folder that is conditionally excluded from the mobile version... Just thinking out loud here ;) but I can see ways to handle it in one project.

If there's not a lot of overlap in features, though, two projects might make more sense, because then setting conditional tags and keeping track of what goes where can become a lot of overhead with not much benefit.

There'll be pros and cons to any method, so "what's best" will probably depend on your app, style, workflow, etc.
Post Reply