Category: Work

Why we need to know about EU Directives

by Kelly Parks, Membership Manager

Let’s say you were creating documentation for consumers in a European Union (EU) state. You have a plethora of issues to consider: adequate research, the consumer’s language, translation costs…the list goes on. However, laws can vary depending on which EU state the product will be sold in. The EU Commission created Directives in an effort to harmonize these laws and make it easier to do business across the member states.

What are European directives and how are they different from European regulations?

The purpose of directives is to harmonise the laws of different member states of the EU. These directives set out goals that all EU countries must achieve. However, each country is allowed to decide how they reach those goals. “National authorities have to adapt their laws to meet these goals,” says Europa.eu, “But are free to decide how to do so.” There are directives for almost any topic, including:

  • Healthcare, medical devices, and pharmaceuticals
  • Environment and the conservation of animals and habitats
  • Copyrights and trademarks

Regulations, however, are far stricter. They are cold, hard rules. Europa.eu describes regulations as “…the most direct form of EU law – as soon as they are passed, they have binding legal force throughout every [EU] Member State, on a par with national laws. National governments do not have to take action themselves to implement EU regulations.”

Do European directives affect technical documentation?

Absolutely. Take the Waste Electrical and Electrical Equipment (WEEE) directive as an example. As part of the WEEE directive, the WEEE symbol
(shown below) must be visible on applicable electrical products. This symbol means that the product does not belong in public waste. If you are writing the user documentation for such a product, you are responsible for ensuring that:

  • This symbol is defined on user documents.
  • Information is provided as to where the product can be disposed of.
  • The potential environmental impacts of disposing this item in public waste are clearly communicated.
WEEE symbol
Chances are you’ve probably seen this symbol on your laptop or home computer. This symbol means that the product should not be disposed of in any public waste system. Companies are required, under the WEEE directive, to place this symbol on all electrical equipment. Source: Wikimedia commons

For more information on the WEEE Directive, visit the EU legislation summary page on waste electrical and electronic equipment.

To complicate matters, directives (and regulations) are written in legal verbiage that can cause glossy-eye syndrome. The legal verbiage makes it hard for technical communicators to understand the directives and how to address them in their documentation. Therefore, it’s important that technical communicators work closely with their regulatory or legal manager.

Each directive document presents a large amount of information that needs to be sifted through. However, it is time well spent because the consequences of not following the directives are worth avoiding. If the user documentation does not meet the goals set out in the directives, the product cannot be sold in the EU – which puts the technical communicator in a rather rough spot.

What has been your experience in working with directives? Share in the comments section.

Working with OEM documentation

by Jen O Neill

Outsourcing manufacturing is big business. Many companies today use the services of other companies to make, even design, some of their products as it can provide them with needed components or products without owning and operating a factory to do this work themselves. The benefits are cost savings, improving time to market, and access to a wider range of products than they could develop themselves in-house. Both hardware and software are outsourced.

What’s an OEM?

Companies to whom manufacturing is outsourced are called Original Equipment Manufacturers (OEMs). An OEM is a company that “manufactures goods that are sold to other businesses that might rebrand them and sell them at retail”. Source of OEM definition.)

An Original Design Manufacturer (ODM) is a company that “designs and manufactures a product which is specified and eventually branded by another firm for sale”. (Source of ODM definition.)

OEM and ODM products are used in many industries, but particularly so in electronics. These companies are located around the world but many are based in Asia. In this article “OEM” has been used to cover both OEM and ODM companies.

The OEM source files

If you are rebranding or rewriting OEM documentation, be aware that in the world of OEMs, Microsoft Word rules. As cost control is a big issue with many OEMs, few have technical writers in-house but instead get their engineers to write the documentation. They use Word.
And often they’re not writing in their mother tongue – most OEMs aren’t located in English-speaking countries. The documentation consequently can often be poorly written and riddled with an “English” contaminated by another language.

Rewriting OEM manuals can be challenging, particularly if you’re working to a tight deadline and the English is poor. If your company works with many OEM products, a further challenge is trying to keep the rewritten manual consistent with the content of the other manuals in your company. Reuse of content is particularly important to help control translation costs. Yet writing for reuse can at times feel a challenge when you’re struggling with reading to comprehend, particularly if you don’t have access to the OEM engineers to ask what they meant in the text they wrote.

Some companies just simply rebrand an OEM manual and leave the content as is. There are unfortunately many examples of such manuals on the internet. Lots of companies don’t have the services of technical writers. And don’t consider the business benefits of having them either.

Keeping terminology correct and consistent

Working with OEM software and documentation increases the need for terminology control as there’s a greater chance of unapproved, inconsistent, and incorrect terms being present than when content is developed in-house. Even when correct, terms may also not always be the same between companies.

Build a glossary of terms related to your OEM documentation and software that includes both the correct and incorrect terms. Include context of use, the definition of the term. So next time a writer in your group is working on an OEM manual and they come across “appearance time”, for example, they can quickly look it up in the glossary and see that this must be changed to “display time”. As with all glossaries, this is a living document and must be regularly maintained.

Fluency in other languages is certainly a help when working with OEM documentation as it can make it easier to spot problems with terminology. One example we had of “flavoured” English was in the software of a French ODM we used to develop a program for us. They used the term “equipments” throughout the English source software. We changed this franglais (English with French influence) term to “devices”. The word “equipment” exists in both languages but the context of use can differ. In French this is called a “faux amis” or “false cognate” in English. Be continually on the lookout for such faux amis when checking software and documents written by OEMs.

Where possible, give the OEM your company’s glossary of approved terms to use when customizing products for your company. But continually check that your company’s approved terms are indeed being used, particularly when the product is updated. A different engineering team perhaps might be put in charge of the product update and for whatever reason they could ignore or overlook your glossary. Stay alert.

Legal issues

Reuse as is or rewrite the OEM documentation? This question will be answered in the contractual agreement drawn up between the OEM and the company using their services. It will specify whether the product documentation will be handed over by the OEM to be customized. So if you have any specific documentation needs, such as you want to the source files in XML, FrameMaker, or HTML, for example, you should ensure that this is agreed upon before any contractual agreement is signed. But as stated earlier, most OEMS work in Word.

In my experience, many OEM manuals have incomplete or no regulatory information included, where required. If you are rebranding/rewriting OEM manuals, check that all required legal information is indeed included for your market. Although legally the manufacturer is responsible for placing the CE mark on the product, for example, once you rebrand it, you then become legally responsible. See an earlier blog on sharing source files with third party companies.

Localisation issues

In my experience, few OEM companies consider the impact of localization on their software and documentation even if they are selling their products worldwide. And that includes OEMs with in-house technical writers.

If you will be translating the documentation you’ve inherited from an OEM, you should review it for potential localization issues such as embedded text in graphics (do you have the source graphic files or just the jpeg files?), terminology (mentioned earlier), and possible cultural issues in the content. One OEM my company worked with had in-house native English-language technical writers who targeted their documentation to the America market although the OEM sold its products in many other countries. They had, for example, used the term “Thanksgiving” in a section of a user manual on programming schedules instead of the generic “public holiday”. We had to carefully go through their manuals to ensure that the content was culturally neutral for our market in Europe, Middle East, and Africa.

In summary

  • From the contractual agreement and your product managers, find out what has been agreed with the OEM with regards to the documentation.
  • Develop a glossary specific for this OEM (or expand your group’s glossary) that includes correct and incorrect terms.
  • Check that the legal information in your rebranded/rewritten documentation is correct and complete.
  • If you translate, check for potential localization issues.

What’s the most important time zone in Europe?

by Jen O Neill

Working for an American multinational company with technical writing colleagues on both coasts of the US and me in Belgium, you’d think I’d be watching the clock to see when they’re in the office so that we can talk.

Nope.

I’m not watching the Instant Messager screen on my computer to see who’s available in the US. It’s my colleagues across Europe that I’m tracking. I often need them at short notice for information.
So which time zone matters the most to me when trying to get hold of my European colleagues during the day?

Lunchtime!

Between time zone differences and cultural differences on when to eat that exist between European countries sometimes I sometimes feel that I’ve been thinking about lunch for much of the day. If it’s X time, then A must be at lunch. And at X+1 time, B and C will be at lunch. C is at lunch at X+2 time …

From 11:00 in the morning (my time) my Finish colleagues aren’t around. It’s noon for them and they’re at lunch so no point chasing Finns then. An hour later, it’s my lunch time. So the German, French, Dutch and Italian colleagues know they won’t have me pinging them as we’re all at lunch.

By 14:00, my time, there’s no point contacting colleagues in Britain for information as it’s 1pm for them and they’re gone to lunch (except they’re not gone for long). In the past my Spanish colleagues would be off to lunch at 14:00 and often not return until near 16:00. So for a few years I was tracking a lunch time zone that could last up to five hours yet I never left Europe.

For many of us in Europe lunch is a main meal and not a grab-n-gobble sandwich at our desks. Sadly the two-hour lunch no longer (officially) exists in our European offices. When I moved to France from Britain years ago, I quickly adapted to a slow two-hour lunch with colleagues. The company canteen served a five-course meal with wine or beer. I then moved to Belgium to work for another company and lunch became an hour. Only one hour!

Working in a corporate environment can mean that local habits change. I can’t remember when the two-hour lunch disappeared in our French office but when we were bought by our current owner, they insisted that the Spanish office fall into line with the rest of the offices in Europe. They had to eat earlier and come back in an hour. They weren’t happy about that. These days I can ping Spain at 14:00 and get a reply.

My lunch time zone now at work is only around three hours.

Bon appetite! (Now if you could just get that info back to me by…and pass the salt. Thanks)

No Weather in Belgium

by Jen O Neill

I’ve been thinking about the recent travel chaos that hit Europe and North America over Christmas when air travel practically came to a standstill for days due to the snow. Like many, I was stranded and sought information everywhere and anywhere in an attempt to figure out when I might be getting off the ground. Internet, radio, TV.
Watching the weather forecasts on French TV, I noticed that the weather curiously stopped at the French border. Changing channels to a Dutch station, the weather there stopped at the Dutch border. Same phenomenon on German TV; no weather outside Germany.

Did this mean that there was no weather in Belgium, situated between these three countries?

Not at all. Belgian TV showed me that the country was indeed having its own enclosed microclimate and not sharing it with its neighbours either. But as a stranded air passenger, I was aware of the larger picture-that all these countries were indeed sharing their weather and that by sharing their weather, the weather was having a much bigger impact than if it had stayed as numerous microclimates.

It’s not just TV weather news that can be accused of confining themselves within self-imposed borders. We can be guilty of it, too. Restricting our thinking and work within the confines of our own boundaries, such as narrow functional responsibilities, is unfortunately too easy to do. Silos can seem such comfortable places. Both for us and the information we produce as writers. How much information in our style guides, for example, could be used by other groups in the company but is never shared or has not been set up to be shared? Perhaps they don’t even know we have it. And what do they have that could be useful to us?

And yet, just as the weather has found, we can make a much bigger impact if we get out and collaborate with others. It can be hard to step outside the comfort zone. Yet if we want to develop and succeed professionally, we need to think outside of the box.

We need to be more like the weather. Circulate.

Sharing our source files with other companies

by Jen O Neill

Earlier this year, Tom Johnson in his blog “I’d Rather Be Writing” discussed the issue of documentation ownership. He had recently handed over the source files of several manuals he had done to an internal client and felt that the manuals had been “stolen” from him. He acknowledged that it was the loss of “ownership” that unsettled him. He no longer controlled the quality of his documentation.

Ownership does matter

The topic caught my attention as I regularly exchange source files with customers, developers and our sales offices. Where I differ from Tom is that I am often exchanging source files with those from outside of my company. “Ownership” takes on a legal context in such situations. Whatever I may think about a document being “mine”, it really does matter to my company what happens to it after we hand it over and who becomes responsible for the content.

Sharing files in a collaborative age

In my product group at work we regularly share source files with third party companies. Several of our products are manufactured by original equipment manufacturers (OEMs). We receive their source files of the accompanying manuals to customize for our market needs as well as to rebrand.

Occasionally a large customer may request that we customize one of our product to suit their market requirements, which will mean the documentation too. Usually we would customize the documentation in-house but not always.

Not everybody wants English. Many of our customers don’t operate in English. As we operate globally, we translate into many languages and they may want their language to be customised. A large Danish customer, for example, wanted our Danish translations customised. As we couldn’t do such work ourselves, it was agreed that we’d hand over the Danish source files to them for them do rework and rebrand. They also wanted to customise our Swedish translations themselves.

And everyone wants the source files in Word. Microsoft Word is the common tool between us all.

Signing a contractual agreement

Sharing source files with third party companies — whether receiving source files from OEMs or handing over source files to external customers for example — means that as writers we should be aware of the legal implications. Obviously we shouldn’t blindly hand over source files whenever an external customer requests it.

There must be a contractual agreement drawn up between two companies and one of the items covered will be document customization. This agreement will state whether your company will do the customization in-house or if the source files are to be handed over to customers for them to modify the documents under their responsibility.

Handing over source files to customers

Before handing over source files to a customer, you need to ensure that:

  • Your company branding has been removed—Your company branding must be removed such as company logos, propriety fonts, and any company branding colours. Proprietary fonts, or example, could be changed to a general font such as Arial.
  • The copyright statement has been removed—Unmodified manuals used by customers remain the property of your company. However, if any changes to the contents of the manual are made—including simply replacing your company’s logo with that of the customer—you need to remove your company’s copyright statement from the manual and replace it with the customer’s copyright statement as they are now responsible for the content. The customer then also determines the legal front matter text to be used.
  • The customer has signed the legal agreement—Before handing over source files to a customer, the customer must sign a license and indemnity agreement drawn up by your legal department. Normally it’s the product manager iwho’s responsible for ensuring that the customer signs the agreement and for keeping the signed copy.

Customising third party documentation

The contractual agreement drawn up with the supplier, such as an OEM, will specify who is responsible for customizing the technical documentation and its maintenance. By customising the contents of the supplier’s documentation to meet your company’s requirements, your company then becomes responsible for the content and its maintenance.

You also need to consider regulatory requirements and how they impact the supplier documentation that you are customising. Products branded as your company’s products, or products imported by your company into a regional market such as the EU, must comply with the applicable regulatory requirements (such as European Union directives).

Under new ownership

There are going to be times when we have say goodbye to our work and wish it well under new ownership. Although as technical writers we can often be loath to handing over our source files to customers for fear of the impact on quality, exchanging information is part of doing business. Our work is part of business. We need to know what’s involved when handing over source files to third parties so that we and our companies don’t get any nasty surprises later on.

Open plan or cubicle?

by Jen O Neill

I’ve been reading up recently on agile environments. I don’t work in such an environment but have been struck at how often they discuss the importance of the office layout to encourage collaboration in a team. The preferred layout always cited is the open plan office.

The layout of the workplace does impact productivity. An open layout encourages communication between people. It’s a more dynamic place to work as it allows team members to interact more easily. The downside is it can be distracting if you need to concentrate. Cubicles encourage solo work, where less interaction is required. However, cubicles can discourage that cross-fertilisation of ideas and exchange of information that comes with close teamwork. Another disadvantage of cubicles is the potential risk, “Out of sight, out of mind”.

The culture of the workspace

There is also a cultural aspect to office layout to consider. Most Europeans work in open plan and most Americans work in cubicles. I’m not sure why this is. Which office layout you prefer may well depend on which you’re used to.

I’ve never worked in a cubicle. I’ve only worked in an individual office or in an open plan layout with up to six people. I’ve never worked in offices with large areas of open plan (+40 people).

Team benefits

In the agile environment you are located in your team. As my projects are determined by Product Management, I’m physically located with that team (I actually report to them). However, I don’t feel isolated from the other writers in the company, who are all located in other countries anyway. I’m in frequent contact with them by Instant Messenger and we chatter about tech comm. related topics and what work is like at our respective sites.

I’m an open plan person. I savour the opportunities to have ad hoc conversations with people, eavesdrop on the telephone conversations of the product managers around me and exchange ideas. I hear about customer evaluations as well as learn about the wider picture of product development and on doing business with suppliers (whose manuals I will be rewriting and with whom I will also be contact). I believe that this helps me collect a wide range of information to better focus the manuals I write and localise. I don’t want to work in a cubicle as I would find it isolating.

In my opinion, an open plan layout of, say, up to eight people is great for encouraging team collaboration. A larger team would probably need a careful review of the different types of workspaces that should be provided to balance team needs and solo work moments (for example a mix of individual desks, meeting desks, places for quiet work, hot desking…).

Coping with noise

Open plan can sometimes be distracting. There are four of us in the office and between us we have six mobile phones and four landline phones. We’ve reached a “gentleman’s agreement” not to use loud “amusing” dial tones on our mobile phones and to use the headsets provided for teleconferences (unless others are invited to listen in). If I really do need silence to concentrate when working on a project, I stay home that day and work from there.

Which layout do you prefer to help you do your work: Open plan or cubicle? What different types of office layout have you work in and which have helped you feel part of a team?