why create HTML targets that don't include the skin?

[kkelleher]

While looking through MadCap's Flare documentation for information about creating HTML targets that don't include the skin, I came across this:

Theoretically, you could have HTML5 output without either a full skin or components, but that would be rare. In most cases, you will want to include skin elements of some kind so that end users can more easily find information in your output.

I'm intrigued by the idea of not using a skin because I think it might solve problems that we currently handle through post-processing. Has anyone played with this much? Under which rare cases would we want to create a target with neither a full skin nor components? Where do the components end up in the output?

I found some third-party information (here and here) that seems to indicate that the use case is when the group receiving the output (say, the customer) wants to supply their own navigation and look and feel, and also to enable SEO for tri-pane HTML output. Is that about right?

Thanks,

Kristen

[NorthEast]

I found some third-party information (here and here) that seems to indicate that the use case is when the group receiving the output (say, the customer) wants to supply their own navigation and look and feel, and also to enable SEO for tri-pane HTML output. Is that about right?

Yes, that's about right (but it's not for tri-pane).

Previously, in Flare v8-10, we just had the tri-pane skin for HTML5 output. Tri-pane uses frames, which makes it problematic for customisation, SEO, or integrating your content with something else. So, various people produced 'frameless' help systems that just delivered the help as a single-page (the topic), and ditched the tri-pane framework (i.e. no navigation pane or header/search). However, by doing that, it also meant you had to build and integrate your own navigation and search into the page.

So for v11, MadCap gave us a lot more flexibility - we can now produce single-page outputs, and choose what skin elements to include, and where they're placed.

You don't have to use them, you might want to build your own menu/navigation control, or use an alternative search facility (e.g. google custom search). It's all about flexibility really, it makes it easier to customise your output, or get it working with other systems, tools and frameworks.

[kkelleher]

Thanks for the info, Dave.

Yes, that's about right (but it's not for tri-pane).

I was trying to distinguish between tri-pane and TopNav types of output, but obviously didn't manage it.

build and integrate your own navigation and search into the page

We've done something similar with our online docs, but I'm hopeful that we can use 'skinless' TopNav output to circumvent some of the complexity of our post-processing, which is brittle and tends to choke on some of Flare's output.

Can anyone offer thoughts on using skinless TopNav output? There's probably a good chunk of work to do to get the results we want, so guidance is much appreciated.

Thanks,

Kristen

Edit: I'm about halfway through the 'goodbye tripane' webinar and realize that the choice isn't TopNav or skinless, so I've edited my previous comments.

[Paulie]

Under which rare cases would we want to create a target with neither a full skin nor components?

Hi there,

One specific use case where I have used targets without skins was to create a regular website based on content that already resided in Flare. This allowed the company to single source information between their website, online help and printed documentation, rather than using a more traditional tool like Dreamweaver for their website and Flare for everything else.

[wclass]

We had a use case where we had a lot of information in a Word document that needed to go into SharePoint wiki pages alongside existing information. We dragged the Word doc into Flare and created skinless output that we then embedded into the wiki. People can use the wiki and don't really care if they are looking at a Flare page or a native SharePoint wiki page - it was the skinless output that let us do this easily.

[kkelleher]

Thank you, Paulie and wclass for your comments -- very helpful!

-K

[gpetta]

Hello,
I know this is an old post but it addresses a possible solution for our intranet that is built on SP 2013. This question is directed at wclass and how you embedded a Flare topic into your SP wiki page. Did you surface the content in an iFrame on the wiki page? Or is there another method you used?

We use drop downs extensively in our content since our topics are very long. My concern is that if I use an iFrame I will end up with a second scrollbar on the iFrame when the topic drop downs are expanded.

I really like the idea of a seemless integration of Flare topics on our SP intranet site but I can't figure out how to make it work due to the drop downs.

Advice from anyone would be greatly appreciated.
Thanks

[wclass]

We used a Page Viewer web part that points to the default.htm page and the Flare output displays OK. You have to specify a height for the web part - scroll bars will only appear if the content (once expanded) is longer than that. We have not found this to be a problem. We use togglers in the topics. We also use "tabbed" content - while this is stored in the one file, the tabs mean we don't have to scroll far.
I don't know the details of the web part - I think it comes with SharePoint but I don't know if our systems people changed it or not.

[gpetta]

Thanks for prompt reply wclass. I suspected you were using some sort of iFrame solution and that just won't work for us. I'll keep exploring options. Thanks again.