Very simply put, in screen capturing, Dr.Explain "looks" at the application you direct your mouse to.  Once you click (or press the key) to capture, you notice a little dialog box that pops up and quickly displays a series of numbers, and when it is done, your Window Capture is complete and has a set of callouts.  What you DON'T see is that while it is doing this, it is going through sometimes hundreds of different items in that window, and yet in the end only comes up with (typically) maybe 10 or 20 callouts that usually make sense as things you would want to document in your help file.

 

If it doesn't make sense, it is only a small number of simple steps to make the needed adjustments so it labels what the author wants to document.  Meanwhile, it still has done most of the work for you!  OR, if you document a LOT of screens this way, you can modify how Dr.Explain "interprets" the screen areas it analyzes.

 

While it is going through those sometimes hundreds of items "behind the scenes", what it is doing is processing a list of rules that you or I as a customer not only have access to, but can completely re-do if we want to!  (Not that you would want to attempt this unless you really knew what you were doing.)  The fact that it is there and allows me to make a few adjustments is very exciting.

 

I will go through one scenario with you of modifying these to suit my own needs for you so you can see, and possibly get started for yourself if you want to.

 

The problem that I am solving is that the application I am documenting uses a type of control called a LABEL for quite a bit of data presentation.  This is actually unusual to do, and so Dr.Explain is not set up to recognize where my data is actually stored, because usually a LABEL is only used to label OTHER controls that have real data in them.  Example:

 

First name:   [ <text box where a first name is entered> ]

Last name:   [ <text box where a last name is entered>  ]

 

The Labels here display the text "First name:" and "Last name:".  Typically, in this scenario, you would normally only be interested in documenting the TEXTBOXes containing the data -- the labels are self-explanatory.  Thus, the "First name:" and "Last name:" labels, never actually containing "data" as such, would almost never be targets for documenting in a Help file.  This is why Dr.Explain is specifically set up to NOT place callouts on these (most of the time you would just have to delete them).  Also, there are usually a LOT of labels on any particular window, and so in MOST cases (not all), having callouts on the labels would be an annoyance.

 

But my application has the unusual circumstances of having used labels in quite a few places to display actual data (data that only the program controls and that cannot be changed by the user).

 

See screenshot of a Screen Capture result of one such area:

 

 

 

 

Note that the rectangles that contain "0" values LOOK LIKE textboxes, but are actually labels, which is why Dr.Explain didn't produce call outs for them.

 

So what I want to do is temporarily create a custom set of Screen Capture Scenario Settings that tell Dr.Explain to in fact recognize labels displaying text containing one or more zeros ("0") as valid targets for creating callouts.

 

Here we go!

 

Step 1 is to observe that Dr.Explain is analyzing my Real-Time Data panel with the Accessible Objects approach.  I can tell this because I have changed the boundary color for the Accessible Objects analysis to bright green:

 

 

 

 

This fact is additionally visible in the "Capture an object" dialog box because the data area in the lower portion of the dialog box is headed "Accessible object properties".

 

As I move my mouse around, I watch this dialog box.  I make it highlight JUST the controls I am interested in:  the rectangular labels displaying "0".  I see that the labels I am interested in all have this in common:

 

Name:   0

 

Role:   Text

 

That's all the information I need.  I click Cancel to cancel the screen capture and proceed to

 

Project Settings > Screen capturing > Capture scenario > Edit > Accessible object filters

 

There I observe there is already one filter (provided by Dr.Explain) for controls having the role "Text", but that its "Parse accessible object as" option is "invisible control".  This is why it is not producing a callout for me.

 

So I highlight the filter just ABOVE that one (to place the new filter just above the Role = "Text" filter) and click New filter and enter:

 

 

 

and click OK and observe my new filter is added just above the original "Text" filter.  I click OK and OK to save my new screen-capture settings and capture the panel again, and voila!

 

 

 

 

In the end, I realize this is not a very practical example, because I only have a few labels that are like this, and thus it takes me only a few minutes with Dr.Explain's "Standard" screen capturing rules to do a screen capture and simply add a few callouts myself to the screen capture in order to accomplish what I want to in my documentation.  However, it gives to me HUGE power in that if I encounter an application I want to document that was created in an unusual programming language, then I can "teach" Dr.Explain how to produce logical callouts for it too!

 

My opinion:   ABSOLUTELY BRILLIANT on the part of the Dr.Explain team!

 

That means that -- yes, I guess I will have to admit this -- this makes Dr.Explain worth probably 2-3 times what they're asking for it.  And that they're keeping their price low tells me they're in line to capture a good part of the help-authoring market!  Good for them!  They will have earned it.