Archive for January, 2010

h1

Microsoft joins the connection party

January 21, 2010

The sharing and connection party started a long time ago with services like WebEx, GoToMeeting, and more recently Adobe Connect, DimDim and the like. I’m not sure when they released it, but it seems as though Microsoft have now joined the party with SharedView.

With SharedView, you can connect simultaneously with up to 15 people, and share your documents and screens. No voice facility exists within the (free) SharedView application but you can use other services such as Skype for voice.

You do need to download the free application to use it. You’ll also need a Windows Live ID (or your Microsoft Passport credentials) to start a session but not to join one started by someone else, as well as an internet connection.

[Links last checked January 2010]

h1

What happens to a blog post?

January 20, 2010

Have you ever wondered what happens to a blog post after you write and publish it? If so, check out this ‘infographic’ from Wired Magazine (click the image to go to the web page where you can see all the detail):

[Links last checked December 2009; thanks to Anne Gentle for alerting me to this infographic]

h1

Games, collaboration and education

January 19, 2010

Great 11 minute video interview with James Paul Gee, an Arizona State University professor, on how people learn, the role of video games in education, the use of manuals as technical references, and how  collaboration can change education… amongst other things.

You can view the video here: http://www.edutopia.org/digital-generation-james-gee-video

[Link last checked December 2009; thanks to @lindaurban for tweeting about this resource]

h1

Acrobat: Convert scanned image of text to text

January 18, 2010

In the category of “I didn’t know I could do that!” comes a neat Adobe Acrobat trick I discovered a few days ago.

I had received a PDF document from my work colleague — she wanted me to convert it into an editable Word document as no-one could locate the original. However, what she sent me wasn’t a ‘real’ PDF — it was a ‘scan to PDF’ of a paper document, and thus an image. So when I tried to copy the text to paste it into a Word document, the selection tool treated my selection as an image. All I could see ahead of me was many hours retyping this 40+ page document…

But then I noticed an option on the right-click menu of the selection. It was Recognize text using OCR. Hmmm… What might that be? To be safe, I made a copy of the PDF, then ran the Recognize text option on the copy (you can also convert the entire document from this menu path: Document > OCR Text Recognition > Recognize Text Using OCR).

Because the original document was almost entirely text, with a few tables thrown in and one figure, the conversion was painless and quick. The best thing was that I then had text I could copy and paste into the new Word document I was creating.

According to the Acrobat Help:

You can use Acrobat to recognize text in previously scanned documents that have already been converted to PDF. Optical character recognition (OCR) software enables you to search, correct, and copy the text in a scanned PDF. To apply OCR to a PDF, the original scanner resolution must have been set at 72 dpi or higher.

I wasn’t aware this tool even existed, so I was pretty pleased to have found it, and even more impressed at how easy it was to use on the scanned document I had.

BTW, I’m using Acrobat Professional 9. I’m not sure how long this feature has been in Acrobat, or if it’s even in the Standard version.

h1

Top job

January 17, 2010

It’s official! Technical writing is 13th on Wall Street Journals’ list of top jobs for 2009, based on these criteria — environment, income, employment outlook, physical demands and stress.

You can see the full list and get a link to the methodology used here: http://online.wsj.com/public/resources/documents/st_BESTJOBS2010_20100105.html

[Links last checked January 2010\

h1

Customer Support loop

January 16, 2010

Matthew Inman, over at The Oatmeal comics site, has done a terrific cartoon on the eternal and frustrating loop we get into when we call customer support (an oxymoron, if ever there was one!).

Here’s a taste:

(Click the image to go to the full cartoon, or go to this link: http://theoatmeal.com/comics/customer_service.)

[Links last checked January 2010]

h1

Basics of writing a press release

January 15, 2010

Here are the basics of a press release:

  • headline
  • dateline
  • lead
  • body
  • boilerplate (basic company info)
  • close
  • contact info

You can read more about each, with examples, and a press release’s structure at: http://www.freelancewritinggigs.com/2008/10/press-release-writing-intro/

[Links last checked December 2009]

h1

Documentation: Backup for UI deficiencies?

January 14, 2010

Sue Woolley, in her article ‘Software Documentation — How much or how little?’ published in the October 2009 issue of Southern Communicator: The Australian and New Zealand Journal of Technical Communication*, stated:

Very few people these days will sit down and read a manual for a new software product. The expectation is that we can install software and start to use it straight away. The younger generation in particular is so comfortable with new technology that they dive in and expect it all to work. They explore fearlessly, and are able to master complex hardware and software concepts effortlessly.

If a user has a problem when they are using the software then they will generally either ask a colleague for help or resort to trying to find the answer in the documentation. Typically, they will “dip into” either a manual or the online help and at this point, if they can’t easily find the exact piece of information they need, they will be frustrated with the software.

Documentation is, therefore, rapidly becoming a backup for deficiencies in the user interface and user training rather than a complete solution in itself.

Do you agree with Sue? Has this always been the case or is it a new phenomena? Are humans ‘programmed’ to learn by trial and error and not ‘by the book’?

Moving out of the software arena, I know that when I’m learning a new recipe, I’ll often just start throwing things together to match what I tasted in a restaurant or at a friend’s house.

Only if it’s a complete disaster (and I want to try it again), or I figure that I might need some help do I check a recipe book or — more likely — an online recipe. Even then, I’ll often only dip into it to find the bit I need and not read the rest.

My 'Mexican' chicken -- a bit of this, a bit of that...

Of course, in the realm of cooking, I’m coming from many decades of experience, so I expect to be able to figure out most of a recipe without help. The exception is baking (cakes, muffins etc.), which require precise measurements and methods — I will check a recipe often when making these.

Does my experience with cooking and recipe books (the ‘help’ for cooks) correlate to the experience others have with software? I know that I rarely consult the help these days when installing or using software for the first time. I’ll follow the installation wizard and choose the default settings, then I’ll try to do some basic tasks once it’s installed. Assuming I have success with those (and early success to me is a CRITICAL step in convincing me that the software is ‘fit for purpose’), I may step into more advanced tasks. I may already have an expectation (perhaps based on the marketing spin on the website) that the software can do a particular task — if I can’t figure it out from the menus, the icons, the interface etc., then I’ll go hunting in the help for it — but that’s only because I expected it to do something, not because I was browsing the help just to see what’s there.

* Southern Communicator is a joint publication of the Australian Society for Technical Communication (Victoria), the Australian Society for Technical Communication (NSW), and the Technical Communicators Association of New Zealand.

[Links last checked January 2010]

h1

Avoiding presentation disasters

January 13, 2010

No, not disasters in your speaking, but in the PowerPoint presentation you’ve lovingly prepared and agonized over for many hours.

Amit Agarwal has used his experience to list the things you should do prior to your presentation to avoid some technological disasters:

  • Put your PowerPoint files on a USB drive
  • Use Arial or Times New Roman font
  • Always carry the Microsoft PowerPoint Viewer
  • Print a PDF of your PowerPoint presentation
  • Take care of margins
  • Some presentation rooms can be very big
  • Turn off screensavers, IM, email notifications
  • Power management

Amit’s full article, with details for each of these tips, is here: http://www.labnol.org/software/tutorials/effective-powerpoint-presentation-tips/1905/

[Links last checked December 2009]

h1

Clients to avoid

January 12, 2010

Whether you’re doing web design, technical writing, graphic design or any other similarly contracted service, you may occasionally encounter the ‘client from hell’. How do you identify them so you can say ‘No’ before you even think about working with them, or so you can take steps to avoid their issues?

In Getting to No (written for A List Apart), Greg Hoy lists five red flags to watch for (and perhaps to run from!):

  • The never-ending contract revisionist
  • The giant project team
  • Mr or Mrs Vague
  • The prospect with ants in their pants
  • The vanishing boss.

In the article, he describes the characteristics of each and how to deal with them. You can read all the details here: http://www.alistapart.com/articles/getting-to-no/.

(NOTE: Fortunately, in 10 years of running my own technical writing business I’ve not come across any of these client types. I have, however, had two reluctant payers,  luckily both for small sums — I won’t work for them again.)

Related articles:

[Links last checked December 2009]