I'd Rather Be Writing » WritersUA

What Tools Do Technical Writers Use

Tom Johnson — Mon, 19 Dec 2011 16:33:14 +0000

Students and others trying to break into technical writing are always wondering what tools they should use. The latest tools survey from WritersUA seems helpful in answering this question.

The survey concludes that some of the most popular tools for technical writers are Adobe Acrobat, Camtasia Studio, Adobe Captivate, Dreamweaver, Madcap Flare, Framemaker, Photoshop, Robohelp, Snagit, and Visio.

Of these tools, Flare scores highest as a tool that participants can’t live without. They ranked it as a 5, meaning “very important.” Presumably this is because Flare does an excellent job in single sourcing to other formats, such as print and mobile. It’s an all-in-one solution, so it by definition it’s important or you’re not using the tool correctly.

The WritersUA survey is a little frustrating because these tools aren’t grouped by category. Some are screen capture tools, others are PDF conversion tools, others are image editing tools, others are video recording tools. I use Photoshop and Snagit, but ranking these along with Robohelp and Flare is to compare apples to oranges. Similarly, Camtasia Studio and Captivate are in another category. It would be helpful to sort the tools by category. (Still, it’s nice to see someone doing a tools survey in the first place.)

Of the help authoring tools, it’s interesting to see Flare rank so high. Flare is an excellent help authoring tool, and with a knowledge of CSS you can completely customize the webhelp and print output to look professional. However, its main failure is the lack of collaborative authoring. If you have 15 writers all contributing to the same help project, you have to import the content from other authors. They can use supporting tools such as Madcap Contribute, or Word templates. You can also try hosting Flare on SharePoint and enabling collaboration this way.

But I’m guessing that Flare is popular because most technical writers are solo sailors on their own ship, without the need for collaboration from other writers. In my career, the number of collaborative projects has been very small. I am usually the only writer for the project, which means collaborative authoring is unimportant. I don’t need a central repository installed on a server that numerous authors can access and pull content from. Content is also not reused between projects, since each documentation project covers a different product.

Sarah O’Keefe also has some comments on the WritersUA tools survey. See her post, The passion quotient. She notes that the survey highlights “the tool for which the importance is ranked the highest.” Despite this criteria in evaluation, I am not sure how I would design the tools survey differently.

Blog Sponsors

Book Review: Developing User Assistance for Mobile Apps, by Joe Welinske

Tom Johnson — Tue, 02 Aug 2011 17:18:36 +0000

Joe Welinske’s latest book, Developing User Assistance for Mobile Apps (published June 2011), fills a gap in tech comm literature that is sorely needed. Joe explores strategies and techniques for providing user assistance for mobile devices, and goes in depth with iOS, Android, Windows, and tablets.

Early in the book, he explains:

Hopefully the organizations that employ us will start buying smartphone devices for us to work with just as they provide us with desktop workstations (13).

It would be odd to be an IT employee in a company without being provisioned a computer. Now that mobile is becoming more common, shouldn’t we also be provisioned a mobile device too, if not several?

One of my colleagues just recently purchased his first smartphone. He decided to buy it himself rather than asking our organization to pay for it. Usually only employees with special needs to be reached outside of work times receive smartphones.

But the world has changed. We know that mobile is quickly becoming the most common way for people across the world to access the Internet. It’s much more common to consider and plan mobile development at the same time that you’re building a browser-based application. Mobile is no longer an afterthought. It should be part of our regular workflow, strategy, and deliverables — not just for developers, but for technical writers too.

Given the need to add user assistance deliverables to mobile, where do you start? Almost every mobile device has an emulator or simulator that allows you to explore the functionality from another computer. You also need the right software and setup. For most of us, this is a new world with unfamiliar terrain. How do you connect, how do you test, what software do you need, how do you publish, and how does it all vary by device? Joe covers all of this in depth for the major mobile platforms.

Additionally, he explores techniques for integrating help into mobile apps. Brevity and user testing are guiding principles. But as for a standard, “the look and feel of the UA is as varied as the apps themselves” (19). You can use everything from Dashcode (a mobile help authoring tool), to text built-in to the app, a standalone webpage, or many other solutions.

As for mobile help formats, I was also pleased to read the following advice for mobile documentation:

Many support situations can benefit from a richer level of presentation to the user. Videos and demos can provide a more engaging experience. The audio/visual capabilities of video make it a great choice for showing complex tasks and helping the viewer feel at ease. Demonstrations are useful for presenting an automated tutorial about tasks and procedures (28).

Yes, even on a mobile device, videos and other rich presentations have a place. When you consider the advanced interactions with mobile devices — the gestures, the pinches and squeezes, the flicks and two-finger scroll, the back swipe, etc., you need to see some of these gestures in action to understand.

Undoubtedly, the diversity of mobile devices makes documentation tricky. Joe says the “wildly different UIs that we find in our apps mean that users can’t necessarily carry conventions from one app to another. Unique icons, buttons, and menu structures can create angst for users” (41).

The operating systems and hardware buttons vary from the iPhone, Android, Windows, and tablets. Android itself has many different devices, with different buttons across the bottom. Not only do the operating systems vary, so do the built-in browsers. You need to test your output in all of these devices.

Add to this mix some difficulty in describing finger/touch movements (are these in your style guide?) and how those gesture words might translate, and you have a real challenge. What may have seemed simple suddenly becomes a full-blown documentation challenge.

Joe’s book is an excellent guide to get started in the world of mobile user assistance. The book is brief (142 pages) but thorough enough to get you comfortable in this space.

To learn more or buy the book, see Developing User Assistance for Mobile Apps.

Blog Sponsors

Lots of Conferences Taking Place

Tom Johnson — Fri, 04 Mar 2011 15:26:15 +0000

Ben Minson and me at the last STC Summit

Have you noticed how many good conferences are scheduled lately? I remember a couple of years ago, when Doc Train conferences ended, and some of us thought the STC Summit was approaching its last time — I thought conferences would become extinct. Today there are almost too many conferences. Here are some of the interesting looking conferences taking place within the next couple of months:

SXSW Interactive – March 11-15, Austin, Tex.
WritersUA — March 13-16, Long Beach, Calif.
IA Summit – March 30 – April 3, Denver, Colo.
Confab (Content Strategy) – May 9-11, Minneapolis, Minn.
STC Summit — May 15-18, Sacramento, Calif.
Congility — May 24-26, Gatwick, UK
Web Content 2011 — June 6-7, Chicago, Ill.

Last month the Intelligent Content conference took place. It seems that the number of conferences are growing. The only conference I’m planning to attend during the next three months, however, is the STC Summit. But that’s only due to time and budget. The Content Strategy conference actually looks really appealing.

———

Photo courtesy of STC on Flickr

Blog Sponsors

Review of Alan Porter’s Wiki: Grow Your Own for Fun and Profit

Tom Johnson — Thu, 25 Nov 2010 15:25:40 +0000

Wiki: Grow your Own for Fun and Profit, by Alan Porter

Alan Porter’s Wiki: Grow Your Own for Fun and Profit, published by XML Press in October 2010, provides an excellent introduction to wikis. This is a short, easy-to-read book spanning about 150 pages. Alan has a keen sense of organization and liveliness in his writing. He carries the gardening metaphor throughout the book, ending with five solid case studies and an extended response to common criticisms against wikis.

Sometimes discussions about wikis make it seem as if they’re a new technology. But Alan explains that Ward Cunningham developed the first wiki in 1995 — fifteen years ago! Despite the relative ease with which Alan responds to wiki concerns (about inaccuracies, lack of participation, disorganization, and so on), wikis still haven’t gained traction as the predominant authoring platform.

One has to wonder, given the many advantages of wikis, why they haven’t they taken off as the platform for web and help content? Especially in an age of collaborative authoring, distributed ownership, dynamic editing, and agile development, you’d think wikis would be the most common platform for help authoring in tech comm departments.

And yet, in the 2010 WritersUA Tools Survey, wikis aren’t even included as a tool (see the survey’s list of tools). Almost every other help authoring, graphics, and video, and layout tool is mentioned, but wikis are absent. Either WritersUA accidentally omitted them (this year and every previous year), or they don’t take wikis seriously, or wikis aren’t considered help authoring tools.

My point is that wikis still have a long way to go toward mainstream adoption, despite their decade-and-a-half presence on the web. Alan’s book is a welcome addition to the promotion of wikis and wiki culture.

Although Alan’s audience seems more focused on new wiki users, he does dive into an issue that I struggle with: wiki round tripping. With round tripping, you publish from a source format to a wiki format, allow the wiki to be updated, and then write your updated wiki content back to your source format. For example, with WebWorks, Alan says the original documentation source is in Framemaker, which they publish to a wiki format using ePublisher. If they did round-tripping, after the wiki was updated, they would write the updated wiki content back to Framemaker.

However, WebWorks doesn’t do round tripping. After users make edits to the WebWorks documentation, the WebWorks team manually updates the source Framemaker files with the changed content.

Even if they wanted to do round-tripping, it isn’t easy to achieve technically. And I assume the technical solution isn’t available because apparently there isn’t a business case for it. Alan says,

When I hear people using the phrase ’round-tripping’ they tend to be talking in terms of automating the process. When I have asked people what the business case is for implementing automated round-tripping, very few have an answer beyond “well it would be cool.

Alan notes that with a multilingual wiki, there may be a valid business case. But for most corporate content, round-tripping may pose liability or legal issues, and requires human intervention to evaluate whether the updated wiki content should change the source file. If round tripping is necessary, Alan recommends making the wiki the original source.

This section was most relevant to me for several reasons. First, round-tripping is very much a tech comm topic rather than a general wiki topic. Second, Alan gets into a difficult issue and explores it in depth. And third, there is no easy answer.

In the authoring process for some of my projects, we do keep the wiki as the original source, rather than maintaining a separate source of content. We all collaborate through the wiki, building the documentation as we go. In my opinion, working in Framemaker and then publishing to the wiki (the WebWorks model) undercuts the collaborative nature and power of wikis. If you’re the only one creating the documentation, it might make sense. But in a collaborative authoring model, with a team of internal and external authors, why create documentation in Framemaker first and then publish it to the wiki? How exactly would you share the content? Also, if community momentum picks up, how can you feasibly input the community’s constant updates back into the source files?

However, if you do use a wiki as the original source, you run into a problem: how do you selectively package up the wiki content and output its content into printable formats? How do you personalize the topics based on specific roles?

These latter questions might be related more to the wiki tool rather than wikis in general. Some wikis allow you to bundle the content together as a PDF output, while other platforms require extensions and hacks to achieve this. Access control also varies widely among wikis. Confluence offers different access control levels, while Mediawiki has an everything-open or everything-closed policy.

Alan’s book makes me reflect more about wikis. Will they ever take off? What holds them back? Is it the lack of a universal wiki syntax? Is it because wikis all too often devolve into chaos? Is it because the fundamental idea of volunteer group writing is flawed? I’m not sure. I prefer wikis more than traditional help authoring tools, but wikis still pose many challenges. I’m glad Alan took the time to write a book on wikis. It will help push tech comm authoring models more toward wikis.

For a sample chapter and links to buy Wiki: Grow Your Own for Fun and Profit, see the XML Press site book page. To read Alan Porter’s blog, The Content Pool, go to http://4jsgroup.blogspot.com.

Blog Sponsors

WritersUA – The WritersUA Tools Survey – Tools

Tom Johnson — Fri, 27 Feb 2009 17:32:30 +0000

WritersUA – The WritersUA Tools Survey – Tools.

Blog Sponsors

Top Technical Communication News for January 2009

Tom Johnson — Mon, 12 Jan 2009 05:29:44 +0000

Download MP3 (to download, right-click and select Save Target As)
Length: 12 min.

In this podcast, I cover the top 10 technical communication news items during the past month. This is a different type of podcast than I’ve normally done. The show notes below are excerpts of what I cover, but without any commentary.

1. Techcomm toolbox

One of the most common questions heard on many forums is “What tool do you use for [purpose]?” Answers vary, of course, because everyone has their own favorites and some folks will even answer that the right tool is “the one that best meets your needs”.

Sometimes, many people will answer that you need to look at the different tools, download trial versions, and test. But where is the list of tools to choose from?

It’s here at TechComm Toolbox, your online resource for all applications, services, consultantsm, and trainers related to technical communication.

2. Emergence of STC groups on twitter

More and more STC groups are joining and participating on Twitter: stcaccess, stcchicago, stchouston, stcboston, stcintermtn. Also, Writer River now has a Twitter feed: writerriver.

3. WritersUA Salary survey and tools survey going on

The WritersUA Tools Survey is underway. The survey is designed to provide our community with a guide to the relative popularity and satisfaction of a number of tools. … The Salary Survey provides a look at the various factors that contribute to higher salaries in the software user assistance community.

4. Jing Pro Released

Jing Pro brings you simply the best-in-class experience for quick visual online conversation. Imagine everything you already know and love about Jing, then add:

* HD quality video for the web
* Direct output to YouTube
* No more branding on the end of your videos.

5. I’m a tech writer photo gallery

Technical Writers (aka Technical Authors, Content Wranglers and Documentation Managers) have an unfair image. This project aims to challenge this image, by showing technical writers in a different light. The photos below are of technical communications professionals, doing a variety of activities.If you are involved in technical writing and you’d like to be included, contact us and send us a photo, together with your name and location.

6. STC to record and make available the entire Summit

Beginning this year at the Summit in Atlanta, STC will capture the content (audio and visuals) of almost every session and make it available to attendees at no additional cost. This will increase the value of your experience tenfold. After the conference, STC will sync the audio with the presentations and make them available (by passcode) for attendees on the STC website. This will allow [you] to “attend” all those sessions [you] missed. It will also allow [you] to revisit the ones that [you] did attend and to refresh [your] memory of the fine points made by the speakers. (From Mark Clifford’s January News and Notes)

7. WordPress 2.7 released.

This may be the last time you ever have to manually upgrade WordPress again. We heard how tired you were of doing upgrades for yourself and your friends, so now WordPress includes a built-in upgrade that will automatically notify you of new releases, and when you’re ready it will download them, install them, and upgrade your blog with a single click. [Also, BuddyPress is in beta: "BuddyPress is a set of WordPress MU specific plugins, each plugin adding a distinct new feature. BuddyPress contains all the features you’d expect from WordPress but aims to let members socially interact."]

8. Alltop publishes Tech Writing category

Alltop is an “online magazine rack” of popular topics. We update the stories every hour. Pick a topic by searching, news category, or name, and we’ll deliver it to you 24 x 7. All the topics, all the time.

9. Camtasia 6 released

When recording audio and video at the same time, it’s hard to be perfect. So we’ve made it easier to fix mistakes. Simply decouple the audio and video tracks to edit them independently. And move audio clips between (and along) tracks to line everything up perfectly. Bottom line: fewer retakes and less time spent on editing.

10. Doc to help releases 2009 version, with ribbon-based interface

What’s new: built-in xml based editor, dynamic help control for embedding help in .net applications. xhtml converter, drag and drop linking, and abbility to import project settings.

Blog Sponsors

WritersUA Salary Survey, Tools Survey, and Upcoming Conference

Tom Johnson — Sun, 11 Jan 2009 06:54:34 +0000

WritersUA has their annual salary and tools surveys going on. Their survey results are among the most influential of surveys, so be sure to participate. Click the following links to take the surveys:

Additionally, WritersUA has a conference coming up at the end of March. Although I’ve never been, everyone I’ve met who has attended has praised the conference. As if this all weren’t enough, they also have a WritersUA Linkedin group.

WritersUA Conference

Blog Sponsors

The WritersUA Salary Survey

Tom Johnson — Sat, 10 Jan 2009 04:39:50 +0000

The WritersUA Salary Survey

Blog Sponsors

Technical Writing — Worth it? Interesting? Creative? Well-Paid? Hours? Answering a Few Questions from Saudi Arabia

Tom Johnson — Thu, 10 Apr 2008 06:28:29 +0000

Kalyani from Saudi Arabia writes,

My name is Kalyani. I am 37 yrs old and live in Saudi Arabia. I have finished my Diploma in Electronics (4 year course). I was working at Hewlett Packard in India before moving to Saudi.

In this country, women have very few opportunities to work i.e., only in the schools or hospitals. I chose to work in the school as an English and Computer Science teacher. Now I have moved into the administration.

After 7 years in this country, I want to move back to India. While looking at the job market, I thought of re-training and getting into “Technical writing”. I have a good command over English and a flair for writing. My computer skills are very good.

I have 4 months before I go back to India. I wanted to start my online training from ‘The Writers’ Block’, a training institute in Bangalore, India.

I have a few questions for you:

Is “Technical writing” an interesting career? (I like to be creative and take up challenges)

Can you maintain your work-life balance? (I have 3 boys aged 9, 5 and 3)

Does it pay well?

In the long term, is it worth being a ‘technical writer’?

Do you think online training is a right choice? Or should I take the regular course??

I hope you will help me out with my queries whenever you find the time.

[Me: I asked Kalyani to tell me the state of outsourcing in India.]

Right now, outsourcing is at a peak in India, especially in Bangalore from where I come. There are many BPOs and there are few technical writers. Unlike software technicians who are in plenty, technical writers are still few in number. I’ll go for this when the demand is still good.
Most of the European and American companies have outsourced their services in India. So I think this is the time to go for it.

I’ll look forward to reading your blog post.

Thanks again,

Kalyani

Thanks for writing, Kalyani. It’s always interesting to hear from readers in Saudi Arabia. You have an excellent background for entering the field of technical writing. With a degree in electronics, experience as an English and Computer Science teacher, and work experience at HP, you are probably well suited for a job as a technical writer. Let me try to answer your questions.

1. Is “Technical writing” an interesting career? (I like to be creative and take up challenges)

Yes, it is an interesting career. However, you can read some posts and discussions on this site that talk about whether technical writing is boring. Also read this post that explores whether I’d become a technical writer again if starting over from scratch. I recently asked a 2 question survey to see if my readers felt the same way.

You can see the results of 16 responses so far. Basically, only 31% of people would definitely become technical writers if starting over. 37% said maybe, and 31% said no.

The funny thing is, most of those who said no would instead move into instructional design, web design, or usability, which are all somewhat close to technical writing anyway. (By the way, the survey is still open.)
Although reading those posts may not put technical writing in a glamorous spotlight, it truly is a solid professional field with a lot of room to grow and explore new technologies. I do enjoy my job as a technical writer.

Technical writers can focus on a variety of things (content management, information architecture, e-learning, usability, single sourcing, XML, DITA, web design, multimedia), but the majority of technical writers spend their days creating help material such as online help, printed manuals, quick reference guides, and writing and formatting other content.

Of course it’s not riveting, but as jobs go, it’s not bad. I would say that technical writing is a satisfying career, but not a fulfilling one. (Vague on purpose there.)

2. Can you maintain your work-life balance? (I have 3 boys aged 9, 5 and 3)

It depends on your company. Most technical writers I know maintain a very comfortable work-life balance. It’s nothing like investment banking or law or medicine where you’re expected to put in 60+ hour weeks as the norm.

I have an 8 to 5 day, and I come home to a home-cooked meal and then wrestle with my kids for a while before putting them to bed and wandering online to post a few entries on my blog. Okay, so it’s not that idyllic, but the work-life balance is one of the best things about being a technical writer.

3. Does it pay well?

Yes, technical writing is probably the most lucrative career in writing apart from being a best-selling novelist or becoming a big-time publisher in New York City. Of the careers one can pursue as a writer — copywriter, copy editor, proofreader, essayist, journalist, teacher, professor — technical writers earn a lot more, at least 1/3 more in salary, I’d say.

For surveys, see the WritersUA 2008 salary survey, which found the average salary of a technical writer in the U.S. to be about 76k a year. Everyone I talk to thinks this number is a little high. In 2006, Money Magazine named technical writing the 13th best job in America and said the average salary was 57K a year.

My own opinion is that the real average salary for technical writers is somewhere between 57 and 76. It depends on where you live, how many years of experience you have, what company you work for, and how good you are at negotiating a salary.

4. In the long term, is it worth being a ‘technical writer’?

I assume this question has something to do with intangible rewards, particularly compared to careers in education. As a teacher, one often feels an internal reward in helping students learn and grow and see the world in a new light. (Or so they say.)

Well, the problem with feeling great worth as a technical writer is that we’re so disconnected with our users. We don’t watch them use our help. Teachers in the classroom can directly observe the impact of their teaching. But I can’t see the indescribable joy that comes to those who read my instructions in moments of frustration and suddenly “get it.” I can’t observe users who, after struggling for hours, finally turn to the help and within minutes fall down on their knees and kiss the software manual I wrote, tears falling down their cheeks in gratitude.

I used to be a copywriter writing press releases, web copy, and all kinds of other campaigns to get people to buy nutritional supplements. While I was allowed be more creative as a copywriter, it wasn’t worth it because I didn’t believe in the products. In contrast, as a technical writer, I feel that helping people understand complicated technology so they can do their jobs better, become more efficient, and feel more comfortable with software applications is worthwhile.

But “worth it” really depends on you. What makes life worth it to you? (Here’s an article that explores whether technical writing is a calling or job.) The sense of worth varies for every person according to their perceived calling and life purpose. Someone gifted in medicine would not feel that writing help content and making video tutorials is “worth it.” A job worth it for that person is in the exam room or ER. But for writers, technical writing is an activity much more worthwhile.

5. Do you think online training is a right choice? Or should I take the regular course??

I don’t know. I learned much of what I know about technical writing from my first job. I learned most of the tools on my own, and picked up style and other techniques by looking at manuals, trying different techniques, and in general reading from various sources. A course could be highly beneficial.
Read this comment by Mike, which he left on a post I wrote called “What’s the Best Thing You’ve Done to Grow Your Career?”:

Without a doubt, the best “move” I made in regard to my technical writing career was completing a graduate degree in communication. The sheer number of programs (broad-based professional programs to specialized technical programs) make a graduate degree possible for every practicing technical writer. And the networking opportunities within a graduate program are extremely beneficial.

It’s never a bad idea to take a course in anything, really. (However, I’m a little confused by the name of the Institute you mentioned, the “Writer’s Block.” Let’s hope they teach you how to avoid that.)

Final Thoughts

As a final comment on offshoring and outsourcing, I was talking to a technical writer at Novell last week. Novell apparently has writers and developers in several different countries, including India. This writer works regularly with about 14 writers from Bangalore. She said that within 5 years, technical writing would disappear in the U.S. and be completely enveloped by outsourced companies in India and elsewhere.

I’m not sure I believe that, because technical writers fit with engineers like peanut butter and jelly — the two go together really well, and colocation is essential. But the instant you move your engineers to another country, the technical writers are sure to follow. Because Novell has engineers in other countries, they placed their technical writers there too.

By the way, I did interview an Indian technical writer for a podcast last year. You can listen to it here.

Also, there’s a great listserv to join called Technical Writers of India. They post jobs and have an active discussion regularly. You might also connect with Rahul Prabhakar. He’s up to date with the latest trends with technical writing in India.

Lots of 2008 SXSW Podcasts Now Available

Tom Johnson — Tue, 11 Mar 2008 05:30:00 +0000

The 2008 South by Southwest Interactive (SXSW) festival, currently underway in Austin, Texas, until March 16, is one of the most popular, high-energy tech conferences of the year.

This Interactive conference “celebrates the creativity and passion behind the coolest new media technologies.” Basically, everyone who is doing anything cool on the Internet ends up speaking there. 37 Signals, Facebook, Wired — they’re all there.

Many of the presentations are interactive panel discussions. Everyone twitters and blogs and texts during the presentations, etc. It’s like a gathering of the Internet geeks and hackers and designers and content creators.

Important: Because almost every session is recorded and distributed practically the same day, you can start attending sessions yourselves. Here’s a list of all the feeds available.

The interesting thing is, although the sessions are recorded and distributed freely, the attendance at the conference seems as high as ever. I haven’t seen statistics, so I’m making an assumption, but I’m guessing that attendance at the conference actually increases every year because people hear how engaging it is.

Listening to the podcasts makes me wish I could attend. The high energy, the new technologies, the experimental successes, the young entreprenuers — it looks like a big tech gathering with continual parties and meetups between and after sessions.

I wish that the STC Summit, WritersUA, Atlanta Currents, Doc Train, and the dozen other technical writing conferences that take place each year would do the same as SXSW — record the presenters and distribute them in near real-time. If I ever became STC president, I would do this. People are often afraid of the unknown. That’s what Jason Fried of the 37 Signals said in his presentation (listen to MP3). At 37 Signals, they recently switched to 4 day work-weeks (not 10 hour days), and they help fund their employees’ personal hobbies.

I’m about 12 minutes into the Mark Zuckerburg (Facebook founder) keynote (mp3). This is a must-listen-to interview, not only to hear Zuckerburg talk about the grander mission of Facebook, but to evaluate for yourself whether you think the interviewer tanked the interview.

Before you listen to the interview, read this post by Jeff Jarvis.

Jarvis writes,

She pulled some basic mistakes in interviewing. She interrupted him. The first minute of the conversation, he wanted to talk about people using Facebook to organize against Colombian guerrillas — a fascinating story — and she didn’t let him finish, trying to show that she already knew this. The real mistake was that she wasn’t listening.

… When it became obvious that the audience was hostile to her — cheering Zuckergerg when he told her to ask a question — she acted hurt, as if this hour was about her. Worse, she told us how tough her job was. It wasn’t tough. It was a privilege and she was blowing it. And at the end, when she said that people should send her an email telling her what went wrong, she was so 1994; she didn’t understand that the people in the crowd were already coalescing in Twitter and blogs into an instant consensus. Oh, if only there’d been a back-channel chat projected on the screen beside her. Then, she could have seen.

As I’m listening to the interview, in places I can see exactly what Jarvis is saying. The interviewer isn’t so bad near the beginning, in my opinion, but it’s annoying when she interrupts Zuckerburg and redirects the attention to herself.

Personally, I still haven’t caught the Facebook frenzy. Scott Abel has started an extensive community in Ning for the technical community crowd. You might want to check that out after listening to Zuckerburg.

Update: I finished listening to the Zuckerburg podcast. At about the 49 minute mark, the interview takes a really interesting turn. Definitely a spiral downward for the interviewer, as the audience rallies in a “witch hunt” — as Michael Arrington calls it — against her. It wouldn’t have been so bad if Sarah Lacy, the interviewer, had just shrugged her shoulders at the 26 second applause for her to shut up — and then turned the questions over to the audience.

But in such a high pressure situation, she got a bit angry and confused and defensive, which made things worse for her. I wasn’t there, so my perspective is distorted, but I think the audience was immature to revolt. And Zuckerberg’s commentary wasn’t that interesting in itself — he kept saying Facebook’s mission is to help people “communicate and connect,” and also to “increase empathy” yada yada yada.