Developers code on their laptops, normally docked with their mechanical keyboards and monitors, right?
As such, when it comes to developer documentation, you don’t need to be responsive, and can focus on a desktop-only set of docs.
I have heard this sentiment many times, and at first blush it makes some sense. For all the talk of mobile eating the world, a lot of the business end of things happens on the desktop Web.
Once you have desktop docs going, you look at your stats and see that you were right! A fraction of traffic is coming from mobile! Glad you didn’t waste any time on a great responsive experience! Well, hold your horses. You may have self selected your answers here.
A great developer experience includes a great documentation experience, and that includes mobile. I have seen transitions from desktop-only to responsive, as well as responsive from day one, and both have shown how important it was to go mobile, too.
Take one of the Google developer sites for example, and a recent slice:
Why is mobile such a big deal?
All documentation isn’t equal. There are a variety of reasons why someone ends up in your docs. The Web is a viral platform due to the sharing of URLs through all sorts of mediums (via Email, Twitter, Slack, etc). People are increasingly accessing these mediums via mobile, and are tapping in to read from there. I often read a lot of developer-oriented content on mobile, and will save it away and often revisit on desktop.
I also do a lot of memorization through mobile, using space repetition systems. A common task during the day will be saving some developer knowledge into my system.
This is somewhat akin to customers who browse for products on mobile and finish the transaction on desktop.
Beyond documentation
It has been fantastic to see the trend of developer documentation being seen as putting the manual online with some hyperlinks, and instead using the medium to add a lot of interactivity to help you learn.
The best way to learn is to do, and it is important to be able to feel how things work and play with them. We have embedded Glitch into web.dev as an example of bringing you tight playgrounds to explore, and remix for your own experimentation.
How do you want this type of content to be approachable on mobile vs. desktop?
The other important realization for me has been integration. Developers often end up in your docs via search, and they rarely probably go to your root domain and just read read read.
Take time to look in the Search Console to see your analytics to see how users are getting to you, and make sure that you have the content they need. You need a base of reference documentation, and then can walk up the chain to use cases, and finally verticals.
Look for other areas of integration.
- Where do your developers live?
- Their IDE? And certain plugins?
- Do you want to reach them on StackOverflow or Glitch?
- Do your error messages link out to documentation to help?
- Do your docs work offline? (e.g. if someone is reading on the subway to work, or generally stuck in poor and variable connectivity)
- Do you include code from source files that you have tests running against to make sure that a copy paste works?
- Have you built a connection between the tools and your documentation so it can be surfaced inline?
There is so much to do, and while “docs” are a first class citizen, it is also important to recognize that good tech writers are still under-rated!