Archive for January, 2009

TechSmith steps up to the plateTechSmith steps up to the plate

Posted January 21st, 2009 by paul.
Category: Jing, SnagIT, Software, TW Tools, Technical Writing | 5 Comments »

TechSmith produces a couple of tools that are important in my tech writing workflow including Snagit (probably the best stand-alone screen capture software available, in my opinion) and Jing (a simple program for sharing quick screen captures and screencasts (video).

I complained last week about Jing’s latest release, and how when I capture small videos and play the SWF file directly, the video scales to the browser viewport size. So videos that I had captured at 300×200 pixels were being displayed six times their size in my web browser, and like 10 times their size on my boss’s monitor.

I’ve had an extended conversation with TechSmith’s support department over this issue, and then yesterday I received an e-mail from a developer who is working to resolve the problem.

We’ve now written back and forth a couple of times, discussing ideas to resolve the problem.

I’ll wait until the next release of Jing to decide what I think about this whole issue, but I wanted you to know that what I think TechSmith is getting right, so far, is  how they are handling my complaint. I feel like my concern has been not only heard, but is being acted upon.

In the end, TechSmith will have to make a decision on how to proceed based on what they think is best. But at least I know that my voice has been heard and considered.

Thanks, TechSmith.

Jing Project makes a huge mistakeJing Project makes a huge mistake

Posted January 16th, 2009 by paul.
Category: Books, Movies, Media, Software | 7 Comments »

I’ve been a happy user of a tool from TechSmith called Jing. It is a quick and easy way to take screen shots and screen cast videos and share them with other people.

I’ve been looking forward to the latest version of Jing, which was released last week, and when it first came out I found some things that I loved about it.

Unfortunately, however, I have decided that TechSmith blew it big time in one critical area for me.

To understand why this is important, let me give you a bit of background.

Like I said, Jing lets you take a quick screen shot or video of your comptuer desktop. This tool has become a valuable tool in my kit. When I’m working with pre-release versions of my company’s software, I often discover bugs. I can quickly take a screen shot of a problem in our application. Jing saves the screenshot to a pre-determined location, and puts the filepath on my clipboard. I go to the bug repoting system, and just click “paste” to put that filepath into the attachments field. It makes attaching an image to a bug report VERY quick, and painless.

The same thing goes for screen casts. When I find a bug that results from a process I encounter, or whose functionality is better shown in a video, rather than captured in a still image, I can use Jing to grab a video, record my audio commentary of the bug. When I save the Jing video, Jing saves the video to a pre-determined location, and puts the filepath on my clipboard. I go to the bug reporting system, and paste the filepath into the attachments field. My developers love it.

I also send jing videos and images via instant message to my co-workers all over. It is a quick and easy way to share information.

However, the newest Jing, released last week made a major change to the way that videos are shown when you play them. Now videos expand to the full window size, regardless of the size of the recording window. I never record full-page videos. It is harder for people to process, and wastes space on the file system. Now, when people open my videos by opening the video from the bug system, or by clicking on the link in my IM, the video plays full screen. My boss has a 30″ screen. I created a video that was about 300 pixels wide by about 200 pixels high. It was expanded to full screen on his monitor. He had to stand back several feet to even understand what he was seeing.

I contacted TechSmith to disucss this issue. They tell me that this is a “feature” in the new version of Jing, and suggest that I embed the video into an HTML page to control the video size.

Nonsense. This is about quick sharing. There is no way that I’m going to take a video, then create a html page, then embed the image into the html page, then save the page, then upload the page to a server and then send the html page’s location to a co-worker. Not going to happen. Remember TechSmith? This is about quick sharing of information. There’s nothing quick about making me embed the video into an html page in order to make the size be at  100%  of the recorded size.

I wish I were writing about what I like in the new Jing. Problem is, I can’t recommend it for anybody who wants to take video  because I believe this “feature” makes it unprofessional at best, and unusable at worst.

TechSmith? Can you hear me? Can you fix this please?!

Update (1/29/09): TechSmith heard and answered. Check it out.

Twitter noiseTwitter noise

Posted January 15th, 2009 by paul.
Category: Blog, General/Random, Software | 3 Comments »

If you’re on Twitter, I bet you have one of these types in your list too: the type who have decided to use Twitter as their personal blog.  The kind that have extended conversations about the same topic over and over and over and over again.

I’ve got somebody like that in my list.

In the last hour, I’ve received 31 tweets. Of those, 24 have come from a single person.

Wait, just got another. 25 tweets in a single hour. Shut up already! Or, if you have that much to say, get a blog!

I’m tempted to de-list the noisy one, but he is well known in my industry, and I do find some of the tweets interesting. I just think that this is getting old fast.

How do you do it? I mean, how do you handle the tweeter who won’t shut up? Do you de-list? Are you ever the noisy one? Do you think before you tweet? Or do you think that you shouldn’t have to?

A shout out to MadCap SupportA shout out to MadCap Support

Posted January 15th, 2009 by paul.
Category: MadCap Flare, MadCap MadPak, Software, TW Tools, Technical Writing | 4 Comments »

You’ve heard me say it before, and you’ll hear me say it again: I really like MadCap Software. In case you just joined us, MadCap produces my main authoring tool, MadCap Flare. I use Flare to create single-sourced online and printed help for a variety of products.

Several times every week, I will be working on documentation, and I’ll use a feature in Flare (for example, conditional snippets), and I stop and literally say, “Wow. I love Flare.”

Now, you might expect a MadCap MVP (i.e. volunteer forum moderator) and a MadSkills Certified Trainer (which isn’t my day job) to like the company that produces the software. I’ll admit I have a bias. But I became a MVP because I loved the software enough to contribute to the MadCap forums regularly. Then I was invited to join the MVP group. And I didn’t set out to be a Trainer. MadCap actually contacted me, because they know how much I know about and like Flare, to see if I could pick up a training session that the other trainers were unavailable to take.

In any case, when I see a blog entry like this, I have to be even more grateful for the fantastic people in MadCap’s support department. In the post, MK Anderson talks about an unresolved customer service incident with Adobe that has been going on since August (4+ months!). And we’re not talking a complex custom feature request. We’re talking about getting a valid product key, even for a newly upgraded product.

I compare that to the customer service I’ve personally received from MadCap software, and the comparison is stunning. I have bronze-level support from MadCap. Yet, several times, MadCap has CALLED ME on the phone to better understand a technical problem I’ve reported. All my support requests have been resolved within a few days (though some of the resolutions were “we’ve filed a bug” — which is all you an say for some issues). MadCap Support doesn’t give up on difficult to find issues; once there was a bug being reported by a couple of customers, but MadCap couldn’t track it down. They worked with the few customers reporting the issue until we discovered repeatable steps to encounter the issue, then they fixed it that same day. Try getting that kind of support from Adobe.

So here is a shout out to all the fabulous people at MadCap Support. Thanks guys for a job well done! You are a big, big part of what makes using MadCap software a great experience.

Creating snippets from multiple blocks in FlareCreating snippets from multiple blocks in Flare

Posted January 6th, 2009 by paul.
Category: MadCap Flare, Structured Authoring, TW Tools, Technical Writing | Comments Off

When you are writing content in Flare, you may decide that you want to re-use some content that you previously added to another topic.

We’ve discussed before how the best way to do this is to use a snippet, which essentially is a really long, formatted variable.

To do this in Flare, you create a new snippet, then you locate the text you want to re-use, and copy the text out of that topic and paste it into the snippet. Then you replace the text in the original topic with the snippet, then insert the snippet into the new location.

This isn’t too hard, but I’ve long wanted to use a nifty shortcut, but couldn’t figure out how to make it work. See, when you are writing in the XML editor, there is an option on the context menu (right-click) menu that allows you to create a snippet from an existing block. That works great if all you want to add to the snippet is a single paragraph, but it doesn’t work if you want to add multiple block-level elements into the snippet.

Today I thought of a way to do this quickly and easily, even with multiple blocks.

Here is what you do.

  1. Open the topic that contains the text that you want to turn into a snippet.
  2. Select the blocks that you want to re-use.
  3. From the Format menu, select Group.
  4. From the pop-up, select the div option. (This groups the selected content into a single block, the DIV block.)
  5. Now, right click on the DIV block, and select “Create Snippet”.
  6. Give the snippet a name and click the Create button. The snippet is created and inserted into the original topic
  7. Go to your new topic and insert the snippet into it.

If you are creating Word or Framemaker output, you may need to change one additional thing:

  1. Right click on the snippet block, and select “Open Link”. The snippet file itself opens.
  2. Right click on the div block, and from the Edit menu, select “Unbind”.

This removes the div, which can cause positioning problems in Word and Framemaker outputs. (I don’t actually know if you NEED to do this extra step, but it isn’t a bad idea.)

Using a div to create a snippet is much faster, in my opinion, when you are trying to create a snippet from a multi-block selection. Try it, and I think you’ll agree.

—–

(This article has been cross-posted on DocGuy Training.)