Coming clean at the 2017 soap! conference in Krakow

I fell in love with soap in 2015. No, not that material you use for washing. The technical communication conference in Kraków, Poland, called soap! with the lower-case “s” and the exclamation mark.

Pink poster of the soap! conference with another small sign showing arrow pointing to the right

I returned for the 2017 soap! experience, which is what I want to share here. I am providing a summary of the conference design, some useful links for additional reading, and all my personal, rather raw notes from the talks. Those are shared “as is”. If you wonder what I meant by something, leave a comment!

I hope some of the information here will inspire you to consider joining the “soapy” community next year in Kraków.

Note: This is a very long post because it covers two days of info from a conference. I wrote it as a reference article for storing my notes.

Where can you find more information about the soap! conference?

The soap! team has a great video summary of the soap! 2017 conference. Watch it if you think this post is too long and too much to read, or watch it for inspiration for your first or next attempt at summarising an event with a nice video.

Other links are:

What is the structure of the soap! conference?

This conference is run by a dedicated group of volunteers and supported by some great sponsors and a registration fee. The conference ran for three days with the main conference on Thursday, 8 June, and Friday, 9 June. On Wednesday, 7 June, there was an all-day Edu Summit filled with workshops ranging from one hour to seven hours. The Edu Summit was only open to the main conference attendees. Topics ranged from DITA to UX to structured authoring.

On Thursday and Friday, the conference ran from 9.00 to 18.00. The doors opened half-an-hour before so attendees could grab a coffee and a bite to eat and say hi to the other attendees.

The location was perfect for this time of year. We used the conference room at the beautiful Manggha museum on the banks of the Vistula River, just across from the Wavel Royal Castle.

Entrance to Manggha Museum in Krakow, Poland on a sunny day with blue skies

The skies were blue and the weather was just right for all three days, with the clouds staying away until we all dispersed after the conference. Sitting on the terrace outside the Manggha café with that lovely view seemed to keep the conversations going non-stop.

This volunteer-run conference also included great evening events: bowling after the Edu Summit, a concert on the banks of the river at the end of Day 1, and a brew pub (T.E.A. Time) after the conference.

The conference always has a theme. This year’s theme was “problem solving”.

They solicited our thoughts for the theme for 2018. Four proposed themes were written up on a whiteboard, and we could vote for a theme with soap! stickers. “Artificial intelligence and content” won the popular vote. Now the committee will evaluate how to make that work as a theme for the 2018 edition of soap!.

What is so great about the soap! conference?

I have to quote one of the speakers, Oded Ilan, on this. He summed up my sentiments in the video summary of the conference.

I see so many young people engaged and interested in [this technical communication field]… That’s the most powerful thing I saw at this event. – Oded Ilan

Why is it called the soap! conference

I learned about the soap! name at the 2015 conference. Gosia Radymiak, head of the soap! team and conference, said it was a fun idea that came up in conversation. They called it “soap” to stand for strategy, opportunity, advancement, and professionalism. Think of it as a fresh, clean start, said Gosia. “It’s something we can relate to, something we ‘just gotta have’.” I think a lot of writers know many manuals that could use a good scrub to get a fresh, clean start! It’s a great analogy.

What was the biggest takeaway from the soap! conference?

It’s all about people and communicating with people. Talk to people. Learn from people. Those people can be those using your products or services and they can be those you work with every day. They can be those you work for or those who work for you.

The talks – my notes and the videos

The remainder of this blog post is a list of all the talks in the order that they were presented along with a link to the video of their presentation and whatever (raw) notes I took.

  1. User documentation vs loser documentation: Great content, no readers?—Dirk Göhmann & Cate Mackenzie
  2. What the tag? From Wiki to DITA CMS in less than 80 days—Barbara Szwarc & Justyna Adamczyk & Mateusz Wiktor
  3. The yin-yang of technical writing. Solve your problems to the user’s advantage—Jarek Orłowski
  4. “Done! Oh, wait… we need translation.” Facilitating content translation process—Dagmara Szostak
  5. Finding your way back from Documentation Mordor—Natalia Katryńska
  6. More than just a technical writer—Maryland Sara
  7. Problems you can solve and create with DITA—Patrick Bosek
  8. Documenting microservicesŁukasz Górnicki
  9. No documentation strategy? Build one from scratch! —Tomek Prus
  10. Need more problems? Start localizing videos! —Anton Bollen
  11. What 1000 participants taught me about productivity—Piotr Nabielec
  12. Overcoming the Forgetting Curve: New Content Creation Paradigms—Oded Ilan
  13. Quality technical training – Making things happen—Szymon Serwatka & Gosia Pytel
  14. Always open – Open source documentation with open tools—Meike Chabowski
  15. Reducing waste in a project with conflicting needs. The story of the 33 miners—Adam Sanyo
  16. Our content sucks, right..!?!? —Alan Miller
  17. The Convergence of Marketing and Technical Communication—Stefan Gentz
  18. Customer success and UX – The ultimate tag team—Paddy McShane
  19. Remote Collaboration for Introverted Geeks and Misanthropes—Brad Schmidt
  20. How to turn local success into global failure—Marta Bartnicka
  21. Rethinking your content. Happifying through improved usability—Joanna Malicka & Tomasz Poznanski
  22. Keynote: Inspiring action through content leadership—Kristina Mausser

View of the stage for the soap! conference with the logo displayed on large monitor

User documentation vs loser documentation: Great content, no readers?

With Dirk Göhmann and Cate Mackenzie from Appway, Switzerland

See the recording of Dirk and Cate’s talk on the soap! YouTube channel.

Great title! You can have great content, but no readers! So true.

What direction do you want to go in? Do we just want to produce great content? Written and published a manual and that’s it?? That can actually be loser docs. No one is interested in it and it never really gets to the reader. How to get USER docs.

Four areas they looked at – the journey they are on:

  • Findability
  • Analytics
  • Testing with users
  • Engagement

1. Findability

Used “Find Waldo” to illustrate situation. The user needs get lost in the chaos. Can you avoid this with “site search”?

What factors are there for your site search?

  • Scope
  • Weighting (how to decide what is really relevant)
  • Presentation
  • refinement
  • Maintenance – need we say more?
  • Performance – slow response is enough to scare away users
  • Showed a nice example of their organisation of information. Started with top level of 9 items. Looks cool.

    Finally talked about inline links. Careful with using them (I agree), but make a dedicated area for pushing people to other areas (like “see also”, “users also liked”, etc.)

    Main takeaways for findability:

    1. Search is a MUST
    2. Organise your content (maybe visual)
    3. Anticipate and link

    2. Analytics

    How do you know your findability works? The answer lies in analytics. Finding patterns in your data. Measurements are numbers. Metrics puts measurements in context.

    Using metrics to answer business specific questions with limited time and resources. What do users love that I should do more of.

    Need to clearly define the goal!! Tracking the wrong metrics can be meaningless.
    AVOID VANITY STATS! Those that make you feel good.
    Measure what matters: What, why, and what. What do I want to learn? Why is this good to know and how can I find that out and how do I implement it and how do I know if it is working? what am I going to do about it.

    Ask for help if you don’t know what to do.

    Get the measures in there so you have the data ready at some point.
    True, measurements can be open to interpretation.

    Analytics takeaways

    1. Have a clear goal in mind
    2. Measure what matters
    3. Context

    3. User Testing

    Numbers can be deceptive. Asked audience if we were enjoying this and nearly everyone said yes. But then Dirk said why – was it because we liked his shirt? So he asked users in audience – give real feedback and that was far more valuable.

    Can use a feedback button.
    Can use surveys.
    Can use face-to-face meetings with real users.

    User testing takeaways:

    1. Make feedback easy
    2. Bigger picture (surveys)
    3. Watch users in action

    4. Engagement

    Would be nice with the roar of the crowds when we publish. When you get negative feedback, it is actually fantastic. I agree. Eye candy. Colours. Font size. Minimal. Different browsers and different devices.

    If you do something great – TELL PEOPLE ABOUT IT!

    How about a doc-a-thon?! Get people focused even if just for one day on your content.

    Do say thank you always.

    Engagement takeaways

    1. Delivery
    2. Communication
    3. Travel (go see your users)

    During the Q&A, someone suggestion a “Doc Day” somewhat like a doc-a-thon. I have also heard of doing “Raids”, which testers often do to plow through the documentation to check for accuracy, validity, etc. Someone asked for a few examples of metrics. Number of page hits (open to debate – maybe refactor the one with 500 hits, not 5 hits), how many support tickets are related to what areas of your content (no support ticket and no one reading it – hmmm).

    What the tag? From Wiki to DITA CMS in less than 80 days

    With Barbara Szwarc, Justyna Adamczyk, Mateusz Wikto from SAP Hybris, SAP Hybris, Braintribe – Germany, Poland, Austria

    See the recording of Barbara, Justyna, and Mateusz’ talk on the soap! YouTube channel.

    Why they moved:

    Mateusz told a cute love story how they got into a relationship with a system. But then they changed. Number of releases a year changed. Needs for versioning were even more crucial. Reuse became poor. Didn’t have the enterprise solution they needed. Top issues were search, broken links, separation of content and form, and manual, permission-based release process. Started to notice a collaboration tool is not a documentation tool. At least not for their product. Growth in the company wasn’t accompanied by necessary changes in their documentation processes.

    The way we moved:

    Justyna told how they moved 10,000 docs automatically thanks to scripts from their Uncle Bill. DITA belongs only to the technical writers. Had to convince the developers that the only good docs were produced by technical writers.

    Life after the move

    Log in via remote desktop.
    Add their content to the structured map. Topics, topics, everywhere. Conversion didn’t specify topics so all were topic topics! Topics were rather long. No TOCs. Random tags! Too many tags not rendered properly.
    Unclear structure, inconsistent content, problems with scrolling.
    Had initial investigate and cleanup. Divided team into committees to tackle the work.
    Introduced regular publishing interval so they could improve their docs EVERY week.
    This led to changes in mindset. Created better docs from the start.

    “Gaze upon my documentation. It is astonishing.” Barbara.
    Had to think ahead and plan the work in advance.
    Worked more at keeping developers informed. More conversations. “Draw some diagrams together – it will be fun.” 🙂

    20 people and 1 DITA expert to do this conversion.
    Remember that all this takes time. Need to change mindset of developers, too.

    Move was for selfish reasons, first, but they also solved issues for users. Thought it was merely a change of tool. Turned out to be a change of mindsets. Writing is better and more structured. Feedback was extremely positive.

    Q: Why 24 hr turnaround for deliverables. Due to a procedure to not overload server perhaps. J said it is because they don’t have dedicated servers for their output. B. said they are planning to have their own servers. Also so many builds put in the queue so it takes a while.
    An audience member said he could do it with one writer manually in 2.5 months.

    They still use Confluence as their internal tool.

    The yin-yang of technical writing. Solve your problems to the user’s advantage

    With Jarek Orłowski, Lead Information Developer, Dynatrace, Poland

    See the recording of Jarek’s talk on the soap! YouTube channel.

    Writes application performance management (APM) docs. His company was previously named CompuWare.

    His users are analysts who check metrics and draw conclusions, dev/admins who just install machines, but don’t care about the performance, business (CTOs) who want software to work as expected and sometimes verify this by looking at the docs, support, sales/partners who perform PoCs (one customer is MoD in UK who only allow you to enter premises with a piece of paper – i.e. docs become important).

    Started out with DocBook. CompuWare bought up lots of other companies, which meant getting a new ecosystem of tech writing each time!

    Ha ha! His company moved from DITA to Confluence.

    He published 10,000 topics to Confluence daily and it killed the server.

    His stories for his presentation covers

    1. being the new kid on the block
    2. being the curator
    3. working with devs – docs as code
    4. being customer support assistant

    Being new, do you ask how should I write something, why I should write something, when I should write something, and how much I should write? You also have to deal with technology: tools, subject, (domain) knowledge, and processes.

    Being the curator means you also deal with content from others.
    I like his Death Star picture with an actual quote from a content provider who wasn’t a tech writer: “It is imperative that a full description is provided with as much detail and reasoning as possible”.

    Those who make graffiti call themselves writers.
    I like his photo of graffiti writers and their work followed by a curation of their work in an art gallery.

    Collaborative authoring:

    • The hardest step is to step back
    • Appreciate input
    • Be kind!
    • Show the difference (Nodded with neighbour Joanna at this!)

    Docs as code – Pointed out word “project” was missing

    Immerse yourself in the dev! Be a pig, don’t be a chicken.

    Points about code as docs:

    • Don’t be a chicken
    • Fail early
    • Commit
    • git not email
    • use the same tools
    • Code is information

    Customer support
    You ARE the support – solve problems before your user knows.
    Build relationships.
    Get feedback.
    Continuous improvements (on doc sets and processes)
    Communicate early.

    Listen carefully: (takeaways)

    • Know what you write
    • Be a wordsmith
    • Your skills are precious
    • Users don’t bite

    A Polish site for technical communicators: fb.com/uContentowani

    Quote on a photo of Kurt Vonnegut sitting on a box marked “SOAP”: “Pick a subject you care so deeply about that you’d speak on a soapbox about it.”

    Said everyone is saying that you cannot commit fully to the scrum teams.

    He’s not part of Definition of Done – only for UI text.

    “Done! Oh, wait… we need translation.” Facilitating content translation process

    With Dagmara Szostak, Project Management Specialist, GET IT Language Solutions, Poland

    See the recording of Dagmara’s talk on the soap! YouTube channel.

    I don’t work directly with translational – I just “write for translation” – but I’d share this talk video for those who have to make decisions about translation and localisation.

    Areas where problems may arise:

    • Terminology: So important to keep consistent terminology, which is also compliant with the customer’s needs.
    • Platforms
    • Quality of the source file
    • The process

    Gave a bunch of tips.

    One example told of pain of no versioning.

    Don’t embed text in images. Don’t embed images in text.

    Advocated style guides (yay!), but had specific recommendations on a slide.

    Re: the process and the quality of the source file. Think of the flow of the documents and keep track of the versions and the quality of the files.

    Write source content so that it is easier to translate. Simplify, gender neutral, no abbreviations.

    Treat your LSP as a partner IN the process & in return you will gain a cooperative partnership & a successful outcome.

    Finding your way back from Documentation Mordor

    With Natalia Katryńska, Senior Technical Writer, Poland

    See the recording of Natalia’s talk on the soap! YouTube channel.

    Sharing some documentation demonstrations.

    She says you need to prepare your environment, your workplace. Build a doc infrastructure.

    [This makes me think of people not following a dictated information model. How to get them back on track. They need to understand that this infrastructure isn’t there to thwart them. It is there to maintain the professional and high quality of the documentation.]

    Her takeaways

    • Talk with your teammates and get inspired
    • Start counting to 3 and automate your work
    • Test your solutions
    • Enjoy it!

    A colleague once told me, “If it can be automated, automate it”. Echoes Natalia Katryńska’s message: Automate your work.

    Always open – Open source documentation with open tools

    With Meike Chabowski, Documentation Strategist, SUSE Linux, Germany

    See the recording of Meike’s talk on the soap! YouTube channel.

    They receive info. Then they move to Trello to evaluate, accept, and organise. (Had to get permission from their workers’ council to use it – wonder why? Possibly religiously open source?)

    The classic programmer paintings are hysterical!

    SUSE has their own style guide.

    They use git. All can contribute.

    Github
    Gitlab
    Gitflow

    Format with XSLT style sheets

    Their DAPS builds the doc and does validation. Would be nice to have.

    Oh! They have a style checker. Stylechecker built in-house. Checks re abbreviations, figure titles, sections, terminology, sentence length, nerdy phrases, etc.

    LibreOffice OpenOffice has a style checker.

    Problems you can solve and create with DITA

    With Patrick Bosek, Co-founder & Director of Customer Success, easyDITA, US

    Completely missed this talk due to chatting with someone long after the break prior to this session.

    See the recording of Patrick’s talk on the soap! YouTube channel.

    Documenting microservices

    With Łukasz Górnicki, Product Owner, SAP Hybris, Poland

    See the recording of Łukasz’ talk on the soap! YouTube channel.

    Been at SAP Hybris for 10 years.
    He was fascinated by the architecture of documentation more so than writing it.

    Compared microservices with a school of fish. Looks like one unit from outside, but has many replaceable units “inside”.

    Architecture: Have to build everything from scratch, otherwise you’re doing it wrong (when moving from monolith to microservices).
    Designed for the cloud.
    Most use REST API over HTTP.

    Services are independent, but documented in one portal. So developers’ challenges become yours.

    You can write microservices quickly. More are forthcoming and teams are extending. Need to scale accordingly.
    Involves continuous development and deployment which adds more demands to the documentation.

    Main principle for microservices is “You build it, you run it”, that is, eat your own dog food.

    Reasons to become a writer for microservices:

    • Ready playground and production environment
    • You really become a “technical” writer and you quickly learn things
    • Continuous release = continuous feedback = continuous improvement

    Talks about “destroying” current doc department/org.
    So TWs are real dev team members with the same manager as other team members.
    Community of Practice that works together on standards and best practices.

    (Quoted Rahel for saying that scrum teams are actually micro silos. True! Gasp.) But he says his CoP helps to bridge that problem.

    New scrum team with cool name that consists of documentation architecture, trainers, language reviews,
    New scrum team that consists of documentation architecture, developers, and works on doc solution.

    Developers start to treat writers as a team member.

    Their writers are talking “developish”. So developers begin to really like their writers.

    “We can’t release it without documentation. We need to document and talk to Q team to get a language review”

    “I don’t like how it is formatted in the UI. We need to talk to the doc team to improve it.”

    (mentioned Spotify using scaled agile)

    Technical change in theory:
    All content stored in git repos with the code.
    Documentation and release notes kept together.
    Central registry of each doc topic.
    Portal template based on static site generator.
    Continuous integration plans.

    He uses docpad.org – it’s what they use as a static site generator. Has details of API documentation template for DocPad at https://github.com/yaas/docpad-skeleton-apidocs.

    No documentation strategy? Build one from scratch!

    With Tomek Prus, Documentation Manager, Unit4, Poland

    See the recording of Tomek’s talk on the soap! YouTube channel.

    He started by just observing.

    Implementing a strategy is a long-term job. Made reference to strategy games, which he used to play before he stopped having time to do it!

    Starting point for doing this is conducting an audit. Checked for

    • Types of content
    • Internal stakeholders
    • Requirements
    • processes
    • content quality
    • effectiveness of your info model

    Checked results of audit. Resulted in among other things creating a style guide and setting up templates for consistency. Also established quality criteria.
    Nice to hear he is also part of the Definition of Done. They use Flare, too.

    They have 12 different types of docs in their old info model!
    Made new model.
    Cut out some things from translation which saves time and money.

    Pointed out four main areas of documentation to focus on in this model:

    • UI Strings / embedded user assistance
    • Online help (guide tours, examples)
    • Release notes (what’s new)
    • Reference manuals (installation, troubleshooting, configuration, system description)

    They have 2 test types: by writers and by testers. Writers mainly test that the help is available.
    Wow! They do a lot of translation and localisation!

    Built strategy pillars.

    Important that tech writer is part of team and that translation is a key enabler.

    Content must be

    • Easy to translate
    • Consistent
    • Easy to read
    • Engaging
    • Easy to find

    In “Design > Measure > Analyse > Improve > Control” implementation cycle, he emphasises communication!

    One of tips & tricks is “Documentation is a part of a product. Always.” Amen.

    Need more problems? Start localizing videos!

    With Anton Bollen, Technology Evangelist, TechSmith, Germany

    See the recording of Anton’s talk on the soap! YouTube channel.

    Anton loves video.

    YouTube is second most popular search engine – after Google!!!

    Bigger use on social media.

    tekom survey: 38% using video.

    Video elements are visual and text and audio and cultural.
    What do you really NEED to localise to achieve your goal with the video?
    Factors:

    • Type of video
    • Audience and expectation
    • Content and content design
    • Resources

    Onboarding videos were so crucial that they decided to localise everything. Too important to ignore.

    Cool tip: Made audio recordings for each step in script that were possibly only a few seconds long. That made it super easy for a non-Korean speaker to synch video with audio. Cool! Very pragmatic. Fine for getting started when you have only a few languages or a few videos. It is time consuming and hard to scale. What to do? Design with localisation in mind. (More detail outside scope of this talk, but he had a couple of pointers.

    Important: de-emphasize audio narration. Reduces localisation and synch needs.

    Captions: Support many languages with a single video file. Captions can actually = more audiences with relatively little work.

    To scale up, they went for a translation partner.
    A translation partner needs info, context, and guidance.
    So they made a video style guide. They also made an enhanced script. Added more and earlier review cycles, made audio pronunciation key. This worked. All this saved about 2 days of back and forth and probably added only 1 hour extra work.

    Question: apropos numbers and what they say. what is the 38%. Is it just using videos or is there also written material?
    Videos should be short. Only meant to enhance or provide variety and not to replace text. Nice answer!

    What 1000 participants taught me about productivity

    With Piotr Nabielec, Chief Productivity Officer, Produktywni.pl, Poland

    See the recording of Piotr’s talk on the soap! YouTube channel.

    We didn’t have smart phones 10 years ago.

    8% are systematically planning implementation of priority goals.

    4 years ago he thought doing lots of stuff meant being productive and had 13 concurrent projects. Wrong.
    2 years ago reduced to 3 projects.

    (He does still believe productivity is about having fun, too.)

    Plans one week every Sunday. Defines tasks for the week. Brains love it because you have fewer things to think about.
    2 recommendations: Asana and Todoist.

    His slide of apps doesn’t include Trello because Trello is only good on big screens.

    Cut out distractions. StayFocused app!

    How do you track progress.

    Bad if you cannot answer “what are the 3 most important things that I want to achieve next week”.

    What are the 3 most important things that you want to achieve here at soapconf?

    Think about spending your time wisely. Can’t spend time like you can spend money.

    OKR Object and Key Result

    How do we organise “near future” projects – projects are “currently running”, “near future”, “maybe someday”.

    Idea: some details.
    In Analysis: what is the goal, how do I know when I am done, how do I track progress (I skip this part, which isn’t good).
    In progress: Ready to be split into tasks and feed weekly/daily system.

    Showed Trello example. He moves 60% of the stuff that moves to analysis BACK into Idea because it’s not the right time to do it. Food for thought!!

    Gather materials for “maybe someday”.

    Tools cannot ask you why are you doing this? Or tell you that you have too much to do this week.

    Q: what to do when outside influences changes your plans.
    A: Remember that your influence is limited. Ensure that your stuff is prioritised. Then you can handle the ad hoc stuff by comparing the value of each and help you to prioritise a bit. You might not be able to handle the prioritisation because you don’t have the power, but at least you know where you stand with the things that you do have power over. (Someone from the audience also suggested the pomodoro technique.)

    Also do Retrospective every week!!!!!!!

    I really enjoyed listening to Piort at soap! 2015. This second talk was also great.

    Overcoming the Forgetting Curve: New Content Creation Paradigms

    With Oded Ilan, Chief Marketing Officer, Iridize, Israel

    See the recording of Oded’s talk on the soap! YouTube channel.

    We forget 50% of what we learn within 1 hour of learning it! – Herman Ebbinghouse 1885.
    After one week – 70% unless we put it into practice.

    Today our world has a lot more data (i.e. a lot to remember or forget).

    The way we use the internet is changing our brains.

    Do you remember your FRIENDS’ phone numbers??!

    Using our brain differently. We find info – finding is a skill. Sifting through that info is also a skill. Recognising what you need now is also a skill!

    Stop thinking about people remembering your info.
    Start thinking about how people USE info on a daily level.

    25-30% of today’s job types didn’t exist 25 years ago.

    What’s more important: performance vs retaining.
    (My reaction is performance.)

    People want to get answers to THEIR questions RIGHT NOW.
    Provide only what is needed to hit the ground running. (Classic progressive disclosure.)
    Get what you need when you need it and not afterwards.
    Info needs to be digestible – entertaining, small bites, relevant.
    Supportive rather than instructive training. This means something that is ongoing.
    Training should be self-paced and always available.
    Metrics (He feels this is SO IMPORTANT) – measure for results and improvement. Just do this! (Diff between training and teaching – doing rather than learning.)

    Because tech has changed us, training should support the new human thought process.

    He feels contextual content is also highly important. Info available when the users need it.

    Micro sessions: small snippets of info specific to what people need and not more. Too much info? – They might stop along the way and not reach something critical at the end.

    Personalised content can be good. (Like logging in to FB in the morning and it says good morning and this is the temp.)

    Measurement and big-data generated training is another area that he has already mentioned.

    I asked a question about metrics – how to find good questions. Ask around in the company. Use intuition to start with. Do A/B testing.

    Someone asked about size for tool tips and other UI things. Think of using Twitter philosophy of just a few words.

    Useful talk – worth re-visiting in the video.

    Our content sucks, right..!?!?

    With Alan Miller, Managing Director, Simply Consulting, UK

    See the recording of Alan’s talk on the soap! YouTube channel.

    Our content doesn’t really suck. Recognition is important to our success. Our confidence, pride, ability, and acknowledgement of our value are key. We must take back the narrative.

    Here’s the problem:
    Everyone has an opinion (like everyone has assholes).
    All the focus on what’s missing or poor. No one looks at what is successful!

    But what if it is us allowing this narrative??
    We discuss how fresh our docs are. Talk about completeness and accuracy. We discuss our technical acumen. Agree! Can’t use terms like DITA, structure, CMS, etc. outside our own little world.

    We’re just framing the discussion the wrong way.
    A challenge when you meet criticism – if it was as easy as they say, it would already be done.

    Zip up your grown-up suits!!

    Lots of talk about customers here at soap! this year. GOOD! Also measuring things about customers.

    They value credibility and knowledge about the product.

    Have the confidence to truly know what the customer needs – be prepared to hear it firsthand. Like feedback. He would call customers for whom he had fixed a content problem and said thanks and it’s fixed and was there anything else he could help them with.
    Define the customer needs simply and share it widely (with your teams/department/etc.)
    Summary: start with customer.

    You need to know what is stopping customer from purchasing goods. Then stop seeking permission to go and fix the problem. Charge out and set the example by acting on the need.
    Leadership needs leaders.

    WHO is saying that our content is crappy and difficult to change? Doesn’t help if WE say it. Get people to focus on the why – what the customer is asking about – and let them focus on the what and how. Don’t assign tasks – empower team members.

    Momentum is a virtuous circle. If you make small changes, get customer delight, get happier writers, and on it goes. Have success and share it with the people.
    Inspire team to understand what the customer needs and empower them to go achieve the outcome.
    “Shoo away the magpies” – be wary of bigwigs saying “that is dull, let’s do this – shiny, shiny”. Show them the money.

    You want to understand what is working – metrics for you – just enough science to survive.
    Whose responsibility was the success? Doesn’t matter. A win is a win! Have confidence in what is happening. Worst you can do is produce great content that isn’t adding value.

    You’re on the verge of greatness, does it sound like it? People can see what you do has an impact. Focus on progress even though it is all about outcome.
    Why are you explaining this to people? We’re explaining details and not focusing on outcome.
    Do the people you speak to deserve your time explaining things – do they deserve to be educated? Don’t get drawn into explain why things are good.

    When content providers feel pride, it is a motivator to take on the next challenge.
    Also be proud when you hear “content is improving” around you, but don’t say “I told you so”.
    Third who will understand things are great, third who don’t understand but know because you told them, third who never care.

    This lets you have freedom to operate, recognition, and (possibly) money.

    Content is becoming a commercial specialism and a strategic asset.

    More than just a technical writer

    With Maryland Sara, Information Developer, SAP Hybris, Germany

    See the recording of Maryland’s talk on the soap! YouTube channel.

    How a tech writer can become a scrum master.

    • Expands your skillset
    • Adds value
    • Leverages existing skills
    • Gets more insight

    How?
    Study the scrum guide (and lessons “out there”)
    Connect with other SMs
    Learn by doing
    Consult other scrum teams (teaches you their best practices)

    5 out of 20 techwriters are TW/scrum masters!!!
    Their thoughts?
    Gain better understanding of a bigger picture
    Solving problems and organising things
    get an overview of what team is doing
    Build strong human relationship
    More involved in the project
    I like to help my team

    What if you are both? Benefits?
    Encourages more visibility
    Helps you to know your team
    Improves your communication skills
    Increases the quality of your product and docs

    Reducing waste in a project with conflicting needs. The story of the 33 miners

    With Adam Sanyo, Senior Information Developer, ARM, Hungary

    See the recording of Adam’s talk on the soap! YouTube channel.

    Phase 1 create a public beta website and add some of the existing content to the site
    Phase 2 (he thinks is most interesting) improve and deliver: improve the wesbtei’s features and deliver live documents
    Phase 3 migration: migrate all existing public tech docs of ARM

    Waste reduction was also important to point out.

    1. Created a process for delivery jobs with clear reqs.
    2. Several related errors were corrected at once.
    3. Established direct link with developers and taxonomy team.

    Quality technical training – Making things happen

    With Szymon Serwatka & Gosia Pytel, Learning Manager, Dassault Systemes, Poland

    See the recording of Szymon and Gosia’s talk on the soap! YouTube channel.

    He uses ReadyTech as the training service in the cloud.

    They were 3 people (another one in California) who got 20 people coordinated to make improvements and even add certification to their training program in just 1 year.

    Had printed & shipped PDFs. Switched to SCORM packages all online-only.
    Went from training server in a desktop to training server in the cloud.
    Went from 100% classroom to blended classroom/self-paced online learning.

    Developed great working relationships with experts.

    Q: Do they get complaints about no classroom?
    A: This offering is just one offering. They also have mentors and regular Q&A sessions. They didn’t eliminate humans from the equations. (Q&A webinars sound like a great idea!)

    Q: What did they produce?
    A: PowerPoint plus SCORM packages. No talking heads. Business reasons: cost. Just went for Minimum Viable Product.

    The Convergence of Marketing and Technical Communication

    With Stefan Gentz, Worldwide TechComm Evangelist, Adobe Systems GmbH, Germany

    See the recording of Stefan’s talk on the soap! YouTube channel.

    Still silos about marketing and techcomms. Unconnected. Seems like it’s in the future. Talking about the future is talking about expectations.

    Techcomm is changing. People are changing as well.

    Transient attention span 12 seconds in 2000. MS study.
    In 10 years, went down to 8 seconds.
    There were attention impact factors.
    Media consumption, social media usage, tech adoption rate, multi-screening behaviour.

    60% of visitors to Adobe techcomm page only consume from mobile!!

    We need to present info on all channels. Let customer decide where they consume it.

    He showed a great example with GoPro Hero5 material. Sexy marketing stuff and awkward tech docs.

    They call it blended communication – marketing together with techcomm.

    Technical communication is marketing communication. (Yes, think about it.)

    As Jarek pointed out in his question, it’s a matter of content strategy to get marketing on board with this.

    Customer success and UX – The ultimate tag team

    With Paddy McShane, Customer Success Manager, Optimal Workshop, Ireland

    See the recording of Paddy’s talk on the soap! YouTube channel.

    UX and customer success are the ultimate tag team.

    He is a Customer Success Manager. That title really exists! Especially SaaS companies.

    They didn’t want just users, they wanted successful users. They looked at other orgs to see what they were doing to achieve success. Looked at those with good user experience. E.g. he uses Slack and feels it works best for him so he is a successful Slack user.
    Also looked at those who weren’t successful.

    He appreciated the creation of personas from the UX team. Learned the people they were talking to weren’t customers, but researchers.
    Learned about language. Knew they were researchers so they knew how to talk to them.
    Just say it like you mean it.
    Learned his users were researchers, learned how to talk to them. Learned to be careful in the language he used, otherwise he would be found out very quickly.
    UX team helped with all this.
    “Desired outcome? That’s what you want to do? Use these features to do that…” Have to know Desired outcome so you can manage their expectations. As effectively as possibly, not necessarily as quickly as possible.
    At this point, they had info to take back to the UX team. This is what makes our researchers successful so let’s design around this. UX team could go in and cut out the fat. Kept only successful researchers.

    He likes the word/concept of friction.

    Per Axbom talks about Friction.

    Hurdles need to be removed. But Per says this friction is an opportunity to stop and think.

    Told of a company that was too fast so not trusted and believed to be inaccurate.
    Told of story of wanting to inquire about a B&B in Krakow and ended up booking it before he knew it! Too fast. No friction.

    Not everyone needs you and you don’t need everyone. How many actually use your product? No friction might get someone onboard, but then not a user and then not a successful user.

    Support – great place to get more input (user research pool) for the UX team to work with.
    Reveals what the user will experience.
    Support can have potential customers – those who are asking questions because they are close to being successful but not quite there and asking a question to get there.
    Demos reveal a lot, too. He’s a super user of their tool. He demos. If he encounters any problems, he is a rich source of info that UX team can also use for improvements.

    Use customer success principles together with UX.

    Must also know what an unsuccessful customer is. Learned this from their support team.

    He had good relationship with marketing. More trouble with sales team, actually. He has got that to change now. It’s about managing expectations and making sure all are singing from the same hymn sheet.

    Remote Collaboration for Introverted Geeks and Misanthropes

    With Brad Schmidt, Documentation Specialist, MSD, Czech Republic

    See the recording of Brad’s talk on the soap! YouTube channel.

    When on a call or podcast, be engaged: stand up, smile, & gesture when talking on conf calls!

    Cultural awareness goes a long way. Oh yeah!

    Virtual Teambuilding is a thing. “Scavenger Hunt” is thing for getting new teams to get to know each other. “Picture This” is about collaborative resolution.

    Structure helps! Makes it easier for reserved people to share ideas, opinions.
    Identify yourself on calls to help people match your name with your voice. Use people’s names when asking questions.

    “Treat others as they want to be treated” – platinum rule!

    Being a better collaborator will change how people relate and connect with you.

    At some point, someone shared this link which is a Google search for “extroverts understand the value of introverts in the workplace”.

    How to turn local success into global failure

    With Marta Bartnicka, Manager for CEE, IBM Translation Services Center, Poland

    See the recording of Marta’s talk on the soap! YouTube channel.

    Covers globalisation, localisation, and internationalisation.

    Why worry about translations – because of money (lost revenue, costly adaption later on).

    She showed some examples of failures and then an IKEA image as a way to avoid language altogether.

    The more global you go, the more factors you need to consider.

    She recommends a free reference: IBM Globalization Design Guidelines.

    Didn’t know that the owl was a symbol of stupidity in India.

    Great link to fun facts about names, that is, what trips up programmers about names!

    Some phrases that can trip people up: West Coast, the first day of the week, Christmas time.

    Wow! Respect to Polish postal service who managed to deliver a package sent to #%D; (which should have been the city named Łódź)!

    Wow. Real story. Phone being tested for Arabic-speaking countries. Could not offer a Hebrew version because it was regarded as offensive.

    Rethinking your content. Happifying through improved usability

    With Joanna Malicka & Tomasz Poznanski, Learning Services Project Manager, Content Designer – Motorola Solutions, Poland

    See the recording of Joanna and Tomasz’s talk on the soap! YouTube channel.

    They are from the Learning Department (training). Critical communication for product safety.
    Transitioned from PDF to web help.

    Followed steps in design thinking.
    Talked to the users in regular conversation.
    Users didn’t like the jumps from their links or having to use several manuals to fit their imagined scenario.

    First issue was about navigation. Based on info model that was a bit old. Cross-reference links were OK at beginning when less complexity. Not now when they have over a million links.

    Had test phase where they performed A/B tests. Wanted to avoid putting old content into new wrapper.

    Gained immense value from building a prototype and testing it. They loved their prototype and thought others would like it, too, but others didn’t!

    Define > Ideate > Prototype > Test. Take notes from Test and repeat.

    Cautiously optimistic to cheerful – the range of feedback they got.
    “Webhelp is great, but where do I get the PDF?”

    Q&A: They did this on their own to get the experience rather than hire external consultants.

    Keynote: Inspiring action through content leadership

    With Kristina Mausser, President and Senior Content Strategy Consultant, Kina’ole, Canada

    See the recording of Kristina’s talk on the soap! YouTube channel.

    Definition of Kina’ole is great – a Hawai’ian word for “flawlessness”. “Doing the right thing, in the right way, at the right time, in the right place, to the right person, for the right reason, with the right feeling… the first time.”

    What happens when there is no uptake on your great idea?

    Parks Canada looks after all the great nature areas in Canada.
    Had to rethink its content culture when they went on the web. Parks in person were great experience, but how about the web.
    Small team in Ottowa managed site for entire country. But different parts had different info needs.
    Team chose to focus on content, not people. Content problems are business problems. Made policies around who can publish what. “The more policies, the less buy-in you’ll have for your ideas.” > Orgs can’t be mandated to change their corporate culture so they might end up going rogue.
    Studies show that the less control people have, the more stress they feel.
    So you stress people with these policies and you can end up having shelfware.
    (Make sure the style guide is not shelfware.)
    So focus on content wasn’t helping. Had to focus on people.

    Because content problems are people problems!! Focus on discovering internal motivations for content decisions.

    More to change than change management. Empathy is a noun, but you need a verb for action.
    She prefers empower. To make someone stronger and more confident. She likes it more because it’s a verb.

    “Content leaders who provide vision, direction & inspiration are critical to a content team’s success.”

    “We often forget importance of internal communications. It’s a fundamental component of change management.”

    A whole lot has to happen for the ta-da moments to happen. She showed slide of the pyramid of this stuff with buy-in and support at the top. Bottom row is internal communication infrastructure. Next layer is employee engagement, then change communications. All helps to build up to the ta-da moment.
    If you don’t know what your role and place are, you can’t get behind the ta-da moment.

    Content problems are Leadership problems. Means you have no comms and you are relying on ta-da moments. (77% of employees don’t undertand their responsibilities.)

    What can we do as content leaders? Focus on learning instead of lecturing. Show, don’t just tell.
    Content team members are motivated by opportunities to grow and develop. (Colleen’s survey).

    Take five ideas you get from soap! and share with your team. Gives a starting point/foundation.

    She uses customer journey maps.

    Focus on problem solving, not problem selling.
    Companies focus on product fixing, not solving. Solving goes deeper.

    Focus on ownership vs accountability.

    She likes to delegate tasks with high a-ha moments. Often to content owners because a-ha has bigger impact with them.

    Focus on Collaboration rather than teamwork.

    Create content in spite of silos, not around silos.
    Docathon is a collaboration idea.

    Develop playbook that encourages autonomy, rather than policies.

    Finally, focus on inspiration and not ideation.

    She says leadership and content are more important today than ever before.
    Content needs leadership. Great leaders set out to make a difference.

    Content is King coined in 1996 by Bill Gates.
    Had connotation of importance over power.
    But this idea has degraded over the years because we talk about content being power – power over importance.

    After this conference, it’s important that we all become content leaders.

    My first UA Europe conference – but not my last!

    I couldn’t turn down an opportunity to visit Krakow. A brand new city and country for me to visit. Yay! It involved attending (and speaking at) a technical communication conference. Mixing a conference and tourism is my geeky idea of a vacation.

    UA Europe is a technical communication conference held in different cities around Europe each year. This year, Krakow was host to the event. I flew in the night before the conference began (like, at midnight) and stayed on for 2 days for some sightseeing. The Technical Documentation Manager from my company attended the conference, too, so we split the session between us. This blog post is a summary of the talks I attended. The notes are lightly cleaned up raw scribbles. If I had any thought bubbles to share publicly, I include them here in square brackets. If I take time to edit these raw scribbles into a better narrative, this post will be dated 2015…

    Matthew Ellison welcomes us

    After breakfast in the hotel and registration with the friendly faces behind UA Europe, we were ready for Matthew Ellison’s welcome speech. He introduced a cute quiz in our bags. There was a list of 17 music bands – one for each of the countries represented at UA Europe. Actually, we only had a thumbnail of the bands. We had to 1) figure out which country they represented and 2) figure out what technical communication “thing” they represented. You see, we had to fill in our areas of interest with our registration. If I wrote “MadCap Flare”, one of those thumbnails represented Flare and was on my name badge. We could look for others who had the same thumbnails and know that we had at least one area of interest in common. This was a great idea and I had fun trying to figure out what areas of interest were represented in one of the groups I was in at one point during the day. I think I had one right – and I forgot to turn in my slip for the competition. Oh well!

    Who are we? A mirror for UA professionals – Welinske

    Joe Welinske, WritersUA, started the show with a walk-through of his famous (in the world of technical communication) surveys and their results. (It’s worthwhile signing up for his low-volume newsletter, which will also notify you about the surveys and the results of those surveys.)

    Various snippets from the presentation. Interviewing is number 2 in the list of things techcomm’ers do all day.

    He used to have a question about doing indexes. Now he split the old index question into search and index. Gave 28% and 48% split as a result.

    He was surprised content reuse hasn’t changed much – now 63%.

    Usability testing is only 39% which he also thinks is low.

    DITA now 21% and has slowly been rising.

    He has been combining HTML and CSS, but will split it next year to break that down.

    He sees more need for techcomm knowing programming languages and scripts. Those ranked at 10% and 7% only. [I see the problem as being time for on the job training.]

    24% use HTML help which was last modified by MS in 1998!!!

    In the next survey, he’ll break apart the browser-based help to get more granular.

    PDF Manuals 77%. 22% do print. [I wonder if he connects it to the industry – manufacturing is probably strong here.]

    Social site are increasing to 13% [wonder if those people also use it privately – any correlation?]

    Wikis at 2% but many use internally and not as open forums. [I wonder about use of mobile platforms vs country and culture. He said Windows Phone is popular in Poland, so I wonder if that influences what platform products are developed on.]

    Agile and DITA are growing. [I wonder if he should also have TBA listed as a variant of DITA.] Microsoft and Amazon are now starting to use DITA

    [Seems he doesn’t have many respondents that have only a few years experience. [I wonder if he is just not reaching the younger audience. Ask him if he knows that Scott Abel is looking to get in touch with those under 30.]
    [Mette asked about his EU salaries and perhaps getting more EU input. Maybe ISTC and Cherryleaf could help promote it more to get more data from EU.]

    Responsive web design in user assistance – Self

    Dr Tony Self, HyperWrite, talked about responsive vs. adaptive. Ethan (Marcotte) did responsive and Aaron (Gustafson) did adaptive. Tony says adaptive is broader in scope. Adaptive uses JavaScript and browser sniffing.

    [I think there is some nervousness about browser sniffing in the screen reader community but I can’t remember the details. I know I’ve seen tweets from Jennison Ascunion and Leonie Watson about this.]

    [I really need to check out media queries some more]

    Progressive enhancement is the responsive way to do things.

    Mobile first is more a mindset thing. [Thought of Janet Swisher’s “Mobile Matters Most” phrase.]

    He says adaptive is good, but responsive is better.

    Remember to base breakpoints on content.

    Showed Chrome Emulation Mode Tool in Developer Tools in the Chrome browser.

    You design for viewport browsers and don’t have to worry about new platform builds.

    Loads of example grids in this article from Design Instruct.

    Practical HTML5/CSS3 for real writers – Gash

    Dave Gash, HyperTrain is a code guy, not a concepts guy. Looks at HTML5 CSS3 from techcomm angle. we focus on content and HTML5 provide elements for that.
    (typable is not typing but semantic typing)

    Have to discuss semantics here. Not much semantics in HTML but there is a lot in HTML5. DIVitis in HTML4 that has no semantics. Doesn’t tell you the organisation you intended.

    HTML5 took HTML4 divs with ids and class and turns them into HTML5 elements. HTML5 elements are what they mean, they are semantic. Remember: HTML5 elements don’t do anything! They have to wait to be styled. (Remember separating form from content). This is the heart of structured authoring.

    He’s not a fan of browser specific features in CSS3. Prefers things to work across all browsers.

    [He makes me think he could do a CSS3 Zen Garden for TechComm.]

    I like his link-nudging thingy.

    Wanted to explain that divs with independent classes can be overdone in HTML and therefore you lose sight of your structure with div div div. Must look and read classes to understand the structure of your page.

    His take on mixed case: dislikes immensely because it causes problems. You have a harder time troubleshooting.

    Prefers use of dependent classes/selectors because it is safer.

    Contextual or ‘descendent selectors’ (new term). Means the second element listed after a space will only get something applied only when it is inside the previous element and possibly where that previous element specifies the class. E.g.: ‘aside.navsidebar img’

    Key point he had in parting:

    Remember, learning new stuff is good for everyone: you, your users, your company

    [I told him about using WAI-ARIA. He didn’t know about it, but was immediately curious to learn more.]

    Designing transactions successfully – Atherton

    Dr Chris Atherton, Equal Experts, works with a part of gov.uk. They said they had to be accessible, usable, assisted digital, mobile. Assisted digital is helping users help themselves.

    She was told she had to do user research almost every other week.

    Shareable pain – film people using something and then show the film clip to the powers that be. That has a lot of power to change people’s mind.

    First point: How to improve readability and usability by limiting page content. People can only take in so many things at once.

    Nice transition from page full of questions to a page with one question only. Then save and continue button.

    Not many in the room are doing discussions about, say, how to make forms cleaner like this example.

    Great slide about war crimes. Perfect for some plain language treatment. When is less more or enough.

    Snowflake pattern – I’m a snowflake, I am special. Like progressive disclosure.

    Get it wrong a lot early on is my best advice

    Hint text – to help you decide what to answer and hint text to help you understand the question. Subtle difference.

    Dislikes free form field because it is hard to parse for the admin handling the form.

    Trying hard to show only what’s relevant.

    Talked about the name field that is culturally challenging.

    They have to ask for Titles Mr, Mrs, etc. because a backend system requires it! We shouldn’t design for the systems, but for the people!!

    Use visible navigation to frame users understanding of what’s going on and just where they are.

    Cool explanation about discussing patterns to find a good nav.

    A case study of enhanced user assistance in the GUI – Khurana and Tiwari

    Rajesh Khurana and Rajeev Kumar Tiwari, Ericsson India Global Services presented this case study.

    Wanted to place an icon in the GUI that can show context sensitive video help is available. They have traditional ? as help icon, but now have video icon to open video on right of screen to describe just the context.

    Have challenges with authorisations for showing videos. User with 4 specific authorisations should only see those 4 videos.

    Video reuse – for 1st time users and embedded in GUI. In other words, in different channels. Have challenges in hand-held devices because there can simply be too much info at once and not enough screen real estate.

    Videos can make the application heavy, but can consider streaming.

    They work in agile so they are planning their videos accordingly.

    Designing user assistance for mobile business apps – van Weelden

    Willam van Weelden, WvanWeelden Consultancy talked about just in time and just enough with embedded in UA. UA = user experience design. BYOD = Bring your own backdoor!!

    Interesting to see the bailiff app and how security is crucial here. Showed how architecture is crucial for IT to ensure that the security is OK.

    Discusses IT vs End users. IT used to tech – tools are their job. End users’ tools are just that – tools. What people think – apps are simple and not more need for support/UA.

    Argues that help takes you out of the app. Separate is a bad idea. We only alleviate pain but don’t take it away!

    Our creating manuals today costs money and doesn’t make sales.

    Shows what he calls halfway there – opening an app that has 5-6 screens with walkthrough of what you _can_ do.

    We need a new paradigm: user experience design. Customer buys the entire experience.

    Thinks of interface as user assistance in itself! Becomes just in time and just enough. Always up to date and helping without being intrusive.

    Best is if no one ever thanks you or notices your manual. !! Then it must be integrated well. He says if they thank you and say how the manual has helped them understand and use the product then it means the product is actually crap and you saved them and something – the entire system – is not a good experience.

    Took him 1.5 years to get people to listen to him in his company. Now they listen to him and they get a better product.

    UX design goes beyond service design thinking he says.

    Ray’s comment is that we are all designing for user experience.

    Embedded Help: nuts and bolts – Gash

    We’re on to Day 2 now. Dave Gash, HyperTrain, shared the actual actual “how-to” for making embedded help.

    Create content in, e.g., Flare. Each page in Flare has a unique element
    Content has DITA –> Output is HTML

    Just identify the pieces you want to grab and show in your application.
    These must be accessible to the Web app.

    Web app is JS code. He wants to read, extract, assemble, and embed.

    Did one run-through with HTML which was alway a bit at high-level. Now he is showing XML. Looks almost the same, but he gives a more granular help. More specific.

    He says EditPlus is a good HTML/XML editor because it has useful extra features to help check tags are done well, etc.

    Uses unique IDs for the content elements.

    He likes the .innerHTML attribute. [Must investigate.]

    His way to improve the XML help would be to load the entire XML file into a variable so that is all accessible and available already for whever he clicks and asks for help.

    He has a slide with differences. He won’t say which is better. It will depend on the situation. THe last point is interesting, thought. HTML requires build process. XML doesn’t.

    Getting to know users – Atherton

    Dr Chris Atherton, Equal Experts, says everyone has to start somewhere. But hard to put yourself in the position of someone who doesn’t know.

    Usability testing on a shoestring. You can start small.

    1. Start with 1 regular user.
    2. Focus on an easy task – what puzzles them

    Novices may be shy and feel all is their fault. So, they might not say much, so you have to observe them more than anything.

    Check your ego! Just listen.

    Let the other person figure it out and encourage them to talk.

    Remember to remind them that nothing is their fault.

    Brief and debrief

    Emphasise that they can help with the good development of the software – it is empowering.

    You don’t even need working software.

    Scale it up like a pro. After 1 person, try testing with 6-8 people.

    Find participants who conform to a relevant trends. E.g. make sure they have similar backgrounds if testing financial software so you know they have a similar basis for performing tasks.

    If you can write a script, it can be helpful. Gives you something to lean on.

    Note down the best quotes.

    Helps, too, to have someone with you because it can be hard to talk and listen to a person while also taking notes.

    Quotes can be fascinating. Can be more powerful when talking to colleagues. Also helps to catalog the common problems.

    Report back to your dev team. Chris’ does a This Week in UX newsletter. Not everyone has time to document all these things. Make summaries, share a few quotes – her example is 20-50 line emails. Very quick to make and not an extra burden.

    Put your important points right at the top. Don’t think chronologically if there is a hot point you want to ensure that people see.

    Next level is to run regular testing days. E.g. once per month, once per sprint.

    Find real users. They are motivated, even if they don’t realise it. They want good working software.

    Record your sessions: Silverback, Camtasia, Screenflow.

    She likes the ones that show the user doing the testing so you see them peer into the screen. Says more than any text can say.

    Good approach is using post-it notes. Everything you hear or see that sounds good – jot it onto post-it notes. Then do a card-sort and structure, grouping. Leave the post-its where all will see.

    Show people the clips – the more painful, the better. (Video clips of users doing testing.)

    No wireframe survives contact with the user!

    Concrete research findings are easier to act on than guilt feelings!

    Knowing your users reduces depersonalisation.

    Your benefit from doing usability testing? Quality time with others will improve your mood. Contributing to making your software better helps you feel useful. This is positive feedback.

    From user assistance to user guidance (+ Business Intelligence) – Graat

    Jang F.M. Graat, JANG Communication, says Business Intelligence is where the money is.

    User assistance – minimalism. Only add something to the equation if you absolutely have to – Occam’s Razor!! He “invented” minimalism, says Graat with a smile.

    Weakest link is the mind that thinks ‘Oh, I thought…’ Eliminate that from user assistance and turn it into user guidance.

    Procedure will lead the user.

    Has good slide about getting big data – usability research, customer feedback, service staff reports, surveys.

    Jang gave good example of an engineer coming up to an engine that needs repairs and thinking I know what to do, I don’t need to read the help, but they have, despite much experience, not worked on THIS engine before so they can make serious mistakes.

    A technical writer’s role in redesigning the application UI – Tkaczyk

    Agnieszka Tkaczyk, IBM, gave an excellent presentation. I hope to see and hear more of her in the future.

    Tech writers are good people for usability.

    She showed a great example of a long, long answer for how to disable SSL, but no one had looked at the interface. All that was needed was ‘clear the Use SSL check box’!!!!

    Answers to requests to make good changes: It doesn’t have impact!

    Showed how she went through and helped to re-write some UI content.

    Cool. When Agnieszka was preparing for her talk and looking for examples, she found inspiration for fixing the UI!
    Thanks to the conference she was able to log some errors about the UI which gave her great satisfaction because she was always getting errors logged about documentation.

    She showed example of bad design of error information and how she proposed new designs to make the information more clear.

    In Q&A, Rajeev said he gets his ideas registered in backlogs so he can record metrics about his worth.

    Matthew Ellison, UA Europe – How long is a topic?

    He collects examples of help as a hobby.

    He’s seen things in help that are cool, but he’s never tried them. That realization surprised him. He wondered if we ever used them and whether it was help at the wrong time.

    Evernote added a subject to the note Matthew started at UA conference in Palm Springs.

    Articles should be neither too big nor too small – advice from wikipedia on size of articles.

    He gives a definition of a topic:

    • 1 idea, 1 topic
    • A tpoic supports 1 task
    • An answer to a question
    • Shortest effective piece of communication

    His definition: self-contained cluster of chunks of information, where each piece depends on the others for context, on a single theme with an overall narrative flow.

    Topics should have a narrative flow!

    The way you link stories together improves the understanding (he referred to a talk by Tom Johnson at a past UA Europe).

    Funny anecdote about the related links. He used to think people loved his writing so much they wanted to see more. Now he knows they are mostly surfing and not happy with what they got and they use the links to move elsewhere.

    This was a very entertaining talk, but I am not going to give you the answer to how long a topic should be! You can share your answers to the question in the comments.

    Conclusion?

    This is a nice size crowd with good presentations, but ample opportunity to chat with the other attendees and talk about the nitty-gritty of your daily routines – and your dreams and hopes. I know the 2015 conference – the 10th anniversary conference – will be somewhere in the south of England next year. The location doesn’t matter. I am ready to register as soon as the virtual doors open.

    You can see my conference photos over on Flickr. I’ll be posting my post-conference-sightseeing-in-Krakow-area photos in a few days.

    By the way, if you love mixing conferences and tourism, too, check out the soap! conference in Krakow 2-3 October 2014. I liked Krakow, and I like the idea of supporting this young technical communication conference. They have an energy that can inspire you in your own techcomm world.