I’m in the throes of composition. My presentation for STC Summit 2014 is in good shape, and I’m working on the proceedings paper right now. I got to thinking about why I put myself up for speaking at conferences. It’s a lot of work! Is it worth it? I also saw a post from Neal Kaplan, who doesn’t get conferences. So I decided to blog my thoughts.
If you’d told me five years ago that you’d seen me speaking at a conference, my reaction would have been
Ha ha, nope, that must have been some other Sarah.
Public speaking scared me to death. (Actually, it still does.) I never thought I’d be able to do it. Simply standing in front of a handful of peers turned me into a blob of jelly on a roller coaster.
Then Joe Welinske asked me to speak at WritersUA in Seattle in 2009. Of course, I said “Eek, no.” But Joe’s sweet persistence persuaded me to think about it. After all, he said, I knew a lot about what was then an emerging technology for technical writing: wikis. A few days later, Joe asked me again. To my utter horror, I said yes. My thinking went along these lines: I know no-one in the US. I’ve never even been to the US. If I make a total fool of myself, it doesn’t matter. No-one I know will ever know.
I survived WritersUA 2009. And now, five years later, I’ve spoken at twelve conferences.
Oft-discussed benefits of attending conferences include:
- Peers: Meeting other tech writers has been hugely rewarding. It’s especially great to meet in person the people I’ve bumped into on blogs, Twitter, and other online meeting spots.
- Learning: Conferences seed ideas. I see what other people are up to, get a glimpse of new technologies, peer at different products. A while later, an idea pops up about something I can use in my own environment.
What’s the benefit of speaking yourself?
Getting funding to attend the conference is a big one. For me, living in Australia, the travel costs are too big to cover personally.
But for me, the biggie is this: Putting together a presentation makes me think about how others see what I’m doing. It makes me look at my own work, and that of my team, in a new light. It gives me a wider perspective. It firms up my own opinions on what are good procedures to follow, and what could do with tweaking.
So, a call to all conference speakers: why do you do it?
I’m curious to see how things have changed since I last asked this question, back in March 2012: What’s your favourite API documentation, and why?
Part of the reason for asking is that I’ll soon present a session at STC Summit 2014 on API technical writing. I want to give examples of excellent documentation. I have some favourite documentation sets myself, but it’s great to get the opinions of developers and other technical writers too.
So, have at it! Please comment on this post.
What’s your favourite API documentation, and why?
I’ll also collect any suggestions that people send via Twitter, Google+, and other channels, and add the links to this post.
OT: This has to be the world’s best bird. Well, it’s my current favourite anyway. This is a Tawny Frogmouth, spotted on an early morning walk. Tawny Frogmouths are night birds, about the size of a large owl (34-52 centimetres). During the day, they pretend to be old tree branches.
I’ll be speaking about API technical writing at STC Summit 2014. Part of the presentation is about useful tools for API technical writers. Since there are already some great resources on the Web about editors and IDEs, I plan to focus on a motley collection of “other” tools. Those that do a specific job very well. Those of which you’d say, “When I need it, I really need it.”
There are plenty of blog posts and articles about tools for documentation and code, including open source tools. Particularly when talking about editors and IDEs (Integrated Development Environments) most people have their favourites. The debates about which tool is best can get quite fiery!
Here are some useful links:
- Mike McCallister’s presentation, Open Source Tools for User Assistance. It’s well worth following Mike’s blog too.
- Chantel Brathwaite, writing on the TechWhirl blog about Technical Writing on a Shoestring.
- From Bret McGowen on the Rackspace blog, My Text Editor Final Four.
So, aren’t you going to talk about editors at all?
My favourite IDE is Eclipse. I like to dabble in Android Studio and IntelliJ IDEA, just to see what’s happening.
Now that’s out of the way, let’s look at some super-useful and less-talked-about tools for API tech writers in particular.
Syntax highlighter for code samples
I frequently need to add a code sample to an HTML page, or include a slice of code in a presentation. Code is much easier to understand if the text is highlighted to indicate method names, variable declarations, and other syntactical essentials. And it just looks prettier too.
hilite.me converts a code snippet into styled HTML, which you can copy and paste into your page. Paste in your code, and select the coding language, to get the appropriate highlighting. Then click “Highlight!” to see the result. You can grab the HTML and CSS code, or copy and paste the highlighted text itself. You can even choose from a number of styles, such as “colorful”, “friendly”, “fruity”, and so on.
For example, I pasted in a Java “hello world” class, and asked for “tango” style highlighting. The “Preview” box at the bottom of this screenshot shows the result:
Testing web services and REST APIs
There’s an add-on for Chrome browser, called the Advanced REST Client, which I find very useful for getting examples of web service requests and responses. You can craft an HTTP request, then submit the request and see the response. This is a nice GUI alternative to a command-line tool like cURL.
Let’s say I want to use the Google Geocoding API to get a human-readable address for a pair of latitude/longitude coordinates. My URL would look like this:
I’ve pasted the above URL into the Advanced REST Client tab in Chrome, then used the add-on to expand the URL parameters, making it easy to see the composition of the HTTP request:
Now press the “Send” button to see the response. This is a partial screenshot:
Very handy indeed.
Chrome Developer Tools
The Chrome Developer Tools are a little tricky to grok, but once you’ve figured out what’s going on, they’re coolth personified. To find them, click the three-barred icon at top right of the Chrome window (the tooltip says “Customize and control Google Chrome”) then choose “Tools” > “Developer Tools”. The keyboard shortcut is Ctrl+Shift+I or Cmd+Shift+I.
A panel opens at the bottom of the page. It’s pretty busy, so take your time getting used to it. You can click an option to undock the panel and see it as a separate window, if you prefer that. In this screenshot, the DevTools panel is open at the bottom of the screen, and is showing the “Elements” tab:
There are many many things you can do with the DevTools. The Chrome DevTools documentation is a good guide. These are the functions I use most often:
- Check which CSS style is in effect on a particular block of HTML. This is particularly useful when there are a number of stylesheets at play. Sometimes the cascading effect of CSS doesn’t seem to follow the laws of gravity!
- Watch the error messages scrolling past on the “Console” tab.
- Edit HTML on the spot, to see the effect live on a web page before putting my changes into the source code.
Open Device Labs – Access to real devices and platforms for test-driving an app
It can be very difficult to try out an application on every supported device or platform. Especially for those of us dealing with mobile apps, there are just way too many devices out there for it to be feasible to have an example of each one.
One solution is to use emulators. But here’s an exciting initiative that I heard about recently: Open Device Labs.
The idea is that people may have last year’s mobile phone lying around, that they’d be willing to allow other people to use for testing. Some people may even want to donate new devices to the cause. Smart, enthusiastic people have set up hubs of Internet-connected devices at various locations around the world, and made them available to us all to use. For free!
I haven’t yet used a device from one of these labs, but the idea is awesome. What a great way to test an app, get screenshots, figure out the “how to” instructions you need to write, and just see how the user experience feels.
Mobile emulator in Chrome browser
With Chrome’s mobile emulation, you can make your desktop browser pretend that it’s something else. It can masquerade as an iPhone, Kindle, Blackberry, Nexus, and more. This is very useful for taking screenshots, and for seeing how responsive an app is to different device sizes and resolutions. The emulator is available via a fairly obscure setting in the Chrome Developer Tools panel.
Online source repositories are good for sharing code. In a tutorial, it works well to include code snippets and point readers to the complete source in a repo. Bitbucket and GitHub are very popular. I have accounts on both, because I’ve worked with teams on both. GitHub works with Git, while Bitbucket supports both Git and Mercurial.
That’s my list so far. If I find any more tools before the STC Summit in May, I’ll add them to the list I’m creating for my presentation. It will be fun to share them with the tech writers at the conference. Can you think of any super-useful tools to add to the list?
Technical writers often need to create sample code, to illustrate the primary use case of an API or developer tool, and to help developers get started quickly in the use of the API or tool. Here are some tips on how to go about creating that code. I’ve jotted down everything I can think of. If you have more tips to add, please do.
I recently published a set of documentation on a utility library created by Chris Broadfoot, a Google developer programs engineer. The utility library is an adjunct to the Google Maps Android API. The documentation includes an overview of all the utilities in the library, a setup guide, and an in-depth guide to one of the utilities. (I’ll document more of the utilities as time goes on.) As part of the guide to the marker clustering utility, I created some sample code that illustrates the most basic usage of the utility and gets developers up and running fast.
Quick introduction to the API and the utility library
The Google Maps Android API is for developers who want to add a map to their Android apps. The API draws its data from the Google Maps database, handles the displaying of the map, and responds to gestures made by the user, such as zooming in and out of the map. You can also call API methods to add markers, rectangles and other polygons, segmented lines (called polylines), images (called ground overlays) and replacement map tiles (called tile overlays). It’s all in the API documentation.
The utility library is an extra set of code that developers can include in their Android apps. It includes a number of useful features that extend the base API. One of those features is “marker clustering”. The full list of features is in the utility library documentation.
The marker clustering utility
The sample code illustrates the marker clustering utility in Chris’s utility library. So before diving into the code, you be asking:
What’s “marker clustering”?
Let’s assume you have a map with a large number of markers. (Typically on a Google Map, a marker is one of those orange pointy droplets that marks a place on the map.) If you display all the markers at once and individually, the map looks ugly and is hard to grok, especially when the map is zoomed out and many markers are concentrated in a small area. One solution is to group neighbouring markers together into a single marker icon (a “cluster”) and then split them into individual marker icons when the user zooms out or clicks on the cluster icon. That’s what Chris‘s marker clustering utility does.
What does marker clustering look like? See the screenshots in the documentation.
Developers can implement the classes Chris has created and customise the appearance and behaviour of the clusters. The utility library also includes a demo app, containing sample implementations of the utilities.
The sample code
The best way to describe a code library is to provide sample code. I created a simple marker clustering example, based on the demo app. Take a look at the sample code in the documentation section on adding a simple marker clusterer.
Now compare it to the code in the demo app that’s part of the utility library: ClusteringDemoActivity.java
The differences, in a nutshell:
- The sample code doesn’t show any of the “plumbing”, such as the library import statements.
- The sample code does include a listing of both the primary method that does the clustering (called “
setUpClusterer()“) and a class that’s important for developers to understand (“
public class MyItem implements ClusterItem“).
- Instead of reading input from a file, the sample code includes a method called “
addItems()” to set up some sample data directly from within the code.
- I’ve added plentiful comments to the sample code, explaining the bits that are specific to marker clustering or the sample itself.
In summary, the sample code provides all the developer needs to get a simple marker clusterer working, just by copying and pasting the code into an existing Android project.
How to write sample code
While writing the sample code, a thought struck me:
Hey, it’s actually quite an interesting process writing sample code. I’ll blog about what I’m doing here, and see what other technical writers have to say about it.
First, a stab at defining the goals for the sample code:
- Get the developer up and running as quickly as possible.
- Be suitable for copying and pasting.
- Work (do what it’s meant to do) when dropped into a development project.
- Be as simple as clear as possible.
- Provide information that is not easy to find by reading the code.
- Illustrate the primary, basic use case of the API or tool.
And here are my jottings on how to go about creating a useful code sample:
- Find out what the primary and simplest use case is. That is what your code should illustrate. Talk to the engineers and product managers, read the requirements or design document, read the code comments.
- Find out what you can safely assume about your audience. Can you assume they are familiar with the technology you’re working with (in my case, Java and Android development)? Do you know which development tools they are using?
- Find some “real” code that does something similar to what you need. Perhaps a similar function or a working implementation that’s too complex for your needs.
- Simplify it. Make names more meaningful. Remove functionality that’s unique to your environment or that adds super-duper but superfluous features. Remove plumbing such as import statements and all but the essential error handling.
- Put your into a framework and test it. The framework should be one that your audience will be using. In my case, that’s an Android development project.
- Take screenshots of the code in action. They’re often useful to give people an idea of the goal of the sample code, and of what the API or tool can do.
- Get the code reviewed.
- Include it in the doc.
- If possible, put the code in a source repository and hook it up to some automated tests, to help ensure it will remain current.
- As far as possible, have all the necessary code in one piece, so that people can copy and paste easily. This may mean moving stuff around.
- Add code comments. Engineers often add technical comments to the code, but don’t include an introduction or conceptual overview of what’s going on. And our target audience, developers, will often read code comments where they don’t read other docs. So code comments are a great medium for technical communication!
Perhaps the most important thing to do is to see yourself as the advocate for or representative of those developers who need to use the API or tool you’re illustrating. Think what questions they would ask if they had access to the people and tools that you do, and put the answers into the documentation and sample code.
To do this job, tech writers need a certain level of coding knowledge, and also a good understanding of what a developer needs to get started. The sample code provides a stepping stone between the conceptual overviews and the complex implementations.
Well, that’s all I can think of. What have I forgotten?