Fixing Save as Adobe PDF Crashes
There have been many reported instances of the "Save as Adobe PDF" workflow crashing regardless of application, but precious few workarounds or resolutions. In troubleshooting, I discovered that there were three instances of the "Save as Adobe PDF.action" in three different locations: /Library/Automator; ~/Library/Automator; and /System/Library/Automator. By eliminating all except the version in /System/Library/Automator, the workflow started behaving, and I was able to cut PDFs directly from the Print dialog.
Series: Hacking the Press
Want to get noticed? Want the world to know about your product? Adam Engst shows you how.
Article 1 of 4 in series
The last two years that I've attended the MacHack developers conference, I've also participated as a speaker. I've done this in large part because the attitude that permeates the conference is one of sharing knowledge, and although I can't contribute a line of code to a hack, I can explain to developers how the press works and how developers can better interact with the press, for the benefit of everyone via improved reportingShow full article
The last two years that I've attended the MacHack developers conference, I've also participated as a speaker. I've done this in large part because the attitude that permeates the conference is one of sharing knowledge, and although I can't contribute a line of code to a hack, I can explain to developers how the press works and how developers can better interact with the press, for the benefit of everyone via improved reporting. In the spirit of the conference, I call this session Hacking the Press. Although my talk and representation of it in this article series are aimed primarily at developers, it should shed light on the inner workings of the Macintosh industry in which we all play roles.
The Utility of Exposure -- In this first installment, I'm going to look briefly at the basic question of why anyone would bother trying to score press coverage for their product. It may seem painfully obvious, but you'd be amazed at the number of developers, both large and small, that don't seem to grok this basic principle: the goal is increased exposure for your product and company. And for those who fail to understand the goal of increased exposure, consider the following results of exposure and decide if they're attractive:
Additional sales. If you're attempting to make money by selling your program, increased exposure is likely to help increase the number of people who will plunk down their hard-earned cash for your software.
Improved brand recognition. If you're trying to make a name for yourself or your company, increased exposure can help make that name the first one that springs to mind when someone thinks of the overall topic. For instance, it's impossible to think about desktop publishing without thinking about Adobe and Quark. But what about Diwan Software (Ready, Set, Go!) and Corel (Print Office)?
Enhanced reputation. Many developers who release their software for free are doing so to satisfy the little voice inside that wants recognition for good work and the reputation that accompanies that recognition. But if no one learns about and uses your program, how can it help your reputation? Keep in mind that reputation is incredibly valuable in helping to open doors elsewhere in life. For example, the reputation I built up publishing TidBITS helped open the door that allowed me to write the best-selling Internet Starter Kit series of books.
Successful altruism. Many developers, particularly smaller ones, write software solely to help other users. Even if there's a financial component to your overall goals, the more people who know about your work, the more likely the software can help them. For instance, when I write books, I do so with the hope that they'll earn some money, but my primary goal is to help readers. If the book doesn't sell well, I'm disappointed both on financial grounds and because few people benefited from my work.
Types of Exposure -- Of course, the press isn't the only conduit for telling potential users about your software, but in many ways it's the best. Let's finish off this week's article with a look at the different possibilities.
First, it has become important to have a Web site, and indeed, it should provide extensive details, including pricing, system requirements, release notes, support information, patches, mailing list archives, and so forth. There aren't any limits on how much information you can put on a Web site, and you shouldn't skimp. You don't get any points for a concise Web site, and if you're confused about what should be on your Web site, put yourself in the shoes of users and journalists. And even if a Web site doesn't automatically increase your software's exposure, you will gain a resource that's always available, working for you while you're working on other projects.
Although a solid Web site is important, users know they're seeing only your side of the story. For instance, it's tempting to publish a comparison table with competitive software that puts your program in a positive light, but no one will be surprised when your program wins on every comparison. There's nothing wrong with doing such comparisons, but don't assume that users will take your word on everything. Plus, no journalist worth his or her table salt will look at your comparison and say, "Wow, now that I've seen this nicely formatted table I can see that GurgleWeb is by far the most powerful Web browser on the market."
Second, it's important to employ some sort of advertising, which can take a variety of forms, all of which are designed to tell people about your program and its features and benefits. Advertising in publications is great on two counts - you control exactly what's said, and it's extremely important in helping publications survive (which is necessary for editorial coverage). However, advertising is less important than it was before the Web, when it was a primary source of information for potential buyers. I remember poring through the ads in computer magazines for every scrap of information I could find. These days, advertising is more about branding and basic name identification - you want users to think of you instantly as soon as a problem solved by your software appears.
On the downside, advertising does cost money, and if you're making claims about your product, you can be sure that many people will take your claims with a grain of your aforementioned table salt. We're all becoming ever more media-savvy - I remember when I first learned that the paper catalogs put out by MacConnection, MacZone, MacMall, and others listed only products that had paid to be featured (it's called cooperative advertising, and TidBITS covered it a few times back in 1996 and 1997). Before, I'd always assumed that merit was somehow related. So although advertising is important, relying on it can be dangerous if users don't buy into the message you're trying to convey.
Third, and here's where we'll pause for this week, we come to the most important form of exposure (in my humble but utterly biased opinion): editorial coverage. Other than the minimal cost of a review copy and possibly a bit of your time working with the writer, editorial coverage is essentially free, making it more attractive than advertising for those on limited budgets. Plus, any opportunity to connect with writers and editors is valuable in its own right. Even if the coverage is limited, such as being mentioned in a review of a competing product, it's almost always better to receive the coverage than not. Full coverage is of course ideal, and although space varies from publication to publication, a review not only offers readers far more detail than any advertising you could buy, it also carries far more weight with readers than anything you can say, either on your Web site or in an ad.
The risk with editorial coverage is that it may not be entirely favorable, since you don't have any control over what the reviewer writes. But is that entirely true? In reality, there are ways you can improve your chances of getting coverage, avoiding bad coverage, and recovering if you do happen to be on the receiving end of some bad press.
I'll include those tips in future installments of this series, which will also look at the different types of publications and the best ways of interacting with each type, the roles different people within your company (development, marketing, PR) play when dealing with the press, what journalists are like and how to interact with them, and finally the types of coverage you can expect and the value of each type.
Article 2 of 4 in series
Last week I talked about the reasons you might want to work with the press; whether you're a developer looking for product exposure, or a non-profit looking for volunteers, knowing how to deal with the press can be a valuable toolShow full article
Last week I talked about the reasons you might want to work with the press; whether you're a developer looking for product exposure, or a non-profit looking for volunteers, knowing how to deal with the press can be a valuable tool. This week I'll continue with a look at publications. Because they vary significantly in the types of information they publish and their target audiences, it's important to tailor your efforts to specific media outlets.
Many types of publications exist because the Internet has lowered cost barriers that previously prevented individuals and small organizations from publishing. Ric Ford's MacInTouch is a perfect example - Ric Ford and Rick LePage started MacInTouch as a paper journal years ago, but the difficult economics of publishing on paper resulted in MacInTouch transmogrifying into a well-received column in MacWEEK. Then, with the rise of the Internet, Ric was able to recreate MacInTouch yet again, this time into a Web site that has become one of the primary sources of frequently updated news in the Macintosh world.
Keep in mind that the lines between the types of publications I discuss below are blurring, with the smudges also caused by the Internet. Few traditional publications lack Web sites, though sometimes they're mere placeholders.
Traditional Magazines -- Traditional computer magazines are still what comes to mind when many people think about the press. The Macintosh world has a handful of major magazines, with Macworld, MacAddict, and MacTech being the main names. Others such as Mac Home Journal certainly exist but don't command the same recognition, and I know less about them. (We've never personally been involved with the business aspects of a paper magazine, but in the interests of full disclosure I should note Tonya and I have written for the three main magazines, I've been a columnist for the now-defunct MacUser and MacWEEK, and I've recently been named a Contributing Editor at Macworld. Other TidBITS staff members also write freelance pieces for these and other industry publications.)
Traditional magazines make and spend a lot more money than most Internet publications. It's not surprising - staff for copy editing, design, and layout aren't cheap, and printing and distributing hundreds of thousands of magazines isn't cheap either. Some years ago, when I last looked into the economics of paper magazine publishing, magazines assumed that subscription fees only covered the cost of printing and mailing. Since then, increased costs may mean publishers spend more to print and distribute than they bring in from subscriptions and newsstand sales.
So, most of a magazine's revenues come from advertising, with the split between editorial and advertising pages varying widely. That's why magazine page counts can change, sometimes radically - without enough advertising, there isn't money for editorial pages. The reverse is also true - with a lot of advertising, the number of editorial pages may increase, since a publication must carry less than 70 percent advertising to qualify for a periodical class mailing permit.
These details explain important facets of working with traditional magazines. The publications have moderately large staffs, pay their writers, and have numerous policies about interacting with vendors. They expect to be taken seriously when they call for review copies or other information, and their quality is generally high. I won't pretend traditional magazines don't publish mistakes, but mistakes are less likely since the publications can hire good writers and pay people to check details - and they want to protect their long-standing reputations.
On the downside, traditional paper publications have long lead times. A writer typically finishes a feature article months before it appears in print - editing, layout, graphics, printing, and distribution not only cost money, but take time. Other types of articles can have shorter leads, ranging from two to eight weeks. As a developer, it's worth asking when an article covering your product is likely to run so you can keep the writer in the loop with upcoming product releases. Many magazines won't review betas, but writers may still want to see them, particularly if your final release and the publication date correspond closely. (Remember that the date on the cover of a magazine often doesn't correspond with the month that people receive the magazine). Be up front about your planned release schedule with the writer and editor (you often talk to both when working with paper magazines), since that's the best way to avoid a less-than-positive review or mention appearing in print right before you release an update or new version. Some accommodation can usually be made if schedules collide.
Keep the bureaucracy of paper publications in mind - it's most appropriate to talk about technical issues with the writer and scheduling issues with the writer and the editor. Never mix any discussion of advertising with the editorial side of the magazine. At best, you'll seriously offend the writer and the editor. For instance, Neil Ticktin, publisher of MacTech, once kicked an advertiser out of the magazine after the advertiser threatened to pull their ad if MacTech didn't review their product.
When inquiring about advertising, talk to an ad sales rep - you can find contact information in the magazine itself. Ask how to make the most from your ad: some magazines can place ads near specific articles, and although some people interpret such placement as collusion between editorial and advertising, the editorial folks are unlikely to know anything about it. Such placement can be especially beneficial, since it links the editorial coverage with your advertising message and tells readers your company is sufficiently "real" to run ads.
Let the writer know you're happy to answer questions - if you're lucky, you'll have the opportunity to fact-check the article ahead of time. Some publications (including MacTech and TidBITS) will do this to increase accuracy; others explicitly do not to avoid tricky issues with pre-publication knowledge and arguments with negative reviews. If you're given the chance to fact-check an article, do not comment on anything but questions of fact, particularly if the article is at all negative: your only chance to improve the conclusions is to point out factual errors which led to those conclusions. Only occasionally have representatives of companies abused this privilege with TidBITS, and in each instance it was tremendously unpleasant and damaging to our relationship with them.
Responding to errors or concerns in a published article is trickier. If the errors are minor, personal email to the writer can prevent similar future mistakes without burning bridges, and the writer can point you in the right direction if the magazine has a corrections column. Address email about more serious errors to the editor, and if you feel that the editor is part of the problem, a politic note to the Letters to the Editor address is best. Although publications are generally willing to acknowledge factual errors, be very careful disagreeing with published conclusions or subjective things like ratings. The relationship you establish with writers, editors, and the publication at large is paramount: it's self-defeating to jeopardize that relationship by complaining about a single article.
If you feel you've been totally wronged, keep all of your communications unfailingly polite. Never blow up at a writer or editor: it's especially stupid with paper publications since the individuals involved are likely to stay in the industry for years and move to more influential roles. Poisoning the well at a paper publication could contaminate a fair bit of the groundwater too.
As you've probably realized, paper publications are marked primarily by structures which you have to work with and understand. Your best strategy is to ask the editor (without being obsequious) what the publication expects from you and how you can help. Editors appreciate this attitude because it makes their lives easier, and (as we'll see in a future installment) journalists are incredibly busy.
Internet Magazines & Newsletters -- I've talked about paper publications because they set the model emulated by other types of publications. Online magazines and newsletters, TidBITS included, often follow approaches similar to paper publications in creating solid, professional content. Some (again, like TidBITS) stick to regular schedules and integrated issues; while others publish new articles on the Web whenever they're ready. Internet publications don't have paper and its associated costs, but do have much shorter lead times. When Tonya and I started TidBITS we made a big deal of our short lead time, which put even MacWEEK to shame. These days, our weekly schedule seems downright relaxed compared to Web sites that publish news items as soon as they can.
The lowered expenses and quick turnaround for Internet publications significantly changes how you work with them. Few Web publications have many staff members, so there's less distinction between writers, editors, and ad sales reps. Despite the multiple hats worn by the people who run Internet publications, it's still best to keep discussions about advertising completely separate from editorial issues. For instance, TidBITS is too small to have someone dedicated to working with current and potential sponsors, so I handle that along with my writing and editing. But I separate the tasks by using a different email address - <email@example.com> - exclusively for corresponding with sponsors to make clear that I'm wearing a business hat, rather than the editorial beret.
When an editorial schedule exists for an Internet publication, it's abbreviated. You need to be prepared to respond to queries quickly, since a turnaround of even a day could mean the difference between good and bad coverage.
The faster the publication schedule, the more likely it is that errors will creep in, and handling these cases is different than with paper magazines. First, you have to keep an eye out - or use some sort of scanning service - for such errors, since it's unlikely you'd be alerted by the publication that they've written about you. Your users are often the best source for alerts - yet another reason to make sure users can easily send you email. One advantage of Internet publications is that they can fix the offending text on the Web or publish a correction immediately (we adhere to the latter approach; see "The Unbearable Lightness of URLs" in TidBITS-467 for our rationale). Some sites may be less interested in doing so since their news cycles off quickly - this is another situation where a good relationship with the publication improves your chances of having mistakes fixed (and fixed quickly).
Reader-based Sites -- There's no official term for these kind of Web sites, but they tend to generate little content on their own, instead relying on readers to submit material. They add value by culling out bogus information, organizing the remainder, and providing a single destination for readers. Ted Landau's MacFixIt is one of the best examples, since Ted puts a huge amount of work into collecting and selecting bug reports from readers, verifying them to the extent possible, organizing them into a coherent whole, and often rewriting them so they make sense in context. Reader-generated content is also an increasingly common adjunct for publications that write their own content. For instance, articles on Mac Publishing's Web sites feature a reader feedback forum at the end, and our moderated TidBITS Talk mailing list serves much the same purpose.
From the perspective of a software developer, these sites are difficult to manage. Anyone can post a message about your product, and it has a good chance of being published if it's not clearly wrong or offensive. For instance, I personally approve every message to TidBITS Talk, but I may approve a message containing incorrect information if I don't know the product in question. Other readers may write in with corrections, but there's never a guarantee.
There are two solutions to this problem. First, get to know the people in charge of the site. (If you've been paying attention, you'll have noticed this theme throughout these articles: personal relationships are all-important when working with the press.) You want the people who manage these reader-based forums to think of you when something about your product comes in. If they know you, they're more likely to ask before posting something potentially damning.
Second, when something does slip by - and it will - it's up to you to address the inaccuracy in person in the same forum. This is extra work, but it's worthwhile. Remain calm and reasoned so you don't lose your rhetorical position of authority. Such a response will also have the effect of introducing you to the people in charge of the site, increasing your chances of avoiding similar problems in the future. I'd also recommend continuing to monitor the forum for appropriate topics - you'll help your reputation if you participate in discussions in a positive way as well as doing damage control.
Mainstream Publications -- Mainstream publications are magazines and newspapers that don't cover technology - they may run stories or even a regular column, but it's not their focus. It's not worth trying to get coverage in these publications - consider it a stroke of luck if they notice you. The hard part is working with them when they do notice you, since the approaches you use with technology publications are less likely to work.
The reason? Reporters for mainstream publications are less likely to be expert in the field on which they're reporting. There are notable exceptions, such as the technology reporting for the San Jose Mercury News and MacWEEK alum Henry Norr's column for the San Francisco Chronicle. But on the whole, assume that reporters for mainstream publications lack technical or industry backgrounds and adjust your discussion appropriately. Also remember that these publications' readership is also unlikely to be technically adept, so tailor your comments to that audience.
The advantage mainstream publications have - and the reason you want to be extremely responsive to them - is that huge numbers of people read them. Although it's difficult to measure, a mention in a widely read news magazine provides tremendous exposure. And being able to say that your product has been mentioned by the Wall Street Journal or the like may confer a great deal of credibility.
Other Media -- If coverage in a mainstream publication is luck, consider coverage in other media - television, movies, and, to a lesser extent, radio - manna from heaven. Over the years I've been interviewed for many local television news shows, and I've learned that my job is to distill the opinion I wish to convey into the shortest possible sound bite. The first interview I gave took about 45 minutes as I explained some Internet topic in depth... and I was on air for 25 seconds. Since then, the reporters haven't pretended to know much, and I've come to accept my role. I try to explain things to them while they set up and tear down; while they're filming, however, I speak in easily digested bits that the general public will understand. I try to make hand gestures so I'm not just a talking head), and I do whatever they ask if they need extra footage (generally of my hands typing). Thousands of people watch the evening news every day, and the exposure is always worth the effort of talking to the television crew.
There are good radio shows that cover technology, such as David Lawrence's Online Tonight and Shawn King's The Mac Show. They're great - the hosts have a clue, and you get a fair amount of time to talk. And on a technology-oriented show, you can be relatively technical without losing the audience. The manna from heaven comes if you end up on a non-technical radio show: you must be careful that you speak to the general public, but since these programs reach larger audiences than most technology-oriented shows they're always worthwhile.
I don't have much experience with movies, although I've done enough video work that I have a feel for the business. It's all based on contacts - one of your beta testers has a friend whose sister is an assistant director on the second unit for some movie. For the most part, it's not worth trying to get product placement - it will either happen or it won't based on contacts you probably already have. Large companies like Apple have departments which work with the film industry to make sure Macs show up in movies and television - if it happens for almost anyone else, chalk it up to good karma.
Looking Forward -- I've skirted the issue of types of coverage - paper publications are generally best at large feature articles that require hardware test labs, Internet publications often specialize in news, and so on. Although Macworld Expo may delay the next installment in this series, I'll next look at the types of coverage you can receive, their utility, and what to expect from each one.
Article 3 of 4 in series
Welcome back to my series of articles on how the press works and how to work with the press. I first talked a bit about why you should care about press coverage, and I followed that up with a discussion of different types of publicationsShow full article
Welcome back to my series of articles on how the press works and how to work with the press. I first talked a bit about why you should care about press coverage, and I followed that up with a discussion of different types of publications. This week I'll turn to the types of coverage you can expect.
Whenever we write a review of a program that has significant competition, we immediately receive email asking why we didn't compare the program with its competitors. Our answer, each time, is that the article was a review, not a comparison. I always feel bad about saying that, since it feels like a cop-out, but the fact is that every publication chooses to publish different types of articles depending on the situation. Let's work through them, starting with the smallest and least considered, but by no means the least important.
Mentions -- When thinking about article coverage, few people stop to consider the mere mention of a product or company, perhaps in a large feature article or even in a review of a competitor. If it happens to you, your product, or your company (for simplicity's sake, I'm going to abbreviate these three possibilities to "you" from now on), you may not even notice. After all, the article wasn't about you, so what difference can a few words make?
Actually, a mention is one of the most powerful and useful forms of coverage you can get, and it's an indication of success. When it comes to press coverage, being ignored is a bad fate. The fact that you rate high enough to warrant a mention often means one of several things:
You're considered the leader in the field.
You're considered a significant challenger to the leader in the field.
Your PR efforts have been successful enough that the writer feels you must be mentioned to avoid numerous redundant comments from readers.
You've established a sufficiently close relationship with the writer that he or she can't in good conscience omit you from articles about the field (but keep in mind that editors sometimes thwart the best intentions of writers in this respect).
So don't underestimate the utility of small mentions. They don't carry much information, but what's important is that readers will think of you in that context. There's little you can do to ensure that you're mentioned other than cultivate your relationships with journalists and work on a solid advertising and PR strategy aimed at making your name well known.
News Blips -- "News blip" isn't a technical term, but I'm thinking about the kind of news coverage that can be condensed into a sentence or two. Publications often use news blips as a way of increasing timeliness and breadth of coverage, since it's easy to throw in a news blip about a product or company that wouldn't otherwise warrant coverage.
Readers like news blips because they're easily digested and give an overview of what's happening. Web-based publications like MacCentral, MacInTouch, MacFixIt, and MacNN, and even headline sites like MacSurfer draw much of their popularity from their frequently updated news blips covering recent events, product releases, and reader reports.
Single news blips are easy to produce, but the cumulative effort of posting numerous news blips each day is huge. Just sorting through incoming email and scanning other publications (yes, everyone does it - it's a time-honored research method) is a brain-busting job, and writing up the results day in and day out requires true grit.
Thus, anything you can do to simplify news blip collection and production efforts will increase your chances of coverage. That boils down to creating effective press releases that contain all the necessary information. Although you should never baldly state this, a well-written summary paragraph at the top of your press release just might find itself becoming a news blip at publications that are under especially high time pressure or that don't feel the need to write everything from scratch. One warning: don't invent or overinflate events (like beta releases) just so you can put out a press release and get news blip coverage. It may work for a while, but it's essentially a modern-day equivalent of the fable of the boy who cried wolf.
Although I don't deny the popularity of news blips, I personally find them less useful than brief mentions because publications specializing in news blips often aim to be comprehensive instead of selective. More and more, I find that I prefer sites or publications - not just in the Macintosh world - that drill down on specific topics. So, when making decisions about where to focus your efforts, aim first at publications that are targeted to your desired audience, then move out to the more general publications.
Product Announcements -- Next up in the arena of coverage is the product announcement, which many readers confuse for a review. A product announcement is essentially a news item that the publication wants to publish before there's time for a formal review. People often confuse product announcements and reviews because a good product announcement brings together a fair amount of information and provides context and advice. A good reporter can even include negatives from early user comments or knowledge from a public beta to balance the positive information from the announcement. Although publications easily differentiate between the two, the fact that readers may not can be to your advantage.
Product announcements tend to be positive because most of the information comes from the company. Any negatives included are less likely to be serious or specific since the writer hasn't yet been able to work with the final version of the program for long. So, when releasing a product, make sure your Web site has plenty of the kinds of information reporters can use to turn a news blip into a product announcement - what's new and what's cool. Plus, if you have relationships with specific reporters, it's worth giving them - independently - a bit more in-depth information about particular features you especially like. That effort will increase your chances of receiving a better and more detailed product announcement article, and reporters like being able to set their stories apart.
Reviews -- In theory, a review is the ultimate coverage you can receive, since it's devoted entirely to your product, with the only distractions being occasional mentions of the competition. I say "in theory" because reviews have a number of gotchas.
Reviews come in a variety of sizes, depending on the publication and product. When I wrote about Internet Explorer 5 in TidBITS, my review was almost 3,000 words. In comparison, reviews in print publications often range between 200 and 1,000 words. Each publication chooses review length based on space, what its editors think their audience finds interesting, and product depth and importance. In some cases, a short review might be better for you, if its size means less room for negative comments, but long reviews are generally best, since their length indicates that the program is both sufficiently interesting and worth the space. To give you some context, this paragraph is a bit over 100 words.
Although it's unusual in the Mac world, a truly negative review can be damaging. Check back to the previous installment of this article series for suggestions on dealing with such a situation, but ongoing contact with the reviewer and editor is the best way to make sure you're not surprised by a bad review. And if you're concerned that the review is going to be awful ahead of time, there's no shame in asking the editor if you can withdraw your product from consideration. Perhaps yes, perhaps no, but it can't hurt to ask, politely and without implying that the reviewer is out to get you.
A glowing review with absolutely no negatives is good for the ego, but it is its own downside. Some readers may blindly believe the review, but if the writer couldn't come up with any negatives, many people will distrust the review. Good publications try hard to present balanced reviews for this very reason - too many glowing reviews and readers may start to distrust everything.
The best way to increase your chances of being reviewed in a publication is to send review copies (also called "comp," for "complimentary," and "NFR," as in "Not for Resale" copies) or software registration numbers to the publications you want to review your product. (But don't assume that sending a review copy entitles you to a review - it just increases your chances.) The cost in sending review copies is essentially nil in relation to the sales a review can encourage, and you want to do everything you can to ease the logistical aspects of a review being written. If you're asked for a review copy by a publication, agree graciously. There are few things journalists hate more than nagging for review copies, and reviews have been cancelled because of vendors being difficult about review copies. In many cases, reviewers don't plan to use the software after the review - writing about products is just a job, and having the software afterwards is seldom a significant bonus. For instance, I did a feature article on cross-platform issues for Macworld that resulted in 18 boxes and 10 loose CD-ROMs. They were mostly necessary for the review, but you know what I'm left with now? Another four feet of software boxes on a shelf that I may never touch again (even if I cover the topic again, I'll probably need new versions).
An important (but often overlooked) flip-side to sending review copies is promptly following up with answers to the writers' questions or concerns about the product. If you don't respond to a reviewer's questions, the likelihood of getting coverage drops toward nil. Since good reviewers tend to look deeply into a program to anticipate readers' concerns, the questions can often help you by highlighting areas that need future development attention. It's best to be straightforward with your answers; don't view each question as an attack on the product since defensiveness may cause the reviewer to focus even more on the feature in question.
Many companies also provide detailed reviewer's guides. I'm of two minds about these - I suspect they're somewhat effective or the companies wouldn't bother, but at the same time, I find them slightly insulting. As a professional reviewer, I should be investigating the program on my own or in concert with other users, not by working through a reviewer's guide. If you're debating whether to invest significant work into creating one, I'd suggest that you restrict your efforts to a one or two page summary of the program's highlights. Reviewers can then use that to make sure they haven't missed anything, but they won't feel as though conclusions are being suggested.
Comparisons -- Readers like reviews, but they like comparisons even more. Where a review aims to tell you whether or not you should consider buying a program, a comparison eases the decision even further by laying out the similarities and differences between competing programs.
The problem with comparisons from the reviewer's standpoint is that they're hellishly difficult because they require that reviewers simultaneously acquire and become familiar with multiple programs, then keep all that information in their heads as they write. Comparisons also aren't as popular with the companies whose products don't come out on top - in a review there's still a chance the user will decide the product is worthwhile, whereas there's less to debate in a comparison. Worse, comparison articles tend to be too long for many publications, and despite their length, there's less room to examine any one program in depth.
One place you might direct efforts with regard to comparisons are Web sites that publish only specific comparisons - I noticed some of these recently while comparing the TiVo and ReplayTV digital television recorders. If you ever run across a site that maintains such a comparison, it's in your interest to work with them to make sure all the information about your program is correct, although it's dangerous to comment on details about your competition.
Feature Articles -- Whereas most everything we've discussed so far revolves around products, feature articles instead focus on topics. I've written a number of features for Macworld on topics like backup, email programs, and cross-platform issues, and in each case, I talked not only about numerous products but also about usage strategies, pitfalls, and other universal aspects of the topic.
My comments above about mentions apply well to the kind of coverage you can expect in a feature, since you're unlikely to be the focus of the article. Any appearance you make in a feature is a good thing, since it legitimizes you in the topic being covered.
It's worth repeating the importance of maintaining good relations with writers and editors. Many writers contribute to several different publications, which are all looking for fresh angles on existing hardware and software. If your product has added a new capability that crosses into a different category, it's more likely to be mentioned in a feature article. For example, there wasn't much to say about the Mac desktop PIM (personal information manager) market for several years until new Palm synchronization capabilities opened up an entirely new editorial category in which PIMs could be mentioned.
Ratings -- Some publications assign ratings to products covered in reviews, comparisons, and features - Macworld took over the mouse ratings after merging with MacUser, and MacAddict has the little "Freakin' Awesome" guy. Ratings work well for readers as a summary of the writer's opinion of your product, and being able to slap a good rating on your box or Web site only helps. However, ratings are tricky for a number of reasons.
Speaking as a reviewer, they're difficult to establish because there are so many variables to consider.
It can be difficult for a reviewer to reconcile the text of an article (particularly a short review, comparison, or feature) with the rating.
Publications often have different reviewers work on competing programs, which either requires negotiation to make sure the ratings match or results in inconsistent (and thus useless) ratings.
Product ratings have to be updated to account for changing competitive landscapes - date of review is extremely important when evaluating a rating.
You can't argue with a rating, and trying will only irritate everyone. Your best strategy if you receive a lousy rating is to release a revision that addresses the problems raised in the review and ask the publication to look at the new version. Even if you don't get a full review, they may redo the rating.
We had some discussion on TidBITS Talk recently about starting a ratings system for TidBITS. In the end we decided it didn't fit with our editorial approach, but the conversation was fascinating.
Tech Support/How-To -- I'm clumping tech support and how-to articles together because they both focus on a specific aspect of your program. Publications generally restrict this sort coverage to the important programs that they think many of their readers are likely to use; as a result it's great to find yourself receiving such coverage because it means you're sufficiently important to warrant such a look. Even if the article talks about a task your program doesn't do well, it probably also offers a workaround.
There's little you can do to influence this sort of coverage, with the possible exception of passing on clever tips with your software to writers. If they think a tip or trick is sufficiently useful, it might become an article.
Editorial Analysis & Opinion -- I've saved the fuzziest sort of coverage for last - these are the sort of articles where a writer spouts off on some topic or another. Much of my writing falls into this category, since I like to explore topics and attempt to explain them. From the point of view of a developer, this sort of coverage might be great or it might be awful - since these sorts of articles are couched largely in the experience and knowledge of the writer, they vary widely in quality and insight. Thanks to the Internet, everyone can express their opinion, and believe me, there are differing opinions of varying quality on every side of every issue.
I've hammered on the utility of relationships throughout this article, but good relationships are never as important as when affecting editorial coverage. Look at it this way: you want to be mentioned in appropriate analytical or opinion pieces, and you want those mentions to be positive. If you have no connection with the person writing such a piece, the chance of a mention decreases, and the chance that any such mentions will be negative increases. In contrast, if you have a relationship with a writer, he or she is more likely to think of you when looking for quotes or giving examples, for instance, and if you've made sure that person's knowledge of you, your product, and your company is accurate, you're less likely to suffer from a misinformed example. From the writer's point of view, having accurate information helps avoid unnecessary comments and corrections.
Having a relationship with a journalist also gives you some additional leeway in pointing that person at topics you think need coverage. It's usually a bad idea to say, "Hey, you should write about such-and-such," since that may raise journalistic hackles. But there's nothing wrong with forwarding a piece of email about the topic along with a short note explaining why you think it's interesting. Who knows - it might turn into an article with you at the center.
That's it for this week's coverage of these rather broad classes of press coverage. I realize I've set myself up for the big question of just how you should go about establishing relationships with journalists, and that's where I'll turn my attention next.
Article 4 of 4 in series
If you've ever wondered about the best ways for software to get coverage in the Mac press, check out the video of Adam's "Hacking the Press" talk from the C4 developer conference.Show full article
Back in the late 1990s, I came up with an idea for a presentation that I, as a non-programmer, could give at the MacHack programmers conference. I called it "Hacking the Press," and it was designed to explain to software developers running their own businesses how to work with the press. It was always big fun to give, since I made sure to ask for an open-ended block of time, and my session usually went at least 3 hours, or until people stopped asking questions. I later turned some of the contents of the talk into a series of articles, and I've heard from many developers over the years that my talks and articles were helpful to them as they launched products. But with the demise of MacHack (and its renamed form, ADHOC), it had been a while since I'd given the talk.
That's when I got email from Wolf Rentzsch, with whom I'd shared a room one year at MacHack and who was the mastermind behind the C4 conference for independent developers that served much the same need as MacHack (see "C4 Conference Rethinks MacHack," 2007-08-20). Wolf wanted me to reprise my Hacking the Press talk at C4, and I jumped at the chance. I had a great time at C4, but I didn't attempt to describe the sessions in great detail, given that many of them were over my head anyway. Since then, however, Wolf has gradually been releasing the videos of the talks on Viddler, and the video of my talk is now up for viewing along with the rest. Be sure to watch Wil Shipley's talk on marketing as well, if only for his opening joke about the iPhone (I disagree with some of Wil's advice, but it's a hilarious talk).