What’s new in MadCap Flare 10, the nitty gritty

Flare 10, the annual major release of MadCap’s flagship Help Authoring Tool, includes several major enhancements that make Flare easier and faster to newcomers and editors of marketing content. And many smaller enhancements target the hardcore techcomm heavy users. The well-balanced improvements testify that MadCap listens to many of its users.

Today, I’ll focus on the enhancements that I enjoy most – many of them are smaller improvements for heavy-duty tech comm users with large projects and many topics. (An earlier post covered the more obvious strategic enhancements.)

• Improved build times are probably the most crucial enhancement for us. We have some crazy large projects, and we’re happy to see that build times for web help and PDF alike decreased on average by 10 to 30%. Apparently, Flare 10′s re-engineered build process causes more read/write operations. That means a fast hard-disk drive with, say, 7200 RPM or a solid state disk help you to really benefit from the improvements. (If you don’t know your RPM speed, find your HDD model ID in Windows’ Device Manager, search the web for that ID and you’ll find the RPM speed as well.)
• Robustness is improved with a Crash Reporting System. Given our large projects, Flare could be really slow at times and occasionally crash. I don’t recall ever losing any data, but it was still unnerving to see Flare disappear suddenly. I like that Flare 10 has better exception handling and captures a lot of run-time errors with an error dialogue.
• Customised project export allows you to tailor the content you share with other writers, translators or MadCap support. You can export projects not just as a whole, but also by selecting a target, a set of conditions or even file tag settings. For example, you can select a target and export that (along with the target’s conditions applied) to your translator. I use file tags to track topic status and translation language – and I like that I can export complete, stand-alone projects which contain only the relevant topics.
• Customised review packages benefit from the same restrictions, and we can select a target or apply conditions to collect only relevant topics. Oh, and topics in a review package now automatically bring along the snippets the link to which is a nice, intuitive touch.
• A Find and Replace widget in the XML Editor lets me find expressions in the active topic much faster.

• Drag-and-drop for conditions and variables makes it easier to select these elements which are now listed individually in the Project Organizer window and drop them into topics where I need them.
• Apply conditions in the XML Editor. I have several “dimensions” of conditions, such as print vs. online and version A vs. B. And sometimes, I lose track whether I have all scenarios covered. This new feature makes it easier and faster to see when I have content missing for “print + version B”, for example.

• File navigation improvements benefits especially users who have a lot of topics and a lot of topic reuse.
• Find and Replace in Files has been revamped to offer more options for tailored results. You can now search:
  • In the whole project which now includes files in the Project Organizer.
  • In any given folder.
  • In files by name, for example, you can search *.flsnp for all snippet files or t*.* for all task files, if you adhere to such a file convention.
  • For whole words which omits partial matches in longer words.

  You can now also save search results in a CSV file which is helpful if you need to work on results over a longer time.
  Note that Replace All has become less transparent! Previously, this function would open all files with matches, apply the replace, mark them with the “edited” asterisk and save them. In Flare 10, Replace in All Files will silently replace matches in all files currently not open. This is much faster, but there’s no asterisk, no undo, and you don’t even see the replace.

• Word count reports per topic and project. Many of my topics get translated, and our translators need to know how much I’ll send their way. With the new word count reports, I can give them an indicative estimate a few days before I finalise my work and send it off. The Report Editor in Flare 10 now has a Content Files > File Word Count report that counts each file in the Content Explorer, whether it’s an actual topic or a snippet or a template:

There’s also the Project > Statistics report which counts all words in a project – which is especially useful in connection with the customised project export mentioned above.

• Locate in TOC has gotten better. This function finds the selected topic in a table of contents. I use this a lot as I switch back and forth between the back-end topic structure in the Content Explorer window and the users’ view in the table of contents. I can now right-click a topic in the Content Explorer and go straight to Locate in TOC without going through the XML Editor or the Link Viewer. This makes my navigation even faster.
• File preview data at the bottom of the File List, Project Organizer and Content Explorer windows shows details of the selected file. First are the file name, which is redundant, and file type, which I usually know, so that is not very useful yet. The second column shows Date modified which can be helpful. But with long-ish file names, I never see the second column in the narrow, docked windows. So this is a good idea with questionable results. I’m also worried that it will slow down navigation in folders with lots of files, but I have no proof for this.
• Searching in source code now gives faster access to the topic in the XML Editor thanks to an added button.

For more information, consult these MadCap resources:

• The product web page
• The 8-minute video where Deadheads can try to spot a favorite piece of Grateful Dead stage banter in one of the sample screens…
• The 300+ page What’s New Guide in PDF
• The list of customer-reported issues that were addressed, from MadCap’s knowledge base
• The Flare 10 system requirements from MadCap’s knowledge base

What do you think are the most impressive enhancements in Flare 10? And where have they come up short?

Advertisement

What’s new in MadCap Flare 10, the hip parts

Flare 10, the annual major release of MadCap’s flagship Help Authoring Tool, includes several major enhancements that make Flare easier and faster to newcomers and editors of marketing content. And many smaller enhancements target the hardcore techcomm heavy users. The well-balanced improvements testify that MadCap listens to many of its users.

Today, I’ll focus on the more obvious strategic enhancements. A second post covers the enhancements that I enjoy most – many of them are smaller improvements for heavy-duty tech comm users with large projects and many topics.

Out with the geek

Many major changes aim to make Flare more attractive and easier. For the longest time, Flare carried the reputation (some say: stigma) of a steep learning curve. Flare 10 goes a long way towards flattening that curve to help you get going faster. In a way, it means Flare has been de-geekified – and I’m sad to say that the nicely geeky propeller hat logo went into hiding as well.

• The new Start Page offers new output templates as soon as you open Flare to get you started:

The new templates mainly support the recent trend of merging technical and marketing communications. They offer formats such as product brochures from 3- to 6-fold layouts and slideshows. I rarely create new projects from scratch, so this isn’t for me. I mainly need the Start Page to re-open previous projects which I can still do.

• Support of desktop publishing is probably better than ever, thanks to the improved page layout editor and the new support of Open Type fonts. Encroaching on desktop publishing products such as InDesign by rival Adobe, Flare has some strong arguments with its ability to reuse content in tech and mar comm. Since I don’t use DTP products and don’t create mar comm, I cannot judge how convincing Flare ultimately is in this arena.

In with the hip

Two enhancements in online output benefit tech comm and mar comm alike.

• Slideshows present a gallery with horizontal page-by-page navigation as opposed to vertical scrolling:

Slideshow pages can show images, videos, workflow stages, etc., along with descriptive captions and auto-play support. Thumbnails or bullets aid navigation. I really like the slideshows and expect to use them mainly to illustrate or guide users through multi-step workflows. I can also imagine drilling down from a process overview to the individual stages on slideshow pages.

• Responsive HTML 5 output ensures that output resizes automatically to fit mobile and tablet devices, see above. We had entertained the idea of creating separate EPUB targets for tablets, but the flexible responsive HTML5 output is of course much more convenient. It’s another good reason for us to move to HTML5 soon.

For more information, consult these MadCap resources:

• The product web page
• The 8-minute video where Deadheads can try to spot a favorite piece of Grateful Dead stage banter in one of the sample screens…
• The 300+ page What’s New Guide in PDF
• The list of customer-reported issues that were addressed, from MadCap’s knowledge base
• The Flare 10 system requirements from MadCap’s knowledge base

What do you think are the most impressive enhancements in Flare 10? And where have they come up short?

Top 4 reasons that make MadWorld 2014 unique

Four unique reasons make MadWorld 2014 possibly the best tech comm conference you can attend this year. (Disclosure: I’m a happy MadCap Flare user and will speak at MadWorld 2014.)

MadCap’s second annual user conference takes place in the Hard Rock Hotel in San Diego, CA, on 13-15 April. It’s featuring not just MadCap’s technical authoring products, but tool-agnostic sessions on DITA, content strategy, professional development, and more. But I think you’ll get the most out of it if you are already using MadCap products or at least very close to doing so. If you are, here are my top 4 reasons that will make MadWorld uniquely useful.

1. Immediately applicable insights

Whether you are relatively new to MadCap or a veteran user, you can pick up helpful tips and relevant advice in sessions “Yeah, Flare Can Do That” and “Ride the Lightning (Talk)”. If you’re stumped for tactical or strategic decisions, you’ll find answers in “Going Solo: Best Practices for the Solo (Flare) Artist” and “We Built This City: Building a Scalable Architecture for a Flare Project”.

Because you know the tools and MadCap knows our tasks, MadWorld eliminates one of the most common complaints of professional conferences: Not quite relevant content. Instead, you can probably find an insight to apply back home in every session. No more “What happens in Vegas, stays in Vegas”! Plus, it’s San Diego.

2. Community networking and support

At MadWorld, you can plug in directly to MadCap’s dedicated and supportive community of users. Many of us folks who help each other on MadCap’s user forum or on LinkedIn will be there. Recently, regional user groups have sprung up in North America and even Europe as MadCap users realise the benefit of a more personal network.

You can hook up with other users to discover what they do with Flare and what ways they’ve found to tweak Flare. That includes the speakers who are regular users, too. Meet them over at MadCap’s blog where they share their expectations and their favorite three songs. I’m looking forward to meeting everyone and to share my experiences – and favorite songs!

3. Prime support included

MadWorld offers personal support from all the guys and gals we might otherwise just know from support emails. I’ve met MadCap staff at other conferences and found them incredibly helpful. They answered any question I threw at them. It felt like free, unlimited access to the proverbial soda fountain. MadWorld’s Hospitality Lounge by comparison is like an open door to the soda factory. I for one plan to bring a couple of crazy projects and indulge… 🙂

4. San Diego in the springtime

Yes, it’s been snowing and raining a lot and in unexpected places, too. But not in San Diego. Not for a looong time, as Jennifer from MadCap reminds us:

The last snow in SD was on 12/13/67! RT@ellispratt Something I thought I'd never ask:Will it be snowing in San Diego in April? #Madworld2014

— Jennifer White (@MsJennWhite) February 14, 2014

So I expect spring to be in full swing by the time we get there. Add to that the Hard Rock Hotel in the Gaslamp Quarter, the world-famous zoo and the beaches, and I start to sound like a tourist ad.

————————–

To sum up, I look forward to MadWorld, a conference with boot camp intensity and summer camp fun!

P.S. I will speak in the tool-agnostic track on cognitive foundations of tech comm:

• You’d Better Recognize! Pattern Recognition For Technical Communicators, on Mon, 14 April, 11:05 am
• Addicted to Meaning: Mental Models for Technical Communicators, on Tue, 15 April, 1:30 pm

And I’ll be on board for the round of lightning talks on Tuesday at 10:55.

Update, 10 March: techwhirl lists 5 Reasons to Attend MadWorld 2014, citing a total of 61 pieces of evidence!

Running lightning talks or Pecha Kucha

Lightning talks (or their siblings Pecha Kucha and Ignite talks) can be great fun. They’re basically presentation karaoke: You avoid death by PowerPoint – instead you get the occasional train wreck when the slides get away from the presenter. But usually, the giddiness of information overload in 5 to 7 minutes is very stimulating!

It just takes a little planning to make sure there’s room for the spontaneous energy to emerge. Here’s what makes lightning talks succeed, in my experience:

• Stick to the timeframe. For example, every speaker gets exactly 5 minutes to show exactly 20 slides where each slide is automated and timed for exactly 15 seconds. (Pecha Kucha uses 20 seconds each.) Now, this sounds a bit counter-intuitive to squeeze hi-energy lightning talkers into a tight format, but scrupulously sticking to it is essential to keep up the energy for the audience. Speakers don’t get to control the slides – which is the imminent danger and spice of every lightning talk! 🙂
• Figure in a bit of overhead time to explain the concept to the audience and to move from one speaker to the next. So for a 45-minute session, plan 6 talks or 7 at most.
• Have an MC facilitate the session. He or she explains the format, hands over between speakers and leads the crowd in applause, cheering, jeering, whatever seems appropriate.
• Curate the content, if necessary. Not every topic lends itself well to the restrictions of a lightning talk. Case studies and project stories of limited complexity usually work very well, as do Top 20 lists.
• Go for lightning flashes of insight, not totall recall. In my experience, the audience can expect to remember 2 or 3 talks of 7 – and maybe 4 or 5 points that really struck them.
• Lean on presenters. The one danger of a lightning talk buzzkill is speakers playing it too safe. Their slides look fine, but they only prepare one or two sentences per slide. They manage to deliver that sentence – and then wait 12 seconds for the slide to change. Sitting through that is quite lame for the last 15 slides… It’s difficult to avoid, but it’s more fun for everybody if speakers come with a tightly packed presentation – even if they stumble and then play catch up with the timer… Maybe encourage speakers to max out their topic and wring every last second from it, as if it was the last 5 minutes they ever had to share their enthusiasm.
• Select a good sequence of talks. This is also a bit difficult to plan, but in general it works best to have speakers with less energy and slides with less “wow” go first and then work up to higher levels of energy and “wow”.
• Demand the presos before hand. You need them to figure out the sequence and put them all on the same machine, so you can minimise the time between speakers. Some events publish the sequence before hand, others just announce it at the beginning of the session.
• It’s not a contest. At least I don’t recall any lightning talk round scoring or voting for a winner. Instead, the Olympic sprit rules: “The important thing is not to win, but to take part”. They are more like a show-and-tell in school or like a sing-song round in a bar: Many people take turns, but everybody who contributes is cheered on, if only for valiant efforts.

What’s in a tech comm blog? Top 10 posts from 4 years

For tech comm, blogs are a great medium to develop our profession, but also to archive knowledge and discussions.

I started Kai’s Tech Writing Blog 4 years ago, with a little fanfare:

Welcome to my new blog, yay! You’ll find my insights and experiences about software documentation here, what I’ve found to work and what didn’t. And some occasional wackiness.

Since 2010, the tech comm blogosphere (and blogs in general it seems) have been on a steadily declining slope. I think there are different reasons why tech comm blogs fade away:

• Some writers move on into other fields.
• Some find they have nothing more to say.
• Some stay in tech comm, but shift their priorities when the demands and responsibilities of their jobs increase.
• Some change their social media habits as they find twitter, Google+, LinkedIn or other services useful.

But the content in tech comm blogs is often still very useful, valuable and worth considering:

• When a question on methods or strategy pops up at the office or at conferences or webinars, I refer to “old” posts and often find them applicable, maybe after a little brushing up
• Old and recent posts on my own blog get a steady stream of readers as my stats indicate. There’s definitely a “long tail” over time to blog posts which proves their lasting value, if to niche audience. (There’s actually a short section on networks and crowds in the long tail on Wikipedia.)

See for yourself. Whether you’ve been reading my blog for a while or just found it a few weeks or months ago, here are 10 posts from the past which I still find useful:

1. Top 10 things that users want to do in a help system

Because a help system is like a library or a department store in a lot of ways.

2. 5 steps from legacy documentation to topics

Because moving from unstructured to structured documentation and topic-based authoring needn’t be difficult.

3. The curse and the cure for the ornery topic

Because topic-based authoring imposes a structure that doesn’t always sem to work.

4. Improve documentation with quality metrics

Because quality metrics for technical communication are difficult, but necessary and effective.

5. Top 4 steps to solicit perfect documentation reviews

Because most of us rely on subject-matter experts who don’t always have reviewing our content as their top priority.

6. Editing

7. Indexing

Because most of us are not done after creating content and getting it reviewed, we often need to edit language and provide index key terms for print output. Here’s how, along with links to resources I’ve found useful.

8. Getting ahead as a lone writer

Because it can be rough being the only tech comm’er in your organisation. My presentation slides link back to some posts to show you how you can improve documentation and raise your profile by adopting a few general management skills.

9. Ragged-right or justified alignment?

Because research is a better argument for your “alignment decision” than personal taste.

10. “The Creative Passion” guest post

This  is the one that started it all, my first post over at DMN Communications. It does show its age a bit, but it’s still the best piece if you want to know “where I’m coming from” and what makes me tick as a technical communicator.

Top 10 tech comm conferences in 2014

Several worthwhile conferences that are relevant for tech comm are scheduled for next year. Here are eight I know about. Help me to round out the Top 10 by suggesting missing ones via the comments! Thanks to everybody who suggested more conferences via comments and twitter!

20-21 Feb 14, Bangalore, IN – tcworld India 2014

26-28 Feb 14, San Jose, CA – Intelligent Content

3-6 Mar 14, Palm Springs, CA – Writers UA West

10-11 Mar 14, Budapest, HU – Write the Docs

13-15 Apr 14, San Diego, CA – MadWorld
I will present sessions on pattern recognition and mental models and a lightning talk.

05-06 May 14, Portland, OR – Write the Docs

18-21 May 14, Phoenix, AZ – STC Summit
I will show how to get From Unstructured Documentation to Structured Topics.

5-6 Jun 14, Kraków, PL – UA Europe

18-20 Jun 14, Gatwick, UK – Congility 2014

Summer? Cincinnati, OH – Open Help (no details for 2014 yet)

16-18 Sep 14, venue unknown, UK – TCUK (web site not yet available)

13–15 Oct 14, Portland, OR – Lavacon (web site not yet available)

11-13 Nov 14, Stuttgart, DE – tekom/tcworld (web site not yet available)

Top 4 layers for your tech comm strategy

To show and increase the value of tech comm in your organization requires focus and priorities. That’s especially difficult in times of too many conflicting demands and not enough resources.

But you can adapt tried-and-proven business principles and tools to keep your tech comm efforts on the rails and contribute to larger business goals.

The 4 strategic layers

A solid business strategy framework has four aligned layers:

• Higher layers have very few abstract elements which give lasting, big-picture orientation. Aligned means they give direction and help to define lower layers.
• Lower layers have many concrete elements which give specific instructions. Aligned means their execution contributes to achieving higher layers.

Yes, it takes some time to formulate the four layers – but I find it’s a good investment in your future: You can decide and defend what tasks you prioritize and how you do them. And you can show how tech comm add value to the organisation as a whole.

Now let’s take a look at the elements of the four layers.

The mission (statement)

The mission is the organisation’s reason for being put into practice. The mission takes several years to accomplish, and it should not be changed or abandoned lightly. The mission is guided by a vision for a future goal.

The mission statement is defined as “a written declaration of an organisation’s core purpose and focus that normally remains unchanged over time.” The mission statement is one or two sentences that fit on a t-shirt which the people behind it can be proud to wear.

In the mission statement, the organisation explicitly or implicitly answers four questions:

1. Why are we here? What is the unique purpose we serve, the value we provide?
2. What do we do? What products and services do we offer to provide that value?
3. Who do we do it for? Who are our markets and audience?
4. How do we do it? What principles and values guide our efforts?

For example, IKEA says: Our mission is to offer “a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.”

For more about mission statements for tech comm, see my earlier post Why you need a tech comm mission statement.

The vision

The vision is the organisation’s goal several years in the future. It answers the question where the organisation wants to go. It can motivate the people behind it to get out of bed in the morning. It guides the organisation’s mission through time. By pursuing the vision, the organisation can accomplish its mission and fulfill its purpose.

For example, IKEA says: “Our vision is to create a better everyday life for the many people.”

Strategic goals

Strategic goals describe self-contained efforts that have a distinct, measurable effect on the organisation’s business success. When reaching a strategic goal, the organisation usually can:

• Offer more efficient or effective products and services
• Translate the improvement directly into a customer benefit

Strategic goals are major advances towards accomplishing the mission. They take around a year to reach, or even longer.

Tactical initiatives

Tactical initiatives are measurable milestones or contributions to a strategic goal. They often take weeks or months to execute.

Operational tasks

Operational tasks are individual steps in tactical initiatives. They take days or weeks to finish. Policies and procedures, guidelines and standards guide the execution of tasks.

Paul Perrotta on change management at tekom/tcworld

Content management/strategy and the business of tech comm were my two focus areas during the tekom/tcworld conference in Wiesbaden, Germany, last week, and I will summarise some of the sessions I attended in several blog posts.

(For a general overview of what tekom is like, refer back to How German is tekom and tcworld? UK tech comm consultant Ellis Pratt and I have been commissioned to sum up this year’s event for an upcoming issue of ISTC’s Communicator magazine.)

Paul Perrotta on change management

Paul Perrotta from Juniper Networks offered two sessions on change management in tech comm. He reported on his unit’s journey from siloed, bickering, intransparent groups to a more efficient Information Experience (iX) organization.

Part of the problem is that we in tech comm are often pretty bad at saying what we do and what value we provide to the company and to customers. Instead, “docs happen” frequently in a black box. If you measure how well-regarded each unit is by their budget increases, a black box is not a good place to be in, because it won’t get you better funding. Executives don’t know (and don’t need to know) how tech comm works. But they need to know whether it’s successful and how it helps them be successful. And whether 8 dollars spent on it will increase their bottom line by 10.

So make tech comm more business-like and make managers’ worries your own: How can we increase customer satisfaction? How can we contribute to increase market share? Address these challenges to show the value tech comm contributes and how you can help the business to deflect some of the threats, such as:

• Doing more (work) with less (resources).
• Deferring costs to a less certain future.
• Offshoring tech comm.

Here’s what you can do specifically:

• Define a vision and mission for tech comm to clarify what they do – and what they don’t do. (See also “Why you need a tech comm mission statement“.)
• Make improvements manageable by chunking them up into strategic initiatives.
• Dissolve the documentation siloes by architecting and governing all content as a whole.
• Improve content to make it complete, searchable and findable.
• Connecting tech comm with marketing, sales and support to contribute to and benefit from the same content.
• Rebrand tech comm as information experience to emphasize its contribution to the customers’ experience.
• Focus on users and engage with them, for example, via user satisfaction surveys, feedback, social media.
• Install an iX customer advisory board which meets regularly.
• Seek out managers with the power and money to help you and map out your allies throughout the organization.
• Make tech comm measurable and operationally efficient:
  • Link tech comm to development metrics where possible.
  • With proven competence, you can aim for 5% of R&D spend which is industry best practice in IT.
  • Ask how much of the product price tags the documentation is worth.
  • Show what (else) you could do with X more money.

Some of the results that Paul found:

• Many customers are happy to offer feedback if they find they get heard, and tech comm improves as a result.
• An ongoing discussion with users builds trust and customer loyalty.
• Commonly governed content becomes more reliable and more easily findable for employees and customers alike.
• Managers will support you because your success is their success of you demonstrate competence and that it’s easy for them to help you.
• If you map your projects to executives’ objectives, you can clarify what you can and cannot do with available resources.
• Achievements require focus to reap their full benefits – and then advertisements to make sure executives realize that you can work like a business…
• To measure their achievements, tech comm quality metrics are not enough; you need customer engagement/experience metrics as well.
• As a side effect, you will have to abandon an implicit ethos that treats tech comm as special, as an art that creates books.

How German is tekom and tcworld?

The world largest tech comm conference and trade show is a really a bilingual affair with two separate names. Follow me as I untangle the differences in reply to Alan Pringle’s request “Help this first-time tcworld attendee, please!” over on Scriptorium’s blog.

tekom, the conference of the German association of technical communicators of the same name, takes place every year in Wiesbaden. What goes by the shorthand name of tekom is really three separate events in the same place over three days.

There is tekom, the German-speaking conference which had 150 presentations, workshops and tutorials. (All numbers are from last year’s event.) Then there is tcworld, the English-speaking variant with another 74 sessions. About 2,400 delegates attend sessions in both languages. While session topics sometimes overlap, the same session is hardly ever offered in both languages.

The two names sometimes lead to confusion, for example, on twitter when it comes to the appropriate hashtag. The official recommendation is to use #tekom for the event and content in German and #tcworld in English.

The third event is the trade fair where you can meet 200 exhibitors who range from tool vendors, via  documentation and language service providers, to professional associations such as the STC. The trade fair is in the same venue and open to all conference delegates. It also draws an additional 1,300 visitors at a nominal entrance fee of €20, though many take advantage of vouchers that offer free admission.

Multilingual diversity

At the size it is, tekom is a unique event with logistical challenges of its own: You pretty much need to map out your schedule beforehand, lest you miss a session or vendor. Because tekom takes place at a convention centre, not at a conference hotel, you also need to plan your waterhole activities. There is no bar and not much of a lobby where you can simply hang around and meet people. Judging from after-hours tweets, though, it seems that many of the English-speaking crowd stay at the same hotel or two.

Among the rewards for hardy delegates is a unique variety of topics and delegates. Session streams include mainstays, such as professional writing, content strategies and user assistance, but also related areas, such as content management, parts catalogues and localization. tekom underscores its commitment to higher education and to graduates, with streams dedicated to young technical communicators as well as to academia and science.

Two traditions of professional presentations clash at tekom, and many sessions fall quite squarely into one of the two camps, regardless of the language they use. ‘Anglo’ presentations are sometimes heavier on business aspects, while ‘Germanic’ presentations tend to focus on technical or process details. As a result, some presentations feel a little stiffer than at conferences in the US or England, especially if the presenter is not a native speaker. But usually, there’s good substance, regardless of the language and delivery.

Just as with TCUK and the STC Summit, the largest group of delegates comes from the host country, followed by neighbouring countries. tekom especially attracts many delegates and exhibitors from Eastern Europe.

While you will get the most from tekom if you speak both English and German, you still get a full conference experience in English. There are two to four presentations and two or three workshops and tutorials in any one slot, offering five to six complete streams in English.

Making the most of tekom

My advice is to plan ahead:

• Make and update your schedule to avoid missing out on your personal ‘must-see’ sessions and workshops.
• Schedule free time to visit the trade fair, to wander the halls, to run into acquaintances and meet new people.
• Bring business cards. I find I am using many more than at conferences in the UK or the US.

Wiesbaden is very conveniently located with direct commuter trains that reach Frankfurt airport in 40 minutes.

There are lots of interesting sites in close proximity: Mainz with its cathedral and the Gutenberg Museum (always a winner with the bookish crowd) is just across the river. The picturesque part of the Rhine with vineyards and medieval castles starts just a little downstream.

Note that 2013 will be the last year that tekom is held in Wiesbaden. The convention centre will be torn down in the summer of 2014. tekom14 will be held in Stuttgart.

This post is an abbreviated, slightly amended version of “How German is it?” which appeared first in ISTC’s Communicator magazine, Spring 2013, pp. 7-8.

2nd day of sessions at TCUK 13

The business and managing of tech comm was the predominant topic of my TCUK13 experience, as I reflect some more on the sessions I attended and the conversations I joined.

A. Westfold on collaborative authoring in DITA

Andrew presented a case study of McAfee over several years, from separate product teams and “artisanal”  lone writers to a larger, unified team of writers collaborating in DITA. During this time, McAfee also grew by acquisitions which meant that additional writers, methods and tools came on board. Here are the most essential stages of their journey:

1. Improve several individual procedures for quick wins: Single sourcing reduced translation efforts. Automating the translation round-trip cut out costly manual layout efforts.
2. Move to topic-based authoring: They chunked up content into topics and moved them into DITA to validate the topic structure. (It turned out that many task topics could not be automated and essentially had to be rewritten in valid structure.)
3. Bring in a content management system to reap the full benefit from single sourcing and topic-based authoring. This helped to reduce the number of redundant topics and to make localization even more efficient.

While their journey is far from finished, McAfee has realized the following benefits so far:

• Easier administration of topics than of larger content chunks before. It’s also easier to solicit reviews for smaller stand-alone chunks.
• Faster, more consistent creation of deliverables for several product variants thanks to better use of standard templates.
• Documentation processes align well with recently introduced agile development processes.
• More efficient, streamlined workflow thanks to better integration between documentation and localization.

I really enjoyed Andrew’s presentation. It showed that projects to improve tech comm do work out, even if you don’t always see past the next stage, and you may have to adopt due to other changes in the company.

A. Warman on “Managing accessible mobile content”

Adrian Warman from IBM hooked up two important tech comm issues, accessibility and documentation for mobile, into a survey session.

Accessibility makes it easier for everyone to fit in, participate and contribute, irrespective of disabilities. In short, it ensures that a user’s disability does not mean a personal disadvantage. For tech comm, this means that sufficient documentation is accessible. For example, if your online help in HTML is accessible, it’s not necessary to make the same contents in PDF accessible as well – or vice versa, as the case may be. Adrian advised us to keep an eye on “EU mandate M 376” which may soon make some level of accessibility mandatory for products traded within the EU.

Mobile (smartphones and tablets) for tech comm means not just a technology, but an expectation, a mindset. It’s more than simply fitting our output onto smaller screens. Its different dimensions of interactivity, such as progressive disclosure and user-generated content, challenges us tech writers to re-think how to best convey an idea. Which is the best taxonomy that supports both, mobile devices and accessibility?

I don’t think there was a lot of new, revolutionary content here, but since I haven’t dealt much with either topic so far, it was a welcome introduction that was concise and well presented.

E. Smyda-Homa on useless assistance

Edward reported on his twitter project @uselessassist where he “Retweets to remind organizations of the frustration and negative emotions that result from poorly prepared assistance.” He presented many examples of poor user assistance. Some people complained about insufficient instructions, whether they had not enough images or only images. Some found the instructions too long (“I know how to prepare toast!”) or too short or redundant. Some pointed out typos or bad translations.

This was a very entertaining session – and you can easily get the gist of it by simply looking up the account or following the twitter feed. It’s anecdotal evidence in real-time that users actually do read the manual – or at least try to.

While every tweet is heartfelt, I think not every one merits a change in the documentation – if only because some are contradicting each other. But I find Edward’s project very enlightening and nodded to myself in embarrassed recognition a couple of times…

– Feel free to leave comments about any of the sessions, whether you have attended them or not.