MadCap Software Forums

I'm in an unfortunate situation here. We're transitioning from a CHM file to web-based help and rolling out the first mobile version of our software. In a happier world I could just change the target and mostly use conditionals to set blocks of material as "large screen only" or "phone/tablet only." But after five years of using Flare the big boss rejected the idea of using the output that way. He doesn't like that we rely on software we didn't write and he does have one legitimate concern about anyone seeing our documentation without a software license.

My immediate boss (along with others in management) are completely on my side on this and I will continue to use Flare to write our Help topics. Since a lot of the material will be the same for the mobile and desktop versions of our software I can mostly reuse the content with some tweaks. As I see it I can either

• make the mobile help an entirely new project, copy/paste the files, and modify them as needed OR
• create a LOT of snippets so that I only have to modify the data in one place as the program changes.

I wish I didn't have to go through all this rigmarole and I'd appreciate any advice y'all could give to make the best of it.

I think you can still use conditions, but instead of excluding them from specific builds you leave them in, then use css to show/hide based on screen breakpoints.

So in the output (and I'm going from memory here, so the examples are are for illustration only) you'd get something like this:
Then you'd add into your stylesheet something like this:

Or, if the objection is that conditions are proprietary, they are, but they are just text, so you could find/replace them to your own "data- " attribute if you move to a different system. Or implement your own data- attributes now, athoug applying them is likely to be a bit of a pain. https://developer.mozilla.org/en-US/doc ... attributes

Or you could implement this same method using generic selectors rather than conditions. Generic so you could apply the special styles to any element (p, h1, h2 etc) you wanted.

Hmm although reading your post again, maybe you have to create to different versions of output, but just aren't allowed to use conditions? In which case snippets are probably the way to go so you don't have to make changes twice and potentially forget.

(Although snippets are potentially as problematic as conditions as they too are proprietary. And chms weren't written by your company, unless you work for Microsoft. And what about the tools you use to write your software? Okay, I'll stop poking holes in the argument now :p )

Historical/group "you" not personal "you" in the previous post, btw.

JoeWeinmunson wrote: Fri Nov 17, 2023 8:30 amIn a happier world I could just change the target and mostly use conditionals to set blocks of material as "large screen only" or "phone/tablet only." But after five years of using Flare the big boss rejected the idea of using the output that way.

It wasn't clear to me what is different about the desktop and mobile versions - is it A or B?

(A) If you have separate desktop and mobile apps with different features and interfaces, then I'd build two separate help outputs. I'd use conditions to mark the content that's specific to the desktop and mobile versions, and use target conditions to exclude/include content for each version.

---

(B) If desktop and mobile are just different views/layouts of the same app, and you can just switch between them in the same session, then I'd probably just produce one help output. However, I'd probably write that content so it works for all screen sizes, rather than try to dynamically show/hide help content according to the current screen size (as that can make things quite complicated).

---

Although you could dynamically show/hide content based on screen size, I would consider:

(1) Can someone view the app and the help on different screens/windows that are different sizes? If so, then you can't really use media queries and breakpoints in the help to determine what content to show/hide, since it needs to respond to the screen size of the app - which might be different to the help. For example, I might view the app at a large screen/window size, but view the help in a much smaller browser window to the side.

(2) You can't (easily) dynamically hide content from Flare's search and menu navigation.

(3) Will it be confusing to the reader to have content that magically appears/disappears, whilst they're using it?

JoeWeinmunson wrote: Fri Nov 17, 2023 8:30 amhe does have one legitimate concern about anyone seeing our documentation without a software license.

That's not specific to using Flare, since Flare just builds the output and it's entirely up to you how you distribute and control access to your content. If the content is hosted on a web server, you can control access to it in the same way as any other content on the web. However, although you can put in restrictions on who can access the content, you will not be able to prevent someone from copying/sharing your content if they are determined to do so.