Sarah Maddox's Blog, page 29

Engaging infographics at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

Michael Opsteegh is about to present a session called Planning and Creating Engaging Infographics. I’m delighted to be here, having survived the Atlanta Ghost Tour last night and just two hours’ sleep.

Introduction

Michael started by discussing the graph on the front page of the Wall Street Journal this morning. Like most of us, he looked at the chart but didn’t read the article. So the only information he got was from the infographic on the side of the page.

Infographics are a powerful way of making information accessible and showing the relationships between pieces of information. You can weave a story consisting of graphs, images and more.

This presentation will focus mostly on the presentation of data, rather than the maths. The focus is on planning and building charts, graphs and larger infographics.

Examples of infographics

We saw a number of examples, and Michael talked us through the plus and minus points.

Infographics can be very persuasive, and can convey a lot of information.A graph, for example, is easier to digest and remember than a lot of text.

Sometimes they are overused. As a result, some people don’t like them. Still, they’re overall very popular.

Infographics can also be fun. Michael showed us one based on a batman theme.

There’s also a lot of room for misrepresentation.

Uses other than selling products and services

You could use an infographic for your resume. A website called visualize.me will produce an infographic based on your LinkedIn profile. But Michael recommends that you do the infographic yourself, rather than ending up with one based on a template.

There’s an infographic showing the wealth gap in America. It incorporates videos and charts, showing what people think the income difference is versus the actual situation. Unfortunately, it’s not easy to see who created the infographic. If someone isn’t prepared to acknowledge they created an infographic, then it may be difficult to trust it.

Skills required to create infographics

The creation of an infographic involves several disciplines. Michael has combined them into three areas:

Liberal arts: Your infographic needs to tell a story, and it needs to be interesting. Companies are looking more and more to creative people to differentiate their products and services.
Social sciences: You need some knowledge of human behaviour and cognitive sciences. How your infographic will be received and how to convey the information.
Mathematics. You need to recognise if you’ve misrepresented your data, and understand the basics.

What about graphic design? If you have the skills, that’s great. Otherwise, hire someone to do the design. You give them the information and the specification for what the chart should look like.

Tools

You need to be able to record your thoughts and ideas, and also questions you have. Michael finds Evernote very useful, because he can jot down notes wherever he is. Evernote syncs the notes from his phone, tablet, PC. You can also include photos, links, videos.

Excel is ubiquitous and powerful. Use it to sort your data and produce preliminary graphs, to help see what your information will look like. Use pivot tables to sort and filter data. Michael demonstrated how you can drill down into data via pivot tables, then generate a graph.

Illustrator or PhotoShop are useful, if you are going to design your own infographic. Michael recommends Illustrator, because it’s great for vector tools and also includes a graph tool.

Visualising data

Bar charts, which can be vertical or horizontal. These are good for comparing figures side by side.

Pie charts are OK for representing data as a whole, and the different percentages within them. But research shows that people aren’t capable of seeing the distinctions well. A doughnut chart is just like a pie chart, with the centre missing. This is even less useful than a pie chart, because you lose the angles at the centre. Bar charts are usually better.

Scatter charts are good for finding patterns in the data.

Line graphs are a little like scatter charts, except that you’re dropping the points at regular intervals.

An area chart is basically a line graph filled in. Good for demonstrating changes over time. The Wall Street Journal chart this morning is an example.

Venn diagrams show relationships between discrete objects. The overlap shows the shared parts.

Flow charts (pedigree charts) show hierarchy or workflows.

Pictograms or iconographs show set numbers. Michael showed a page with a number of figures of people. Each figure might represent 1 million, for example.

There are many other types, like radial charts and maps. See the Wall Street Journal’s guide to designing infographics. Also the Napkin Sketch Workbook by Don Moyer.

Research

This is a critical stage. You need reliable and accurate data before you can move forward.

Identify your sources: must be current, reliable, non-biased.

Get permission to use the data. If a company conducted the research, for example.

Editing

This is where you decide what story you’re going to tell, and how you will tell it. Be aware, as you’re editing, that people will call you out if they find an anomaly or if they want to view it in a different way. So, play with different ways of viewing the data. See if there’s another way to tell your story.

Look for outliers in your data, and see how they affect the message.

What about rounding your numbers? Make sure you round at the end, after you’ve plotted the data. If you do it before, it will skew the graph.

If you’re going to place charts side by side, make sure you’re not comparing apples and pears. Make sure you’re using the right figures to illustrate a point. For bar charts, always start the axis at zero. For other graphs, if you need to start elsewhere make it very clear.

If you’re missing data, you may still be able to create the infographic. If you’re missing more than 2 points out of 10, then your infographic will not be reliable. Look at the data that’s missing and decide if it affects the perception of your story.

Plotting

This is the most fun part. The point where you actually draw the infographic.

Make sure you’re staying true to the data. Remain aware of the maths involved.

If you’re plotting several graphs for the same infographic, you’ll need to wireframe them. A wireframe is basically a set of boxes or circles (in Illustrator) to represent where the bits of data will go. The advantage is that you can move the sections around, before actually drawing them. Look at where the infographic will appear, to decide whether it needs to be tall and thin, or wide and short. Make sure your dimensions are correct.

Reviewing

Make sure your infographic visually represents the data that it ought to. Get a couple of colleagues to take a look and give you feedback. Ask them if there’s anything that worries them.

Ethical considerations

Throughout the process, make sure you don’t misrepresent the data.

Remember: Correlation is not causation. Michael showed us to line graphs that could show that ice cream consumption leads to murder.

Make sure the story you are trying to tell needs telling, and that it will benefit the audience.

Accessibility

There was a lively discussion around accessibility. Michael recommends you put a textual description on the page, near the infographic. An alternative is the new “longdesc” attribute. Don’t use the “alt” attribute, as it’s intended for a short description.

Thanks Michael

Thank you for an informative introduction to infographics. I’m keen to get my hands dirty creating one!

Doc sprints at STC Summit 2013 – the presentation

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

Today is was my turn to stand up on stage, knees quaking, watching people enter the room, and hoping what I had to say would be useful to them.

Overview

My presentation is called Doc Sprints: The Ultimate in Collaborative Document Development. It focuses on planning and running a doc sprint, and how doc sprints are useful in developing the documentation our readers need.

It also includes a number of stories and tips, gleaned from doc sprinters around the world. Thanks to Anne Gentle, Swapnil Ogale, Ellis Pratt, Katya Stepalina, Andreas Spall, Jay Meissner, and Peter Lubbers, for contributing their ideas!

What’s in the presentation

The presentation covers these topics:

Introduction to doc sprints, agile environments, and why a doc sprint is a good fit for technical documentation.
Who to invite, when to start, and how to ensure that the sprint will produce the documents you need.
How to get the best out of the sprinters.
Collaborative tools for use during the sprint.
Sprinting across the world: Handling multiple time zones, early sprinters, late sprinters.
How to run a retrospective, and why.
Reviewing and publishing the documents, and writing up the results.
Other innovative types of sprints for documentation teams.

Getting the slides

You can watch or download the slides from SlideShare:

Feedback from attendees

There were plenty of questions, both during and after the session, which is great. People came up and told me they enjoyed the presentation. That’s very very nice to hear.

There were also quite a few tweets during the session. This has to be my favourite, from Stephanie Donovan:

Stephanie’s tweet

If you see any blog posts or reviews appearing, let me know. And thanks so much to everyone for being such a great audience!

Conveying messages with graphs at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

Early on Tuesday morning, Jean-luc Doumont presented a session titled Conveying Messages with Graphs. The blurb for this session is:

Graphical displays are still poorly mastered by technical communicators and other professionals. They seldom think of using graphs to communicate about data; when they do, they often use the wrong graphs or in the wrong way. Based on Doumont’s book Trees, Maps, and Theorems, about “effective communication for rational minds,” this session discusses how to select the right graph and how to optimize the graph’s construction, and how to phrase a useful caption.

Because this session is immediately before mine, I’ve decided not to take extensive notes. I’m too scatterbrained just before and just after live speaking! Instead, I’ll just give you my impressions from Jean-luc’s talk.

Jean-luc is an engaging and knowledgeable speaker, and the topic is very important in technical communication. I’m one of those text-oriented people. I find graphs difficult to interpret, and also difficult to create. A simple bar chart is good, but when you get to scatter-charts and 3D graphs, you leave me behind.

That’s why I attended Jean-luc’s session – to pump up my knowledge of conveying information in graphs. And I wasn’t disappointed. I’m now more comfortable with the more advanced types of graphs. More importantly, I know when to employ the simpler graphs, and how to knock out superfluous information. Simpler is better, as in most types of technical communication.

My two key take-aways are:

Beware of the x-axis in Microsoft Excel. It assumes the data is string-based, even if you enter numerical values. If you want a true numerical reflection of your data, you need to set the data type explicitly.
Horizontal bar charts are often more effective than vertical ones. The default is often vertical, but try flipping it around. A big advantage is avoiding vertically-oriented text.

Thanks Jean-luc for an informative presentation, delivered with charm. Here is a link to the handout from the session (PDF): Effective graphical displays.

Creating user experience for gamified products at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

Marta Rauch presented a session titled Game On! Creating User Experience for Gamified Products. Marta learned about gamification when she became interested in what motivates people to contribute to communities. This was around 2005. She is now a certified gamification designer.

A key take-away from Marta:

Gamification is already here. It’s time for us to get our game on!

Importance of gamification

Why should we pay attention to it, as technical writers? Gamification is the technique of applying game techniques in non-game situations, to motivate people and drive behaviour. So if that’s what we need for a particular piece of user assistance, gamification would be a good fit.

Game techniques:

Game dynamics, which are rules to help you progress through the game
Game mechanics that help you achieve your goals
Game components that help you track your progress

Some stats

By 2014, over 705 of companies will have at least one gamified product. And by 2015, half will gamify innovation.

In the near future, a company that gamifies will be as important as eBay, Facebook, or Amazon.

In terms of money, the market is huge.

The focus is on engaging users. Gamification is the best way to engage younger workers (“millennial” workers). They have 10,0000 hours of gaming by age 21. This qualifies them as experts in gaming. They form 25% of the workforce now, and it’s a growing portion.

Marta highly recommends a TED talk by Dr Jane McGonigal: Gaming can make a better world.

Game changers for tech comm

The next 9 sections are about the things gamification is introducing that we need to consider in tech comm.

1. Understanding motivation

We need to understand our players’ (users’) motivation. What would engage them and what do they really like? To this end, Marta has set up special sessions at user conferences (such as Oracle OpenWorld) to talk about gamification. They had surprising results:

Some players are not interested in badges, but rather in gaining access to information and people. That would be the kind of reward they would like.
Some people really like to help other people. This can also be a reward.

There’s been a lot of research on the general types of players that play games, and what motivates them:

Competing. Seeing how you rank against other players. Getting visibility.
Completing tasks and checking them off.
Helping other people.

In your gamified product, have tasks that play to these difference types of motivates.

Marta gave the example of the Nike fitness apps. They target main user groups, such as people who want to move through their fitness goals, or those who want to talk to and share with friends, or those who want to compete.

2. Gamified user assistance architecture and patterns

Plan the process, then keep the players motivated throughout.

There’s the concept of “onboarding” in games. It helps people know what to do when they get started. Games give you a plan to get started, and quests to follow or levels to conquer. Marta gave an example of a game used to teach maths.

A use case in tech comm: we may need to get people more involved in installing and configuring a product, and we want to keep them motivated all the way to the end.

In games, there’s often no documentation. Everything is embedded. There may be a quest to set up your user profile and get connected with other people. The game may also show you what other people are doing – a bit of peer pressure.

3. Gamification terminology

Marta listed some examples of game terms that have crept into general terminology, such as:

Onboarding
Avatar – this targets people who really like to customise and personalise
Quests
Leaderboards

4. Gamified messages

Messages are really crucial in a game.  They set the tone, as well as telling people what to do and giving them instructions. Think about a coach in real life. The messages are there just when they’re needed.

Often there is a link to the game FAQ. Inspired players love to share what they learn in a forum, and you may want to consolidate the top tips into the FAQ.

5. Writing style

The style is more informal, more friendly, intended to engage and motivate.

Marta pointed us to a chart by Amy Jo Kim – a social actions matrix. It shows the type of words you would use, depending on the quarter of the chart in which the target audience sits, or the type of quest.

6. Testing

When testing, have people sitting in a booth, unable to see each other. Watch how they’re doing. Are they achieving what we want them to achieve. Are they gaming the system in ways we don’t really want? Sometimes you may want to let them do that, and add it as a new feature, otherwise design it out.

7. Change mangement

If you’re going to upgrade or change the game, you must let the players know. They’ll be engaged and motivated, and will hate it if you take something away or change it while they’re in mid stream.

8. Accessibility

If your company is required to be accessible, your gamification must be too. The best information available is from game designers. See Includification as a good source.

9. Localisation

This is always a challenge, because you need to consider the culture as well as translation. Game strategies may need to change. In some countries, for example, you don’t want a leaderboard, because it’s not seen as a good thing to be at the top of the board. Or, it may be OK for a group instead of an individual to be at the top. There are also legal and privacy considerations.

Examples of user assistance

Marta picked a few examples that she thought would be fun to talk about, and to get us thinking.

Microsoft Office – Ribbon Hero 2. “You’ve tried [various games]. Finally, here’s a game that will make you better at your job.” Marta recommends we download and try this game. It’s fun. Knights on horses, dragons. The “Canterburied Tale” quest helps you learn Word, for example. It has some excellent and fun animations. There are other quests to help you with Excel, and more.
Adobe PhotoShop – Level Up. There are five key tasks. They had a business need to teach these tasks, to reduce support calls. An example is changing red-eye. The game takes you through various missions. You “level up” as you move through various missions, and its tied into social networks (Facebook). People love to share, so let them do it.
Cisco – Mind Share. Cisco knows their players – these are certifications for network administrators. It’s really hard to get the certification, and was a painpoint for the administrators. Cisco knew that their administrators really enjoy SciFi games, so this was very successful for them.

A gamified reading app

This reading app was introduced in a gamification summit in San Francisco just a couple of weeks ago: “Read Social App”. You log in via Facebook, then start reading a book. The app shows your progress, and makes you feel good about it.

Marta showed us some great photos of how the app looks on a mobile device. You are presented with challenges to engage you in the content. Players type interesting tidbits they have learned while reading the chapter. The game also has ways to quiz you about what you’ve learned.

There’s also a way to unlock content. You can get access to a video, for example, as a reward for your effort.

You can see a tour at http://www.readsocialapp.com.

Gamification framework

How to get started:

Define your business objectives
Define your audience (players)
Describe the behaviours you want them to follow
Devise activity loops
Remember it must be fun
Deploy the tools you need

Marta’s responses to some questions

Gamification is not the same as games. It’s doing something with a business focus, but with a little more fun and a little more engagement.

Check your metrics. By gamifying a task, we aim to achieve that task a little more efficiently and effectively.

How does this apply to mid-career professionals? The data shows that the average age of a gamer is older than we thought. Also, a number of women play games. The Home Shopping network is very into gamification.

Thanks Marta

Marta finished off by pretending we (the audience) were on a gamification quest. Yaayyy, we’re already on stage 1, by attending Marta’s session. She took us through a number of “levels” we can follow,  to take us all the way to “mission accomplished” where we become gamification gurus.

Marta’s slide deck on SlideShare has a number of useful resources, for learning more about gamification. She also recommends a gamification course by Kevin Werbach, hosted on coursera. It’s pretty intensive, and you can gain an accreditation at the end.

This was a fun and inspiring session. It made me want to learn more. Thanks Marta!

From technical writer to content strategist at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

Alan Porter‘s presentation is called From Technical Writer to Content Strategist. Here’s what Alan promises for this session:

Content strategy is a hot topic right now. The rise in corporate awareness of the value of content represents a great opportunity for technical writers to leverage their skills and experience. This session will help you position yourself to take advantage of that opportunity.

I’m looking forward to a talk by Alan, someone I admire for his diversity and depth of knowledge in the writing and communication fields.

Kicking off the session

After a couple of laughs about food, beer, and cut-and-paste (you had to be there!) Alan summarised the message of his session like this:

I’m going to talk about why I think technical communicators are best fitted to become content strategists.

Alan asked various members of the audience what their company does. After hearing a few specific answers (develop software, medical devices, etc) someone got the right answer: Every company is in business to make money. The other answers describe how we do it.

There’s no good developing something, without telling people about it. That’s marketing. Then you have to get people to buy it. That’s sales. Collect money. That’s finance.

And the fifth thing every company does is: Create content.

Different views of content

The thing about content is, it’s not seen as a strategic asset, because everyone creates is. We have to change this view. Depending on your role, you have a different view of content. Alan showed us some pictures of different ways of seeing a pig.

Marketing puts the lipstick on the pig.
The tech comm department shows a diagram of the pig and describes its various parts.
The customer sees pigs wallowing in the mud.

What customers care about

They care about their problems, not ours.

We’re the people causing the disruptions.

As content strategists, we need to see the customer’s view of the content. And we, as technical communicators, are really good at that.

Definition of content strategy

One problem is that there are so many definitions of content strategy at the moment.

To Alan, it’s about:

Achieving business goals for us and our customers, by maximising the impact of content.

Analysing enterprise content

Companies don’t know:

What content they have that is relevant to the customer.
Where the content gaps are. The content is developed in silos, so things slip through the cracks.
What resources are available elsewhere, either inside or outside the company, that you can use instead of developing new content.
How to put processes in place for the more advanced aspects of content, such as retiring content, managing content.
How to deliver content in the way the customer needs.

Where a content strategy fits

Alan showed us a four-part pyramid. From the top down:

Editorial vision
Content strategy
New capabilities
Foundational capabilities – these are the skills and knowledge that technical writers have. Things like metadata, for example.

Providing value to the customer

Content needs to be engaging, relevant and actionable. It must help the customer do something, so they can solve an immediate business need. Alan is currently analysing exactly what “engaging” means. In part, it must be something the customer wants to read, and can find easily.

Where’s the opportunity for a technical communicator?

A survey asked companies whether they have a unified content strategy that covers both marketing and multi-channel publishing. 80% of the responders said no.

That’s a big opportunity for us. But we need to change our terminology. Instead of talking about metadata and publishing processes, we must talk about business case and strategy. We need to use the vocabulary that the business uses. That’s the role of a content strategist.

Alan took us through a chart showing a typical framework for a content strategy process. The chart is in his slide deck on on SlideShare.

How to go about it

Be aware that content resides across the organisation. We need to break down silos, build bridges, talk to people, and get them to talk to each other. End the cold war between departments, such as tech comm, marketing, training, and so on.

Perform audits of your content. Find out what you have, across the organisation. This can be painful. You need people who understand content, and can ask questions about the business purpose of the content.

Offer advice, build a vision, and share that vision across the organisation.

Figure out a way your content adds revenue. Don’t say you can save money, because that will make it more difficult to get more budget the following year.

Thank you Alan

My key take away from this talk is that we must learn to talk the language the business people are talking, and use it to emphasize our skills, knowledge and impact. Thank you Alan for an encouraging glimpse into the life of a technical communicator become content strategist.

Documentation teams and company mergers at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

Kirsty Taylor’s presentation has an intriguing title: And Then There Was One … Documentation Team. Her team of technical communicators has recently undergone a company merger, and the documentation team has merged with another global team. Kirsty will tell us how to keep our sanity under such circumstances, while looking at the aspects of “culture, standards, time differences, and multiple Englishes”.

Setting the scene

Two years ago, the company Kirsty worked for was bought by a huge conglomerate. The conglomerate then acquired another company, and merged Kirsty’s documentation team with the teams in the other company. They now work together as one team. The company is in the business-to-business area, in the mining and defence industries.

The content team consists of 21 people, over 3 continents, and 11 offices. Kirsty manages the Asia-Pacific region, which covers 5 time zones. Kirsty’s team is also responsible for producing the classroom training materials for their consulting services.

In the last 5 years, there have been multiple acquisisions. The development and documentation team have been merged into one. It’s a distributed team, but with a central function and reporting structure.

This has involved aligning tools, standards, styles, responsibilities and roles. As technical writers come in from each organisation, they learn to use the standard tools. Their roles are aligned with the rest of the team.

One of the really strong things about the team is that they strive for consensus. There’s not always agreement, but there is consensus.

Mincom was added in 2010

This was the largest acquisition to date, in terms of merging of tech comm teams – there were 9 technical writers at Mincom. At first, the two R&D groups worked independently.

Technical writers are inherently curious people. So Kirsty and the other writers from both teams found each other and started talking and comparing notes. The structures and development team were still silos.

There have been many changes at top-management level too.

At the end of 2013, the R&D teams started working together. The technical writing team are still the teams who work most closely together. In March this ear, the VP of Quality Operations started, and the technical writers became part of the QO area.

Kirsty says that this was not like a takeover. It’s a much more collaborative environment, where they’re working together to decide how to move forward.

Refreshed branding

When the merger finally happened, the brand had to change. Luckily it was just the logo that needed to change. Not much else.

Standards committee

The team decided to form a standards committee for online help. There were too many writers to include everyone in the meetings, so they decided to involve the key team members with clever ideas.

Quick wins and collaboration

They looked at the things they could do to improve collaboration and get quick wins early.

Style and standards for online help. This can be tricky, because everyone feels passionately. People had just recently redefined their styles, and didn’t want to change again. The approach was “not to kill anyone’s babies”. Don’t enforce the standards unnecessarily. Be grateful that we’re working together
Output format. They focused on this because they’d be able to show stakeholders they were working together.
The aim was to start looking like one company, in terms of the documentation, and to show they’re working together as a team, even if not a single team.
Knowledge and experience gained from earlier mergers and acquisitions. It was incredibly useful having people who had already gained skills in negotiating decisions.

Problems and challenges

There are some problems to tackle.

Time zones. Kirsty has one person in Perth, while most of the team are in Atlanta. The time difference is 12 hours. There are 21 individuals in the team. Some like/need to start early. Others want/need to start late and work late. This makes team meetings difficult. One trick is to shuffle the meeting times, so that it’s not always the same people who have to work early or late.

The Australian team is used to having the team get together and make a decision, then go back to their desks and make the change. Now it takes adaptation to make the decisions monthly via a standards committee.

It’s tempting to group and name things for the former region or company. But this can create division. Management needs to guard against this. Instead, create a sense of unity and team. Use the words “our team” and “we” frequently and by default. Foster and develop relationships between team members across the pond. Buddy up the technical writers. Make sure they have the facilities (WebEx accounts, for example) to work together.

The company is still consolidating the tools to be used. For example, at first they used GoToMeeting. Then that was no longer available, and they’ve tried Telkom, WebEx, Skype. All have their problems. You need special headsets, or Skype credits, and so on. These ongoing changes can cause problems that can upset team members.

Other important tools are those for content creation, publishing, eLearning, etc. What is standard in one office is not necessarily standard globally. This can cause confusion.

There are changes to content style and writing standards. For example, do you use US or Australian spelling, syntax and punctuation? The information architecture needs to be consolidated. Think about the voice of your content, and more.

Encouraging the team to collaborate

Kirsty mentioned the idea of a team-building exercise somewhere half way between Atlanta and Brisbane. Hawaii, for example! But she laughed and said this probably wouldn’t happen.

Hold a global team meeting. Use games to help people get to know each other, and slide with a photo and short bio.

Have some internal social networking, in a tool like Chatter. Encourage team discussions, share articles and blog posts, ask questions, and respond when others ask questions. They do have SharePoint too, but felt that Chatter is more collaborative.

Pair people on projects, as “buddies”. Be flexible. Allow people to work from home for early or late starts.

Within SharePoint, try a shared team task list. This was a great initiative from the US team. A team task list is a request list from any team member who may need help from another team member. People can ask for a review, or help with something specific like CSS. This is also a useful tool for managers to see when team members need help, or someone is regularly giving help.

The team needs some way of sharing ideas. Hold virtual brown bag sessions, via webinars and recorded sessions.

Main themes

These are the main themes Kirsty has noticed so far:

People. It’s all about change management and working on team relationships.
Processes. When you’re aligning your processes, it’s a really good time to see why you’re doing something or not doing something. This can be really hard to justify.
Collaboration. Focus always on co-operation and the fact that you’re one team.

Thanks Kirsty

This was an intriguing glimpse into the issues that arise when global teams are merged, and the creative solutions Kirsty and her team are putting in place. Thanks Kirsty!

Flexible content and future-ready organisations at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

I love Sara Wachter-Boettcher’s bio:

Content strategist, writer, thinker, cocktail drinker. My name eats character limits for breakfast. Chomp.

Sara’s presentation is titled Flexible Content Demands Future-Ready Organizations. She talked about mobile users, mobile content, and the world of responsive sites, apps, APIs, and read-later services. Structured content is the way to give customers what they need. Producing structured content isn’t just about getting the right CMS. It affects the entire organisation.

Most of what Sara works on is web-based. But the issues and challenges are shared in other tech comm areas too, as are the skills needed to address them.

Introduction

Sara quoted some web designers who are realising that their customers are concerned with content problems. The challenges that mobile has created for us, have made people in the web field realise that content is a problem that needs attention. Designers are realising they only have one “known” to work with, and that’s content. All the other aspects of mobile design are fluid – basically, the presentational aspects.

But what do web designers actually know about content? Luckily, they have content strategists to help them. Talking about content as a strategic business asset for the organisation. Defining how content supports the customers and the business, and the benchmarks and measurements for success.

Strategies:

Organise your content.
Define what you want to sound like.
Devise plans for creating the content you need. Templates. Ways of getting information out of SMEs.

OK, so we have a lot of emphasis on content and how it matters for mobile.

But it’s still really really difficult

How do we implement our strategies so that we can get content that’s more flexible? We don’t want our readers being told the content is not available on a mobile device. Or something that just looks awful, or is even illegible, because not designed for a mobile device.

Look at read-it-later applications, not solely devoted to mobile, but most people use such services on mobile devices. Examples: Instapaper – allows you to save content for reading at a later date. We don’t want our content to be missing when people schedule it for later reading.

We also don’t want our mobile interface to override the user’s choice by giving them a simplified view of the web app they were looking for. Sara gave us the example when she Googled something, got the useful link, and was directed to a simplified mobile overlay of the site. The URL she had found was lost to her. The content had become useless because she couldn’t get at it.

Why is it difficult?

Because of the content. It’s difficult getting the content ready for mobile. Sara referred us to an article called “The Story of the New Microsoft.com” by Nishant Kothary.

Looking at the redesign of a web page to cater for mobile platforms, you could say, “This is a new home page”. Or you could say, “This is a huge change to the way the organisation works”. Sara says the latter is the case, and that’s why mobile is such a problem.

Our content is stuck

Sara often hears people saying, “Just stick it up on the website”. You’ll end up with a website that looks more or less like Seattle’s chewing-gum wall. A lot of content that’s just stuck there. No reason. No way to move it.

We tend to create content by putting it in a big box, to fit on a big web page. That’s what our CMSes are designed to do.

If you’re building things for just one platform, or for one platform at a time, you’re going to keep on getting stuck. Because more and more devices will keep appearing. You’ll need separate strategies for each one. Sara mentioned the possibility of our content having to appear in a car, or on a web-enabled fridge. Trying to make more content for every new device is a losing battle.

Single sourcing

We have the tools to make our content more adaptable. This idea is fairly well known in tech comm, but not in the wider world of web development.

DITA has a number of great features.

NPR has a great system called COPE (Create Once Publish Everywhere). They have everything in a custom-build central content management system. No representational information. Then it goes via an APR to all the various websites, apps, mobile browsers, and so on.

Content like water

Web designers have started saying we need content that can flow, and fill whatever container size it’s given. But content doesn’t magically flow. It’s messy!

Sara showed us an example of an API diagram for NRP’s COPE. It illustrates beautifully that it’s complicated to get the content from content entry, via the APIs, to the end destination.

And it all starts with the data entry. Writing stuff in chunks, so they can be stored separately, is the most flexible way of doing it. It allows you to make separate decisions about each chunk.

Content models

Next you need to think about how content is connected – the relationships between the chunks of information. Create a model of your content. Compare this to a database model that defines how data is interrelated.

Data is also content. When data people design the data model, they tend to forget this. Decisions that ultimately affect how our content reads are often made by people who aren’t trained or empowered to think about content.

The structure of the content must be valuable to people, and must reflect the way people think. You can’t just break it up into parts arbitrarily.

So, find the patterns

We must analyse our existing content to find patterns. Pages are not all the same. They support meaning.

From the patterns, you can identify content types. For example: blog posts, press releases, “how to” guides, and so on.

Each content type has basic structural elements. Sara gave the example of a recipe, which has a title, ingredients, instructions, and even metadata. Decide the inherent elements required in each content type for your organisation.

Then decide how the content types fits together. For example, a recipe may be just one of many for a particular dish, which may be part of a cuisine.

Adaptive content

Adaptive content automatically adjusts to its environment. If you have a resilient and flexible content model, you can make decisions about how it is displayed.

We can’t manage how every bit of content will look. But structure allows us to make rules, which we can apply to our content as a whole. Structure sets our content free. It can go where we want it to go.

Why is our content stuck?

Why is it still so hard? Because organisations are stuck in their existing processes. They get bogged down in expectations of stakeholders.

Organisations have a mass-production strategy. People keep producing content the way they always have, without thinking about where it’s going to end up.
Content-producing roles aren’t tied to organisational strategies. Content producers don’t know how their work fits in to the corporate goals. It’s hard to make changes, and people don’t see why they should.

Content strategy should be the bridge between the corporate vision and the content producers’ role.

Teams are siloed. Teams don’t communicate, or are even hostile towards each other.
As a result, content is duplicated and confusing.
It’s impossible to have the users’ needs at the forefront.
Organisations are so concerned with how they’re organised internally, that that’s what they show to the rest of the world.

These are hard problems to solve. One way is to create small teams with a cross-department focus. Spread new ideas, and focus on a single issue.

Organisations have obsessions with control.
Stakeholders don’t get digital. They want to see their content in fixed format, such as print.
Businesses are scared of the idea will take their content away and read it later in another format. User control terrifies them.
Organisations aren’t built to change, but things are changing very rapidly. So people try to freeze things rather than change. But that doesn’t work.

The organisation doesn’t have to learn just how to deal with mobile. It has to learn how to become adaptable.

What can we do?

There are some good things we can do. We need to change the way we work.

We have a lot of passion about content. Share it with people. Here’s how:

Make mobile a start, but not the end goal. Karen McGrane says we should “use mobile as a wedge to create a better experience for ALL users”. Sara says this is true for organisations too. Mobile is an opportunity to get people from different departments to work together.
Don’t sell solutions. Invest more deeply. Don’t tell people we’re going to fix everything. We can’t be our organisation’s saviour or mastermind. An organisation doesn’t need a mastermind. You need to find ways of getting people to work with you. Teamwork is messy, but it’s the only way to sustainable change how we deal with content.
Do less, and facilitate more. It’s not all about the thing we produce. It’s about the way our work is carried on. So we need to be facilitative. This is also the way we can take on leadership roles. Find the people your work will affect, and involve them from the start of the project.

What’s coming?

We can’t know what the future will bring. We do know mobile is not going to go away. But we can’t know what it’s going to look like. How many people will be using mobile, and what kind of devices will there be? We can’t know.

But if we and our content are adaptable, we’re in a better place.

Thanks Sara

This was an inspiring and lively session. It put a lot of things into perspective. Thanks Sara!

Information development flexibility in Agile at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

It’s bright and early on Monday morning. Alyssa Fox is kicking off with a session titled Bending Without Breaking: Info Dev Flexibility in Agile. She has made her presentation available on SlideShare. Here’s the blurb:

This session helps technical communicators face challenges in agile planning and execution. It’s increasingly common for writers to work on multiple agile teams. The session includes tips for better communication and teamwork on your agile team, with the goal of a “whole team approach” in mind.

The old way and the new way

Alyssa explained that initially in her organisation, the functional areas were split: the developers, QE (quality engineers), ID (information developers, or technical writers) and other members of a product development team worked separately on their own tasks.

Later, they moved to the “whole team” approach, which means all members of the team accept responsibility for delivering all aspects of the user story. QE, technical writers, developers, and all. Everyone accepts that all aspects of the user story, including documentation, must be complete in order to declare the sprint complete.

How to get to the new state

There are a number of ways to get to that happy state. These are the ones I noted while Alyssa was speaking:

All developers do their own unit testing.
Automated testing is also essential.
QE and information development must be included in all estimates. If you don’t do that, it will not be possible to meet your targets.
Make sure you fix all bugs within the sprint in which they were created.
Help other functional areas to complete their tasks, when you’ve finished yours. For example, you can help with usability testing, setting up environments, grooming the backlog of tasks.

Swarming

To ensure the info dev team can successfully become a useful and productive part of an agile team, you need to give them support by adapting the processes of the agile team.

When setting up user stories, do them in vertical slices rather than horizontal. In other words, make sure all functional areas are covered during a single sprint. This means you can have something potentially shippable by the end of the sprint.

Feature testing, regression testing and documentation therefore happen during the sprint. If you have a testing crunch or a doc crunch at the end of the sprint, it means the team as a whole is doing something wrong. This requires the discipline where all members of team know what is required of them.

(I looked up “swarming” after Alyssa’s talk. It’s the practise where an agile team focuses all its effort on one story at a time, where practical.)

Release planning

The way you plan a release has a big impact on the success of the release. A release consists of a number of sprints, culminating in a marketable release to present to customers.

Have a backlog of user stories to pull your sprint tasks from. Make sure the user stories are well estimated. Define a theme for the release, then pick stories that fit into that theme. Take the velocity of the team into account.

Before you start, make sure you have a good idea of the stories you will tackle in the first two to three sprints, and have all the stories for the first sprint clearly defined.

Document review cycles

Alyssa recommends that you plan for two to three drafts of each document: a first draft, an approval draft, and a quality edit draft. Get the SMEs to review the first draft during the sprint.

Creating user stories

This is the most vital part of ensuring success for information development. You need good user stories so the info dev team can plan and draft the documentation.

User stories must focus on the user’s point of view. Ensure you prioritise those of the highest value to the customers.

Making user stories focus on the user

There are three parts to a user story:

Problem statement. This is the most essential part of the user story. Usually, the developer writes the problem statement. Info dev can add tremendous benefit by helping to refine the problem statement.
Acceptance criteria. This is essential to know how the users can know that the problem is solved. Again, the developers start by writing this part, and the technical writers add value by reviewing it.
Acceptance tests. These form the technical way of testing that the problem is fixed. Info dev typically doesn’t have much input here.

Thanks to the info dev involvement in defining the problem and the acceptance criteria, it is much easier for the writerss to start the documentation and release notes.

More advantages of this approach

It gets everyone on the same page. Everyone knows what the problem is and how we can know when it’s done.

It eliminates unnecessary ad hoc testing and reveals possibilities for user testing.

It forces everyone to think about the user’s side of things and the user impact of the planned changes. Writing a user story may make you realise the problem actually isn’t such a great problem, and it would be a waste to spend effort on it.

It gives the product manager a sense of security that the team understands the requirements.

Backlog grooming

Backlog grooming is the process of looking through the stories in the backlog, analysing, estimating and prioritising them. You should do your backlog grooming frequently. For example, once a week or at the beginning of each sprint.

Alyssa discussed the technique of “planning poker”. The idea is to discuss the stories and estimate the effort using story points for all functional areas. Make sure the user stories at the top of the backlog are small enough to complete in a single sprint.

It’s important that all team members, or at least the leads from each functional area, are involved in this exercise.

Sprint planning

Create your sprint backlog by pulling stories from the product backlog into the sprint backlog. Estimate the tasks in hours, and remember to include time for overhead (meetings, technical setup, admin, etc). Make sure your estimate fits your capacity for the project and the sprint. This is particularly important for people working on multiple projects, as so many technical writers do. Book yourself for the number of hours you have available, and no more.

Allyssa recommends planning 20-25% of each writer’s time for vacation and non-sprint responsibilities. She says we should exclude the last day of the sprint from our planning.

Make sure the development finishes before the end of the sprint, to give testing and info dev time to complete their tasks too.

The writers on Alyssa’s team maintain spreadsheets showing their capacity (in hours) across the various projects.

Coping with multiple projects and meetings

If you’re on multiple projects, you can’t attend all meetings. You’d never get your work done. Think about attending one or two scrum meetings per week instead of all of them, and prioritise the ones that are the most important to you. Ask the scrum master to send status emails for the meetings, so you can catch up on what you miss.

Be pushy. Make your presence and needs known. You need to make sure the team knows you need the information. Alyssa has put together a list of criteria to help development teams know when info dev needs to be involved. For example, when the development team is ready to start coding. Then they hold a team kickoff meeting, so that the info dev team can decide when they need to start work on the project.

What does “potentially shippable” mean?

A document should be shippable for that part of the product developed during the sprint. The documentation for that part of the product needs to be ready. This includes the topics, videos, and other material required, but not the whole book or whole help system.

Tasks such as an approval draft of the whole document, final reviews, the production process, and the release notes, are delivered at the end of the release. They don’t need to be part of the sprint delivery.

More topics arising from questions

There were a number of questions from the audience.

How do you handle translation? Alyssa’s team fits this into their milestones. They give the translators 90% of everything towards the end of the release. They make sure all the English-language stuff is ready to go by release date, and deliver the rest later. All their documentaiton is online.

What is the typical sprint length in Alyssa’s organisation? Sprint length is three weeks for most teams. This works best. Some teams have shorter sprints, but those are difficult to work with.

How hard was it to get all the development teams to follow the same process? Some of them find this difficult. In the early days, some teams were using different processes. This was very difficult for the teams working on multiple projects, like QA and infro dev. Support from upper management is essential, to get agreement from all teams.

How do you handle changes in the software resulting from user feedback? It’s a good idea to build in buffers when doing your estimates, because you may need to make changes as a result of customer feedback. Being able to change is built into agile.

Alyssa mentioned the concept of “targeted” documentation, which focuses more on conceptual documentation rather than “how to” guides. It comes from the perspective of “how do I do my job with this product” rather than “how do I use this product”. Alyssa’s team don’t document everything, but spend time analysing what’s needed. If something is obvious from the UI, they don’t document it. If they get feedback from customers that they need the documentation that has been left out, then they consider adding it.

What source material is available on doing info dev in an agile environment? Alyssa says there’s not a lot available. There are blogs, but there’s a lot to say and not a lot of information yet. It’s been mostly trial and error for her team.

Thanks Alyssa

Alyssa spoke engagingly and passionately, and covered a complex topic with aplomb. Someone in the audience suggested she write a book. I second that suggestion!

Information Development Flexibility in Agile at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

It’s bright and early on Monday morning. Alyssa Fox is kicking off with a session titled Bending Without Breaking: Info Dev Flexibility in Agile. She has made her presentation available on SlideShare. Here’s the blurb:

This session helps technical communicators face challenges in agile planning and execution. It’s increasingly common for writers to work on multiple agile teams. The session includes tips for better communication and teamwork on your agile team, with the goal of a “whole team approach” in mind.

The old way and the new way

Alyssa explained that initially in her organisation, the functional areas were split: the developers, QE (quality engineers), ID (information developers, or technical writers) and other members of a product development team worked separately on their own tasks.

Later, they moved to the “whole team” approach, which means all members of the team accept responsibility for delivering all aspects of the user story. QE, technical writers, developers, and all. Everyone accepts that all aspects of the user story, including documentation, must be complete in order to declare the sprint complete.

How to get to the new state

There are a number of ways to get to that happy state. These are the ones I noted while Alyssa was speaking:

All developers do their own unit testing.
Automated testing is also essential.
QE and information development must be included in all estimates. If you don’t do that, it will not be possible to meet your targets.
Make sure you fix all bugs within the sprint in which they were created.
Help other functional areas to complete their tasks, when you’ve finished yours. For example, you can help with usability testing, setting up environments, grooming the backlog of tasks.

Swarming

To ensure the info dev team can successfully become a useful and productive part of an agile team, you need to give them support by adapting the processes of the agile team.

When setting up user stories, do them in vertical slices rather than horizontal. In other words, make sure all functional areas are covered during a single sprint. This means you can have something potentially shippable by the end of the sprint.

Feature testing, regression testing and documentation therefore happen during the sprint. If you have a testing crunch or a doc crunch at the end of the sprint, it means the team as a whole is doing something wrong. This requires the discipline where all members of team know what is required of them.

(I looked up “swarming” after Alyssa’s talk. It’s the practise where an agile team focuses all its effort on one story at a time, where practical.)

Release planning

The way you plan a release has a big impact on the success of the release. A release consists of a number of sprints, culminating in a marketable release to present to customers.

Have a backlog of user stories to pull your sprint tasks from. Make sure the user stories are well estimated. Define a theme for the release, then pick stories that fit into that theme. Take the velocity of the team into account.

Before you start, make sure you have a good idea of the stories you will tackle in the first two to three sprints, and have all the stories for the first sprint clearly defined.

Document review cycles

Alyssa recommends that you plan for two to three drafts of each document: a first draft, an approval draft, and a quality edit draft. Get the SMEs to review the first draft during the sprint.

Creating user stories

This is the most vital part of ensuring success for information development. You need good user stories so the info dev team can plan and draft the documentation.

User stories must focus on the user’s point of view. Ensure you prioritise those of the highest value to the customers.

Making user stories focus on the user

There are three parts to a user story:

Problem statement. This is the most essential part of the user story. Usually, the developer writes the problem statement. Info dev can add tremendous benefit by helping to refine the problem statement.
Acceptance criteria. This is essential to know how the users can know that the problem is solved. Again, the developers start by writing this part, and the technical writers add value by reviewing it.
Acceptance tests. These form the technical way of testing that the problem is fixed. Info dev typically doesn’t have much input here.

Thanks to the info dev involvement in defining the problem and the acceptance criteria, it is much easier for the writerss to start the documentation and release notes.

More advantages of this approach

It gets everyone on the same page. Everyone knows what the problem is and how we can know when it’s done.

It eliminates unnecessary ad hoc testing and reveals possibilities for user testing.

It forces everyone to think about the user’s side of things and the user impact of the planned changes. Writing a user story may make you realise the problem actually isn’t such a great problem, and it would be a waste to spend effort on it.

It gives the product manager a sense of security that the team understands the requirements.

Backlog grooming

Backlog grooming is the process of looking through the stories in the backlog, analysing, estimating and prioritising them. You should do your backlog grooming frequently. For example, once a week or at the beginning of each sprint.

Alyssa discussed the technique of “planning poker”. The idea is to discuss the stories and estimate the effort using story points for all functional areas. Make sure the user stories at the top of the backlog are small enough to complete in a single sprint.

It’s important that all team members, or at least the leads from each functional area, are involved in this exercise.

Sprint planning

Create your sprint backlog by pulling stories from the product backlog into the sprint backlog. Estimate the tasks in hours, and remember to include time for overhead (meetings, technical setup, admin, etc). Make sure your estimate fits your capacity for the project and the sprint. This is particularly important for people working on multiple projects, as so many technical writers do. Book yourself for the number of hours you have available, and no more.

Allyssa recommends planning 20-25% of each writer’s time for vacation and non-sprint responsibilities. She says we should exclude the last day of the sprint from our planning.

Make sure the development finishes before the end of the sprint, to give testing and info dev time to complete their tasks too.

The writers on Alyssa’s team maintain spreadsheets showing their capacity (in hours) across the various projects.

Coping with multiple projects and meetings

If you’re on multiple projects, you can’t attend all meetings. You’d never get your work done. Think about attending one or two scrum meetings per week instead of all of them, and prioritise the ones that are the most important to you. Ask the scrum master to send status emails for the meetings, so you can catch up on what you miss.

Be pushy. Make your presence and needs known. You need to make sure the team knows you need the information. Alyssa has put together a list of criteria to help development teams know when info dev needs to be involved. For example, when the development team is ready to start coding. Then they hold a team kickoff meeting, so that the info dev team can decide when they need to start work on the project.

What does “potentially shippable” mean?

A document should be shippable for that part of the product developed during the sprint. The documentation for that part of the product needs to be ready. This includes the topics, videos, and other material required, but not the whole book or whole help system.

Tasks such as an approval draft of the whole document, final reviews, the production process, and the release notes, are delivered at the end of the release. They don’t need to be part of the sprint delivery.

More topics arising from questions

There were a number of questions from the audience.

How do you handle translation? Alyssa’s team fits this into their milestones. They give the translators 90% of everything towards the end of the release. They make sure all the English-language stuff is ready to go by release date, and deliver the rest later. All their documentaiton is online.

What is the typical sprint length in Alyssa’s organisation? Sprint length is three weeks for most teams. This works best. Some teams have shorter sprints, but those are difficult to work with.

How hard was it to get all the development teams to follow the same process? Some of them find this difficult. In the early days, some teams were using different processes. This was very difficult for the teams working on multiple projects, like QA and infro dev. Support from upper management is essential, to get agreement from all teams.

How do you handle changes in the software resulting from user feedback? It’s a good idea to build in buffers when doing your estimates, because you may need to make changes as a result of customer feedback. Being able to change is built into agile.

Alyssa mentioned the concept of “targeted” documentation, which focuses more on conceptual documentation rather than “how to” guides. It comes from the perspective of “how do I do my job with this product” rather than “how do I use this product”. Alyssa’s team don’t document everything, but spend time analysing what’s needed. If something is obvious from the UI, they don’t document it. If they get feedback from customers that they need the documentation that has been left out, then they consider adding it.

What source material is available on doing info dev in an agile environment? Alyssa says there’s not a lot available. There are blogs, but there’s a lot to say and not a lot of information yet. It’s been mostly trial and error for her team.

Thanks Alyssa

Alyssa spoke engagingly and passionately, and covered a complex topic with aplomb. Someone in the audience suggested she write a book. I second that suggestion!

EPUB and technical communication at STC Summit 2013

This week I’m attending STC Summit 2013, the annual conference of the Society for Technical Communication. I’ll blog about the sessions I attend, and give you some links to other news I hear about too. You’ll find my posts under the tag stc13 on this blog.

Scott Prentice presented a session titled EPUB and Techcomm – Are We Ready? EPUB is a standard for ebook publishing. In other words, the EPUB standard defines a format the ebook readers can interpret. Scott’s talk focuses on the current state of EPUB tools and technologies, and how technical communicators can make the most of EPUB as a content delivery option.

Quick audience survey

Scott asked for a show of hands for how many people were already delivering EPUBS. A handful of people put up their hands. A couple of others responded when Scott asked how many were producing EPUBS but not yet delivering them. There were approximately 50 people in the room.

What is an EPUB?

Scott started by explaining the EPUB format. He encourages people to get hold of an EPUB file and unzip it (it’s just a zip file) to see what’s in it. This is a good way of understanding what’s going on. At the end of the session, Scott opened an EPUB file in an Oxygen XML editor and walked us through the content of an EPUB file.

Interestingly, there’s a fixed layout format, approved in 2012. This is useful where you need a fixed format output, such as a comic book.

EPUB and tech comm

Scott says tech comm is late to getting into the area of EPUB. The tools are slow to move in this direction. EPUBs are best for linear content, where you move from page to page, like a book. There isn’t really the concept of a topic. EPUBs are also not great for tabular data, because it tends to truncate tables.

EPUB will probably not be your primary deliverable, but it may be useful as another format available to customers.

Readers

You can make custom readers and embed them in your product. But typically, your customers will be using existing devices such as mobile phones and Kindles. Each brand of mobile phone has different apps for reading EPUBS. There are also desktop readers. For example there are plugins for browsers like Firefox and Chrome.

Scott recommends Chrome Readium as a good reader to test your EPUB content.

The EPUB document will look different in each reader. This is one of the big challenges, and something to be aware of when developing content.

Scott showed us some screenshots of the same document on a few different devices, with slight formatting differences. The screenshots come from Tony Self’s book, DITA Style Guide.

Technologies and tools

An EPUB file is a collection of XHTML, CSS, XML, and media files. Most technical writers will be single-sourcing their content, and using EPUB as just one output. Most other people writing EPUBs will really craft their content for the EPUB.

You could hand-code your EPUB files, but Scott doesn’t recommend this, because there are many interdependencies amongst the files. Instead, use a tool and then tweak the output. You will need to tweak it, because no tool is perfect. You’ll find it’s missing metadata, for example, that you need for your publication.

EPUB 2 or 3?

EPUB 3 has plenty of new features, but the tools don’t yet support it fully. For now, Scott recommends sticking with EPUB 2 or using simple EPUB 3.

EPUB 3 is based on HTML5, so you can use scripting and get a lot of interactivity. You can use JavaScript, for example, to modify the content. For example, a table could start off small, or convert itself to a list. But at the moment, to take advantage of these features you have to hand-code them. Even the tools that claim to support EPUB 3 don’t really use the new features.

One of these new features is the “read aloud” feature, one of the “media overlays”. Others are fixed format, and flow from right to left. Scott thinks an EPUB could replace PDF, because it contains all the information in your help system and is now available in fixed format.

Formatting

The most important thing is to keep it simple. This is the best way to ensure your content will work on as many readers as possible.

You can embed fonts, but Scott says don’t bother. You’re adding to the download size of the file, and adding the possibility that it won’t work on all readers.

If you do use styling, don’t use the style attribute on elements. Use CSS selectors. Note that many tools use the style attribute.

Kindle and EPUB

Kindle does not support EPUB directly. They have their own format. Amazon provides a tool called KindleGen that will convert EPUB to MOBI or KF8 for use on a Kindle.

But you may need to modify your EPUB file, and some things may not work on the Kindle.

Always test your content after converting to Kindle. Don’t rely on the emulators. The Kindle desktop app will render the content differently from the Kindle device.

Keep it simple!

EPUB publishing tools

Scott gave us a list of tools that offer EPUB generation and that he considers suitable for tech comm, giving an overview of the pros and cons of each.

Adobe TCS
Doc-To-Help
Help & Manual
RoboHelp
MadCap Flare
Webworks ePublisher
DITA Open Toolkit with the DITA for Publishers plugin. In Scott’s opinion, this tool provides the cleanest EPUB output of all the tools.
DocBook, with various scripts e.g. Python scripts
FrameMaker with the ElmSoft EPubFm2 plugin. Scott says this does a good job at a low cost.

Problems with publishing tools

This is an overview of the type of problems you’ll find when generating EPUB from the tools Scott discussed:

Some tools find the EPUB file structure difficult to handle. Keep your document simple, so that you can make manual adjustments.
Most tools provide you with “fake” lists i.e. styled lists, instead of real HTML lists. These don’t work well in an EPUB.
Many tools use the style attribute on HTML element, instead of CSS classes. If you use proper CSS styles, these will typically follow through into your EPUB. But the tools prevent this.
EPUBs allow you to provide many different types of metadata, such as author name, dates. The tools typically don’t allow you to add this metadata, or offer only limited parts of it. You’ll need to add metadata later.
Inside an EPUB, each HTML file starts a new chapter. This will start on a new page in an EPUB. Some tools give you the ability to specify the topics that start a new page. Other tools give you no control at all.
As already mentioned, the tools that claim to support EPUB 3 don’t really offer more than EPUB 2 tools.

Other tools

You’ll need other tools:

EPUB editors. Scott recommends Oxygen XML editor, BlueGriffon EPUB Edition, and Sigil.
Calibre, a multi-purpose tool for cataloging and organising your EPUBS. It has a server, which you can use to make your EPUBs available. It has a reader and some conversion options too.
epubcheck, a validator. You should always validate your EPUB file after generating and tweaking it.
KindleGen, for converting EPUB to MOBI or KF8 for use on a Kindle.

Where does an EPUB best fit in

Because of its linear nature, an EPUB is not useful for “just in time” learning, or solving a problem. Rather, for conceptual information and guides. Something you want to take away with you and read on the train.

An audience member suggested it would be useful for installation guides, when you don’t yet have the app installed.

Conclusion

Thanks Scott, this was a useful session, with plenty of take-away information from an expert in the field.