This is a presentation I gave at MadWorld 2019 in San Diego. Here is the slide deck from the presentation:
This presentation was given as an advanced workshop at MadWorld 2019 in San Diego.
You can download the project files and PowerPoint slide deck at the following URLs:
This is a presentation I gave at MadWorld 2019 in San Diego. Most of the presentation was a live demonstration, but for reference, here are the slides:
On Wednesday at the MadWorld conference, I join forces with the indomitable Daniel Ferguson for a presentation on advanced TopNav output.
Session Description:
You already know that MadCap Flare is the best tool to help you create a great experience for your users when they engage with your help system online. What if you could make it even better? Turn those ideas into action by attending this advanced workshop where we’ll show you how to use bleeding edge CSS3 with complex selectors, pseudo classes and more to make your output “sizzle”. We’ll talk about how you can integrate JavaScript libraries like jQuery and Grunt to do more to make your output shine above the rest. Flare trainers Paul Pehrson and Daniel Ferguson join together in the workshop to not only show you what is possible, but to give you the tools you need to try it on your own. You’ll leave with specific ideas of things you can do in your current projects to make them better for your users.
In-Class Files
Click here to download the sample project and JavaScript files:
In case you missed it, MadCap Software announced that due to the success of the annual MadWorld conference in San Diego, they are adding a new conference in Europe, MadWorld Europe.
The conference is scheduled for September 11 to 14, and will be held in Prague, Czechia.
If you are interested in presenting at MadWorld Europe, a Call for Papers is open until Jan 23rd.
Read more about it on MadCap’s blog:
Conference Update: MadWorld Europe 2018 Announced, MadWorld 2018 Registration Discount Ends Dec. 31
Hey everybody,
The 2016 MadWorld Conference is now in the history books, and I’ve been asked to provide my content from my presentations here on my blog. I’ve created a page where you can view all the shared content from my presentations.
This year I was asked to participate in the Lightning Talk session. To be honest, I had a hard time narrowing down my topic until the last minute, so I didn’t have any slides prepared for that session. Instead, however, I’ve taken my topic–Using Browser Tools to Understand Your CSS–and I’ve turned it into a short YouTube video (you can see it at the end of the post).
I’ll write up a conference wrap-up post a bit later, but I wanted to get my slides and other content out there for you as soon as possible.
Here’s my lightning talk.
I’m pleased to announce that I will be presenting a free webinar as part of the MadWorld 2013 Speaker Series in cooperation with MadCap Software.
Please join me on Thursday, May 16, 2013 for “Picture This: Optimizing Images with MadCap Flare and Capture,” a free webinar from MadCap. I will be giving a slightly adapted version of my popular MadWorld 2013 presentation. I received a lot of great feedback on this presentation, and I think this will be a popular webinar.
Register by visiting MadCap’s Live Webinar site.
If you have specific questions you’d like to see answered in the webinar, please leave a message in the comments.
Watch for an upcoming announcement about another free webinar I’ll be giving in June on content reuse — one of my favorite topics.
Its Monday morning, and I’m back in Utah. It snowed last night, which is a pretty stark comparison to the weather a week ago at MadWorld 2013 in San Diego. What a great conference! If you followed my Twitter or Facebook feed you already heard me say that this was the best technical conference that I’ve ever been to. I really hope to be back next year at MadWorld 2014.
So here is my post-conference postmortem.
Hotel
MadWorld was held at the San Diego Hard Rock Hotel, right downtown in the Gas Lamp Quarter. It’s a hip, modern, 4-star hotel. The first thing you saw as you entered the hotel was the floor-to-ceiling backdrop behind the check-in counter featuring the MadWorld 2013 logo in some type of recurring video loop. Right there you knew that this conference was going to be something different.
We checked into our room (Christina and our 7-month old came along for fun) and took the elevator up to our floor. The room was amazing. We had a sitting area with a couch and chair, with a large flat screen television and a stocked mini-bar (not a temptation, actually, because the price of a candy bar started at $4). In the bedroom section, we had a large king size bed — the nicest hotel bed I’ve ever slept in, another large screen television, and a Juliette balcony overlooking the Gas Lamp Quarter. The shower had two heads – one in the standard location and one coming directly overhead out of the ceiling. As a tall person, I especially appreciate showers that accommodate my height, and I loved this shower.
The first night, a small welcome gift arrived in our rooms from MadCap. They gave us a MadWorld bottle opener, MadCap M&Ms, and a welcome card. It was a small touch, but something that just made the day nicer and showed a polished finish.
Additionally, the hotel was literally across the street from the light rail station, and we were able to take the light rail on several occasions to get around San Diego.
Conference Venue
The sessions were all held in conference space at the Hard Rock Hotel. MadCap went all out. Each of the rooms had a color on the printed schedule, and there were colored lights along the walls of the rooms that corresponded to the room’s color. Hard Rock has televisions built into the wall at each conference room, showing you the room schedule for the rest of the day. At various locations in the hotel, you could also see what rooms were being used by the conference and which sessions were currently being held in which rooms. The chairs were comfortable, and the atmosphere in general was very well done.
If I had two wishes for the conference next year, the first would be to make the presentation screens higher, so that more people in the room could see the whole slide deck; and second, provide conference wi-fi in the presentation rooms.
Sessions
No matter how cool the conference is, the quality of the conference comes down to the presentations that are being given. I’m an advanced MadCap Flare user. I’ve been using Flare since version 2, and providing training and consulting services on Flare since version 4. I have the MadCap Advanced Developer certification, and I’m an MVP in the Flare forums. Yet, despite all I know about Flare and other MadCap tools, I still found sessions I wanted to attend, and I learned new stuff at the conference. There were four tracks ever hour: beginner, intermediate, advanced, and tool agnostic. I generally attended sessions on the advanced and tool agnostic tracks, and I found that the presentations I attended were given by people with excellent domain knowledge and experience. I felt like I was learning from people who really understood their subjects and had relevant, useful information to teach us.
I’d rank the presentation sessions as good to great, and the feedback I got from most people was the same. I didn’t hear a single person talking about a session they didn’t like. (Most conferences do have sessions that people don’t like, but I certainly didn’t hear anybody complain at any point about the sessions, so I think that is a good sign.)
Food / Non-session meetups
MadWorld provided lots of food and good networking opportunities outside of the classroom sessions. There was a full breakfast both mornings with fantastic fresh fruit (including fresh berries, melons and grapes!) and good selections of eggs and meat.
MadWorld provided lunch both days of the conference, and that was very good and gave attendees a chance to talk to each other and get to know one another.
There were mixers on Sunday evening, Monday evening, and Tuesday evening with drinks and appetizers provided by the conference. This was a great opportunity to talk socially with other attendees, as well as MadCap staff, which were everywhere during the conference, which leads me to the next section — MadCap Staff.
MadCap Staff
The MadCap staff were everywhere at the conference. They were at all the sessions, all the non-session events. They had a room set up staffed by employees where you were welcome to bring your project and get one-on-one help with the problems you were facing in your project. They even hosted a session for people to share their complaints about MadCap products–and took that feedback to incorporate requests in their project planning. At the mixers, it felt like MadCap staff were making sure everybody felt included and nobody was sitting alone. In short, the staff were a major part of what made this a great conference.
Door Prizes and Collateral
The door prizes at MadWord were interesting. When they first announced that they had boy prizes and girl prizes, I’ll admit that I was a little bit nervous, as that could go wrong in so many ways. No need to worry, though. The first prize was a “girl prize” and was a very nice, very expensive handbag. The next two prizes were gender specific: one men’s pair and one women’s pair of Prada sunglasses. The next prize was a men’s watch. Then they combined the names and drew several gender neutral prizes, like an iPad mini, a $500 Amazon gift card, and a Microsoft Surface tablet. Finally, they raffled off two custom-made (by Mike Hamilton, none the less!) electric guitars. (They were essentially a Zagg-style invisishield wrap on the face of the guitars — they were very cool. For the two winners, MadCap was willing to ship the guitars to them, since they would be difficult to get home on an airplane.
The conference collateral added to the overall feeling at the conference. The room key cards were emblazoned with the MadWorld logo. Everybody got a MadWorld t-shirt. The Lanyards and badges were very nice and very professional-looking. There were pins to attach to your lanyard for each of the MadCap tools you use. The theme of the conference was everywhere from the information packet to the room lighting, to the “rock star” invitations to the special events.
Presenter perks
As a MadWorld presenter, MadCap flew me to San Diego at their expense, picked up my hotel tab (for an upgraded room), provided free full conference registration, and included hotel VIP service (a special check-in and check-out counter with free drinks, and nightly turn-down service in the room. All I paid for was my airline baggage, and a couple of off-site dinners. That is the nicest presentation package I’ve ever had at a conference.
Wrap-up
I really loved presenting at and attending MadWorld 2013. I can’t wait until the 2014 call for proposals — I’m already getting my ideas ready. I hope that you will join me next year at what I’m sure is going to be another amazing event. Start planning for it now… At the conference MadCap said MadWorld 2014 will again be in April next year. This is one conference I know I’m not going to want to miss.
Again, I’m honored to present at the 2013 MadWorld Conference today in SanDiego. Today I present on customizing HTML5 output.
This post includes links to the slides, videos, and source code that I used in this presentation. This is meant both for conference participants as well as all blog readers, giving you a flavor of what was presented today at MadWorld.
Here is a link to the PowerPoint Presentation itself (10MB).
The Content
Now, for an abbreviated version of the presentation.
When trying to take all the information that is available about styling Flare output and distilling it into a 50 minute presentation, I decided to focus on four key areas:
- Modifying the HTML 5 skin
- Using webfonts
- Brief introduction to responsive layout
- Making dramatic changes to Flare output
Let’s start with modifying the HTML 5 skin file
Because this is a presentation rated for beginners and intermediate Flare users, I want to discuss each of the tabs in the skin editor. In Flare, the skin file is the bread and butter of how the webpage is construted. The skin file controls most aspects of the framework that displays your help content. It controls the logo, the icons in the toolbars, which tabs display, the colors of the tabs and icons, etc.
Open an HTML 5 skin in Flare, and you see the skin editor which has several tabs.
I won’t discuss each tab in great detail for three reasons:
- This is pretty basic stuff and is covered extensively in the Flare help system.
- Recent versions of Flare give you a lot of contextual help in the skin editor.
- I want to spend the bulk of our time on some of the non-standard changes you can make.
The General tab
On this tab, I just want to point out that the term “Caption” means “HTML frame set page title.” In HTML 5 this isn’t used because instead the page title in the browser is the same as the topic that is being displayed. In standard WebHelp, this Caption is how you get a title on the frames et. In HTML 5 you can leave this field blank, and nobody will ever notice.
Flare 9 includes an option to keep or remove unreferenced images. This is because the skin file is one of the few binary files in Flare. When you add an icon (like a book icon, or a print icon, etc.) to Flare, the skin file stores the binary of the image in the skin file itself, rather than referencing the image from another location. If you add an image to the skin file, and later replace it, this option tells the skin file whether to keep the unreferenced, old image, or to delete it when you save the skin.
The Size tab
You can ignore this tab. Let your developers have control over how the help system looks when they call it.
The Setup tab
Two important things to note here. First, the Pane Position and Size options. Please choose either a left or right pane position. Nobody wants to see your tabs on the top or bottom of their help system. The pane size is the width of the left navigation pane when it opens. Users can drag this to make it wider or narrower.
The Toolbar Tab
This tab lets you select which icons appear on the toolbar above the topic. If you aren’t connected to Feedback or Pulse, your only real options are Print, Expand All, and Remove Highlight. However, if you want you can add custom Javascript. Note, this isn’t for a specific button. This is for the toolbar page, so this javascript is loaded each time the toolbar is loaded. I haven’t found this useful yet, but if somebody uses it, I’d love to hear about it.
Also, you can click the new toolbar button button to add a new button to the toolbar. Clear as mud? I’ll show you how this works in just a minute.
The UI Text tab
Let’s jump down to the UI Text tab. This tab lets you modify the actual text that is displayed in the user interface. So, if you don’t want it to say “TOC”, you can easily change it to something else here, like “Contents”.
The Styles tab
Here is the meat of where you set up how your HTML 5 output looks.
This should feel familiar to those of you who use the advanced version of the CSS editor in Flare. This works the same way. Pick the item you want to style from the column on the left, and use the properties on the right to change the settings.
The top of this list is full of Feedback settings. I wish they were grouped together into a single top-level entry for those of us who don’t use Feedback, but just scroll down past them.
On this screen note that if you select Logo, you can use your own company logo instead of the default MadCap logo. Expand the Background section, and edit the BackgroundImage property.
Sometimes people ask whether or not they need to use an icon here. In HTML5, there is no Home button on the toolbar, so if you don’t include a logo, the users have no way of going back to your output’s start page. For this reason, I recommend you include something.
Look how items are grouped in the Styles list. Lots of the individual settings you want to create are hiding in these groups.
When I first started working in Flare, I didn’t realize that I can make settings for ALL THE ITEMS IN THE GROUP by making those settings on the parent node. I was opening each of these items and changing all the settings, trying to make them all identical. That is not necessary. Set the global properties on the parent node, and then just set the unique settings on the child nodes.
Let’s talk about editing the toolbar icons. First, note that in HTML5 there is only one image: “BackgroundImage”. In WebHelp, there were three different images, one for normal, one for hover, and one for click. HTML5 is MUCH simpler. You only have one image because there are no “hover” or “click” effects.
Ok, remember how we wanted to add a custom button? Let’s say I added a custom button to link to my Facebook page.
Notice that my custom buttons show up in the styles list, so I can add my own settings.
You need to set two things for custom buttons: (1) the BackgroundImage, and (2) the Click event. The background image is the button icon. The click event is javaScript code that is executed when users click on the button.
So that is your whirlwind overview of customizing the skin file itself. Lets move on to Webfonts.
Webfonts
What are webfonts, you ask? Webfonts are font files stored on a webserver, and they are called and used like any other online resource. They allow you to use non-web-standard fonts, with a reasonable assumption that most internet-connected users will be able to see the content in that non-standard font.
If a user loads a webpage using a webfont while not connected to the Internet (think government contractors, for example) the computer would be unable to locate the font resource, so it would fall back on the next font defined in the style sheet.
If you have a secure site, you will need to load your webfonts from a secure server, or users will get an error that some elements on the page are not secure. This is outside the scope of this particular discussion, but I wanted to point it out and let you know I found the solution by googling it.
Please be aware that you need to be very careful about posting fonts on a web server. Most fonts on your computer are covered by intellectual property laws, and you are bound by the terms of the license agreement. Most font license agreements do not permit you to post the font on a webserver. To be safe, I use fonts from a trusted source: Google Web Fonts, which can be found at google.com/fonts.
So, how do you use Google web fonts? First, visit their site, pick the font you want to use, and then review your collection. Then you add the proper code to either your CSS style sheet or your Flare MasterPage. I recommend using the CSS method, but you can do whatever works for you. Google gives pretty good directions on its site.
Once you have the URL, you paste it into the top of your CSS stylesheet.
Now, just use the proper name of the font in the “font-family” declaration. In my site, I set the font family for my heading 1 to be “Permanent Marker,” and the font-family of the body tag to “Noto Sans.” Note that I used the body element, so that I didn’t have to add it to every individual child element. If I hadn’t done it in Body, I’d have to do it separately in <p>, <li>, <table>, <heading(s)>, as well as the MadCap-specific elements like drop-down text. When it is in <body> it is automatically inherited by all of <body>’s child elements.
The image on the right shows the rendered result.
So, there are a couple of caveats. Webfonts work best on, you guessed it, the web. Webfonts do NOT work in PDF targets. You need to use a local font for PDF targets. (You can set this either in the Print section of the style sheet, or you can use a standard font as part of the cascade in the font-family declaration.)
You can also try downloading the font from Google. (The fonts are free.) Install the font in Windows, and then open Flare and see if you can access the font in the CSS editor. (If Flare is open when you add the font to Windows, Flare won’t be able to use it until you restart Flare.) Due to limitations of the .NET framework that Flare uses, Flare is not able to recognize all fonts on your system, so this process may be hit or miss.
Ok. Let’s talk responsive layout, then.
Responsive Layout
First, I know that there is a technical difference between responsive layout and adaptive layout. Since this is a pretty basic introduction to the concept I use the term responsive, even though it might not be the most correct term for a more technical audience.
Websites that are responsive use specific sections of the CSS style sheet depending on the conditions of the viewport. This isn’t new to Flare users, since you’ve been using the Print section of the style sheet. This is just another section of the stylesheet, but rather than being based on media type (print versus online), these styles are used based on other properties.
Here is an example of a responsive website. Open the window full screen, then reduce the size of the browser. Watch how, as you drag, the elements on the page change. Some content disappears, some of it moves to a different location. This is responsive design in action.
Responsive layouts are supported by all current browser versions, though IE has only had support since IE9. All in all, about 86% of users world-wide are using browsers that support responsive layouts. But don’t worry. The responsive section of the CSS is just ignored by those browsers, but all your standard settings will still work — it will be no different than they get today. And since responsive design is really geared for mobile users, or users of tablets and smaller devices, you don’t need to worry too much about the older IE support.
So, how does it work?
In your style sheet, add the following code:
@media (PROPERTY: SETTING) { ELEMENT { STYLE: ATTRIBUTE; } }
For example:
@media (min-width:500px) { h1 { font-size: 24pt;} }
There are a lot of properties you can pick from including min-width, max-width, device orientation (portrait vs. landscape), screen resolution, etc.
Here is a link to a site that gives you a good starting point for what types of queries you could use depending on devices you were targeting. Here is an abbreviated version of the CSS I used in my Flare project to move the content from two columns to one, depending on the viewport size.
Lets take a look at some of those styles side by side. In the left column you see the standard settings set in the main section of the style sheet. These are the styles that will be used when one of the media types does not match. (In this case, anytime the viewport is 911 pixels or wider. In my case, I have a wrapper that has a nice border around it, and I specify a size setting for the wrapper.
When the viewport width is between 475 and 910 pixels, I allow the wrapper to reduce in size. When the viewport is narrower than 475 pixels I remove the drop shadow, remove the border, remove the margin, and set the width to 100% of the viewport width.
I also have a two column layout. The standard layout is to have two columns that float next to each other. However, when the window with is below 910 px, the second column drops below the first column, so the users don’t have to scroll horizontally. When the width drops below 475, I ensure the column gets 100% of the width to make it easy to see.
The second column works just like the first, but in the standard view, it floats right.
Finally, let me show you one site I worked on where I radically changed the way HTML5 output looks.
Dramatic Changes to HTML5 Output
You are not necessarily limited to what changes you can make in the HTML5 skin file in Flare. If you are willing to get your hands a little dirty in the code, and make some post-production changes, it isn’t too hard to radically alter the way the help system looks. I had a client who wanted to dramatically alter the way HTML5 output looked, because they wanted it to more-closely match their website’s UI. The image at right represents as close as I could get making the edits in the HTML5 skin editor. However, this wasn’t exactly what they were looking for.
They wanted the search box on the left side of the screen, and their logo on the right side of the screen. The wanted corners to be more round, and they wanted text in the toolbar that is above the topic. The left column was to be a single tab, not multiple tabs, and it needed to look like a column header, not a tab.
The trick to making these changes was opening the default.htm file that was generated in the Flare output, and then making changes to that file. The changes to the styles and such in that file override any styles set in the style sheet, so I was able to get a very granular-level of control over the output’s details.
Here is what I was able to create for them with those tweaks to the default.htm file. This change requires the client to copy over the modified “default.htm” file into the output after each build, but the look and feel to the client was more important than that minor detail. The changes I made were for Flare V8. If the client were to upgrade to Flare V9, they would need to make different changes, because in Flare V9, MadCap modified the default.htm file. I’ll post my code modifications so you can see what they did, but please note that if you are using Flare V9, these modifications are not correct. They were for Flare V8 only.
Here is a screen shot of the source code. I’ve highlighted the sections of the document that I changed. It is also worth noting that I removed a bunch of extra code that wasn’t needed. Some of it looked like commented code that wasn’t removed before V8 was released. Other parts were for websites where the navigation panel was in a different position. So this is a simplified default.htm that only included the parts that V8 needed to display the page based on the configuration the client had chosen.
If you want to see this customization live, you can visit help.zebrazapps.com.
I hope this has provided you with some ideas on how you can modify your HTML5 output to match your company’s style. If you have questions or want clarifications, please let me know in the comments below.
I am honored to be able to present at the MadWorld 2013 Conference today in San Diego.
This post includes links to the slides, videos, and other content that I used in this presentation. This is meant both for the conference participants as well as all blog readers, giving you a flavor of my presentation today at MadWorld 2013.
Here is a link to the PowerPoint Presentation itself (20 MB, includes videos).
The Content
In this presentation, I covered the following topics:
- How Flare and Capture work together
- Capture Features that integrate with Flare, specifically showing you how you can save time and money and reuse content
Flare and Capture Integration
If you haven’t been using Capture as part of your MadCap Flare workflow, now is the time to begin. Starting with version 9 of Flare, Capture is a free download for Flare customers. I have a couple of screen capture tools that I use, depending on what programs I’m working in, but when I’m working in Flare, I always use Capture. Those times where I used a different tool, then came back and wanted to edit the images, I was disappointed because I had to re-do a bunch of work.
Flare makes it easy to initiate screen captures. Depending on your settings, you don’t even need to open Capture or edit the file in Capture. I’ll show you more about this a little later. Capture allows you to edit your images, and you can edit an image from Flare by right-clicking on an image in a topic and selecting “Edit with MadCap Capture.”
Capture also makes it easy to use conditions and variables from your Flare project in the call outs of your Capture images.
Capture Features
I want to focus on how Capture can save you time and money, and show you how you can maximize your content reuse in Flare.
First, Capture saves you time because you only have to do the hard work of image editing once. You can capture a full-screen image, and then crop it down to a single menu item for use in your Flare project. If you ever need to re-capture that button, Capture remembers where the screen was that you captured,what size the capture was, and how you cropped it. So you can go to the updated page, and take the full-screen screenshot again, and Capture correctly crops the image down to the single menu item (assuming, of course that it hasn’t moved.)
Cropping and Re-capturing
When you crop images in Capture, the original image is never deleted. It is stored in a properties folder next to the final image. So if you come back a month (or a year) later and want to change the way the image was cropped, you can open the image in Capture and click the Crop button. The original image is shown, allowing you to change the way you cropped the image.
I’ve worked with developers who decided a week before product launch to change the whole color scheme of the application. I had hundreds of pages of documentation with call-outs — the works, but my work to re-capture the application was minimal because Capture did most of the hard work for me.
Here is a demonstration video (no audio) of how this works.
First, I capture a screenshot, then I crop it.
Next, I modify the style of the interface I’m documenting.
Next, I come back to Capture and re-capture the image.
This works the same way whether you do it the same day, or at any point in the future.
Resizing Images
Let me show you how you can re-size images in Capture. (Again, no audio).
We start with creating a new capture from Flare and editing it in Capture. When you have a screen capture open, you right click on the image and select File Properties. On the Image Effects tab, change the background scale to change the size. 1.0 represents 100%. Point 5 (.5) is 50%, etc.
Blurring Sensitive Information
Capture lets you blur information that you don’t want people to read. This is helpful if you are working with confidential production content. What’s great about this, is like other Capture features, if you re-capture the screen again later, the blurring will automatically occur in the same location.
From the image toolbar, click the Effects button, then select Blur Inside Effect Mode. (If you just choose Blur Effect Mode, then everything BUT the image you draw will be blurred.)
Drag the box around the area to be blurred. Right-click on the blurred area to change the Properties. (I make sure there is no border around the box, and I change the Image Effects tab to have a Blur Factor above 10.)
Image Classes
When you use images in Flare, be sure to create different CSS classes for different types of images. This allows you to have similar images appear in a similar way.
For example, in this image, I have the exact same image from my project, but with different image classes. One is called “thumbnail”, and one is an image with no image class.
For the thumbnail image, you can see that you get a small version of the image that has a red border around it. This is a visual cue to let the reader know that they can interact with this image. Images in general, with no class, don’t get the border, they don’t get down-sized, and they don’t have any interaction when you hover or click.
Examples I have of image classes are: (1)thumbnail, (2) border, (3) specific sizes.
Image Profiles
Capture introduces the idea of profiles, or commonly used settings, that make capturing images faster and more efficient. This helps you get uniform images quickly and easily, directly from Flare.
For example, let’s say I want all my screen captures to be resized to 300px wide, and have a 1px black border and a drop shadow. I can save all these settings in a profile, and they will be automatically used for all images captured with that profile. Observe:
How does Capture save me money?
First, remember that time is money. Every time-saving feature is a money-saving feature.
Next, like I mentioned before, Capture is a free download with Flare 9. You don’t necessarily need another screen capture tool, so that is more money saved.
Third, if your help files need to be translated, you probably don’t use too many image callouts, because you don’t want to have to re-do every image that has a callout. In Capture, the callout information is stored as XML in a properties file in the same directory as the Capture image. Since this information is in XML, it is easy for MadCap Lingo to package that text for translation. What’s awesome is that before Flare builds a target, it re-builds each image in Capture, so if you change a setting in the XML, that setting will be reflected in your documentation the next time you either open the image in Capture, or rebuild your Flare output.
Finally, Capture saves you money by making it easy to reuse and single-source content.
Tell me more about single-sourcing images
One of my favorite Capture features is the ability to use variables in your image call outs. Since Flare re-builds the Capture images at every build, you can use target-specific variables in your callouts.
Watch this video to see how I use a variable to show the product release number, and how when the variable definition changes, the image automatically updates.
You can do the same thing for conditions. Any box or object on the screen can be conditionalized to appear in some outputs, but not others. You can also apply snippet conditions so that different versions of a picture show depending on which topic the image is placed in.
What about using the same image for Print and Online?
Capture allows you to have different settings for a single image, depending on whether your target is online or print.
Here are the settings I typically use (set in a profile) to differentiate print versus online images:
- Image Effects tab:
- Background scale: 0.7 (70% of captured size)
- Format tab:
- Format: PNG (this is for Online output types)
- Flare Print Format tab:
- Enable Print Format: [checked]
- Format: TIFF
- Print DPI: 150
Be aware that by increasing the DPI, the resulting image WILL LOOK SMALLER because you are condensing 92 pixels per inch into 150 pixels per inch. This is a good thing for print for a couple of reasons. First, it makes the printed image look crisper, and second, images on a printed page typically don’t need to be the same size as images on a webpage. You may want to play around with this setting to get a number that works for you, but for me, this has been a good balance. Then I can change it for individual images, as needed, or if I want different settings for a different type of image, then I create a different profile.
Common Questions
Often people have questions about how to use Capture, so I’ve included some answers in this post.
How do I create image captions for my images?
This is technically a Flare question, not a Capture question, but it is still a good one.
I create a container DIV in my Flare project CSS file. I call it DIV.CAPTION
I use the following settings:
div.caption {
font-size: 80%;
page-break-inside: avoid;
padding: 10px;
margin: 10px;
border: solid 1px #000;
background-color: #d3d3d3; max-width: 300px; /* use standard width of images */
float: right;
}
Next, I create a paragraph style to number and style my captions. I use this setting:
p.captionnumber {
mc-autonumber-format: {b}Figure {n+} - {/b};
}
Watch how I apply this div and paragraph class.
But what if my image numbers need to include the chapter?
Especially for printed output, you might want to use the chapter number in your figures (Figure 4.3, for example). You can easily do this in the print section of your stylesheet by changing the style:
p.captionnumber {
mc-autonumber-format: CH:{b}Figure {chapnum}-{n+} {/b};
}
For online help, you can do this differently, because you can use the different media sections of the style sheet. Note, however, that if these are done differently, depending on the medium, then you will have a hard time referencing them directly in the help text.
I hope this post has given you some ideas on how you can integrate Capture into your Flare workflow. Do you have questions, or do you want to share your favorite Capture feature? Please share, in the comments below.