Skip to content

BOOK REVIEW: Excellent Project Guide for Commercial Designers and Technical Illustrators who Draw Graphs


 Powered by Max Banner Ads 

© Ugur Akinci

If you’re a beginner or amateur illustrator or designer Adobe Illustrator CS2 @work: Projects You Can Use on the Job is not for you since it does not address the nuts-and-bolts aspects of Adobe Illustrator. This how-to volume assumes that you already know the basics of using the Illustrator.

What the author excels in doing is to present commercial-grade projects with all the steps patiently explained. If you’re just hired by an advertisement agency to work on product packaging design, for example, then beg, steal, or buy this volume right away. It’ll save your career.

The design projects covered include designing corporate identity materials, designing packaging, creating 3D product packaging mockups, tri-fold brochures, etc.

One chapter of the volume that’s probably obsolete is the one devoted to “Designing a Website and Flash Animation” given the declining fortunes of Flash and the rising start of HTML5 as these lines are written in January 2012.

One chapter I found very useful as a technical writer is the great chapter on “Creating Graphs for a Report.” Illustrator has this great functionality to create graphs and charts but it’s rarely explained how to do so. The author explains that process in a chapter that spans over 30 pages.

Recommended resource for all professional designers, technical illustrators and writers.

Illustrator CS2 at WORK

Share

Posted in Books, Graphic Design, Illustrator, Technical Illustration.

Tagged with , , , .

No comments

By admin – January 27, 2012

“Should I use an Index for my help file or technical document?”


 Powered by Max Banner Ads 

© Ugur Akinci

My SHORT answer is: you should always use an Index for all long documents and help files, especially if they are in print format.

“How long?”

There are no hard and fast rules for that. It’s up to your personal judgement and/or what your client/manager asks for. It depends on the “document specs” or “documentation plan” as well as your personal judgment. But for any technical document that is over 10,000 words, I’d say it would not hurt to have an Index.

“How about Glossary links?”

Some techncial writers use glossary links for the terms in their online help files. That takes care of the explanation function but not the navigation function of the Index.

If you’d like to know what a specific word means, you can click on the Glossary link and read it. But what if you don’t know what the significant concepts are to begin with? What if you don’t know where the significant Glossary links are located in your document? In those cases even Search would not help because by definition one wouldn’t know what to search for. In contrast, a well-designed Index will easily guide you to those concepts and items that really count.

Some users print the help file for easy desk reference. That’s another case when glossary links would be useless since they obviously do not work when printed. An Index, on the other hand, works equally well whether it’s online or printed.

Share

Posted in Help Files, Technical Writing.

No comments

By admin – January 26, 2012

David Farbey of Medidata Solutions – A TCC Interview


 Powered by Max Banner Ads 

© Ugur Akinci

David Farbey is a senior technical communicator selected the 8th most influential technical communicator on MindTouch’s list of 400 Most Influential Technical Communicators. David’s blog “Marginal Notes” is at www.farbey.co.uk, and you can follow him on Twitter as @dfarb.

QUESTION (1):   How long you’ve been a technical communicator? Where do you work right now? How would you characterize a typical day at work?

ANSWER: I have worked in Tech Comm since 1994, and I am currently a Senior Technical Communicator at Medidata Solutions (www.mdsol.com). We provide technology to support clinical trials. I am responsible for the user documentation for two products and I am also leading a content strategy project team. Sometimes it feels like the only thing I do at work is attend meetings.

QUESTION (2):  How did you become a technical communicator? Did you start out as one or did you switch to it from something else? What was the reason?

David_Farbey_Technical Communication Center interview ANSWER: In the early 1990s I was living in Israel and working in a rather dull management job in a public service department. I had a lot of friends who were working in the software industry which was blossoming in Israel at that time, and I was interested in getting involved in high-tech as well. Everyone in my department would come to me – rather than to the department’s technician – with their computer problems. I realized that I was quite good at explaining technology to other people, and that I enjoyed doing so, and so I decided to look for a new career which would interest me. I took an evening class at a private college to learn the basics of technical writing, and was very lucky to find my first job, through a friend of a friend, at a local software company. I worked with a fantastic technical writing team at that company who taught me far more than I had learned on my course, and I haven’t stopped learning since then.

QUESTION (3): What is the single most important change that you see in the technical communication sector since you first became a technical communicator?

ANSWER: I can’t single out one thing, as there have been so many positive changes. For example, the recognition that end-users are partners in the development and dissemination of product information rather than merely consumers of it is a big change. The growth of social media as an important channel for communication is part of that. Another major change is the widespread adoption of structured authoring methods, which in the past were only used by the very largest corporations. Continued…

Share

Posted in Success, Technical Writing, Writing Life.

No comments

By admin – January 25, 2012

How to Express a Continuous Cycle Visually in a MS Word 2007 Technical Document

© Ugur Akinci

“Continuous Cycle” is a fairly common idea both in life and in technical communication.

Seasons form a continuous cycle that never ends: Winter, Spring, Summer, Fall, Winter, Spring, etc.

In technical writing the process of writing, editing, reviewing, releasing also forms a process that never ends. It’s a continuous cycle that repeats itself.

You can express such a cycle very easily and elegantly in MS Word 2007:


Follow these steps:

1) On the ribbon, select the Insert tab.

2) Select Smart Art > Cycle > Continuous Cycle graphic options to insert the main diagram:

(Click top enlarge the image)

MS Word 2007 SMART ART Continuous Cycle

3) To format the diagram with different colors or perspective etc., feel free all the formatting options MS Word offers on the ribbon:

(Click top enlarge the image)

MS Word 2007 SMART ART Continuous Cycle 2

4) Click on TEXT placeholder and type in your text into each cycle element.

5) To delete an element, select it and press Delete key on your keyboard.

6) To add an element, right click on an element and from the pop-up menu select Ad Shape > Ad Shape Before or Ad Shape > Ad Shape After.

 

Share

Posted in Graphic Design, Technical Illustration, Technical Writing.

No comments

By admin – January 24, 2012

Tom Johnson of “I’d Rather Be Writing” – A TCC Interview

© Ugur Akinci

Tom Johnson is a well-known technical writer who works for the LDS Church in Utah, USA. Tom has ranked #1 on MindTouch’s 2011 list of 400 Most Influential Technical Communicators.

QUESTION (1): How long you’ve been a technical writer? Where do you work right now? How would you characterize a typical day at work?

I’ve been a technical writer for about seven years. I currently work for the LDS Church in Utah. A typical day at work depends on what project I’m working on, but it might include updating help information on the wiki for LDS.org applications and working on content for the LDSTech blog. For more detail about my typical days, see this post or this one.

QUESTION (2): How did you become a technical writer? Did you start out as one or did you switch to it from something else? What was the reason?

I started out as an English teacher in Egypt, teaching writing to college students. I then worked as a copywriter for a time, but then switched to technical writing for better pay. I found out that I enjoyed technical writing more than I imagined. I enjoy the combination of writing and technology. I wrote about this with more detail in Becoming a Writer: Reflections on a Trip to Idaho.

Tom Johnson Technical Communication Center InterviewQUESTION (3): What is the single most important change that you see in the technical communication sector since you first became a technical communicator?

When I first became a technical writer in 2005, my main deliverables were a how-to guide and an online help. I’ve since become more fond of quick reference guides, video tutorials, and wiki content.

I think as a whole, we’ve seen some changes in the industry, such as the increase of content management systems, the implementation of DITA, and the increased use of web platforms for help. But overall, I don’t think the tech comm field has been that full of innovation. Part of the problem is that technical writers are mainly writers, not tool creators, so our innovations may be less tool-dependent and more content-centric. Some tech comm professionals have piggybacked onto the innovation of the web, but documentation requirements around content re-use and translation don’t often find their way into web tools.

I wish I could point to something and say, oh, definitely structured authoring. Or definitely the use of videos. But at the end of the day, these are little branches from the main tree, not a huge shift in the whole field itself. Of course, I’m still young by comparison. You’d probably get a better response from someone who has been a technical writer since the 1970s, like Neil Perlin.

Still, the question intrigues me, so I will expand on what I think the greatest transformation in technical communication should be. The greatest transformation yet to come is to drop the single-author paradigm of technical writing and to embrace the way information flows on the web. Continued…

Share

Posted in Success, Technical Writing, Writing Life.

Tagged with , , , .

No comments

By admin – January 23, 2012