Write the Docs Prague – Day 3 (Summary)


The following write up is about sessions I attended. I spent an hour or so mid-afternoon joining in one of the unconference sessions. A special thanks to Sarah Chambers for sharing her session notes.

After an excellent day of presentations and ideas, I was looking forward to another round of thoughts on writing, API documentation and customer support docs.

In the first talk of the day Pretty Hurts, Riona McNamara explained why better is sometimes better than the best when it came to quality. While it may be looked upon as effective to create documents in vast quantities, the quality of the documents is something that often gets overlooked. We don’t have an established vocabulary to talk about the quality of docs was the essence of her talk.

She spoke about the 2 types of quality

  • Structural quality – Focuses on the grammar, language, organisation and navigation of content.
  • Functional quality – Asks the more pertinent questions such as:
    • Does it do what is is supposed to do?
    • Does it satisfy requirements?
    • Achieve it’s objective?

Functional quality is harder to gauge than structural quality when it came to metrics. How do we achieve this?
a. Understand – State what the document should achieve or is supposed to do.
b. Define – Define functional requirements and get buy-in from internal and external stakeholders.
b. Execute – Create the docs keeping the requirements in mind.
c. Measure – Measure against requirements. Use quality data to communicate impact and value.

Given that almost everyone has used or use some sort of checklists (physical or mental), it was interesting to hear Daniel Beck talk about how he uses checklists in his daily schedule.
His statement “We live in a world where even the best people make mistakes – not because we are bad, but because systems become more complex and expectations increase” made a lot more sense after he showed some photos of flight cockpits and how they have evolved.

  • It is important that checklists contain completable and repeatable actions, instead of merely one to aspire.
  • You should design checklists with some context, such as thresholds or boundaries around what needs to be included.
  • Checklists usually fit a pattern – read-do or do-confirm.
  • Use the checklist to exploit existing habits, reward yourself or log your progress.
  • You can create physical checklists and add movement/sound to make it more dynamic.

Daniel demonstrated how he uses checklists to ensure automation is working by verifying, integrating and prototyping them. It was a very simulating presentation, especially about something we create frequently, but without giving it too much thought.

I am personally an avid reader and fiction is one of the genres I often fall back on to provide some mental stimulus away from work. The presentation by Thursday Bram on What Writing Fiction will teach you about writing documentation thus provided some excellent insight into how these 2 worlds could converge.


This is what there is to writing documentation like fiction:

  • Write what you knowYou’re never going to know everything about your audience and your product. Even if you’re documenting code you wrote yourself, you’re going to learn things from the way other people use that code. Good writing gets a little personal — but you should make an active decision about whether they help the documentation.
  • Be Brief – Good writing is clean and clear.
  • Emotion matters – Instead of just writing out steps in an instruction, try and inspire the readers/users to make most of the inspiration. Use storytelling to add relevance, context and suggestions.
  • Kill your darlings – While we may be tempted to leave clever words in our writing, it is necessary to keep documentation simple and easy to follow for everyone.
  • Provide context – This can’t be stressed enough. Without context, users will have no idea of the why’s and when of the instructions.
  • Set a reading order – Setting a preferred reading order to guide the user.
  • Maintain the CanonThe concept of canon is crucial when talking about fiction series. It’s the idea of the core information that has to remain true over the course of multiple storylines, like where a character is from or which characters are in relationships. Similarly, for our documentation, it the stuff that is based on what’s actually going on with the product or service we are documenting.
  • Encourage fan fiction – “Creating a set of core or canon docs will provide a base for community members to start from, as well as give you a way to denote documentation produced in-house and by fans.” This will assist users on building a community of documentation around products.
  • Use Beta readers and workshops – Similar to creating beta version of software, it can be useful creating beta versions of documentation to gather feedback.
  • Reading and Writing are connected habits – This is perhaps the most important of all. The more widely you read, the better. An article here or a novel there can spark ideas — and I’m not just talking about ideas for good fiction. You can find new metaphors and new perspectives with every word you read. I have found this to be true when I write documentation myself.

Do you know the best people in the organisation to talk about what customers want? Not the trainers, or the developers or even the marketing people. The support staff have more interaction with the customers directly than anyone else combined. Why are we not engaging them with the documentation efforts then? In her thought-provoking talk, Documentarians and Support: Work Better Together, Sarah Chambers gave some great insights into doing exactly this.

  • Technical writers and support staff have exactly the same goal – to help customers perform a task. Technical writers + Support = Superpowers!
  • Support help writers close the feedback cycle perfectly by showing them where the users are having trouble finding docs, are unclear or do not exist.
  • Support can provide writers a lot of information about the users, behaviour, the way they use the product or the language they use

Speaking from her Online Support background, she explained some metrics that support can provide about effectiveness of your documentation (in addition to your doc metrics around page views, engagement etc):
a. Measure your self-service ratios – Self service ratio = (no of article views)/(no of tickets created)
b. Customer effort score – Use a scale from Strongly Agree to Strongly Disagree to respond and look at the distribution of scores (High, Medium and Low effort)
c. Ticket tagging – Tag support tickets by how-to questions (for writers), bugs (for developers) or feedback (for product owners). You can use this data to graph your work effort, distribution of issues.
d. Qualitative data – Make your support tickets topics match your documentation topics. Makes it easy to track and troubleshoot. Also helps with proving ROI on documentation.

How do we get the support team to work with the writers?

  • Use common tools that support can use to create first drafts of documentation
  • Provide them downtime to work on other projects such as documentation
  • Create a in-house style guide as a reference
  • Use the same workflow to progress a document
  • Provide the correct templates to support staff

Kata Nagygyorgy has been working on polling useful data around technical communications for some months now and she provided us with early insights. In an initial sample of 100 responders across NA, EU, AU:

  • There are around 30-40 names our documentarian community identified with, with Technical Writer as the most popular title for documentarians
  • 20% people got into Tech Writing by coincidence
  • Github has quickly grown to be the most popular, with Confluence, Text editors and Word as the most popular tools
  • 71% responders have and use an in-house style guide for their documentation
  • Markdown, XML and DITA are the most popular outputs
  • 66% responders self-review their documentation

You can use this form to fill in your stats: https://goo.gl/6SQc63



I took some time off in the afternoon to network with other attendees and join an unconference table talking style guides.

While the term “unconference” is not new in itself, most conferences I’ve been to in the past, encourage attendees to mingle over breaks.

At Write the Docs, attendees who had an interest in hosting an unconference session could do so by putting up their ideas on a whiteboard at the start of the day and others could join in, providing a break from the intense presentations. I thought this was a real cool way for people to talk about topics close to their heart, be it coding, APIs, style guides, or search algorithms.

I joined in the Style Guides session where a group of attendees spoke about the pros and cons of style guides, what needs to be included/excluded, the “live” nature of style guides and how companies should encourage staff to contribute to style guides.

The key takeaway of this session was: Everyone needs a style guide. It makes life easier, documentation consistent and removes ambiguity around standards.


Write the Docs Prague – Day 2 (Summary)


The following write up is about sessions I attended. I spent an hour or so mid-afternoon taking a mental break or joining in the unconference. A special thanks to Sarah Chambers for sharing her session notes.

After a hectic Day 1 of contributing to, talking about, improving and creating new documentation via the sprint style action, it was time for the presentations.

In her welcome speech, Mikey spoke about how the Write the Docs movement has gained steam worldwide, the main driving factor being the true sharing-and-caring nature of the community. The community is not just about technical writers (even if they form the majority), but anyone who is involved in documenting, be it developers, support, testers or anyone else.

In his very uniquely named presentation Postulating the Backlog Laxative, Paul Adams essentially drew on his experiences to present a case for fitting documentation in a scrum. Coming from a life of playing rugby, he is quite familiar with the word “scrum” and expanded on it to provide some answers on the role of tech writers in a scrum. According to Paul, tech writers are either:

  • Not involved in a scrum, leading to no documentation at the end of a sprint or release.
  • Like a fish riding a bicycle, leading to communication overhead and distraction towards the tech writer. Tech writers could also be spending time writing for one person as opposed to the team, working against the very principles of scrum.
  • Involved in the scrum, but always out of sync by one iteration.

To solve this conundrum, Paul suggested keeping the tech writers out of the scrum, but in constant touch with the scrum team. His rugby analogy of having the tech writers like back runners provided justification that they don’t have to be in a scrum, but just work smoothly with the scrum team.

The 2nd speaker of the day, Istvan Zoltan Szabo provides some great insight with his very timely and needed talk Writing as a non native speaker. For a lot of tech writers in Europe, English is not the native language. Recounting his own experiences, Istvan threw light on the limits of language and how entropy creeps in our communication with using English, as he reckons that English does not have the same preciseness that some other languages provide for. He provided some very good examples to illustrate this point. To counteract this, he explains how he went about pushing his own personal limits, or stretching the borders to quote him directly.

  • Follow a process – Draft, Rest, Self-Edit, then send for review.
  • Stretch the borders of your language – Translate a book, watch a TV series, or get a coach/mentor and practice.

Ever wonder why they ask you to put on your own mask before helping your dependants on an airplane? It may have something to do with being able to make sure that you are in a position yourself before you help someone. In his very offbeat, yet very relevant topic Healthy Minds in a Healthy Community, Erik Romjin spoke about how important it is to identify, talk about and work on our private health in an increasingly connected community.

  • 70% of people regularly experience physical symptoms due to stress, yet they get away by hiding it under the pretext of being “just tired”
  • We are not mental health professionals (as a community), but we make a difference to someone’s well being by simply being empathetic and listening.
  • People love contributing to projects, but we often forget that we need to help ourselves before we help others
  • It is perfectly OK to say NO and it is ok to say NO MORE to things that you are already committed to
  • Suffering through our work serves no one, so it is necessary to let out some of that anxiety and talk to someone.Asking for help is not failing – it is as a matter of fact succeeding.
  • Build a culture that makes everyone feel they are welcome and that you are delighted to have them involved.
  • Show appreciation where due. It can feel uncomfortable to appreciate people, but it is always well received.


Lightning talks

Just after lunch, attendees were invited to present 5-min lightning talks on any topic. Slides were optional, so it was pretty much a chance to present an idea, discuss an issue, provide an answer, or talking about your product/tool/technique.
It was a very cool platform for people to build up confidence or address that stage fright or make a case for a future conference presentation.

If you thought software documentation was a tough gig with multiple approvals and non-forthcoming SME’s, Joan Wendt’s talk Documenting Data Center Operations demonstrated how hard it was to document operations documentation for field staff.

Presenting stories and non-classified artefacts from her work, she explained her workflow on how she went about attending design meetings, working in lab to photograph prototypes, accompanying engineers to first build site, creating draft documents, field testing the documents and then publishing the production versions. For some documents, she was required to get up to 20 levels of approvals before she published the documentation.

Given the nature of the documentation (instructions) and the audience environment (on-field), her documentation sometimes needs to be created with minimalist principles, and with clarity rather than including superfluous text or focus on formatting. Some of the more common challenges she faces:

  • Difficulty in getting knowledge out of some people
  • Strict security policies and up to 20 levels of approvals
  • Detail oriented documentation required.

As with other jobs, there are pros (travel, field testing possible, meeting end users, best practices) and cons (physically demanding, stressful, tedious work) to this type of doc work as well.

Creating meaningful interactions with users requires a strategic voice with a human tone“. In her talk Watch that tone“, Sarah Karp expanded on this quote and explained how voice (personality) and tone (mood) make for a good information experience. She cited some examples of Warby Parker and Mailchimp content that uses the correct voice and tone to guide the user.

In order to keep a consistent voice and tone throughout your documentation, it is important to:

  • Look at your company values and what stands out should be in your content
  • Be bold, optimistic and practical
  • Define your own individual voice

At Atlassian, the Information Experience Designers use something called Voicify cards that have guidelines for different scenarios. It is like a cheat sheet that sets the scene (for the content), provides tips and tricks, a feelings slider scale across the bold, optimistic and practical aspects of the content. It allows them to learn by example and gauge feedback. She summarised her talk with “Voice and tone builds trust – people know you and can identify you!“.

This was my first time at a Write the Docs conference as an attendee and presenter. Drawing up on my experiences (and frustrations) of bad screenshots used in documentation, I spoke about the why and how of screenshots and what we as tech writers could do, to address the issue.


Bad screenshots make a tech writer’s work harder, by adding to the content development time, plus the hassle of getting new and clear screenshots. One way to address this at the very outset is to have relevant instructions around capturing, naming, saving screenshots in the company style guide. Screenshots are basically the most effective when they are used with a specific purpose, be it to educate, complement or guide the user.

Documentoring is a thing, at least according to David Oliver, who uses it to mentor his engineering and marketing team members on the art of producing quality documentation. Documentation needs to be added to the definition of done in a product team. According to David, “documentation is a product. You cannot have one without the other.” This resonated strongly with a lot of attendees.

David Oliver spoke about 2 different cases:

  • Great product/flawed documents – In this particular case, while there was considerable interest early on, users became frustrated with the product particularly around difficulty in using the product. It became difficult to retain users.
  • Simple product/better documents – While the product was easy, users could get into all the features and the feedback was around improvements. Documentation made it a very good experience for the users.

In order to give yourself the best chance to succeed, it is crucial to use the same toolset (JIRA, Markdown, Github) as other teams. Also, sometimes it important to have documentation at 80% correct than 80% complete.

The key to good documentoring is: persistence, process, events, empathy. And donuts. They always seem to work.

Write the Docs Prague – Day 1 (Summary)


The Write the Docs community is growing. In leaps and bounds. No doubt about it. Their conferences (both the US and EU versions) have been a hit since they first started 2-3 years back. I admit I was a bit late to the party, but I am glad I had this chance to become a part of this community.

When I found out that the Prague conference dates coincided with my son’s school term break, I knew it was time to pack our bags and head to Europe. While this was the 4th Write the Docs conference in Europe, this was the second year in a row that the Write the Docs EU conference was held in Prague.

Day 1 – Writing Day

Day 1 of the conference was an official Writing Day. A huge, all-hands-on-deck style documentation sprint. Documentation sprints are a great way of getting everyone on the project involved contribute to the project documentation, be it internal wikis/knowledge bases or external user facing content. This allows everyone to get a taste of the documentation process and feel ownership of the content produced. Besides, if you are a tech writer, it adds immensely to your professional equity and builds on your network.

The first day saw a lot of attendees present at the conference venue at 9am sharp, surprising even the organisers. Breakfast, lunch and tea/coffee with snacks were included in the ticket. The writing day kicked off with 3 projects put up as needing help with the documentation:

  • Mozilla Developer Network – The MDN project was basically documenting how the web works. It was a very cool idea where anyone could contribute via new articles/tutorials, editing or proofreading existing content.
  • PyLadies Global – This project involved assisting with the PyLadies blog and working on a new Contributor’s Guide.
  • WikiMedia Germany, WikiData and SparQL – You could help with learning and documenting the WikiData Query Service, proofread existing documentation or document SparQL for end users.


Once the attendees had gathered their bearings post coffee, it was all business, with tech writers, support, developers chipping in with their best effort on their preferred project.
I met a number of tech writers, translators, editors and developers from Germany, UK, Romania, Ukraine and other parts of Europe. It was a really good, swapping stories and experiences.

  • I discovered that a large number of Europe-based tech writers face similar issues with employers as some of their Australian counterparts do – lack of knowledge about the tech writing profession, small and dispersed communities, plenty of startups offering good opportunities and availability of right tools for authoring and publishing content. (Regardless of who I spoke to, SharePoint was never looked upon with great enthusiasm I must admit).
  • A large number of attendees I spoke to were heavily involved in developer documentation or API/SDK content. In Australia, we do not see a lot of such roles regularly, unless you are already a part of companies who do this for their clients.
  • Surprisingly, a large number of attendees have never been part of traditional technical writing societies such as STC, TCUK, ISTC etc and instead favour more spontaneous meetup style activities or events to meet other people in similar roles.

At the end of a tedious day, attendees let down their hair and relaxed with a drink or two at the reception. I thought this was a really good way for everyone to acclimatise themselves and warm up for the conference sessions for the rest of the program.

About Prague

This is my first trip anywhere in Europe and no better place to start off than in Prague. Such a lovely, lovely city. My first impression was that it looked a little outdated, but you soon discover that is entirely its charm. Other places want to modernise themselves, but it is as if Prague set itself a challenge of keeping its heritage listed architecture instead, and succeeded greatly.


My family and I visited the enormous Prague Castle. Built well over 500 years back, it still looks very impressive and intimidating. The gardens surrounding the castle are equally splendid. Although it is a recommended tourist hotspot, there were not many visitors on a wet and cold Sunday evening, which made the visit feel very private and unique. We also did a 2 hour tour of the city on bicycles, which was immense fun as it led us down some interesting alleys and places that we would have otherwise missed.

Is Content King? – A social view of the TWIA conference 2015

[Note: This article was published in the recent edition of Context, a quarterly TWIA/ASTC publication]

I recently attended the first national TWIA conference in Melbourne, on 23–24 October. The conference venue, the Rendezvous Hotel, is located on Flinders Street, one of Melbourne’s busiest streets. Against the background of the clattering of Melbourne’s A, B and W class trams ferrying tourists around the CBD, over 70 technical writers, information designers, technical authors and business analysts attended, participated in, and contributed to the conference.

TWIA_logo_icon only

The conference theme, ‘Content is King’, was suggested by Sue Woolley. Very timely. In a day and age where a lot of tech writers have to learn new tools, technologies and systems to present information effectively to their audiences, we often overlook the key component. Content. It is the very engine that drives the technical documentation vehicle. So, it was pretty much back to the basics with this conference theme, with a few important scenic routes (e.g. customer feedback, user metrics) along the way.

I’ve been to a few conferences in Australia and overseas and, almost every time, one of the first things I check out is not only how the presentations will help me personally or at work (this one is a no-brainer), but also how the various sessions are scheduled. Much as I like learning, it helps to have the presentations I’d like to attend spaced out, in order to avoid conference burnout. That, and opportunities to talk to other delegates and presenters when, how and wherever I can.

It’s all about the content. And cats.

Janet Taylor had done a fabulous job of selecting the presenters and sessions and scheduling them over the two days. She should know; she has been doing this for the better part of 8–10 years. The technical writing community in Australia is close-knit, very receptive and encouraging. The presentations and the audience interaction reflected this in equal proportions. Most of the sessions were very interactive and audience-engaging.

In a presentation on creating documentation from source code, a delegate queried Grant Noble, ‘How did you get your developers to write good comments for docs?’ ‘Very slowly’, came the reply. With the abundance of help authoring and content creating tools available, it was a presentation on Microsoft Word, especially setting it up correctly for maximum effectiveness, that got the most audible gasps and sighs. This was followed by more ‘a-ha!’ moments on Day 2 when Andrew Lockett demonstrated customising Word to use it effectively.

What happens when all that wonderful content we create is published? How are the customers using it? Are there patterns you can identify in their use of the content? Are they providing any feedback or commentary on the effectiveness of the content? I personally found the customer metrics, feedback and analytics sessions on Day 2 the most interesting because the presenters addressed these very ‘post-first-publish’ issues. A lot of tech writers, regardless of their experience or the industry they work in, go through similar issues. Non-cooperative subject matter experts (SMEs), suspicious managers and monosyllabic developers can do their best to throw a spanner in the works, yet we persist.

Overall, a lot of presentations were well received.

(Maybe it was because they featured a conference-standard prescribed number of cat photos, but that’s a correlation I am unable to validate!)


My personal favourite activity during conferences in the last couple of years is live tweeting. Not only does it help keep non-attendees in touch with what’s happening at the conference, I also find it is a great tool for making personal notes. It is an excellent way to let the organisers know what worked (and what didn’t). Believe me when I say the world is listening, especially conference-related tweeting.


Often, I hear something useful in a presentation and tweet about/re-tweet it to the larger tech writing community, getting opinions, feedback and in some cases, answers.





While Madcap Software was the main sponsor for the TWIA conference, there were a few other door prizes. And what good ones too!


Main sponsors Madcap had a door prize of the latest MadPak Professional Suite, which was won by Sheetal McGregor of Frontier Software. I was called upon to present this prize.


Contented, who provide online business and technical digital writing courses, provided a door prize that went to Elizabeth Gibson of AssetOwl. Her name was drawn by Kylie Weaver.


PerfectIt, an editing add-in for MS Word, helps you create error-free content. Anthony Wilkinson from Boeing picked up this prize, presented by Rhonda Bracey.


Brian O’Donnell picked up the first of the TP3 prizes during the conference – the TP3 learning course. Sue Woolley was another recipient of a TP3 prize. These prizes were presented by Andrea Marlan, General Manager, TP3.

In the presenters’ corner

The conference boasted some excellent presenters from around Australia (and overseas). I had the opportunity to chat to a few presenters during the conference and found out some really interesting and cool titbits about their interests and what they like doing outside their sphere of skills.

Grant Noble, when not trying to make sense of developer-written documents/comments, is an avid cyclist and a beer maker. He enjoys long weekend rides on his bicycle, especially those that culminate in a good coffee with his friends. He also enjoys experimenting with various flavours in his home-brewed ciders and beer and takes his craft quite seriously.

Rhonda Bracey is into quilting when she is not rescuing an organisation from inexplicable and inexcusable MS Word issues. She prefers to carry her quilt equipment wherever she goes, enjoys attending (and organising) quilt competitions, and making quilts that are distributed to various charity organisations.

Dave Gash has been honing his vocals and practicing his strings long before he started alternating his time with consulting as a technical communicator at companies like Microsoft and Google. His band, Good Mojo, is a regular at San Diego venues.

Gerry Gaffney is passionate about UX. And that’s an understatement. He lives and breathes user experience. And then some more. He is currently the director of the User Experience Professionals Association.


I find conferences a good place to meet other similar-minded people who don’t mind chatting about technical writing.

A few delegates at the conference had attended tech writing conferences before, most notably those organised by the ASTC(NSW) [now TWIA] and AODC. Although it hasn’t been held for a few years now, quite a few people still have fond memories of the AODC (Tony Self, are you listening?). Vasanthi Govindasamy, who travelled from Malaysia, excitedly mentioned this was her first conference in Australia. Although she was keen on attending a conference, Vasanthi was not aware of any such tech writing specific events in Malaysia or surrounding areas and was very glad to attend the TWIA conference in Melbourne.

A crucial element of any conference is the food, and for some that can be a real deal-breaker. Fortunately, the conference venue managers and the café had excelled in that area. Along with bite-sized servings of fruit, nuts and healthy snack mix at each table throughout the conference, the breaks were well catered by the staff and thoroughly appreciated by the delegates. Jam-filled lamingtons, pastries, danishes and scones rounded out the short breaks.

Lamingtons Scones

Lunch at the Straits Café took the conference dining to a new level. On offer was an excellent spread of salads, fresh fruits, mains, cut sandwiches and cheese platters. A number of delegates specifically mentioned that the food on offer throughout the conference was outstanding.

The networking dinner on Day 1 provided more opportunities to get a feel for what other writers faced, what they were working on and how they were winning over non-believers, one document at a time. I was seated on a table with Craig Simms and Carlee Potter from Campaign Monitor and it was interesting to hear how they were creating and managing content and getting the required support from their managers. Rob Phillips, seated at the same table, gave us a few great examples of how and where the written language has deviated from being Plain English to something that has become overly complicated, confusing and, subsequently, simply unusable.

The very core of a conference is networking. While there may be a lot of useful takeaways from the presentations, delegates relish the opportunity to chat to other technical writers and find out about who’s doing what in their respective projects. I tend to also pick up a lot of information on tools, processes, and opportunities/jobs going with various organisations. It is also a good place for organisations offering technical writing courses and services to meet and find out about the talent available in the market.


We discussed content in its barest form, heard about Plain English, tools (that was always going to come up!), tracking and getting customer feedback, finding meaning out of developer source code; we took comfort in knowing that there is yet hope for MS Word as a tool using various customisations; we understood how Information Typing and Safe Web Fonts work; and we learnt why things such as Frequently Asked Questions should not be a part of technical documentation.

It was a good opportunity to meet ex-managers, fellow tech writers and potential future colleagues. The venue for the conference was easily accessible. We had two excellent chairpersons (Gerry Gaffney and Kylie Weaver) on the two days and the audience was warm, friendly and appreciative of the things we have to collectively go through every single day.

Overall, I enjoyed the TWIA conference and look forward to attending the next one.

MadWorld 2015: A Wrap-up


Flying in from a rather cold and wet East Coast of the USA, San Diego was a beautiful sea-change. The Californian sun was warm, the skies were sensationally blue throughout and I had MadWorld to attend.


Everything from the conference location to the speaker list, from the variety of presentations to the cool Hospitality Lounge made an immense impression.



Anthony Olivier, the founder of Madcap Software kicked off MadWorld by welcoming a room packed full of Madcappers (or so one would hope!) and introducing us to our keynote speaker Wayne Cotter.
I’ve been to a few TW conferences, but I was forewarned by more than 1 person “there are conferences and then there is MadWorld“. Who else would have a speaker who wanted to bring humour to a keynote.

Wayne Cotter comes from an engineering background and one would assume has worked with Technical Writers/Communicators, because he was spot on with his remarks about most things us Tech Writers do. Talking about a recent OS update he made to his laptop, had to say this “Windows is like a trophy wife. Expensive and when you get a new one, you still have to support the old one.” He spoke at length about our profession being an unique one in that we get to catalogue human stupidity and kept the audience in splits for almost 45 mins, with some sparkling gems about warnings, troubleshooting sections etc.
What a brilliant start to the conference!
Well, I was told this could get addictive and it did.

The following are summaries of sessions I attended:
You’re Using Capture with Flare, Right?
The Power of Print in MadCap Flare
Best Practices for Going Mobile
Supercharging Search
Lightning Talks
Case Study: Goodbye Tripane, Hello Frameless Top Navigation
Managing a MadCap Flare Project
Developing Topic-Based Thinking
Embedded Video Production and Integration Tips for HTML5

In between all these presentations, there was ample time to catch up with some friends, old and new and some great networking opportunities. The Happy Hour at the Local Pacific Beach, with its Hawaiian fare made provided an ideal foil to a day packed with content goodness and was a great place to unwind, watching the sun go down on the warm waters of the Pacific Ocean.

This was my first MadWorld, but I am sure this won’t be my last!

P.S. A few photos of the great conference venue…