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)
Single Sourcing for desktop and mobile
-
flarenewbie
- Propeller Head
- Posts: 25
- Joined: Thu Feb 16, 2012 9:47 pm
-
ajturnersurrey
- Sr. Propeller Head
- Posts: 348
- Joined: Fri Nov 05, 2010 3:30 am
Re: Single Sourcing for desktop and mobile
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.
Re: Single Sourcing for desktop and mobile
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.
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.