Twitter feed

Archive

Adobe Seminar: everyone is welcome

Adobe and Sabern are organizing a short half-day seminar at the Adobe Amsterdam office. The details are provided below and everyone is welcome to attend. FREE sign-up.

What: Seminar on “Document-, Database- and Tablet Publishing, and Web to Print”

When: Thursday 27th September 2012, 10AM – 1PM

Where: Office Adobe, Hoogoorddreef 54A, Amsterdam Z.O., Nederland

Topics that will be covered:

  • FrameMaker version 11 and Technical Communication Suite version 4.
  • BookDB Database Publishing software for the computerized layout of structured documents like: catalogues, price lists, brochures and manuals
  • Different demonstrations of Adobe InDesign and FrameMaker in database publishing.
  • DesignDB web to print software for corporate design and online layout
  • Tablet Publishing for export to smartphones and tablets.
  • Adobe Acrobat for document exchange and export.

Sign up here: http://www.sabern.com/index.htm?show=formulier2.htm

Best wishes,

Team TechComm @ Adobe

 

Posted in Technical Documentation | Comments Off

Blog plan

Hi All,

Firstly, our sincerest apologies for the lack of activity on this blog. We plan to consolidate it with our existing blog, but under a separate header for ease of navigation.

In the meanwhile, we hope you’ve heard about our recent launch of Adobe Technical Communication Suite 4 along with FrameMaker 11 and RoboHelp 10. If not please read more here.

Best wishes,

Team TechComm @ Adobe

Posted in Technical Documentation | Comments Off

Visual Guides

In September 2011, Eeva Viljanen attended her first-ever #TCUK conference. In the subsequent Winter 2011 edition of ISTC Communicator magazine, she summarised the conference and its sessions, providing a specific focus on the closing keynote session presented by IKEA on the importance of visual guides in documentation, which has been reproduced here under kind permission of both Eeva and the ISTC.

Eeva Viljanen is a board member of STVY, the Finnish Technical Communications Society. She is a self-employed Technical Writer and Translator, and a visiting lecturer at Tampere University, Finland.

LinkedIn: Eeva Viljanen

In the Forefront of Visual Guides by Eeva Viljanen

IKEA probably leaves no one untouched. This is the case also among technical communicators judging by the eager show of hands among the audience, when Jan Fredlund and Magnus Ohlsson asked about user experiences with IKEA instructions. Jan’s and Magnus’ talk The Ikea Concept: Global and ‘Textless’ Communication, a Pedagogical Challenge had indeed attracted a lot of interest.

Both Jan and Magnus have worked at IKEA since the 1980′s with illustrations, instructions and communications. The initial decision at IKEA to go with graphics rather than text came from the rapid global growth of the company and the host of languages to be translated. IKEA produces 400 assembly instructions per year. The motto is, of course: We do our work, and you do yours, and together we save money.

Jan’s and Magnus’s advice on graphics are simple, but they work. With an easy start the user is motivated. Listing the steps in accurate order is essential. Early succeess encourages the user to go on. If the object needs to be turned around during the process, show the object from different angles. That’s the way to do it! And by the way, if you were wondering about the exotic product names, they come from IKEA’s Scandinavian heritage; some which do not translate particularly well in the global market.

Special Resource

The ISTC have also granted permission for the reprint of its Special Supplement on Technical Illustrations, published in conjunction with the 2011 Winter edition of Communicator magazine. Featuring such distinguished writers as Douglas Newton (MISTC), Patrick Hofmann and Matt Pierce, this supplement covers iconography, meeting end-user expectations, speaking visually and drawing with pencil and paper.

ISTC Special Supplement on Technical Illustration

Notes: The Special Supplement is published by the ISTC, and Adobe has permission from the ISTC to distribute it. The Editor welcomes articles and letters for publication. Opinions expressed by contributors are not necessarily those of the ISTC. All articles are copyright and are the property of the authors, who have asserted their moral rights. For permission to reproduce an article, contact the author directly or through the Editor. All trademarks are the property of their registered owners. Advertisements are accepted on the understanding that they conform to the British Code of Advertising Practice. Acceptance of an advertisement does not imply that a product or service has the ISTC’s endorsement.

 

Posted in Technical Documentation, Technical Illustration | Tagged , , , , , , , , | Comments Off

Tips for TechComm Job Seekers in the Nordics Region

Guest blogger CJ Walker, Director of Firehead Ltd., a recruitment firm specialising in Web Content, Digital Strategy and Technical Communication across Europe, contributes this posting which provides tips for those seeking TechComm jobs in the Nordics regions.

Twitter: @FireheadLtd

The Nordics: Sweden, Denmark, Norway and Finland (I’m leaving out Iceland in this post) is a big and varied market for TechComm professionals. As a specialist recruiter in this area, Firehead sees a large demand for experienced English-speaking contractors in technical communications.

What are the Companies’ Profiles Like?

Firehead sees the highest demand for contractors from larger companies and international corporations. They usually bring them in for very specific domain knowledge and experience, in addition to their native language skills.

Which industries tend to use native-English speaking contractors?

  • Sweden – Software and Telecoms
  • Denmark – High-Tech with some Manufacturing
  • Norway – Oil
  • Finland – Telecoms

Sweden, for example, exports a fair amount of its products to the United States. As one English contractor put it: “Americans won’t get Swenglish – our emphasis is on documentation in clear American English.” However, many companies reported they don’t care if it’s UK or American English if they are not client-dependent; it just has to be consistent.

For this post, I got numbers from six employers that ranged from 15% to 70% native-English speaking requirements. It depends on a few general factors such as the size of the company. International corporations usually have English as the company language (for better or worse) for communication.

How do they break down by size?

  • Mid-sized companies, just past the start-up phase, often bring in contractors to set up doc systems once they reach the level of needing more sophisticated systems to track their doc cycles. These contracts tend to run just the length of the original brief and no more.
  • Smaller companies like someone who can speak with the SMES in their native language. Being bilingual is an obvious advantage.
  • Smaller companies will also try to use someone within the company (engineer, marketing, etc…) to do the job if they can. Then, when they get stuck…

Many UK contractors have expressed surprise by the very focused and specific nature of the role specifications in the Nordics. They do their homework about the information on a CV before they bring someone into their team; they want to know the experience and skills are a match before they begin. And they do check references.

What are the Profiles of the TechComm Contractors?

  • High technical knowledge, including industry-standard tools such as Adobe FrameMaker, Illustrator, and strong knowledge of doc systems and processes.
  • While you might not have to learn to speak the local language fluently, it really does help to be willing to try. The appreciation will pay for your efforts.
    A veteran Danish Technical Communicator told me: “I have worked with so many foreigners over the years and one trend is clear: All the lonesome wolves who come here and go to the pub once a week with their buddies, who don’t like to learn the language or commit in one way or the other, they keep cursing about the country and everything that’s Danish.  Some people move, others don’t.”

What Can You Expect from Working in the Nordics as an English TechComm Contractor?

  • You can count on a high level of professionalism and quality of infrastructure in the Nordics. They also offer a high level of autonomy compared to many other countries – there’s an expectation that you will get on with your work. In turn, they have demanding expectations of the contractor’s level of skill, knowledge and professionalism.
  • The cultures in these countries tend to emphasise “fairness” and have a consensus in their approach to hiring and moving ahead with project decisions. They tend to have a flat hierarchy compared to other European cultures.
  •  An experienced English Technical Communicator in Sweden told me: “Senior non-native English speaking technical communicators who work in English in the Nordics know what they don’t know regarding the language issues this brings up.”
  • The pay rates are roughly the same as the UK, but remember to take into account the costs of living abroad and Nordic taxes. You must register in your working country’s tax system after a grace period.  Pay rates are obviously higher in Norway, but as they are not part of the EU; you will need a visa to work there.

What Should you Have on Your CV to Create Interest from Nordic Companies?

While there is no Technical Author qualification as such in the Nordics, a contractor needs to have enough experience to fill the role expectations.  Some common experience and skills Nordic employers seek:

  • A science or engineering degree
  • Good writing samples (essential)
  • Domain knowledge in the client’s area
  • Industry-standard tools such as FrameMaker, Illustrator, Acrobat are baseline expectations. Hiring discussions are about what you can deliver, not what tools you know.
  • Many contractors said that a demonstrated ability to “reason” your case well and work well in committees are important skills to demonstrate on your CV.

You will usually be expected to meet with the technical team during the interview process to determine if you can communicate with them.

Ulrike Forsberg, a seasoned Danish Technical Communicator summed it up: “An engineering degree and my combination of languages, a track record with known corporations and nice work samples,” got her the job.

Posted in Career Opportunities, Technical Documentation | Tagged , , | 1 Comment

Why ReadSoft Chose to Publish AIRHelp

ReadSoft is headquartered in Helsingborg, Sweden. Jason Nichols is Technical Writer and Trainer at ReadSoft.

Twitter: @jasonanichols Web www.jasonanichols.net

Publishing to Adobe AIRHelp by Jason Nichols

A few years ago our Technical Communication team upgraded to Adobe’s Technical Communication Suite 2. One of the reasons why we decided to get TCS2 was the ability of RoboHelp 8 to output to Adobe AIR—at the time a brand new publishing platform. (And not just for technical documentation, but any application. TweetDeck is perhaps the most famous example.)

There are a few reasons why we publish to Adobe AIR, which I’d like to explain below.

Modern look and feel

Technical documents have moved a long way from the days of WinHelp and Compiled Help (CHM files). The first thing that strikes you when looking at AIRHelp is that it’s modern:

An Example of Adobe AIRHelp

An Example of Adobe AIRHelp

Documents that sell

Technical documents also market your organisation, in the same way a website does. An old website built on old technology with outdated colour schemes is going to have a negative effect on visitors. If I was a potential customer browsing the documentation, and it looked outdated, I would definitely think the company was old-school. I would lean more favourably toward the organisation that looked modern.

So this is a general tip for all you tech writers out there: Irrespective of what output(s) you produce, spend some time making it look cutting edge (at best) or up-to-date (at least).

Online/offline modes

AIRHelp can act as a web browser and display content not contained in the original AIR file, but rather content on a web server. Our content is updated continuously, between product releases. (This is because there is always so much to document!) A major product release may be the current one for a whole year, but fixes and service packs are always released in between. In this typical software release schedule, it obviously makes sense to be able to update and improve the documentation at the same time. Or, better, anytime!

We host our Help content on a web server as well, as HTML pages (also generated from RoboHelp). This week I updated several topics in a guide and added a few extra ones. I then generated the Help and published the new HTML output to the web server. And anyone with the AIRHelp installed and an Internet connection will see the new content without having to do anything.

The benefits for consultants

Being online though can sometimes be a luxury. Our consultants—those that perform installations and configuration—often don’t have Internet access when they are on a customer’s site. But they still need the documentation. So they take the AIRHelp with them on their laptops. When they come back to the office, the content can be updated.

This is a much better solution than PDFs. PDFs cannot be updated. They are static, passive. One of the big problems we had is that a lot of our consultants were walking around with documentation that was literally years old. They have heavy workloads and I can imagine they don’t have the time to check for new versions. But as a result we always had technical and support questions about various issues that they could not find the answer to in the documentation because it was an old version.

Whither printed documentation?

We’re really trying to push PDFs into the background and to get people to use AIRHelp and our HTML pages instead. It takes a lot of time to publish a document for print purposes. I mean, we use RoboHelp to generate Word documents and macros to apply final formatting and create the PDF. But a significant amount of time is taken with fixing small formatting issues. This is the nature of printed documentation—each page has to look right. And in our case (and not just for us) people rarely print out an entire guide. They just want to browse the contents and look for a particular piece of information.

Commenting function

AIRHelp gives readers the ability to add their own comments to a topic. We’ve used this for peer reviews. However, we use RoboHelp 8 and the ability to administer comments (view, edit, delete) is limited. I’ve heard this has been improved in RoboHelp 9 but I haven’t yet looked at it.

Conclusion

In summary, we use AIRHelp because of its modern look and feel, it’s ease to push out updates, and because it has an offline mode which is a must-have for our consultants.

To learn more about ReadSoft’s implementation of AIRHelp, read an interview with Jason.

Posted in AIRHelp, Technical Documentation | Tagged , , , , , , , , , , , , , , , , | Comments Off

Getting Started with Accessibility in Techcomms

Karen Mardahl, Technical Writer at G.R.A.S. Sound & Vibration, Denmark

Twitter: @kmdk Website: mardahl.dk

“Where do I start?” This is one of the first questions I hear when discussing accessibility for technical communicators. I shared my suggestions in an Adobe eSeminar with Tom Aldous, the Adobe Technical Communication Suite Product Evangelist. This article is a collection of the links from the eSeminar.

Read this article with the definition of disability from the World Health Organization in mind (WHO).

[WHO] acknowledges that every human being can experience a decrement in health and thereby experience some degree of disability. Disability is not something that only happens to a minority of humanity. The ICF thus ‘mainstreams’ the experience of disability and recognises it as a universal human experience.
- from the International Classification of Functioning, Disability and Health (ICF)

If disability is a universal human experience, why aren’t we all thinking accessibility in all our communication?

Start with your writing

Content is at the root of all we do, so that is a logical place to implement accessibility immediately. All it takes is plain language. Unfamiliar with the concept? The links, including Nordic resources, will explain it.

The Design To Read site is a good place to understand the value of the words you choose.

Plain language resources are

The EU has produced an excellent little booklet called How to Write Clearly in 23 languages! You can download a free PDF of the booklet from the“How to Write Clearly” page in the EU bookshop. In case that link changes over time, just search for the EU bookshop on the page for EU translations and drafting resources.

While we’re on the topic of the EU resources, note these EU resources on accessibility.

Next Up is Alt Text

The next easy-to-start step is alt text, or alternate text. This is text that is used “in place of” an image. You can see this text when a large image is loading on a webpage. If you can’t see, your screen reader reads it for you. So simple, and yet so many forget or ignore this step in writing content. I won’t explain more because the WebAIM page on alt text says it all. Memorize it!

Steve Faulkner of The Paciello Group is working on HTML5: Techniques for providing useful text alternatives. It is a valuable companion to the WebAIM article.

Accessible PDFs

Making accessible PDFs is a natural extension of the PDF work many technical communicators already do. Download my presentation on techcomms and inclusion from the TCUK 2010 conference to read the slide notes explaining this process. The notes include more useful references.

Captions and Transcripts

That presentation I just mentioned also contains information about adding captions and doing transcripts.

I cannot emphasize enough how important captions or transcripts are for truly including all members of your technical communication audience. The transcript for my own recent eSeminar with Adobe on accessibility and technical communication is not yet ready, but I will tweet the availability when it is.

Communities

Don’t feel lonely in your quest for knowledge. There are communities out there full of awesome helpfulness and knowledge. Sign up for the discussion list at WebAIM to start learning today! You can also start following this Twitter list of great accessibility resources. I started following many of these people when I opened the @stcaccess Twitter account in late 2008. I credit them for much of what I know today.

Education and Standards

Even though you can go far on your own, structured training can give you more focus.

The Accessibility for Web Writers series at 4 Syllables from Australia gives you the fastest education. It goes into depth about many of the issues I raise in this article and in the eSeminar.

My favourite recommendation is the book Just Ask: Integrating Accessibility Throughout Design by Shawn Lawton Henry. It’s available in print, too, but being freely available online makes the information truly accessible to all.

The newsletter from University of Minnesota in Duluth is an education unto itself. It’s one way to get digestible morsels each week on topics like typography, information architecture, usability, and of course, accessibility. It is maintained by @laura_carlson, an incredibly knowledgeable person worth following on Twitter.

Depending on your level of geek, try the Opera Web Standards Curriculum in association with Yahoo! Developer Network for structured training, or the Web Standards Project’s InterACT website. I have heard good reviews of the book they have produced.

Speaking of standards, you’ll need to know about the necessary standards from the W3C. They live at the Web Accessibility Initiative (WAI) site. If you work with software products, you must know the Web Content Accessibility Standards. Every writer should know the Authoring Tools Accessibility Guidelines. Throughout the WAI site, there are educational documents to help both writers and developers.

If you are working with the UK, you will want to investigate the Web Accessibility Code of Practice BS8878 for your business. It costs money, but some businesses may require it.

In connection with the BS8878 standards, Sandi Wassmer, a member of the UK’s eAccessibility Forum, wrote up 10 principles for guiding your work with accessibility.

  • Be equitable
  • Be flexible
  • Be simple and intuitive
  • Be perceptible
  • Be informative
  • Be preventative
  • Be tolerant
  • Be effortless
  • Be accommodating
  • Be consistent

Read the reasoning behind these points on the Copious website and .Net magazine’s article. Then, place these 10 principles somewhere as a daily reminder of what you want to achieve with your acccessible technical communication projects.

Words to Ponder

Learn more about the information I present here by watching the eSeminar – Accessibility in the World of Technical Communication.

I’ll leave you to think about this excellent statement that applies fully to technical communication.

When universal design processes fail to include, consult with, and listen to the people we are actually designing for, we also fail to design effectively.
– from Lisa Herrod

Posted in Uncategorized | Tagged , , , , , , , , , , , , , , , , , , , , , , | 1 Comment