A well-rounded program and excellent organisation at the second MadWorld user conference avoided many of the traps that can mar a sophomore effort and point to a way of growth into the future. The second day again saw great informative sessions and networking around doc issues and careers, not to mention lunch and drinks under the San Diego spring sun… 🙂
Advanced single sourcing of content in Flare uses a clever combination of snippets and conditions which are called, not surprisingly, “snippet conditions”. These allow you to maintain reusable chunks of content with slight variations – which one is ultimately displayed is controlled on the topic that contains the snippet.
In his single sourcing presentation, Paul Pehrson had many more tricks up his sleeve:
- To repeat a topic in the same TOC (with or without variation), put the topic content into a snippet and embed it into an empty unique topic container – else your breadcrumb trail in online help goes haywire, because it cannot know which of the two occurrences it should refer to.
- To reuse similar front matter across several PDFs, you can put the front cover, the copyright page, and the table of contents into a TOC of their own, import it as a nested TOC into each target and control the individual differences with variables.
- To maintain individual project styles and corporate styles, create your project CSS and import the corporate CSS into it by using the @import CSS command.
- To share condition sets or variable sets across two projects, store them as External Resources where you can keep them in sync with one another.
The lightning talk round was a very colorful fast-paced session. Passionate speakers addressed widely different topics, including
- A MadCap version of Jeopardy by Pam Coca (“Who is our tech comm game show host?” 🙂 )
- Several ways to avoid inline formatting with the help of Chuck Norris by Scott DeLoach
- MadCap’s latest group of spokespersons: Dentists who recommend Flare for more smiles than any other help authoring tool by yours truly
The 6 topics wouldn’t necessarily have warranted a full session each, but they were fun and valuable to have in a compressed 5-minute format.
Our addiction to meaning gave attendees food for thought as I led them through a quick overview of semiotics and mental models which included Japanese restaurants and misheard song lyrics. In the Q&A session we explored how we could apply such insights into cognition to offer users confidence in their tasks along with meaningful instructions.
Writing, editing and translating topics is frequently done by people who don’t have Flare and don’t need it either.
Mike Hamilton showed several scenarios to address special demands in authoring workflows:
- For writing and editing users of Contributor, you can customize exactly which Flare files, such as snippets, condition and variable sets, are available to them. You can also lock down certain text in Contributor templates to enforce structure and labels.
- For reviewers using Contributor, you can now apply conditions and variables when creating the review package, for example, to keep internal data out of packages for external reviewers.
- For translators of Flare topics, you can create customized export packages and choose to preserve the code of snippets and variables or to convert them into flat text.
For MadWorld 2015, my guess is that we might see fewer sessions on basic Flare techniques which are well-covered in available webinars and other information online. Instead, I’d recommend more sessions that show how MadCap supports tech comm workflows and business cases. These could cover, for example:
- How to integrate documentation and training content with Flare and Mimic
- How to build a business case around single-sourcing topics that can turn tech pubs into a profit center which leverages content as corporate assets
- How to use MadCap’s products in corporate, large-scale products, like Lynn Carrier has shown this year.
Overall, MadWorld was a very instructive, very fun event! The user conference format affords a welcome focus which sometimes gets lost in industry-wide conferences which have to try to satisfy more disparate needs.
CEO Anthony Olivier spoke of welcoming us all to the “MadCap family”. I think that metaphor is stretching it a bit. For me, it feels more like a versatile community of dedicated, often enthusiastic users who get to hang out with one another and with, say, a band we like – and we get to spend some time back stage in the hospitality suite. 🙂
Filed under: conferences, MadCap Flare |
Kai's Tech Writing Blog 
Thanks for your notes on the conference – very handy for those of us on the other side of the world.
I was interested in a comment you made in the abstract for your “Addiction to Meaning …” talk, about why FAQs don’t work. I’d love to hear more about this as FAQs are quite popular at my work – would like to hear about the alternatives.
Thanks, Margaret, I’m glad you’ve found the summaries useful!
My take in “Addicted to Meaning” on FAQs is more descriptive than prescriptive, so it can explain why they don’t work, when they don’t work. It’s also a bit flippant… 🙂
Following Heinz von Foerster and his tenets of radical constructivism, meaning is always created by the reader in their individual situation and context. In my experience, most questions about a product are one of three types:
1) Frequent and expected: What is this product? Why is it cool? How do I benefit? How do I use it? – These questions, I believe, should be answered in the general documentation in such a way that users can quickly and easily find them.
2) Frequent, but obnoxious: Why is this so weird? Why does it not work as I expect it to? – This happens when documentation has to write around bad user experience. Ideally, these issues, I believe, do not belong into documentation, but on developers’ and engineers’ desks so the UX can be improved to make this type of FAQ superfluous.
3) Less frequent and dependent on individual use cases and situations: How does this or that work in particular? – These issues, I believe, should be answered in the context of the concepts or tasks they relate to, and also in a way that users can quickly and easily find them.
I’m especially wary of FAQs that come in great abundance. I once saw an FAQ respository of approximately 1500 entries. The result was that hardly a user had a chance to guess correctly how and where to find any one answer, much less gauge whether the entry he looked at actually applied to his particular issue or not.
But as I said above: I think there are good reasons why FAQs do not work – but that doesn’t mean that all are doomed to failure always.
Hope this helps, Kai.