Tag Archives: Technical writer

Is GraphQL really “self-documenting”?

If you Google for ‘API trends’ or ‘the future of APIs’ , one technology that crops up a lot is GraphQL. Developers rave about it being a more powerful and flexible alternative to REST. Not only that but if you’re a technical writer like me, claims that it is self-documenting are particularly interesting. So what is GraphQL and is it really as self-documenting as people say?

What is GraphQL?

GraphQL is an open source data query and manipulation language that was developed internally by Facebook for their mobile applications before being released publicly in 2015. Since then it has grown in popularity with some people claiming it might replace REST APIs in the future.

Like REST APIs, both operate over HTTP with requests being sent to retrieve or manipulate data. The key difference is with REST you might need to send requests to multiple endpoints to retrieve a particular set of data, with GraphQL there is only one endpoint so with a single request you can retrieve an object and all of its related objects.

For example, with this GraphQL schema and server wrapping the SWAPI (Star Wars API), you can retrieve multiple pieces of data using just one endpoint. In this case, finding out the species and home planet of Luke Skywalker by adding more fields to the endpoint:

Star-Wars-GraphQL

“The self-descriptive nature of GraphQL”

There seems to be plenty of love for GraphQL on Twitter with developers praising its speed, flexibility and introspective nature. The other key attribute that crops up a lot is “self-documenting” or “self-descriptive”:

One developer even went as far to say that GraphQL doesn’t require documentation at all. However, after playing around with GraphQL and experimenting with some public GraphQL examples out there, I’m not so sure I agree.

Naming matters

The key thing about GraphQL from a documentation perspective is the importance of naming. Lee Byron, one of developers behind GraphQL, spoke about this in his talk “Lessons from Four Years of GraphQL” at the GraphQL Summit in November 2016: “Naming things is super important in GraphQL APIs,” he said. “An important question to ask when designing APIs is ‘Would a new engineer understand this?'[… ] And that means no code names or server-side lingo.”

Lee-Byron
Lee Byron, one of the developers behind GraphQL, spoke about the importance of naming.

He continued: “Imagine that most of the engineers who are going to be using your API might not find it so easy to go and find out how that field maps to some underlying system. It’s really important not just to have names that are good but to have names that are self-documenting. Naming things that adhere closely to what those things actually do is really important to make this experience actually work.”

“An important question to ask when designing APIs is ‘Would a new engineer understand this?’ […] Naming things that adhere closely to what those things actually do is really important to make this experience actually work.” – Lee Byron

Despite Byron’s warnings, fields with poor or no descriptions were a common issue in the different GraphQL APIs I looked at. In the example below, taken from the GraphiQL documentation explorer, I had no idea what the ‘section’ query field did or what data it sent back because it had no description:

Screen Shot 2018-07-25 at 18.44.37

Apart from the documentation explorer, another way to see what query and mutation fields are available is the auto-populating feature in GraphiQL. Hovering over the field or type reveals a description but this can be as useless as the description in the documentation explorer if all it says is ‘Self descriptive’, as this Twitter user found out:

Does GraphQL need documentation?

I agree that GraphQL is self-descriptive and if you’re familiar with the query language and the schema, its introspective nature means it is easy to refer to the description of a field or type to find out what it does. One of the other advantages of GraphQL is the API documentation is easy to keep accurate and up-to-date as the descriptions are pulled directly from the code. In version 0.7 or above of GraphQL, this is as simple as adding a comments directly above the type or field in the code:

Star-Wars

However, GraphQL is only “self-documenting” if the developer or a technical writer has given the fields adequately intuitive or self-descriptive names or has added decent descriptions for them in the schema code. If the names are obscure or the descriptions aren’t great then your GraphQL API is as useful as a chocolate teapot and there are already a few chocolate teapots out there from what I’ve seen. So I guess the good news for technical writers is that we still have a role to play in helping to document GraphQL, it isn’t a magical solution that renders us unnecessary just yet!

Advertisements

Write the Docs Portland 2018

Earlier this year I stumbled upon Write the Docs, a global community of people who care about documentation, and through its Slack channel, I have learned so much from the advice and knowledge shared by its thousands of members. The discovery has been a real godsend for someone like me who has worked independently or in small teams for most of my technical writing career.

This month I was lucky enough to go halfway across the world to the annual Write the Docs conference in Portland, Oregon to meet some of the community in person and listen to some brilliantly insightful and entertaining talks from fellow technical writers. In this post, I’ll share my highlights of the conference, my favourite bits of Portland and offer some advice on how to get there.

Conference Highlights

DISCLAIMER: I didn’t attend every single presentation but all of the talks I listened to were great. I’ve highlighted a few memorable ones below:

Kat King from Twilio, who had the unenviable task of giving the first talk of the conference, delivered an entertaining and engaging talk about how she and her team were able to quantify and improve their documentation with user feedback.

Beth Aitman from Improbable spoke about how to encourage other members of your development team to contribute to the documentation. This is something I think we all struggle with and can relate to. It’s well worth a watch:

Bob Watson gave a great talk about strategic API documentation planning, with some interesting tips about your target audience and the different types of API doc consumer  you might come across. These included the ‘Copy and Pasters’ and the ‘Bigfoot’, the rare developer who actually studies the documentation and applies the code!

As well as the main talks, there were some excellent Lightning Talks, five minute presentations given during the lunch breaks, that contained some real gems such as Mo Nishiyama’s resilience tips when dealing with Imposter Syndrome and Kayce Basque’s talk on improving response rates from feedback widgets:

If the talks aren’t your thing, there was also an Unconference where you could discuss topics such as API documentation, documentation testing, individual tools; whatever you want really. I just sat and talked with two technical writers about a documentation tool for half an hour!

Apart from the people, one of the best things about Write the Docs Portland was the venue, a striking 100-year-old ballroom with a “floating” dance floor that has played host to the likes of Jimi Hendrix, the Grateful Dead, Buffalo Springfield and James Brown. Also, if stickers are your thing then you could collect a load of stickers provided by the conference sponsors, hiring companies and Write the Docs themselves (see below):

Portland Highlights

Apart from its scenic surroundings and the views of the Tualatin Mountains, Portland has a lot to offer in the city itself. Some of my personal highlights included:

Doughnuts – Portland has a reputation for great doughnuts. We skipped the enormous queues outside Voodoo Doughnuts and went to Blue Star Donuts instead. The PB  & J with habanero pepper was pretty unusual!

Coffee – Portland has developed a thriving yet relaxed coffee culture with more than 30 coffee roasters across the city. It goes without saying that the coffee here is good! Check out Heart or Barista.

Restaurants – The food in Portland was amazing. One of my favourite meals was at Life Aquatic-themed oyster bar Jacqueline in SE Portland. For sushi check out Masu on SW 13th Ave and for a relatively cheap but delicious lunch go to Nong’s Khao Man Gai thai food cart.

Washington Park – If you want to escape the sights and sounds, head to the 412-acre Washington Park which boasts a Japanese garden, a zoo, a rose garden, an amphitheatre and lots of trees!

Powell’s Books – No trip to Portland is complete without visiting the world’s largest independent bookstore. My only advice would be to pick up a map and have some idea of what you’re looking for, otherwise you’ll find yourself wandering the many colour-coded sections and aisles for hours.

How to get there

If you live in the US or Canada, it might be slightly easier to convince your boss to fund your trip to Write the Docs. If like me, you’re based in the UK, its slightly more difficult but there are a number of options:

1. Use your training budget – Ask if you can use your training budget for the trip. It cost me my annual budget but it was well worth it and I was able to combine it with a trip to my company’s head office in San Francisco.

2. Become a speaker – I met a few writers whose company paid for them to be there because they were speakers. It’s great exposure for you, your documentation team and your company.

3. Recruitment  – If you’re company needs to grow its documentation team, you might be able to justify the cost by attending because there is a job fair and you have the opportunity to network and meet writers with a wide range of experience.

4. Exposure – Even if you don’t become a speaker, it’s a great way to raise your personal profile and that of your company. You never know when that visibility might come in handy in future.

5. Specific talks – Highlight a few specific talks from the schedule of the upcoming conference or a previous conference that may benefit you or your team. Write the Docs is a fantastic opportunity to learn from some of the best technical writers in the business!

If all else fails, see the sample email and other tips under the ‘Convince Your Manager‘ section of the Write the Docs website.

 

Help Review – Mozilla Firefox

I stumbled across Mozilla Firefox’s help system last week and was interested to find most of the articles were largely written by volunteers. I hadn’t come across this kind of model for documentation before so it raised some interesting questions. For starters, can a group of volunteer technical writers collaborate to produce an effective help system?

2016-05-20 11_32_36-Mozilla Support

Mozilla released Firefox as an open-source web browser back in 2002 and as such the source code is open to anyone. As a non-profit organisation, Mozilla also relied heavily on the code, along with the support and documentation being largely maintained by volunteers. Although the company now has a large workforce of paid employees, an army of volunteers also still contribute to roughly 40% of its work, which includes not only the documentation but also coding tweaks (around 24% of all source code changes) and even the Firefox logo design. The help system was created through the SUMO technical writing program, which invited participants (a mixture of college students and technical writing professionals) to take part in each release cycle in order to produce the documentation. Although the program is not currently active, the participants and other volunteers still seem to be actively involved in maintaining the existing help articles.

Firefox-3

First Impressions

Visually, I think the design and layout of the Mozilla Support homepage is really appealing, with all of the individual products and their logos mapped out in different sections. It just looks cool. The simple grey background, contrasting with the colourful designs of the Mozilla product icons and clearly marked out sections make it very easy to navigate. It was interesting to discover that some of the legacy of Mozilla’s design is down to an interface designer called Steven Garrity wrote an article listing everything that was wrong with Mozilla’s visual identity back in 2003 and was subsequently invited to their head office and asked to head up their new visual identity team which led a re-brand in 2004 when the now well-known Firefox logo, designed by Jon Hicks, was introduced.

2016-05-24 12_55_59-Start

The help is broken down into nine help topics, with multiple articles under each topic. The documentation itself is clearly laid out, although the screenshots are sometimes different sizes and formats (some fade into background, some do not etc.) and it is easy to spot where different technical writers have worked on the same article and used different styles to highlight sections of a screenshot. In the example below, you can see three different contributors’ work, with one opting for a crimson red rectangle to highlight ‘Desktop’, another using a orange-red circle and the third person using a brighter scarlet red oval:

Inconsistent

Each page does actually list the authors of each article so it is possible to see how many people have contributed to each article. This particular article had eight contributors but other have even more, and unfortunately it shows:

2016-05-31 12_31_59-How do I tell if my connection to a website is secure_ _ Firefox Help

In this article, which had 22 contributors, there were little issues like the screenshots being slightly different sizes. While it’s not the end of the world, the different styles of writing and formatting are pretty noticeable, even for someone without mild OCD, and it can look a bit messy and unprofessional. I guess it’s the kind of thing that’s forgivable when you’re using a free open-source browser but it could be easily remedied if Mozilla implemented a style guide for all contributing technical authors to ensure there is more uniformity with terminology, screenshots and how things are highlighted. Alternatively an editor could go through and make edits to clean things up where necessary.

Features

One thing I was really pleased to see in the help was the occasional gif clip and a good number of tutorial videos which ensure the content is dynamic and semi-interactive for its readers. The videos, which have been produced by Mozilla senior UX designer Michael Verdi, are short and well edited so they are very watchable. He has a personal, informal style and friendly tone which is more engaging than a robotic Siri/Cortana-style  narration.

At the top of each article, there is also a drop-down menu on the left-hand side which has some pretty useful features such as a link to any discussion items on the article’s topic, multiple language translations of the article, showing what other articles are linked to the article you are reading and seeing the history of who contributed and edited the article.

2016-05-27 11_44_48-Photos

In terms of help and support, it has three main branches: Twitter, a support forum and help articles. Again, this is a great way for Mozilla to keep all of their bases covered. The other great thing people volunteer to assist with all three of those branches as well, with volunteer contributors on Twitter, volunteers answering questions on the support form and volunteers writing the help articles themselves. These volunteers are prompted to help by various Volunteer for Mozilla Support buttons, as shown in the screenshot  below:

2016-05-26 14_34_31-Start

There is constant encouragement to get involved in things like the “Army of Awesome” (their Twitter helpers) and statistics about how help matters. For example, “1 Tweet can save 1 day” and “1 article can be viewed by 400 million users”. It just has a really positive, pro-active community feel about it.

Another common theme is the carton Firefox character, who is like a superhero-type figure, which appeals to everyone’s inner geek. It’s another simple but effective way to make  the support pages fun and engaging.

This slideshow requires JavaScript.

Conclusion

I am really impressed with the content and support that is being produced by Mozilla, especially given the high percentage of work being done voluntarily. On top of the written content, they are also managing to offer video tutorial content and a Twitter help account which are further supported by a support forum. It would be useful to have a style guide or some kind of lead technical author/editor to iron out any issues with uniformity but overall I think Firefox’s support pages prove that open source projects can be reasonably well-documented through crowd-sourcing volunteer technical writers. I’m not sure this model of documentation would work for everyone but I think Mozilla have proved that volunteers can collaborate to produce an extensive help system, this clearly isn’t just a big work experience project.