One of the many titles that we documentarians assume is user’s advocate. This means that we defend the user’s interests, cater for their information needs, and provide them with the right content at the right time. But what if some of them cannot read the help topic because the font is too small and light, or they cannot do a step in a procedure as the instructions are too vague? This means that probably, we have overlooked such thing as accessibility. Continue reading
It has been almost two months since I attended the Write the Docs but even now I reminisce on two days in Prague when documentarians from all over the world gathered to share ideas, experiences, and later—some beer.
Below are the most memorable slides of talks, lightning talks, and untalks (that’s how one calls the talks on the unconference, right?)
ELEKS InfoDevs have been attending the soap! conference for the 4th year in a row. This time, the theme was Problem Solving, and the speakers shared their stories of all kinds of problems they face.
I would like to single out four areas that usually bring a headache and make us seek for a way out.
The idea of this post has been lingering in my mind for quite a long time. Having created documentation according to the Microsoft Manual of Style (MMoS) in the majority of my projects, I was puzzled a bit when I started investigating the Apple Style Guide. Not for the obvious reasons like structure differences, or depth of topics covered, or style of writing but for the small discrepancies like spelling or wording that were crucial nonetheless.
Having exclaimed “I need to write that down!” for the fifth time, I decided to make a side-by-side comparison of the guidelines proposed by both MMoS and Apple Style Guide.
We, bloggers, dream to make our content visible, visited, and viewed. And even if we don’t think of SEO when starting our blogs, the time to look for tools for link building and keywords research always comes.
If you have already scratched the surface of the iceberg we call SEO or you just don’t want your website to be buried in the depth of Google search results, you surely need to know the notion of latent semantic indexing (LSI). And that’s when the article by Nikolay Stoyanov may be your first and foremost resource.
There are times in our, InfoDevs’, lives, when we try to find our own place under the sun, I mean, within the team. We start questioning ourselves: “What should I do first? Is there anything else I can do? How can I help my teammates?” And our answer to the last question sets the role we play among the Developers, BAs, QAs, Designers, and PM. Are we merely doc writers defined by our proficiency in languages? Or are we an important part of the team that brings value and facilitates the work of each team member?
On the corporate level, the questions remain the same. The article by Sarah Maddox and the feedback for it by Larry Kuntz reminded me of the road towards self-identification that my fellow InfoDevs and I have taken.
How the story goes
We began as a Documentation Stream within the Software Engineering office, and over a year, after long debates of how we could be most productive—as a separate entity or as part of other offices like Marketing or UX, we formed the Information Development office, a full-fledged department in the company structure. That decision led to the common understanding that we could provide our services not only to the company’s external customers but also to the company itself. We help other offices as we handle corporate documentation of all types and formats. We deal with reviews and translations, prepare case studies and proposals, decipher pencil-written notes and turn them into cool infographics. That makes us recognizable among colleagues and shapes the image of an Information Developer as a competent and versatile professional. Also, being a separate functional unit allowed us to create the Information Development center of expertise where we share our knowledge and help newcomers grow.
Here we stand
This is how it works for our company now, and this story is in the making. Of course, the future might hold new challenges for us and new discoveries as our industry progresses, and you can never be sure where you might end up.
I’m sharing this article with you, so that if you faced a similar problem or still try to find a place within your company, this might set a direction for you.
Imagine a situation: you’re going to prepare a help system for a website. You suggest creating a help that has the look and feel of the website itself. The customer is happy with that, and you’re eager to start as you have MadCap Flare 11 or 12 with that cool TopNav output. However, the website uses custom fonts, and you need to use them in your help system.
What would you do?