Online Video Courses

Plain writing SAVE 20% TODAY!
Learn Plain Writing
------------------------------------ technical writing SAVE 20% TODAY!
Learn Technical Writing
------------------------------------ research paper writing SAVE 20% TODAY!
Write Great Research Paper
------------------------------------ MS Word Power Tips
MS Word Power Tips

Free Download

Learn 7 Reasons Why Becoming a Technical Writer is a Great Career Move!

New Graphic

Every Week! 

Subscriber Counter

We value your privacy. We will not share your information with anyone.

Selected Technical Writing Jobs for June 29, 2016


Technical Writer

Technical Writer To provide technical writing support for medical device industry product labeling within Technical Communication. Responsibilities.

Technical Writer

Assist in meeting overarching content goals by handling other writing, editing, and project tasks as assigned. The Technical Writer (Content Analyst) …

Technical Writer

Technical Writing, Technical Writers wanted for a growing organisation!

Technical Writer (147)

We are seeking a Technical Writer to create technical instruction manuals using for the PLM collaboration software, Enovia. Candidate will be working …

Biomedical Technical Writer -contract

Biomedical Technical Writer contract Can be done mostly offsite with the writer coming into their Cambridge office for meetings as need. Our client is …

Free Windows 10 eBook by Microsoft


Windows 10 IT Pro Essentials: Top 10 Tools

Ed Bott

Dive in to Windows 10 with award-winning journalist and Windows Expert Ed Bott in this highly curated free eBook covering the top apps, accessories, and utilities included in the box with Windows 10.
The sheer volume of Windows programs and accessories says a lot about the power and complexity of Windows—a fact that every IT pro knows from firsthand experience. There’s a tool for nearly every task, and a large part of the process of becoming a Windows expert is knowing how to find the appropriate one when you need it.
This eBook contains descriptions and hands-on advice to help IT Pros work faster and smarter.

Get your free copy today!

This post is indexed by – Careers & Industries Blogs

Selected Technical Writing Jobs for June 28, 2016


Technical Writer (SC15474)

Summary: This person will work as a technical writer, writing, revising, and completing Intel motherboard user manuals, quick reference guides, and …

Technical Writer

Technical Writing, Calling all Senior Technical Writers looking to be a part of an exciting opportunity!

Sr. Technical Writer

The Senior Technical Writer at NxStage is responsible for authoring and updating technical product manuals including user guides, instructions for …

Job Description

Applying technical writing principles and established style guide conventions to … Demonstrated understanding of grammar and writing mechanics

Senior Technical Writing Analyst

View full details for Senior Technical Writing Analyst job in Edinburgh on

FREE PREVIEW - 101 Tips & Tutorials to Write Like a Pro

FREE PREVIEW - 12 Transition Phrases and Sentences

Technical Writing Jobs for June 23, 2016


technical writing jobs

Technical Writer

Technical Writing, A great opportunity to join an Australian owned company who are not only the leaders in their field but growing innovators.

Technical Writer

A Technical Writer position in Forth Worth,TX is available courtesy of Adecco Engineering and Technology. You must have a minimum of two years …

Sr.-TechnicalWriter Job – Raleigh, NC

Eaton has a job opportunity for a Sr. Technical Writer in Raleigh, NC.

Technical Writer

Technical Writing, Stimulating and varied Technical Writer Role; CBD.

Technical Writer

Apex Systems is in need of a cleared technical writer to provide temporary support for the Product Document Management team. The technical writer …


Writer/Editor jobs in Anaheim for Cenergy Partners. View additional job detail and apply directly to Cenergy Partners.

Technical Writer – Productivity Apps – 49592971

Changing the world is all in a day’s work at Apple. If you love innovation, here’s your chance to make a career of it. You’ll work hard. But the job comes …

Technical Writer – Calgary

Technical Writer – Calgary, Alberta – Our Calgary client has an immediate requirement for a Technical Writer. Required Essential Skills: Proven …

Technical Writer

Technical Writing, FinXL are currently seeking to engage multiple Technical Writers with current security clearances on both perm and contract …


How to Convert Non Editable PDFs into Excel Sheets

By Paulina Gibson

Special for TCC

As PDF is the dominant format for corporate document sharing, it is no wonder there is a wide selection of complimentary tools that can help you get more done when working with this file format.

Even though Adobe also has its set of additional tools and extensions, at times they can cost a lot of money.

Luckily, there are a lot of free options a professional can choose in order to be more productive.

One tool that is particularly popular among lawyers, accountants and HR managers is this free PDF to Excel online software.

The beauty of this tool is that it allows you to convert extensive PDF reports without any limitations on the number of files you can convert, or their size.

For example, an accountant can easily take a large annual financial report in PDF format and convert the figures into editable and collectable financial stats. Similarly, an HR representative from a big corporation can easily convert job application data saved in PDF format into editable Excel sheets and save a lot of time by doing so.

PDF to Excel converter is not only more time efficient, but also more effective. By giving the software the task to compile data, the number of mistakes that a human would make while transferring data manually is much smaller.

You can easily use this tool by following the 3 simple steps below.

PDF Conversion

Step One

To start, take the PDF file you want to convert by clicking on the Select button, as seen from the image above. A great bonus for this tool is the fact that you can use it with any device, as the page is absolutely responsive. This means that you can finish all the paperwork from either your PC, laptop, tablet or a mobile phone.

Step Two

In order to get your converted document straight to your Inbox, submit your email address in the provided field. Investintech has a privacy policy and it will not use your email to send you unsolicited content or give your address to third parties.

Step Three

Lastly, click the green Convert button in the third section. Your conversion should take only a couple of minutes. In rare cases it can take a bit longer (up to 30 minutes) if there are a lot of conversions in queue.

That was it, a really simple and free way to save yourself some time at work. Feel free to check this tool out for yourself.

(Do you have any other alternatives for converting files to your favorite formats? Please leave a comment down below. Thanks.)

If You Ask a Rhetorical Question, Answer It, Right Away

© Ugur Akinci

If you pull your readers into a topic by asking a rhetorical question that’s perfectly acceptable as a writing style.

But if you do that, you’d better answer your own question right away. Otherwise some of your readers can be really frustrated.

Rhetorical questions increase the stakes. They introduce a tension that needs to be relieved by delivering the promised answer. You cannot assume that the readers know the answer to such a question.

Rhetorical questions that are left unanswered is a sign of sloppy writing at best. Some reader may even construe it as “disrespect for the audience.”

Here is an example:

what is git

The paragraph opens up with a wonderful teaser: “So, what is Git in a nutshell?”

But then writer disregards her own question and forgets to answer it. No where on the page is there a definition of Git “in a nutshell.” The overall impact is one of frustration and unrealized user expectation.

If you’d like to maximize the User Experience (UX) of your documentation don’t forget to answer your own rhetorical questions. The sooner the better.

Which topic would you like to master next?

Dear Reader,

Which new topic would you like to master next?

We are developing our next wave of online video courses.

Our goal is to make sure we offer exactly what you want.

Here are some of the topics under development:

  • How to self-edit a document
  • How to write and publish online documentation with Adobe RoboHelp
  • How to write and publish print documentation with Adobe FrameMaker
  • How to write and publish interactive learning projects with Adobe Captivate?
  • How to design and publish videos with Microsoft PowerPoint?
  • Basic and quick illustration techniques for writers
  • Plain English writing techniques for ESL students
  • Perfect mail-merge every time with Microsoft Word

(1) Which of the above topics would you like to learn the most?

(2) What other topic would you like to study this Spring?

You can send your response to [email protected] for a surprise gift as a token of our appreciation!

Many thanks in advance for your response.

Respectfully, Ugur

Ugur Akinci, Ph.D.
Fortune 100 Technical Communicator

3 Top Rules of Technical Writing

© Ugur Akinci

Every job, every occupation has its rules, correct?

Break these rules and you’ll be in trouble.

Here are some general rules in tech writing:

Tech Writing is Correct

This is the most important (but not the only) characteristics of technical writing.

No matter what else it is, a technical document first of all needs to be CORRECT and ACCURATE.

If it’s not correct, nothing else matters. You can dump such incorrect document straight into the trash bin.

For example, if a document instructs the user to connect a 100 Volt appliance to a 220 Volt outlet, that is an incorrect and dangerous instruction. Wrong technical instruction can be very costly and even lethal at times.

So I cannot emphasize this one enough: please make sure your documentation is CORRECT above anything else. Double and triple-check the accuracy of everything you write.

Tech Writing is Detached

Technical writing is detached from our emotions and value judgments as human actors. For that reason, a technical writer should refrain from projecting human desires and emotions onto technical systems.

For example, be wary of the verb “want” since a system really never “wants” anything. It either does something or fails to do it.

BAD DESCRIPTION: “When you press the START button, don’t worry if the engine does not want to come alive right away.”

BETTER DESCRIPTION: “Press the START button to start the engine. Wait a few seconds if the engine does not start right away.”

(What do you think about this post and video? Please leave a comment. I’d like to know what you’re thinking. Thanks!)

Can You be a Technical Writer at 60?

Or, “What I learned from James Williamson”…

Should technical writing be boring?

© Ugur Akinci

Someone said “good technical writing is boring writing.”

Not only that is true, but that’s a beautiful thing too.


Allow me to explain.

Let’s think about what makes a piece of writing EXCITING versus BORING.

Read any creative writing book you like and I think you’ll see that the author recommends VARYING word usage, VARYING sentence length, VARYING adjectives and descriptions, the voice and even POINT OF VIEW….

VARIANCE, in short, is what makes prose exciting and ENTERTAINING.

But VARIANCE can literally be DEADLY when it comes to technical writing.

Would you rather be ENTERTAINED or DEAD? (I’m exaggerating a bit of course but I think you get the idea.)

Here is how my reasoning goes…

Imagine you are flying in a commercial airplane.

Again imagine that the MAINTENANCE of that plane has been performed just before you took off, by MECHANICS who were trained by MAINTENANCE GUIDES that included a lot of ENTERTAINING VARIATIONS such as the following:

Page 16: “The TURBO FANS must be maintained every 100,000 aeronautical miles.”

Page 52: “Use only GR567 fluid when greasing the TURBO BLADES.”

Page 110: “Follow these procedures for the second stage of ENGINE ASPIRATION UNIT maintenance…”

Page 268: “Follow these procedures to uninstall and re-install each PROPELLER FIN UNIT…”

Imagine the mechanics trained on an ENTERTAINING maintenance manual, complete with JOKES and TRIVIA, a manual in which the same object (ENGINE FANS) is referred to 4 different ways, with a lot of VARIANCE….

Would you feel flying on a plane like that?

I wouldn’t.

I definitely would like to fly on a plane maintained according to a manual in which the same object is referred to in exactly the same way throughout the manual. I’d feel more comfortable with a manual that exhibits ZERO VARIANCE.

And such a manual would OF COURSE be BORING by DESIGN.

As technical writers we are not trying to entertain the world. There are plenty people who are doing that.

We are instead trying to EMPOWER people so that they will PERFORM technical PROCEDURES without any ERRORS, and do so in a TOTALLY PREDICTABLE way, in a fashion that F-15 pilots call “FLAWLESS EXECUTION.”

Without FLAWLESS technical documentation, there is no flawless execution and lives would be at stake.

So cheers for the no-variance documents! Cheers for boring manuals! And cheers for safe trips across the continents.

(What do you think on this issue? Please leave a comment below. Thanks.)

An Embarrassing Start to My Technical Writing Career

(Please leave a comment, good or bad, I appreciate them all. What questions do you have? I’m interested to know. Many thanks!)

© Ugur Akinci

I have a confession to make today…

I’m embarrassed and actually still blush a little when I remember how I started my tech writing career.

The year was 1998.

At the time I was a reporter for a print daily covering the U.S. State Department and the U.S. Congress.

It was an exciting job which allowed me to rub elbows with the rich and famous, the movers and shakers of the nation’s capital.

These were all powerful men and women, way above my socioeconomic class and pay grade.

If it weren’t for my credentials as a journalist, I’d never have the chance to share the same room with them.

Once for example I rode the same elevator with the late Sen.Ted Kennedy of Massachusetts. Perhaps a trivial moment by the standards of many people but I still remember that day.

Other times I would attend the press briefings at the White House even though I was not an accredited White House reporter. To be in the same room with a Cabinet Secretary or the President of the United States is an experience I’ll cherish as long as I live.

However, the truth is I wasn’t making any money at all.

The print journalism was already in trouble and I knew I had to something else if I were to take care of my family.

One morning as my wife was leaving the house I asked her where she was going. “To my head hunter,” she said. Back then she was a newbie computer programmer looking for a job.

“You wanna come too?” my wife asked.

And for no good reason at all, for reasons I still cannot explain, I said “Yes, why not?”

So we went together to this glass-and-chrome employment agency office in a commercial tower in Rockville, Maryland.

After the usual exchange of pleasantries, my wife introduced me as a writer in-between jobs, which in a sense was true.

After she listened to me for a few minutes, the recruiter said something that changed my life forever:

“I might have something for you… would you considering a technical writing position?” she asked.

And like an idiot, I said … “What is that?”

My god, I still cringe when I remember that moment. Whew!

The truth is, like millions of people in the world, I also had not heard of “technical writing” before.

She explained to me patiently what tech writing was and why it would be a great fit for me given my technical and creative sides. I kept nodding my head and the rest is history, as they say.

So if you at this point also do not have a very clear idea of what technical writing is, it’s completely understandable because once upon a time I didn’t know what the heck it was either. There’s a beginning to everything, isn’t it?

(How do you feel about this video? What do you think? Please leave a comment below. Thanks.)

How to Create a Daily Job Alert Feed

WORKING - MorgueFiles© Ugur Akinci

Here are three email job alert feeds that I use all the time. When you create any of these, you’ll find an email in your inbox every day listing the jobs available for your search keyword(s).


1) Create a free account.
2) Go to
3) Make a search with keywords, company, or title. For example let’s use “writer” as a search keyword. For the city, we’ll use “New York City”.
4) Click Search. This will take you to search results page.
5) Click the Create Job Alert button to receive daily job alerts about writing jobs in NYC.


1) Sign on to your free Google or Gmail account.
2) Go to
3) Enter a keyword into the “Create an alert about…” field.
4) Configure alert options by clicking the Show Options drop-down list.
5) Click the Create Alert button.


1) Log in to your free Craigslist account.
2) Go to the Craigslist page for the city you are interested in.
3) Click the JOBS category title.
4) In the JOBS page, make a search with a keyword.
5) Click Email Alert link right next to the search field.

Free photo courtesy of

Selected Technical Writing Jobs for Jan 16, 2016

Microsoft Word Tutorials: For Word 2010 and 2013, Vol 1

Microsoft Word Tutorials: For Word 2010 and 2013, Vol 1

TCC has a new logo!

Here is our new logo that we’ll use in all our communications:



Did you like it? Let me know what you think. Thanks. Ugur

How to Write Cause and Effect Sentences and Paragraphs Properly for Building Convincing Arguments

How to Write Cause and Effect Sentences and Paragraphs Properly for Building Convincing Arguments© Ugur Akinci

Cause and Effect Sentence

Writing a cause and effect sentence is very commonplace in both fiction and non-fiction works.

Its structure is very simple and straight forward.

There are two basic types of cause and effect sentences:

1) You start with a CAUSE, then connect it to an EFFECT with a CONJUNCTION.

2) You start with an EFFECT, then connect it to a CAUSE with a CONJUNCTION.

An alternative form starts with the CONJUNCTION:

3) You start with a CONJUNCTION, then follow it with a CAUSE, comma, and an EFFECT.

What is a “Conjunction”?

A conjunction is a sentence component that JOINS two clauses, two parts of a sentence.

Although it sounds complicated, actually it’s not since you already know and use dozens of conjunctions in daily life.

For example, every time you use AND you are using a conjunction.


1) Sentences that start with a CAUSE and end with an EFFECT

“He studied hard for the SAT exam [CAUSE] and [CONJUNCTION] got a perfect 800 [EFFECT].”

“They trained hard [CAUSE] but [CONJUNCTION] they still lost the match [EFFECT].”

2) Sentences that start with an EFFECT and end with a CAUSE

“She has been unhappy [EFFECT] since [CONJUNCTION] she was assigned to this case [CAUSE].”

“We chose him [EFFECT] due to [CONJUNCTION] his MBA [CAUSE].”

3) Sentences that start with a CONJUNCTION

“Because [CONJUNCTION] of the severe weather alert [CAUSE], all flights have been cancelled [EFFECT].”

“Now that [CONJUNCTION] you’ve seen the evidence [CAUSE], I’m sure you can write a better report [EFFECT].”

Cause and Effect Paragraph

Writing a cause and effect paragraph is not that hard: you can either start by a cause and then explaining the effects; or the other way around – start with the effect and explain the causes.

Let’s examine these two different types of paragraphs one by one:

1) Paragraphs that start with a CAUSE

Let’s say you start your paragraph with “rising fertility rate in rural villages.” That’s a CAUSE.

What would be the effects? Let’s mention three:

  1. Population increase.
  2. Falling living standards (if agricultural productivity remains the same).
  3. Thus eventually a migration to cities.

Importance of Assumptions

Here as you can see the crucial component is the ASSUMPTION that agricultural productivity will remain the same. This is important because if the productivity goes up it can support a growing population and thus there won’t be any urban migration.

You start with a TOPIC SENTENCE which describes the CAUSE. Then you continue by listing the EFFECTS. Important thing is to make clear what your ASSUMPTIONS are including in your reasoning and mentioned very clearly.


“Fertility rate has risen 7% in Western XYZ between 1990-2010 [THE CAUSE].

One effect of this would be increased pressure on food resources, if we assume that the agricultural productivity remains the same [THE ASSUMPTION].

A second and related effect would be dropping standard of living in Western XYZ.

We should expect this to lead to an eventual migration to the cities in the region like La Capital [THE EFFECT].”

2) Paragraphs that start with an EFFECT

You start with a TOPIC SENTENCE which describes the EFFECT. Then you continue by listing the CAUSES. Important thing again is to make clear what your ASSUMPTIONS are.


“Those with a college degree are shown to earn a million dollars more over a lifetime than those who do not go to college at all [THE EFFECT].

One reason why this is so is the higher paying jobs available to college graduates [CAUSE 1].

Another reason is college graduates are more comfortable with high-technology which helps them start high-profit businesses [CAUSE 2].

Of course, we are here assuming that the two groups (college and non-college) start off their adult lives more or less from the similar socioeconomic backgrounds.”

As you can see, even though there is a structure to the way a cause-paragraph is written [TOPIC SENTENCE first, followed by supporting effect or cause sentences], there are no standard phrases or keywords that you need to use while writing them.

As a writer you should use your creativity and come up with the correct style to stitch together the cause and effect elements together as shown in the above examples.

5 Reasons Not to Convert to Structured Authoring

5 Reasons Not to Convert to Structured Authoring© Ugur Akinci


XML-based structured authoring has been one of the hottest topics in the technical writing community for quite a while. Shifting from traditional documentation to “structured documentation” has been the “holy grail” of top-echelon technical communicators for the good part of the last decade. In one survey reported by Scott Abel of The Content Wrangler, for example, 44% of the companies surveyed said they were using XML-based structured authoring. That’s an impressive number indeed.

Yet, as I can tell you from my own personal experience as a Fortune 100 technical writer, the transition is not always smooth and easy. Even though they are usually touted as the next best thing after sliced bread, structured authoring and platforms like DITA (Darwin Information Typing Architecture) have their own disadvantages and hurdles as well.

Here are five of them.

The Need

The most serious obstacle standing in the way of converting to structured authoring is this: perhaps you do not have a real need, a good business case why you should convert. Ask yourself: will your documents be read by customers in different countries talking different languages? Will the content of your documents be published in many different formats like PDF, HTML, digital content on mobile phones and pads, and even in publicly accessible kiosks? Will they be updated regularly or frequently? Will you reuse the same modular content in different combinations to create different deliverables? You need to give a strong “Yes!” answer to these questions to justify the conversion.

The Cost

The transition takes a serious commitment of resources. You need to purchase not only a reliable, robust and scalable CMS (Content Management System) but also hire the correct SMEs (Subject Matter Experts) to lead and manage the transition. We are talking about an investment of not hundreds or thousands of dollars, but easily of tens of thousands of dollars, either paid upfront or budgeted monthly. In some cases the total cost can climb up to well over six figures. When they hear the real numbers, most small and medium businesses have a change of heart and decide that perhaps they should “wait a little more” before taking the plunge.

Management Buy-In

Structured authoring requires cleaning up the legacy files. DITA expert JoAnn Hackos of ComTech suggests four kinds of decisions that documentation managers need to make: 1) What to convert, 2) What to reuse, 3) What to rewrite, and 4) What to leave behind (see

To get the management agree on all these four questions is a monumental task in itself since it can get political easily. Managers protect their own turfs and area of operation. Getting rid of certain documents, rewriting others, or changing their mode and scope of distribution affect their own decision making autonomy directly. So it sometimes becomes an inter-departmental battle to decide what to do with the legacy documents. That in itself may delay the conversion significantly as well.

Staff Buy-In

Structured Authoring has a steep learning curve. Training not only takes time but money as well. You need to have a team of technical writers willing to make the transition by learning new tricks and devoting themselves to the conversion. When the team leader or one of the writers support the decision but the others don’t, team spirit and productivity suffer. Some writers love the way they traditionally do their job and they are threatened by this “new hi-tech mumbo jumbo.” It’s totally out of their comfort zone; and so they resist the process.

Thus even when the management commits the appropriate resources, internal staff conflict can make the transition a most unpleasant experience indeed.

The Structure

Even if you answered all the above concerns satisfactorily, you’ll still need to structure the conversion, as all structured authoring experts agree. And by “to structure” this is what they mean: you cannot one day just start slapping XML tags to document components and think you’re converting them into “structured documents.” The conversion needs a much more comprehensive effort than that.

You first of all need a “Content Strategy.” You need to know where you are heading; how you will assure quality; how you will distribute the new content; how you will measure the results; etc.

After that, you need a “Content Model,” that is, which XML-based conversion platform are you going to use? Will it be DITA, one of the widely-adopted platforms, or another like DocBook, S1000D, TEI, SPFE, Markdown, or a totally custom-made platform with specific XML components for your niche?

Following that you’ll need a Pilot Study to test the limits and outcomes of the conversion. If your legacy documents have a lot of visual elements embedded into highly-designed page layouts, for example, the structured outcome may not be what you were expecting. This may give you an opportunity to tweak your style sheets and redesign your templates. During the pilot phase you may also find out that you have difficulty with some of the output formats. This is the time to correct such errors or find workaround solutions. Once the pilot project starts to generate the kind of outputs you are pleased with you can go into full production and scale up your production.

As Scott Abel says: “Don’t jump in [to structured authoring] without a clear business case, a repeatable strategy, and measurable goals” (


Do your homework and ask all the above questions before making a commitment to structured authoring.

This is a long-term conversion project that requires significant investment of time, money, and human capital. It’s better to stay on the sidelines and watch where this particular documentation niche is going than investing heavily because “it’s the new sexy trend to follow” and suffer in the end.

Structured Authoring and the Evolution of XML Standards - Two Perspectives on XML


Structured Authoring XML technical writingBy Max Dunn

I have been working with XML since it was a glimmer in the eye of Jon Bosak. In fact, before XML was conceived, there was SGML; going from SGML to XML represented a streamlining for the web, but at its core there was not much functional difference; in fact XML is a subset of SGML. The key concept of semantic markup is central to the core value of SGML/XML.

The two main perspectives I have seen are Document-centric XML and Data-centric XML. SGML initially appeared in support of document-centric work: managing all the technical documents or contracts of IBM or Boeing, for example. Charles Goldfarb has maintained that “SGML literally makes the infrastructure of modern society possible” and I think he’s right – hmm, should we blame him for the lengths to which humans have gone to destroy the earth?

The document-centric XML world is really a direct continuation of SGML. When XML came out as a standard in 1998, those of us working with document-centric XML became giddy with excitement, anticipating that the standards being proposed at the time (notably XML itself, XLink, XML Schema, RDF, XSL and pre-cursors to SVG) would finally facilitate tools that made publishing work for organizations that weren’t quite as big as IBM or the Department of Defense. The vision of a semantic web and ubiquitous XML multi-channel publishing, seemed to be growing a foundation in theories gaining critical mass, with apparent support of software companies. It appeared these vendors might actually adopt the standards of the committees they were sitting on. “Throw away Xyvision!” I told my boss at Bertelsmann, “this XSL-FO will completely revolutionize database publishing!”

We were sorely disappointed over the next five years. In the years before 1998 W3C standards seemed magical; concepts from the standards were implemented relatively quickly, without perfection but with steady progress: browser updates would reflect CSS and HTML advances; even Microsoft was shamed into some level of compliance. But the monopolistic tendencies of those on the standards committees, coupled with the academic approach of some of the standards committees, managed to make it less and less likely that a given standard would find a functional implementation.

And there was that other perspective – the data-centric side of things. For many reasons, XML was at the right place at the right time in terms of data management and information exchange. In fact, the very year that XML became a standard, it also became the dominant way that machines (servers) talked to each other around the world. Highly convenient for exchanging info, as firewalls would tend to block anything but text over http, while XML markup would allow any sort of specification for data structures, and validation tools would ensure no info was lost.

In 1998, when you asked a programming candidate “what do you know about XML?” only the document-centric people would know anything. By 2000, everyone doing any serious programming “knew” about XML. Trouble was, they typically knew about “XML” only in the much easier-to-use, irrelevant-to-publishing, sense.

And the standards now had to accommodate two crowds. The work of the W3C XML Schema Working Group, in particular, showed the disconnect. Should a schema be easily human readable? What was the primary purpose of Schema? Goals were not shared by the document- and data-centric sides, and data-centric won out, as they have tended to dominate the XML space ever since that time. RELAX NG came about as an alternative, and if you contrast RELAX NG with W3C Schema, you will see the contrast between the power of a few brilliant individuals aligned in purity of purpose and the impotence of a committee with questionable motives and conflicting goals. Concurrent with a decline in the altruism of committee participants was the huge advance of data-centric XML and the disproportionate representation of that perspective.

Ten years later, we find in the document-centric world that toolsets related to XML in a data sense – parsing, transforming, exchanging info – have made great leaps forward, but we are in many ways still stuck in the 1990s in terms of core authoring and publishing technologies. It is telling that descendants of the three great SGML authoring tools as of 1995 – FrameMaker+SGML, Arbortext Epic, and SoftQuad’s Author/Editor, are, lo and behold, the leading three XML authoring tools in 2009.

There have been some slow-paced advances in document-centric XML standards and tool chains as well, especially the single bright light out there for us, Darwin Information Typing Architecture (DITA) which came out of IBM like XML itself. Yet standards for rendition, XSL-FO and SVG especially, have not advanced along with core proprietary rendition technologies such as InDesign, Flash, or Silverlight, though all of these enjoy nicely copied underpinnings pillaged from the standards. More important, nothing has stepped in to replace the three core authoring tools: the “XML support” of Microsoft Word and Adobe InDesign, for example, do not approach the capabilities of a true XML authoring application. There are a proliferation of XML “editors” but most of the new ones are appropriate for editing a WSDL file or an XML message (the data-centric forms of XML), not a full-fledged document.

Meanwhile, on the data-centric front, XML has simply permeated every aspect of computing. There are XML data types in database systems, XML features in most programming languages, XML configuration files at the heart of most applications, and XML-based Web Services available in countless flavors.

Document-centric XML is simply a deep challenge that will take more time (and probably more of a commercial incentive) to tackle. For the time being, structured authoring managed the XML way is still implemented mainly by very large organizations: such an approach has “trickled down” from organizations the size of IBM to organizations the size of Adobe (which does, in fact, use DITA now), but there are not tool chains yet available that will bring it down much further. The failure of the W3C XML Schema Working Group to provide a functional specification supporting document-centric XML can hardly be underestimated.

As long as content is not easily authored in a semantically rich, structured fashion, the vision of the semantic web will remain an illusion. When and if document-centric XML gets more attention from standards bodies and software vendors, human communications will become far more efficient and effective.

Max Dunn has been programming typographical output for over 15 years. In 2000, after 4 years directing programming at Bertelsmann Industry Services, Max founded Silicon Publishing, a development company specializing in document generation and dynamic web site automation.

TOP 3 Ph.D. Programs in Technical Communication in the United States

© Ugur Akinci

A full-fledged doctoral program that focuses exclusively on technical writing and communication is still a rare bird out in the market today.

Here are the top 3 Doctor of Philosophy (Ph.D.) programs in the United States on technical communication – the highest academic degree you can get as a technical writer and communicator.

TOP 3 Ph.D. Programs in Technical Communication

1) Illinois Institute of Technology

Name of the degree: “Ph.D. in Technology and Humanities” (used to be called “Ph.D. in Technical Communication”)

This is not a practical hands-on program that prepares technical writers for the real world of technical writing out there. However, if you’d like to be an academic and do research and teaching in a university setting in the field of technical communication then this might be what you are looking for. It is a 72-hour program beyond the bachelor’s degree. Students who have earned a master’s degree in a relevant field may transfer up to 30 credit hours.

For more info:

TOP 3 Ph.D. Programs in Technical Communication

2) University of Minnesota

Name of the degree: “Ph.D. in Rhetoric and Scientific and Technical Communication (RSTC)”

This is also a research degree aimed at preparing technical writing students for faculty positions. It is not designed to prepare technical writers to work in government and private sector.

Ph.D. candidates must earn a minimum of 42 credits in coursework, at least 27 of which must be taken in Writing Studies classes and seminars.

For more info:

TOP 3 Ph.D. Programs in Technical Communication

3) Texas Tech University


The program provides a broad base to conduct research in technical editing, design, rhetorical theory, online documentation, publications management, and usability testing.

60 credit hours are needed to complete the program.

For more info:

STC INDIA Presentation: Working for a Software (SW) Company

Working for a Software Company

Click  below to download the presentation slides in PDF format:


How to Import a Word File into a FrameMaker Document

© Ugur Akinci

1) Create a FrameMaker (FM) file. Place your cursor in the first line of the file.

2) Select File > Import > File to browse to the Word document you’d like to import. The Import screen will display:

Importing Word to FrameMaker

3) Select the “Import by Reference” and the Word file you want and click the Import button.

4) In the Unknown File Type dialog box, select “Microsoft Word 2007” and click the Convert button:

Unkown FIle Type

5) In the Import Text Flow by Reference dialog box, leave the default values alone and click the Import button once again. FM will import the Word content.

Here is the original Word content:

WOrd version

And here is its FM version, after the import:

FM Version

It looks pretty good, correct?

Yet the looks can be deceiving since this not editable text converted into FM format yet. If you click the text in FM, the whole page will turn into an non-editable black image:

Noneditable FM

6) To convert the imported text, double click it to display the Text Inset Properties dialog box:

Text inset properties

7) Click Convert to display another dialog box:

Convert Text Insets to Text

8) Click Convert once again and the imported text will be converted into editable FM content.

How To Calculate The Number Of Workdays Between Two Dates Using NETWORKDAYS in MS Excel

By BJ Johnston

Is is easy in Excel to calculate the number of working days between two dates. Most, but not all businesses, operations or project activities and progress happen during weekdays. So, if you need to report and calculate the number of days that have elapsed between a start date and an end date of a project or project milestone for example then counting weekends in the calculation is not what you want to do, and you will need to avoid those days in your calculations. It is easy to do in Excel with the NETWORKDAYS function.

The formula NETWORKDAYS is pretty straightforward and has two required arguments or parts to it.

The syntax of the formula is


So, an example always helps when working through Excel formulas.

Below is the start date and end date of a short project. Start Date is in cell C4 and End Date is in D4.

01/01/2015-Start Date

31/03/2105-End Date

The formula calculates the number of workdays (excluding Saturdays and Sundays which is the default), in this example it is 64 days.

So, this is a straightforward calculation automatically excluding Saturdays and Sundays, but some projects could and do include Saturdays, Sundays or even both.

Well of course Excel can handle this. In this instance we can use the NETWORKDAYS.INTL function.

The difference with this formula this is that it includes an extra argument or part, a weekend code, which allows us to specify which days to exclude as a weekend day or days. The syntax of this formula is


Let’s apply the same formula- but let’s assume we know our project work was active on Saturdays also. So, we need to ensure exclude any Saturdays from the calculation of days worked on our project

So, we need to select option 17 which is Saturday only. You can choose any of the options of 1 to 17 from the drop down menu. This now increases our work days to 77 days in the period 01/01/2015 to 31/03/2015 as Saturdays are now included as normal working days and should increase the number of days worked on our project. The number of days between the two dates now increases to 77 workdays.

The NEWTWORKDAYS and NETWORKDAYS.INTL are a useful couple of Functions to have in your Excel Tool Kit.

BJ Johnston has been an advanced Excel user for 15 years and is the creator of a site that shares Excel tips and tricks with it’s enthusiastic members.

Proposal Planning and Writing for RFPs: Write Great Proposals to Win U.S. Government Contracts

6-5-2015 2-31-32 PM

Proposal Planning and Writing for RFPs” is a 51-page (8.5” x 11”) comprehensive volume describing in over 10,000 words every aspect of responding to a government RFP (Request For Proposal).

This e-book even covers the questions that need to be asked to decide whether an RFP is the correct one, way before the prosal writers type the first word on their keyboards.

Government proposal writing is a fast changing field and thus RFP how-to guides need to be updated on a regular basis. This edition includes the latest developments and references in the field.

Proposal Planning and Writing for RFPs” is researched, developed and written over a 6 month period with the following two groups of audiences in mind:

1) BUSINESS and TECHNICAL WRITERS assigned to write a proposal in response to an RFP. There is plenty in here to guide a writer from start to finish, including a detailed description of every component that a good proposal needs to have.

2) PROJECT MANAGERS whose jobs are much harder since not only they need to hire and direct the RFP writers, but they also must first evaluate if the RFP is actually the right one. If that research yields a positive result, then they need to shoulder the even more ardous task of putting together an RFP project team and driving the delicate process to its very end. This ebook also has chapters exclusively written for such project managers.

The main chapters are:

1) Introduction and Terminology

2) Six Set-Aside Programs (for small businesses)

3) Subcontracting facts

4) GSA Schedules

5) Focus on Selected Agencies and Resources

6) First Things First – the things you need to do to start the process

7) Questions to ask BEFORE you start to write your proposal

8) Questions to ask BEFORE you start to send out your proposal

9) Parts of the proposal

10) 5W + H Reality Check

11) Watch Out for the “Fishing Expeditions”

12) Step-by-Step Reply Process for RFP Managers

13) RESOURCES: U.S. Federal Procurement Web Sites (69 web sites)

14) RESOURCES: U.S. State & Local Procurement Web Sites (71 web sites)


Chapter 13 is a unique chapter: it describes a step-by-step development process for the proposal management team, starting with the assignment of responsibilities and selection of work teams all the way to writing the final draft and bringing the project to a successful conclusion.

The updated and alphabetized list of 140 federal and state procurement web sites in the resource chapters alone is worth the modest price of this comrehensive guide.

Those two chapters alone can save you untold hours of searching for the appropriate resources. Knowing where those web sites are important to find the right RFP or project bid. Now you have them all under your finger tips in two convenient lists.

Proposal Planning and Writing for RFPs” is recommended for all business teams, project managers, business and technical writers, and all those who would like to get their share from the annual $500 billion U.S. federal procurement pie.