Posted on Leave a comment

Designing, Building, and Specifying APIs

Designing, Building, and Specifying APIs

The technical author has many options when designing and building APIs. While building a service with modern technologies and frameworks can be incredibly fast, creating an enduring approach that stands the test of time requires careful thought and deliberation. In this article, we will examine REST and RPC models that are frequently used in API implementations.

One key understanding in this journey will be the role of standards in steering design decisions and evading potential compatibility issues. We’ll also examine OpenAPI Specifications, understanding their practical applications for technical teams and the crucial versioning aspect.

RPC-based interactions are generally specified using a schema; to compare and contrast with a REST approach, we will explore gRPC. With REST and gRPC in mind, we will look at the different factors to consider in model exchanges. We will also consider whether providing a REST and RPC API in the same service is practical.

Representation State Transfer (REST) is a set of architectural conditions commonly applied using HTTP as the underlying transport protocol. From a practical perspective, to be considered RESTful, your API must ensure that:

  • A producer-to-consumer interaction is modeled where the producer models resources the consumer can interact with.
  • Requests from producer to consumer are stateless, meaning the producer doesn’t cache details of a previous request. To build up a chain of requests on a given resource, the consumer must send any required information to the producer for processing.
  • Requests are cachable, meaning the producer can provide hints to the consumer where appropriate. In HTTP, this is often provided in the information contained in the header.
  • A uniform interface is conveyed to the consumer. You will explore the use of verbs, resources, and other patterns shortly.
  • It is a layered system, abstracting away the complexity of systems sitting behind the REST interface. For example, consumers should not know or care if they interact with a database or other services.

 

Introduction to REST and HTTP by Example

Let’s see an example of REST over HTTP. The following exchange is a GET request, representing the method or verb. A verb such as GET describes the action to take on a particular resource; in this example, we consider the attendees resource. An Accept header is passed to define the type of content the consumer would like to retrieve. REST defines the notion of a representation in the body and allows for representation metadata to be defined in the headers.

In the example below, we represent a request above the — separator and a response below:

GET http://mastering-api.com/attendees

Accept: application/json

200 OK

Content-Type: application/json

{

    “displayName”: “Jim”,

    “id”: 1

}

Posted on Leave a comment

Tech Monopolies That Have Emerged, Which Are Bringing Home the Reality of the Metaverse

Tech Monopolies Which Are Bringing Home the Reality of the Metaverse

Paul Chambiras

Technical Writer | IT Consultant & Blogger

Introduction

The Metaverse is the ultimate realization of the abstract realm of the virtual world, not via smartphones and powerful computers, but within immersive technologies such as Virtual Reality (VR) and Augmented Reality (AR). When these technologies effectively merge and integrate, the real value of a metaverse entity will be difficult to comprehend.

The augmented Metaverse will become popular for a simple reason; VR is available and affordable – and much more controllable than real existence is. Virtual offices, personal interactions, and obtaining goods and services will have minimal costs, and within reach upon a few mouse clicks.

And there will no longer be any need for long commutes to work. With a large field of imaginative possibilities to explore, the initial value of the Metaverse will be the instant connection and integration to everything that is already created virtually – such as online banking, digital social media, electronic gaming, and multi-modes of attainable entertainment.

The ability to transform, translate and synthesize normal daily tasks into this new online world will alter the nature of virtual reality and physical reality. What we currently do on the Internet can be encountered within a metaverse, as opposed to tapping and manipulating abstract icons and colorful symbols on our smartphones.

This virtual vision has enormous personal and economic potential, as developed countries (and some emerging ones too) embrace technology and telecommunications and are already dependent on it.

You would expect the leading global tech companies to have already made a stake within the technical ground regarding AR and VR, and that has been the case. Microsoft has released its own next-gen VR/ AR headset called the HoloLens 2; however, it is primarily used for virtual business applications, and not entertainment.

Not to be outdone, Apple has been far more tight-lipped about its metaverse plans, but reliable reports suggest that 2022 will be the year that it will launch its first device. What news that has been significant to date has been Apple’s viewpoint that only an Apple metaverse will be permitting Apple device users to enter and engage only.

What is the Metaverse?

The term – Metaverse – first appeared in a science fiction book in the early 1990s. The plot focused on people who chose to interact with each other in a 3-dimensional world, using avatars.

The closest metaverse entity currently is the online game Fortnite. This shared gaming platform is immensely popular, where online player interaction and sharing experiences occur in the virtual space. Tech company – Unity Software – have staked their claim with 3D software gaming products, but recently (March 2021), they announced a landmark deal with car manufacturer – Volkswagen – to design and market their vehicles in 3D and within real-time virtual workspaces.

Interestingly, the term ‘meta’ has one meaning as ‘beyond,’ therefore the Metaverse implies an augmentation of the physical and virtual presence we currently live in.

What will Occur within the Metaverse?

Once an initial (non-gaming) metaverse has been developed and deployed – now what?

Early metaverse prototypes have overseen AR innovation for online users to try and buy goods and services, such as clothes, furniture, perform DIY jobs in your home, and even sample and try different makeup options – all virtually performed.

The Metaverse will be more than just an online fashion and lifestyle bonanza – all forms of retail marketing and purchasing will exist in the Metaverse, with virtual items containing crypto value, operating within virtual economies. Avatars will wear digital clothing, and virtual enterprises will exist in a similar form as their real-world equivalent entities do.

Social media will obviously have a presence within the Metaverse, with Facebook recently acquiring VR company Oculus – who plans to release the latest generation Oculus Quest 2 headset, which will introduce users to the whole VR experience, and right out of the box as well. Using Facebook’s services, Oculus just might be the fast-pass to connect its owners to any new metaverse available.

Entertainment within the Metaverse will not just include gaming but will spread to reach other platforms also. Virtual cinemas showing movies in a metaverse world with enhanced digital-only effects are more than a possibility. Music concerts and festivals, sports, and sporting competitions are likely to all have a digital presence as well. Metaverse travel can safely occur without any pandemic-enforced restrictions.

What does the Metaverse hold for Marketing and Marketers?

There can be no guarantee that people will respond to marketing within the Metaverse as they do so in the real world, and while the Metaverse can devise and deliver entirely new economic digital concepts, it will require innovative marketing and advertising ideas to connect with potential consumers.

Digital marketing visionaries such as Simulmedia, are already exploring and studying these new theories to adapt to the Metaverse, advocating that advertising the right virtual scale will need to complement some of the existing, core ways advertising is performed in digital channels.

Technical Companies and the Metaverse

Leading IT commentators believe there will be a need for multiple technologies, and from a multitude of tech companies, required to create and sustain the Metaverse. One such company – Roblox – which recently commenced trading publicly (and raised USD 40 billion), has made no secret of their desire to create a virtual scaffolding or framework for a metaverse, so their users can create and virtually engage within as they see fit.

The Metaverse will require a new programming model as an extensive and live emerging platform, where you go from one world to another, and the code all interacts. That requires an open-world programming model that currently does not exist.

How the Metaverse Could Evolve

The Metaverse will not simply be about the potential commercial opportunities possible. As we develop toward existing in both the real world and digital VR, the Metaverse will offer a fundamental advantage: convenience with accessibility.

The possibilities on how the Metaverse will operate just might depend upon wireless capability, and especially 5G technology. The Metaverse will need adequate bandwidth, the capacity to move copious amounts of data and faster throughout a network while optimizing any futuristic applications and seamlessly deploying them, like add-ons to a complex piece of software. The metaverse transformation will become global, and it will impact all of us.

Conclusion

What will be the ultimate feature that will appeal to almost everyone who engages within the Metaverse? It might simply be virtually getting together with family and friends to have social experiences that can be recorded and be made readily accessible, rather than personally relying on memories.

Leave a Reply

Posted on Leave a comment

What Does a Technical Writer Do?

What Does a Technical Writer Do?

This article has been kindly reproduced by site: Glassdoor

Technical writers are responsible for the management of the consistency of technical written content. Because technical writing is versatile in nature and demand, it can be found across many company departments, including marketing and customer relations. Technical writers also assist research scientists and institutions with writing grants and proposals and prepare instruction manuals, how-to guides, journal articles and other documents that represent complex and technical information more easily to the reader.

Technical writers help develop and gather relevant technical information and to share the completed information through an organization’s communication channels, which could be internal, external, or both. Technical writers may be called upon to work with product liability specialists or customer service managers to improve the end-user experience through design change for new products. They manage the flow of information during product development and testing processes and phases. They can also conduct usability studies to improve product design and gather research courtesy of libraries and websites and their own observations and discussions with technical experts. Technical writers often have a bachelor’s degree in journalism, as well as specialized knowledge or additional degrees in related fields like medicine or computer science.

What responsibilities are common for Technical Writer jobs?
 
  • Updating existing documentation for both user groups (new and existing customers).
  • Create illustrations, graphs, charts and other media for materials, as needed.
  • Develop content that is consistent with company branding and style guidelines.
  • Consistently meet program and quality objectives for technical orders.
  • Work with developers to produce quality documentation and training materials.
  • Under general direction, write technical copy for various type of documents for a program/project of similar complexity.
  • Revise documents according to internal specifications and client feedback.
  • Build presentations and project documentation as requested using government furnished software.
  • Update spreadsheet daily on the status of workflow products.
  • Lead proposal development efforts, working closely with a capture manager.
  • Prepare and maintain operations documentation, user guide and manuals and technical publications.
  • The Writer will develop outlines and drafts for review and approval by technical specialists and project management.
What are the typical qualifications for Technical Writer jobs?
 
  • Bachelor’s or Graduate’s Degree in business, computer science, engineering or information systems, or equivalent experience.
  • Advanced writing and editing skills.
  • Experienced with user documentation.
  • Quick learner who pays careful attention to detail.
  • Able to work in an environment using cloud systems.
  • Demonstrates excellent leadership and collaboration abilities, along with solid time management and problem solving skills.

Leave a Reply

Posted on Leave a comment

How to Write Software Documentation in 7 Simple Steps

How to Write Software Documentation in 7 Simple Steps

Written By: Josh Fechter

This article has been kindly reproduced by Technical Writer HQ

If you want to launch a software product from scratch and guide users to adopt it, then you’ll face challenging and unpredictable variables. The concept of software documentation emerged to keep everyone on the same page and make an otherwise overwhelming journey easier to navigate.

Software development teams, testers, and users alike (and everyone else related to the project) need some guidance to help them with their goals. With adequate documentation, everyone wins.

But that itself is a complicated process, requiring technical writing expertise. Even if you’re not a technical writer, you can learn how to prepare excellent technical documentation for your product. If you’re interested in learning via video, then watch below. Otherwise, skip ahead.

To that end, in this article, we’ll discuss:

  • What software documentation is
  • How to write software documentation in 7 easy steps

Let’s get started.

What is Software Documentation?

Software documentation refers to the documents, tutorials, and other material describing a software product’s development, functionality, and use. It is one of the many forms of technical documentation.

The purpose of software documentation is simple: to streamline the communication between all the parties involved with the product.

Within an org where the software is being developed, a technical document can be considered a wiki page – a guiding blueprint that the development team can refer to when working on it. Additionally, it can also help those who use the finished version of the product.

To be more specific, adequate software documentation can help:

  • Align Expectations with Understanding—one of the main concerns of any software company is to ensure that the software engineers work towards bringing the stakeholders’ vision to life. An error in documentation can cause discrepancies between what’s required and developed.
  • Aid in Helping the End-User—in addition to guiding the programmers in implementing requirements, software documentation also helps the audience set up the software, understand the user interface, and follow the best use-cases.
  • Record Progress—another internal use of software documentation is to keep track of the software development lifecycle (SDLC). This can help a company measure progress, learn from mistakes, and make better decisions in the future.

Every tech company—from small startups to well-established giants like Microsoft, Amazon, and Google—uses some form of software documentation.

Programmers, stakeholders, and users alike benefit from this form of technical communication.

The Different Types of Software Documentation

Before learning how to write software documentation, it’s essential to understand the different types of technical documents you might be required to work on.

They are mainly distinguished based on the specific goals they accomplish.

Depending on the methodology/approach it uses, a company may not use every type of document (those that follow an agile approach don’t usually engage in heavy documentation in the beginning).

With that out of the way, software documentation can be split into two broad categories:

Product Documentation

When talking about software documentation, people mainly refer to product documentation.

As the name suggests, this category includes all the documents/material that contain essential details about the product. Of course, it can be for both the software developers and the end-users.

We can further classify product documentation into the following types:

  • Requirements Documents – these are created at the very beginning of the project. As the name suggests, they’re intended to clearly communicate what is expected from the software (the functionality, features, goals, etc.) to the software engineering teams. They are also known as “ReadMe” documents.
  • Architecture/Design Documents provide an overview of the software’s architecture and highlight the design principles to be used.
  • Source Code – this includes documents containing the software product’s actual code (Python, HTML, etc).
  • End-User includes all the user documentation, such as user guides, user manuals, reference manuals, etc. The purpose is to ensure a smooth user experience. If the solution is an API, the material is referred to as API documentation.

In addition to the above, a document detailing the marketing strategy/research can also be filed under product documentation.

Process Documentation

This category includes all the documents describing the underlying processes that bring a product from ideation to launch.

Process documentation aims to break down the software development journey (and provide a vision for all the teams involved in the project).

Process documentation can include:

  • Plans – not to be confused with the requirements, these are also typically created before the development starts. They include cost estimates, schedules, etc.
  • Progress Reports help measure the success of the software’s development (using certain metrics) and ensure that the development team is on the right path.
  • Working Papers – these special documents record the ideas, thoughts, and notes that the engineers, developers, and systems administrators have during development.
  • Finally, development teams need to specify the coding and design standards that they stick with to keep things consistent.

While product documentation is intended for both internal and external audiences, process documentation is mainly intended for the people developing the product.

How to Write Software Documentation [in 7 Steps]

Writing software documentation is tricky. While workflows vary from company to company, there are certain best practices that, if adhered to, can make the process a lot smoother (and yield the ideal results).

In 7 simple steps, you can create any type of software documentation, irrespective of its goal(s). We won’t be talking about the use of templates or any documentation tool such as GitHub, Confluence, etc. The steps we’re about to discuss are generic – ones that may only require a basic text editor.

Let’s dive in:

1. Understand the Purpose and Audience of the Document

Before anything else, you need to take a step back and ask yourself why you’re about to create the said document.

Since there are so many software documentation types, even the most experienced technical writers are prone to mixing up the main purpose or the audience they’re addressing.

For that reason, you first need to highlight the purpose of your document. A simple tip is to open up a blank doc and type up its purpose as the title.

For instance, if you’re creating a document that conveys the expectations of the stakeholders to the software developers, the title could be something along the lines of: “The Vision for XYZ Software.”

Furthermore, highlight the audience of the document. Go one step further and create personas of the type of people who would read your technical content.

These may sound like trivial things to do, but they help.

2. Jot Down Important Questions

Creating a technical document that doesn’t address the pain points or answer the audience’s questions is pointless.

Once you’ve identified the goal and the audience for your technical document, the next step is to anticipate (or better yet, ask about) the questions the readers might have about the product.

This is where your personas will come in handy.

List down those FAQs somewhere. But don’t include them in your main document just yet.

The goal of identifying the questions is to collect your thoughts, design your document accordingly, and provide the most relevant information that delivers maximum value.

3. Outline Technical Documentation

Figuring out the outlining process is an essential aspect of writing software documentation.

That is why the next step is to develop an appropriate design for your document.

If you’re writing a particular type of document for the first time, you may need to prepare a structure from scratch.

There is no universal template for every type of software documentation as with everything else. The design and outline of your document will be based on the specific goals you want to accomplish and the comprehension level of your audience.

Here’s what it should include, in order:

  • The title and the audience
  • An executive summary of the document
  • The problem statement and the scope
  • The goal(s) of the document
  • Requirements for the reader (if applicable)
  • Instructions/Steps/Solutions/Findings/Code (whatever is applicable)
  • A timeline (if applicable)
  • References (if applicable)

You know your audience better than anyone. Include anything else in your outline that might help.

Structure the information in the most helpful way. You may need the assistance of a graphic designer.

You can then use the outline/design as a template for all future documents to maintain the consistency of communication and make minor improvements along the way.

If you’re looking for a more detailed process of writing technical writing documentation, check out our Technical Writing Certification Course.

4. Gather the Required Information

Depending on your level of familiarity with the subject, you may need to conduct some heavy researching to gather and validate all the relevant information for your document.

This may entail interviewing experts or users, talking to the stakeholders, going through existing documents, and conducting research over the internet.

Process the research data into usable information, compile it over your outline, and provide references wherever necessary to add credibility to your writing (if it applies).

5. Write Documentation Drafts

Now that you’ve laid a strong foundation for your technical document, all that’s left to do is to draft it.

If you’ve created a solid outline and gathered all the required information beforehand, the actual drafting process shouldn’t take very long.

Here are some quick writing tips:

  • Don’t write more than you need to
  • Wherever possible, avoid using jargon
  • Use plain English to convey your thoughts
  • Avoid being unambiguous
  • Don’t edit while writing

While drafting, keep referring to the goal and the audience to stay on track.

6. Leverage Good Documentation Visuals

After you prepare your draft, you should include a few visuals (flowcharts, illustrations, screenshots, etc.) to augment your document.

If they’re available, you may also choose to add the graphics as you write the draft. Some writers even prefer adding them during the outlining phase. You’re free to do whatever feels correct based on your particular circumstances.

Technical writers can use these visuals to emphasize a point, further explain a technical concept, help the reader, and make your document look much better.

7. Perform Final Editing

We’re still not done yet.

The only thing left to do now is to edit your technical document.

Depending on your researching, formatting, and writing skills, it can take anywhere from a single to multiple rounds of edits to get the final document.

This entails having an editor (if available), a subject matter expert or just another pair of fresh eyes look at your document for any grammatical, technical, or contextual errors.

Final Note on Technical Documentation

The secret of good software documentation—whatever it may be—is comprehensive planning. Like any other form of technical writing, software documentation cannot be rushed.

Furthermore, it’s not always a one-person effort. It requires close collaboration with the relevant stakeholders, software developers, and other parties directly or indirectly involved with the project.

By following the best practices, touching all the pain points, and most importantly, staying within the scope, you can easily prepare excellent software documentation in no time.

Leave a Reply

Posted on Leave a comment

How to Write API Documentation in 5 Simple Steps

How to Write API Documentation in 5 Simple Steps

Written By: Josh Fechter

This article has been kindly reproduced by Technical Writer HQ

You tap on your smartphone’s weather app, and a few seconds later, you see the latest weather updates for your location. The smartphone weather app does not store the weather data, nor does your smartphone. So, where did the weather data come from?

The ride-hailing apps you use do not have real-time location tracking systems. But whenever you enter a destination on Uber or Lyft, a few seconds later, you see your current location, the destination, and a route, along with estimates of arrival times. From where did your ride-hailing app get this data?

So, where does the data come from?

The answer to this all-important question is that your smartphone apps access data through APIs.

Your weather app uses an API to get weather data from one of the many online weather services.

Your ride-hailing app uses Google Maps API (or a similar service) to access real-time tracking information.

APIs are software developed for software developers. Software developers need high-quality API documentation to use APIs and extract the maximum benefit.

This article will go over the best way to write API documentation. 

Let’s get right into it. 

What are the Types of API Documentation?

There are three types of API documentation: reference, tutorial, and conceptual.

Reference

Reference documentation provides information about the structure, parameters, and return values for each function or method in an API. This is the most important type of API documentation as developers spend most of their time on reference documentation.

Tutorials

Tutorials provide step-by-step guides for using APIs to accomplish specific tasks. Tutorials are helpful if your users want to learn about specific use cases. Tutorials contain detailed instructions on the use of specific function calls and parameters.

Conceptual

In contrast to tutorials that provide specifics, conceptual documentation provides higher-level information, such as how to use APIs to build applications and integrate APIs into a single application.

How to Write API Documentation: A Step-by-Step Guide 

Writing great API documentation can be hard, but you can do it well if you follow a process based on best practices. A good understanding of APIs also helps. It’s ideal if you have some knowledge of programming languages, such as PHP, Java, and Python, along with some technical writing experience. 

Furthermore, good communication skills are essential for effective coordination between team members and developers.

You can check out API documentation from major companies, such as Microsoft, to better understand the format and content. 

To write great API documentation, use templates, use the right API documentation tools, and follow a step-by-step process. 

When you’ve set yourself up with the first two, you can start following the steps described below. 

Make a Plan for Your API Documentation

The first and foremost step is to plan out your API documentation process. If you don’t develop a complete plan and set up a schedule, there’s a good chance that you’ll either miss out on key points or miss your deadlines. 

Before you start working on the API documentation, you need to understand your audience well. Understanding your audience and their needs are crucial to planning documentation. That’s because it will help you decide on your documentation’s structure, language, and overall design. 

Furthermore, it is best to learn about the API itself, whether it’s a web API, payment API, or an API with a different function. You will also have to consider what API documentation tools you will use, such as Postman, SwaggerHub, or apiDoc. You can also consider using online sources and tutorials from sites like GitHub. 

To ensure the API works for people who use the API documentation, you’ll have to look at the API blueprint, API design, and API key. 

Understanding these essential concepts and developing API documentation with the user experience in mind will help you plan well. 

Include Critical Sections 

Each API document needs to have some fundamental sections. These sections improve the document’s usability and improve the developer experience. 

The following are some of the important sections for API documentation. 

How to write API documentation

  • Examples: It’s no wonder that examples are the most important thing developers look for in API documentation. After all, developers need to use the API; examples show them how to do that. Examples are included as pieces of code. You can also include a mock API for developers to test and use by making real calls. You can share the mock APIs via a URL or on GitHub.
  • Product overview: The product overview is an essential section as it is relevant for technical users and for decision-makers who can use the information in this section to decide whether or not to buy the API. Documentation often tends to focus on technical details, and the overall business goals and purpose of the API are ignored.
    • The overview section includes what you can do with the product, the market needs or pain points it solves, some examples of its use, requirements to use it, who the product or other features are for, and other introductory information.
  • Getting Started Guide: API docs are complex technical documents that some users find overwhelming. A getting started section can make it easier for inexperienced and experienced users to navigate the documentation and find what they are looking for. This section helps to show a user how to use a framework, API, or some other system to get the simplest and easiest result, so they get an end-to-end sense of how it works.
  • Authentication: Authentication and authorization are essential API functions: APIs don’t work without them. Since developers can’t use the API without knowledge of API keys, this section needs to appear right after the getting started section.In this section, you need to explain necessary information such as how to get API keys, how to authenticate requests, error messages related to invalid authentication, sensitivity around authentication information, and token expiration times.
    • You don’t need to explain the authentication in detail to outside users. This is because keeping the internal details of your authentication process confidential prevents hackers from obtaining unauthorized access. It is also important to explain the use of public and private keys: explain where each key is used, and emphasize that private keys are confidential (not shared). Include related information in this section if you use different license tiers to provide different access to the API calls.
  • Status codes and error messages: Everyone is bound to get some error messages when using an API. Therefore, the user must understand each error message, its reason, and potential solutions.This section is helpful in first-use cases where someone is using an API for the first time.It’s a good idea to list status codes and error messages on a separate page as it allows you to describe each code in detail without crowding the other documentation. You will need to ask the API developers for a list of all the status codes and error messages for your API. Status codes and error messages can be helpful when it comes to troubleshooting.
  • HTTP requests: Including relevant information about web requests in your API documentation is essential. This is because even though developers know how to send web requests in their preferred programming languages, they might not be familiar with the language used to create requests in the API.

Stay Consistent and Avoid Jargon 

When you’ve figured out the sections and start writing the API document, you need to ensure you’re consistent. That means you use the same terminology, formatting, and reference points throughout the document. 

Remember that all users of API docs don’t have experience with APIs. So it’s a good idea to write for the entry-level. That way, your documentation will benefit users with different levels of experience.

Make sure that all content is uniform in all aspects, including formatting and language. The best way to ensure consistency is to proofread each section after writing it and then proofread the entire document once complete. If you notice any areas that are difficult to understand and read, either edit or remove them altogether. 

Furthermore, it’s important to avoid jargon. It’s best to use standard terminology so that everyone can understand the terms. If you can, avoid using technical jargon unless it is necessary. 

You’re already doing a great job with technical writing if you can convert all technical jargon into understandable words and sentences. The idea is to write something that resonates with the user and helps them understand complex aspects. 

It’s best not to assume that everyone who reads the API document understands all about APIs. Therefore, keep the language consistent and straightforward so that even first-time users can grasp all the concepts. 

Use Interactive Examples 

When you write a block of text, there’s a good chance people will avoid reading all of it. You have to keep your readers engaged; the best way to do that is by including interactive code samples and demos. 

One way of teaching and learning concepts is in isolation. However, this method is an ineffective method of teaching and learning. One of the significant benefits of using examples is that they provide a context that links multiple concepts and enhances learning. Examples based on real-world API applications further enhance learning by bringing in variables that API developers will have to deal with daily.

Interactive examples will help comprehension of the API documentation because the reader will be applying what they’re reading in real-time. It will also reduce the learning curve of the API in the long run. Furthermore, it can help users understand any new features that pop out. 

You can also include various helpful resources such as SDKs and libraries in the API documentation. The extra resources and information will help the users understand the API better and use it in an effective manner. 

Maintain the API Documentation 

While good documentation is crucial for API success, maintaining API docs is also critical. 

It’s crucial to ensure all your documents remain accurate and up-to-date. Obsolete API documentation will lead to frustrated users, reduced retention, and increased support costs as developers turn to your teams again and again for help.

It’s not hard to maintain your API documentation; you can do the following to make sure it stays updated: 

  • If any new features have been added to the API, ensure all relevant information appears in the documents. A good practice is to release updated API documentation with each new API release. 
  • Update descriptions for any features that are added or removed. If a feature is removed, mention it in the document, along with the reasoning behind the removal. 
  • As a writer, feedback is important to improve the quality of your API documentation. You may have missed out on some things or were unclear; therefore, it’s best to use the feedback to make continuous improvements. 

API Documentation Best Practices

Here are some best practices that will improve the developer experience for your API documentation.

Use Simple Language

It is easy to create API documentation with document generation tools. However, such auto-generated documentation lacks good explanations that only a good developer or technical writer can provide.

Therefore, create API documentation written in simple language, making it easy for developers to use and benefit from.

Make it Accurate, Compact, and Easy to Find

API docs that are disorganized, inaccurate, too long, or difficult to locate will not be used. So make API docs easy to find and easy to use.

Make it Available for Everyone

Many customers prefer to understand what your API does before buying it. Your API documentation can help them decide.

Limiting access to registered users is terrible marketing and prevents potential clients from learning about your products and services.

API Documentation Tools

Using an API documentation tool can provide many benefits. Tools help to reduce the time it takes for developers and technical writers to write and maintain API documentation by automating or simplifying some tasks.

Some of the features that API documentation tools support include automatic updates to documentation based on changes to source code, version control, collaboration, and customization options.

Here are some common tools used for writing API docs.

Postman

Postman is an API platform for developers to design, build, test, and iterate their APIs.

You can use Postman’s API documentation tool to generate machine-readable documentation for your API and keep it up to date.

Postman pulls sample requests, headers, code snippets, and more to populate the documentation with dynamic examples and machine-readable instructions. It also updates documentation when you make changes to your collection.

Swaggerhub

SwaggerHub is an integrated API design and documentation platform, built for teams to drive consistency and discipline across the API development workflow.

Supported features include smart error feedback and syntax auto-completion, embedded API design rules that reinforce standards in real-time, and real-time commenting and issue tracking.

Redocly

Redocly is an open-source tool that generates API documentation from OpenAPI specifications.

It supports version control, collaboration, user roles, try-it authentication, and other security features. A unique feature is preview functionality: you can preview every branch or pull request to ensure your changes are reviewed and discussed before pushing to production.

Who Writes API Documentation?

Writing API documentation requires technical skills and an understanding of how APIs work. It is a collaborative process between developers, technical writers, and other stakeholders.

Developers

API docs are written by the people with the best understanding of the APIs, i.e., software developers. Even though developers have the best technical knowledge of APIs, they might not have the best writing skills or give the highest priority to writing documentation.

This is where technical writers come in.

Technical Writers

The job of technical writers is to translate complex technical subject matter into easy-to-understand explanations.

Even though programming experience is not essential, technical writers with programming experience write the best API documentation. Technical writers collaborate with developers and other stakeholders to create API documentation.

Other Stakeholders

Sometimes organizations don’t have dedicated technical writers, and the responsibility for writing API documentation falls on product owners, content writers, or even the startup founder. The essential skills required for the role include writing and technical knowledge.

Wrap Up 

‘API economy’ is the term used to denote the new way of distributing software and data that relies on APIs. And the size of the API economy keeps growing:

In other words, APIs make the world go round.

Whether a software developer or technical writer, knowing how to create excellent API documentation will help you in your job and career. Following the steps outlined in this article can help you create great API documentation and guide others.

Leave a Reply

Posted on Leave a comment

Essential Technical Writing Skills in 2023

Essential Technical Writing Skills in 2023

Written By: Josh Fechter

This article has been kindly reproduced by Technical Writer HQ

Technical writing skills are constantly changing with the growing needs and demands of technology. The ability to identify the exact skills that can help you advance in your technical writing career is difficult. That’s why, in this article, we will discuss the top in-demand technical skills, what they entail, and how to hone them in 2022.

Technical Writer Skills

Technical writers are constantly expanding their skill set considering the need of the time—the digital age. Since their career is growing, the demand for a diverse set of technical skills is also rising. 

Following are the top technical writing skills every technical writer should possess in 2022: 

Communication Skills

First and foremost, technical writers are technical communicators. They’re experts at identifying/adapting their communication according to the knowledge and understanding of their audience. 

To that end, a technical writer should work on polishing the following communication skills include:

  • Clarity—Technical writers are cohesive, concise, and clear in their verbal and written communication. 
  • Purpose—Before their interaction with the audience, they are well aware of why it is crucial to communicate in the first place, the purpose of what they are sharing, and what problems they are aiming to resolve for the end-users.
  • Openness—They deliver an overall positive tone in their message, avoiding all sorts of patronizing and negative remarks or instructions. 
  • Confidence—For their content to be trusted, they avoid hesitancy to pursue knowledge.
  • High Regard for Ideas and Opinions of Others—A technical writer serves the audience. Therefore, they respect their audience’s perspectives and needs by incorporating them in their technical communication.

Furthermore, a technical writers’ role involves actively listening and planning before contributing to the verbal or written discourse. 

Technical Skills

Technical skills are a broad term used to understand industry-specific technology (including their product and services). 

Even though many technical writers pursue their higher education in a technical field (such as engineering or information technology), the technical skills of a technical writer refer to their technical knowledge of their subject matter of interest. 

The technical skills of a writer are just an expanding ocean of knowledge in different fields of their interest and the interests of their company. 

However, on a general note, a few in-demand technical skills include:

  • Project Management
  • Product Development
  • Programming Languages 
  • Marketing
  • User Experience (UX) Design

Senior technical writers are also good at document management through various productivity software. 

Research Skills 

A technical writer’s process cannot begin without extensive research. They document each technical document through feedback from end-users and subject matter experts. 

However, for a more precise overview, technical research can be divided into these two broad categories:

  • Audience Analysis—This is the research they conduct throughout the process for certain technical content. The approach involves understanding the target audience, including demographics, level of technical knowledge related to the product, and interests and needs. 
  • User Experience—The experience includes the readability of technical documentation after the product or feature has been launched (such as usability testing, which explains how easy it is to use a product for the target users).

Whereas everything else in the research process pertinent to the scientific conduction of the research is a prerequisite for every technical writer (such as metrics, data collection, and data analysis).

Writing Skills

Since technical writers must write different types of technical content, they must have a flexible approach to and knowledge of different styles.

The most common types of content that they must know how to create include:

  • User Manuals—Often used interchangeably with the broader terms, online help or user guides, these are documents containing instructions for end-users on how to use a particular product or process.
  • Technical Reports—These are reports that maintain complex information about a specific product in an understandable format, including its development, progress, and history. 
  • Policies and Procedures—These include documenting guidelines for the appropriate usage of industry assets and technology to ensure a safe and productive work environment. 
  • Case Studies—are documents that explore end-users interaction with the product and analyze complex technical information for future improvements. 

Additionally, technical writers should write and manage their content on specific tools, such as Microsoft (MS) Word, RoboHelp (for help files), and FrameMaker (for formatting), etc.  

Editing Skills

Besides skills, technical writers can analyze their work, edit, and format critically, and consistently improve until the technical information becomes entirely understandable for the desired audience. 

While editing a technical draft, technical writers should consider the following:

  • Proofreading
  • Content review 
  • Spelling and punctuation
  • Structure and style
  • Tone of voice
  • Technical vocabulary

Overall, they ensure that their document follows the exact format and guidelines of the specific technical content at hand.

If you’re interested in learning more about editing technical documentation and other technical writing skills, check out our Technical Writing Certification Course.

Design Skills 

It is important to remember that technical writers communicate technical information in a written format and visually in graphs, infographics, and videos. Writers make the content more appealing and easily digestible for the user. 

Considering that, some of the in-demand design skills a technical writer needs include:

  • Information Design—The ability to visually and verbally represent information (including facts, graphs, statistics, tables, and figures) in the most accessible way, understood by the specific audience.
  • Information Architecture—The ability to structure and organize information in the most user-friendly way. 
  • Typography—The ability to arrange and present written word most appropriately and legibly depending upon the type of technical document. 
  • Basics of Graphic Design—The ability to visually communicate complex information in the form of helpful illustrations. 

The above skills need the knowledge of widely used design software, such as Adobe Photoshop and Adobe Illustrator.

Teamwork 

Even though technical writing jobs are assumed to be desk jobs, most technical writers must work with employees from all departments and diverse target audiences. 

Therefore, every good technical writer knows how to work collaboratively with people from different backgrounds and areas of knowledge and expertise. 

When it comes to teamwork, a technical writer should have the following skillset:

  • Team Building Skills—Technical writers are active listeners, observant, and they make sure every voice of authority shows with feedback incorporated in their consultation and process.  
  • Conflict Resolution Skills—When it gets hard to understand product language, team members, and target audiences, and they fall into disagreements, they’re quick at resolving them by finding different ways to communicate anything that the audience misunderstood. 
  • Problem Solving Skills—The ability to promptly derive innovative solutions to problems that arise in their process. 
  • Decision-Making Skills—They are good at trusting their instincts and competence, making calculated but firm decisions when finding solutions for end-users. 
  • Planning and Organizational Skills—They know how to plan, structure, and manage different technical documentation projects and deliver them timely. 
  • The Art of Persuasion—To find common ground with developers and subject matter experts, and for their say to be valued, it is essential to have influence. 

Apart from the above, individuals must possess tolerance, empathy, and perseverance to navigate through the technical writer job function smoothly and successfully apply their skillset. 

Develop Your Technical Writing Skills 

Now that we’ve listed the essentials technical writing skills, the question arises, how to hone them? 

Here are a few actionable steps you can take to improve or acquire technical writing skills:

  • Complete Your Education—Technical writers are encouraged when they possess a bachelor’s degree in a technical field such as engineering, information technology, or communications (Journalism, or English). 
  • Take Different Courses and Training Programs—You can quickly learn many skills such as technical writing and graphic design skills through online or onsite courses. It is wise to with investing in a class. 
  • Follow the Professionals—It is essential to look at all the resources from subject matter experts from your field of interest, including their books, guides, articles, and training programs. 
  • Research Your Field—To consistently improve your skills, you must have access to good technical content resources, which means you’ll have to stay updated with your industry. 
  • On-the-Job Training—There are a lot of employers that are willing to give training to technical writers for them to understand how things work within their organization. However, it is equally important to show them your enthusiasm and dedication. Put together a compelling technical writer resume and go for it.

Again—all you need is the determination to become a technical writer, and the technical skills will follow with appropriate investment. 

Final Thoughts 

The list above of technical writing skills is comprehensive enough for anyone to acquire or improve them. 

However, before you begin, you must remember, technical writers do not write for the sake of technology, but for one and only one purpose alone, to make technology accessible. 

Therefore, if you’re considering a career in technical writing, make sure to with the right mindset.

Leave a Reply

Posted on Leave a comment

How to Become a Technical Writer Without Experience

How to Become a Technical Writer Without Experience

Written By: Josh Fechter

This article has been kindly reproduced by Technical Writer HQ

If you enjoy writing about technical subjects and have a knack for condensing complex information, a career in technical writing might be for you. As a growing field, the demand for technical writers is at an all-time high. If you’re interested in this career path and would like to know how to become a technical writer, keep reading.

In this guide, we’ll provide a crash course on becoming a great technical writer, followed by a brief job description of a technical writer (roles and responsibilities).

Furthermore, we’ll also lay down a roadmap that anyone can take to kick-start their career in technical writing. 

How to Become a Technical Writer

The road to becoming a technical writer isn’t as simple as merely completing a bachelor’s degree and seeking employment.

There are a few prerequisites that you must meet, skills you must acquire, and additional steps that you need to take along the way to build a successful career for yourself.

If you’re an aspiring technical writer, here’s a complete roadmap that will help you kick-start your dream career:

1. Invest in the Right Education and Training

First and foremost, you have to build a solid foundation for your career. This entails creating a solid academic background.

If it’s still not too late, consider getting a college degree in a technical field such as computer science, engineering, or physics. 

As a technical writer, if you’re not a subject matter expert, the chances are that the opinions you share independently won’t be considered credible.

Specializing in communication fields will also be worth it, but make sure you know about the technical side of the job.

Investing in the aforementioned formal education programs will certainly give you a massive competitive edge. However, that alone won’t guarantee success. 

For that reason, in addition to acquiring a college degree, you must also invest in different technical writing courses. 

These courses will provide you with the knowledge you need to enter this field. Furthermore, they’ll help strengthen your professional profile and grab the attention of recruiters.

2. Work on Developing the Right Skillsets

Skilled technical writers are in high demand. Specific courses and certifications will help you develop some of the required skills, but you’ll need to make some extra efforts for the rest.

Basic writing skills are prerequisites. But for recruiters, being just a decent writer isn’t good enough.

On top of written communication skills, a great technical writer should also have good command over verbal/spoken communication skills due to the day-to-day collaborations with others.

Furthermore, decent critical thinking, interpersonal, and good management skills are essential for the job.

In addition to the soft skills discussed above, there are a few in-demand technical skills that can go a long way in setting yourself up for success.

First and foremost, proficiency in popular software programs (such as Microsoft Office), work management tools (like Asana), and content management systems (such as WordPress) is required.

Web design and experience with primary programming languages like HTML, Javascript, and CSS aren’t mandatory but can help you stand out from your peers.

3. Start Consuming Technical Content

Contrary to popular belief, a writer doesn’t get better by just writing more. 

To polish your writing skills, reading is critical.

For that reason, you should start consuming any form of relevant technical content to your desired industry that you can get your hands on.

Look up real examples of technical writing on the internet. If you’re drawn towards specific technical content (such as user manuals, white papers, business plans, and more), search for their examples.

Looking at the actual content and taking inspiration from the experts will help you better understand the job.

4. Start Writing (Even if it Doesn’t Pay)

As you gain the relevant credentials, develop skillsets, and garner inspiration, you need to start applying everything.

You may apply for an internship to gain some work experience if you’re starting.

However, you don’t necessarily have to gain practical hands-on experience in a professional setting. You should also start developing different content assets as a hobby to polish your skills, show them to a willing expert, and get feedback. Or better yet, look up tech founders on LinkedIn and volunteer to develop content for them (they might even hire you on a full-time basis if they like your work).

You can also select the best content and build an online portfolio to show your skills to potential recruiters.

5. Apply for Open Technical Writing Jobs

All that’s left to do is apply for technical writing gigs.

Since the job market for technical writers is so competitive, newcomers don’t fare well as freelance writers

Unless you’re lucky to find an independent project, the best way would be to apply for technical writer jobs.

From new tech startups to well-known giants such as Microsoft, Google, and Apple advertise new jobs now and then. 

Put together a solid technical writer resume, set up solid profiles on Indeed, LinkedIn, and Glassdoor platforms, and set up alerts for any open positions that are remote or near you.

Leave a Reply

Posted on Leave a comment

How To Write a Tech News Release

How To Write a Tech News Release

 

Written By: Julia Portelly

This article has been kindly reproduced by ec-pr.com

There are ten key questions you should consider when you start planning a tech news release. The purpose of a news release is to communicate to your target audiences that you are an active player in the market and worth talking to; it’s also a valuable vehicle to remind your competition that you’re a force to be reckoned with.  Tech moves fast which means there is always news, so you need to make sure you are part of it. So, here’s a checklist to ensure focused and impactful B2B tech news delivery.

Ask yourself, what is the news story? (in less than 20 words)

A news story is something that has never been announced before – it’s important to remember this. It is bad practice to dress up an old event and try and pass it off as a news story. So, ask yourself: what is the new and interesting element of my news story? If you can answer this, you will know whether you have the power to excite your audience or not. The story is not the product or service, it is what the product or service will do for the industry.

Is a news release the right vehicle?

It is easy to believe that a new customer, new product, or a new office is all news, and that a news release is the only vehicle. But might a 1000-word article placed in your top target media outlet be a better way of communicating your messages than a short news mention? The article can be shared widely on LinkedIn, re-purposed for a blog, and may have a far more powerful outcome for the brand. Consider all options before just defaulting to a news release.

What is your ‘headline grabber’?

You want to grab the journalist’s attention straight away, so you need a headline that is arresting, demands attention and makes the reader want to read on. In B2B, a news release announces one of the following recent achievements: a client/customer contract wina significant technological development, or a new industry insight – possibly because of recent research. Caution: unless your most recent recruit is a well-recognised industry authority, new employee announcements are best done through internal comms.  It’s not news.

‘Business benefits’ is a much-overused phrase in tech PR but, being honest, whatever your news is, it must connect with the industry, as making money is a driving factor, for you and your customers. You need to write a headline which will not only engage the journalist but will attract the audience of your chosen target media. 

Does every word pack a punch?

The first paragraph should fully encapsulate the core message with every word packing a punch. One of our golden rules is to write the first paragraph as a stand-alone. In years gone by, this meant that if an editor was short of space, they could edit from the bottom up. If all that was left was the first paragraph, this should stand alone as a summary of the story. Of course, the advent of online media means that space isn’t necessarily an issue for editors now, but don’t think this means you can ramble on forever.  Editors may not be short of space, but readers are definitely short on time.

Two to five paragraphs should follow, including a quote.  These should cover the essential news release elements of who, what, why, where, and how.  Write these with the view that they should be intelligible for, and interesting to, a non-specialist journalist who may be working across several sectors – this will ensure you do not disappear into a black hole of technical detail.

Now, having identified the story and written your release, you can write your headline.  Headlines should be factual and arresting, signposting what the story is about, and be mindful to avoid technical jargon.

What language should you use?

Keep your language business like and easy to understand. The days of ‘waffle’ and jargon are over. Be succinct, factual, using British English, and ensure every word in the first paragraph supports the exact story you are delivering. Less is definitely more.

Who is the audience for your news release?

While drafting, keep in mind the audience for your news release, specifically the readers of the publications you are targeting. Again, much over-emphasised, but if you are launching an education technology story, make sure your language reflects the academic industry and that it will resonate with readers.

And then, once drafted, some final words of advice:

Have you sense-checked your news release?

Just because you know your subject matter does not necessarily mean your news release will make sense to the reader. Once the release is written, give yourself a break, do something else before reading it a couple more times. Keep asking if you’ve made clear compelling points. Reading out loud can provide an effective reality check and it’s sensible to ask a colleague who doesn’t work in your team to review the text. If at this stage, it doesn’t deliver, you will know before it hits the editors’ inboxes, and you have time to re-word to shape up your copy.

Can a news release be too short?

If you miss out evidence or fail to give the necessary context, a news release can become too brief – in which case, the editorial team may reject it because it appears insubstantial or that it simply doesn’t fit their format.  A press release should be at least 450 words, traditionally, no longer than 1.5 sides of A4, using 1.5 spacing. If you need to go beyond this with supporting documents, include links. It will be easier for the journalist to publish, and you’ll be keeping it lean and focused.

Are backlinks in news releases a good idea?

A backlink should be considered an essential element of your news release – it’s not a good idea, it’s a brilliant one!  Nothing should go to the media these days without at least one backlink to the company website, possibly a second link to a specific landing page which is relevant to the product/service/report you are launching. This will send readers straight to your target webpage. By using trackable links, you are also providing yourself with a key measurement tool. Some media will have a policy of no links, but it’s always worth a try.

How do you distribute a news release?

You should never distribute a news release without considering the inbox of the recipients. Always send a news release to named journalists at your target publications. Ideally, someone who has expressed an interest in your type of technology or service. The days of blasting out a release were over well before the COVID-19 pandemic, and these days it is harder to connect with media, since phone follow-ups are a no-no. A succinct email pitch, followed by the release, to a target journalist, is what is required. Make it brief, targeted and friendly, and never add attachments, but rather links to images using Dropbox or a similar cloud platform.

Leave a Reply

Posted on Leave a comment

From Journalism to Technical Writing: How to Combine the Best of Both Worlds

From Journalism to Technical Writing: How to Combine the Best of Both Worlds

Written By: Edgar Ramirez

This article has been kindly reproduced by wizeline.com

If you had asked me a couple of years ago what technical writing is, my mind would have been blank. Maybe I would have tried to come up with something just to avoid embarrassment.

I even applied for a technical writing position in 2018, thinking that my experience in journalism was enough. I was wrong… but I was also correct.

A journalist has almost half of the way covered in becoming a technical writer. This article will explain the similarities and differences between both fields and how to combine them to find your way in the world of technology — all based on my experience as a technical writer at Wizeline.

For those who are neither journalists nor official technical writers, I hope this article provides you with a clearer perspective of technical writing and prompts you to try it as a professional career.

Similarities

First, I am going to highlight the similarities between journalism and technical writing. Here we go.

Interviews

In technical writing, believe it or not, you still have to interview people. They are what we call Subject Matter Experts (SMEs). They own relevant information for the projects we are involved in and for our documentation. 

Similar to a journalist digging into a politician’s mind, technical writers participate or conduct interviews with SMEs to understand things such as the project scope, the client’s needs, or the solution to develop.

There is nothing more terrifying than not knowing what a team is supposed to do on a project. Technical writers can help overcome this uncertainty by asking the right questions and putting all the answers in a document shared with everyone involved.

Research and Notes

The first steps of the technical writing process are research, preparation, and organization. They constitute the foundation of any document and take most of the time before even writing a word.

Technical writers collect all the relevant information for a project, such as basic concepts, technology stack, coding conventions, repository strategy, and even a list of keywords or terms for a glossary. We also take notes that can serve as a future reference, for example, about the decisions and agreements reached during meetings or workshops.

On the other hand, the core of investigative journalists is research. To reveal the truth about a topic, they rely more on facts and figures than personal or political statements. Numbers speak louder than words, they say.

Without information, it is almost impossible to start writing in both cases.

Reviews

Journalists and technical writers share the same step before publishing their work: reviews.

Reviews help detect errors or blind spots in documentation by removing writers’ bias in their work. A rule of thumb is to perform a self-review always, but peer reviews are highly recommended and encouraged.

Technical writers can ask for a peer review from other colleagues or teammates, such as developers. Journalists have their editors.

Style Guides

Journals and technology companies with structured writing teams commonly implement and follow a style guide. 

Style guides consist of standards, guidelines, and conventions for writing and designing documentation. Their purpose is to ease collaboration, reduce time in creating error-free documents, enhance accuracy and consistency, and develop a distinctive voice and tone, among other benefits.

An essential component of the style guide is the objective writing approach. Both technical writers and journalists are encouraged to write without adjectives, stick to the facts, and be concise and clear. So, marketing lingo is off-limits, as well as using synonyms to avoid repeating words.

Multidisciplinary Teams

Producing a journal or developing an application is not a one-person job. Multiple disciplines or roles are involved in the process. For example:

  • Producing a journal
    • Reporters
    • Photographers
    • Videographers
    • Editors
    • Designers
  • Developing an app
    • Developers
    • DevOps
    • QA
    • UX/UI Designers
    • Technical writers

And I only mentioned the directly involved disciplines in a journal page and a standard software development project. The list gets enormous if you include non-directly involved roles.

In both cases, collaboration is vital for success. Therefore, the more you are used to working with other disciplines, the better.

Ceremonies and Processes

When planning projects and tasks, journalists and technical writers have similar ceremonies and processes.

Considering software development methodologies, such as agile, scrum, and waterfall, the following table shows similarities in terms of ceremonies:

JournalismTechnical Writing
Daily editorial planning meetings in the morning to do the following:

 

  • Review what was published that day, including competitors
  • Collect feedback about each editorial section
  • Identify what went wrong and what can improve
  • Review the news agenda for each section and proposed tasks for each discipline
  • Draft a proposal for each section’s front page, considering the public agenda and exclusive articles
 

 

Daily standup meetings to do the following:

  • Review what each team member did the day before and what they will do that day

Sprint planning meetings to do the following:

  • Select items from the product backlog to include in the current sprint

Sprint review meetings to do the following:

  • Review the sprint outcome
  • Identify next steps

Sprint retrospective meetings to do the following:

  • Identify what went wrong during the sprint and what can be improved for the next sprint

Daily editorial meetings in the afternoon to do the following:

 

  • Refine the proposal for every section’s front page

Product backlog refinement meetings to do the following:

 

  • Refine user stories, tasks, and items to get them ready for a sprint

Weekly editorial meetings to do the following:

 

  • Review exclusive articles, investigations, and cover stories
  • Refine the articles and get them ready for publication
  • Draft the proposal for each section’s front page for publication on Saturday, Sunday, and Monday.

Product backlog refinement and sprint planning meetings to do the following:

 

  • Refine user stories, tasks, and items to get them ready for a sprint
  • Select items from the product backlog to include in the current sprint

Terms such as sprint and product backlog can be translated into the editorial world. 

A sprint can be the daily work for the next day’s newspaper edition or the weekly tasks to prepare the weekend editions. A product backlog can be the list of articles and stories with different statuses and characteristics, such as the following:

  • Exclusive
  • Dependent on a public event
  • Written or not
  • Accompanied by photography or not
  • Reviewed by an editor or not
  • Ready and packed for publishing

Also, the product owner’s role in software development projects is similar to the editor-in-chief, editorial director, or whoever is in charge of defining what will be published.

Differences

Now comes the tricky part. 

Journalists know how to obtain, write, and structure information. They are used to working in multidisciplinary teams and following specific processes to get their articles published. However, journalists usually lack technical knowledge and skills, and this is where technical writers prove their worth.

Specialization

The main difference between journalists and technical writers is precisely the technical specialization.

You don’t have to be a developer to become a technical writer in software development projects, but you must have at least basic knowledge of topics, such as the following:

  • Software and hardware
  • Networks
  • Cloud infrastructure
  • Databases
  • UX and design
  • Coding
  • Version control
  • APIs
  • Automation
  • DevOps
  • QA

This specialization is what enables technical writers to collaborate and add value to software development projects. Through documentation, they build communication bridges by translating technical and abstract concepts into information suitable for a specific audience, for example, end-users.

The list of documents a technical writer can deliver is huge, and it depends on the type of industry, the project or product, and the client’s needs.

Methodology

As mentioned in the Ceremonies and Processes section, journalists have similarities with the management part of software development methodologies. 

But what if I tell you that you can apply the same iterations approach from agile methodology to documentation?

Technical writers can deliver documents in incremental pieces. It all depends on the development progress and the project needs. For example, they can write about features as soon as they are released to production or about the current state of the software architecture. If anything changes, they adjust the documents accordingly.

Concerning deadlines or milestones, technical writers can create different versions of a document to meet those dates and keep iterating until the development process is complete. Journalists cannot deliver incomplete articles.

Version Control

Now that we’re discussing versions in documentation, get your mind ready to be blown with version control.

Some old-school journalists still use traditional word processors to write, and they end up storing multiple files with different versions of an article. Some others know how to use web-based solutions to boost collaboration (the editing mode is a big plus) and track documentation changes. However, only a few have heard about version control tools such as Git, CVS, or SVN.

In software development, version control is vital because it enables developers to do the following:

  • Keep track of changes and comments in the source code
  • Prevent and identify mistakes
  • Go back to the latest error-free version of the software
  • Maintain the code
  • Facilitate collaboration among multiple developers by enabling them to work on the same source code without overlapping

Technical writers are immersed in this workflow. Moreover, they can implement version control tools to identify how a text evolved from the first draft and perform in documentation the same actions a developer does with code. Pretty cool, right?

Tools and Delivery Formats

Journalists have limited tools and delivery formats, unlike the wide range of possibilities in technical writing.

Most newspapers still print a version on paper (this implies space limitations) and usually have websites and social media accounts to showcase and share their articles. Journalists even have blogs to share content. But that’s pretty much what they offer.

A word processor (whether a native or a third-party solution) is the minimum requirement for journalists in terms of tools.

On the other hand, technical writers use different tools to deliver documentation in multiple formats depending on the project or the product’s needs. Here’s just the tip of the iceberg:

  • Use word processors to deliver shared documents or PDFs
  • Publish information on websites by working on Markdown files or HTML documents
  • Implement a docs-as-code approach where we use the same tools and development processes in the documentation as developers do. Among these tools, we can use the same version control systems of the source code

If you want to know more about the docs-as-code practice, you can read our recent blog on Implementing a Docs Like Code Solution at Wizeline.

Let’s Wrap It Up

My journalist experience has, indeed, helped me in becoming a technical writer. It was an excellent foundation. 

Nonetheless, my journey in this new field has only just begun. With technology moving as fast as it does, I see a lot of learning on the horizon. It’s exciting!  

Technical writing is a relatively new discipline; therefore, it remains unattended by universities as a career. So, if you are interested, start reading documentation about it, take certifications, or watch tutorials online.

Leave a Reply

Posted on Leave a comment

What is Technical Writing?

What is Technical Writing?

Written By: Kara Latz

This article has been kindly reproduced by instructionalsolutions.com

Are you looking to understand what technical writing is and how you can become more proficient?

Technical writing continues to be a highly coveted skill in the professional workplace. Demand is expected to grow at 10% from 2014 to 2024. This is faster than the average for all occupations.

In this article, we cover the exact definition of technical writing. We also show you an average day for a technical writer, how to improve your skills when writing complex documents, and why the field is quickly changing.

 

Traditional definition of technical writing

What is technical writing? The traditional definition of technical writing is:

Technical writing is the practice of documenting processes, such as software manuals or instructional materials. Traditionally, it was limited to user manuals of some sort.

Frankly, this definition has become outdated. Technology moves quickly, and lexicographers are often left playing catch up.

New definition of technical writing

Today, technical writing encompasses all documentation of complex technical processes. It includes reports, executive summary statements, and briefs. Any time technical information is conveyed in writing at work, it is, by definition, technical writing.

This can include high-tech manufacturing, engineering, biotech, energy, aerospace, finance, IT, and global supply chain.

The format is no longer bound to lengthy user manuals. Technical information must be distilled and presented unambiguously. This can come in the form of technical reports, emails, policy, briefs, and press releases.

The bottom line is if you work in a technical field you are most likely performing technical writing.

How is technical writing different than business writing?

The new definition starts to sound a lot like the definition of business writing.

However, a business writer focuses on business plans, case studies, e-books, and sales/marketing collateral. They are experts in strategy and business management. 

In contrast, technical writers have a strong aptitude in the field of science, engineering, or IT. They are tasked with the compilation of technical documents such as instruction manuals and other instructional materials, guidebooks, technical product descriptions, and research reports.

What is the job of a technical writer?

The job of a technical writer will differ depending on the industry and company that they are employed with.

They often work on multidisciplinary teams functioning as the mediator between the more technical staff and less technical readers. They will work closely with these teams to develop a communications strategy.

Their responsibilities often extend beyond just writing. They must understand the entire project from high-level goals to the intricacies of implementation.

What is the job of a technical writer?

The job of a technical writer will differ depending on the industry and company that they are employed with. But the important task of a technical writer is taking the highly complicated and sometimes confusing subject matter, and putting it in a digestible format.

This is of particular importance in a variety of industries but specifically science or technology such as biotech, engineering, manufacturing, software, and healthcare. 

Technical writers often work on multidisciplinary teams functioning as the mediator between the more technical staff and less technical readers. They will work closely with these teams to develop a communications strategy.

Their responsibilities can extend beyond just writing. They must understand the entire project from high-level goals to the intricacies of implementation.

Educational experience for a technical writer can vary, but the majority of professionals hold a BA in English with an emphasis in writing, journalism, communications, curriculum development, IT, software/computer, or engineering. Some also possess an MA in technical writing. 

The bottom line is that whether accumulating related knowledge or expertise through formal education or hands-on job experiences, a good technical writer must be skilled in translating technical jargon into layman’s terms. Strong communication skills and technical writing skills are crucial. 

A day in the life of a technical writer

Many excellent writers are intrigued by the work environment of a professional technical writer. They find the quiet and tranquility of the atmosphere as a genuine job perk. Being alone with just a computer for researching and crafting documents through a technical writing process appeals to the introverted. Writers from all corners of the globe share their love for a job that can be more of a passion. 

When defining what technical writing is, it’s important to look at the persona of a technical writer and explore dominant character traits. Unsurprisingly, a professional in this field is marked as artistic and investigative. They are especially inquisitive. A fun fact is that Leonardo da Vinci is deemed the most famous technical writer of all time. Apparently, during the period of the Renaissance, he wrote ‘user manuals’ for his unique inventions.

As you further your understanding of technical writing and your technical knowledge, you may want to evaluate if it matches your personality type. It’s recommended to do a self-assessment and consider your personal strengths and talents when pursuing a new professional career.

Skills needed for technical writing

To be a successful technical writer, there is a core set of skills that you will want to master. Here are some of the most common skills needed to be successful: 

Research

Research is one of the first steps in technical writing. After you have an assignment, you will be responsible for collecting the data (numerical and non-numerical) and turning it into valuable information.

Research can come from a variety of places including:

  • On-Site Data
  • Online and Intranet Publications
  • Interviews
  • Libraries and Research Databases

After you have researched, you will need to synthesize and begin planning your document organization.

Audience perception

The technical information you research and gather has to be shaped for reader interest, understanding, and perception.

Technical writers often have to communicate highly technical information to a non-technical audience. Therefore, an early step in the most effective technical writing process is analyzing your audience carefully so you can match information to their needs.

Communication skills

Communication skills are imperative to be a successful technical writer. You will likely be working with multiple teams and individuals from differing roles.

Your ability to listen, record, and communicate will be crucial.

Technical skills

It is imperative that you understand the technical nature of the content you are writing about.

It is difficult to clearly convey a concept that you have not mastered. Many technical writers have academic or work experience in the topic they are writing about and many technical writers have job titles of engineer, geologist, seismologist, financial analyst, or business analyst. They are employed in technical positions and have to summarize information cross-functionally to other areas of the company.

Technical writing is slightly easier if you come from the technical side and are learning to write. It is sometimes more difficult if your background is in writing and you are trying to learn the technical content.

Writing

Excellent writing skills ensure your documents are easy to read and are free of errors. Writing encompasses many of the other skills on this list.

It is important that you have the correct tone, style, and format for your document.

Often these rules are outlined by the employing organization in a style guide.

Document design

You may be responsible for adding graphics to complement your document.


It is important that the graphics aid the reader in comprehending the information. Graphs, tables, and charts are commonplace in technical reports.

You will also need to be proficient in formatting documents. The formatting should be professional and aid the reader in navigating the document. Headings should be easy to skim, and the content should be organized logically.

A poorly designed document will make it more difficult for the reader to understand the content. Document design is a key aspect of technical writing.

Fluency with digital tools

Today, writers must use multiple tools during the technical writing process. This often goes beyond basic text editors. Technical writers are expected to be able to create graphics and annotate images and screen captures and extract data from Excel and convey that data in charts and tables.

User research and testing

Some forms of technical writing may require user research and testing. An example application where detailed research and testing would be appropriate is a written guide instructing engineers how to fix a faulty mechanism on a deep ocean oil rig.

It is important that the documentation is easy to follow, especially if the application is crucial to a major function. To accurately write the guide, the writer may first observe how engineers solve the problem. They may use recording devices or just notes to write down the research. This type of research is closely related to testing.

Testing is necessary to ensure your document functions as intended.

After the writer has completed a draft of the document, they may give it to a test group to read. They can then observe the end users following the instructions in real-time.

They may follow up with a focus group or survey to get feedback on the usefulness of the document. They will use these real-world insights as they revise the document.

Even in less complex or critical applications, it is always a good idea to have a third party read over the text. This helps combat the curse of knowledge. The curse of knowledge is a cognitive bias that an individual has when trying to explain something they already understand. As an expert, it is hard to put yourself in the shoes of a learner who is less experienced.

This is why having a second set of eyes look at the document can help alert you to areas that need to be improved.

Leave a Reply