Blog Archives

How to track textual input with Google Analytics

This week an analytics ninja showed me how to use Google Analytics to track the values entered into a text field. It comes down to sending a dummy page name to Google Analytics, containing the value entered into the field. Google Analytics faithfully records a “page view” for that value, which you can then see in the analytics reports in the same way that you can see any other page view. Magic.

For example, let’s say you have a search box on a documentation page, allowing readers to search a subset of the documentation.  It would be nice to track the most popular search terms entered into that field, as an indication of what most readers are interested in. If people are searching for something that is already documented, you might consider restructuring the documentation to give more prominence to that topic. And how about the terms that people enter into the search box without finding a match? The unmatched terms might indicate a gap in the documentation, or even give a clue to functionality that would be a popular addition to the product itself.

It turns out that you can track input values via Google Analytics. The trick is to make a special call to Google Analytics, triggered when the input field loses focus (onblur).

<input onblur="ga('send', 'pageview', 'my-page-name?myParam=' + this.value);" />

The above ga call sends a customised page view to Google Analytics, passing a made-up page name that you can track separately from the page on which the input field occurs. The made-up page name is a concatenation of a string ('my-page-name?myParam=') plus the value typed into the input field (this.value).

The string my-page-name can contain any value you like. It’s handy to use the title of the page on which the input box occurs, because then you can see all the page views in the same area of Google Analytics.

Similarly, the part that contains the input text can have any structure you like. For example, if the page is called “Overview” and the input field is a search box, the Google Analytics call could look like this:

<input onblur="ga('send', 'pageview', 'overview?searchText=' + this.value);" />

This blog post assumes you have already set up Google Analytics for your site. See the Google Analytics setup guide. The Google Analytics documentation on page tracking describes the syntax of the above “ga” call, part of “analytics.js”.

Follow-up on yesterday’s talk about API technical writing

Yesterday I was privileged and delighted to speak at a meeting of the STC Silicon Valley Chapter in Santa Clara. Thanks so much to Tom Johnson and David Hovey for organising the meeting, and thank you too to all the attendees. It was a lovely experience, with a warm, enthusiastic and inspiring audience. This post includes some links for people who’d like to continue playing with the APIs we saw last night and delving deeper into the world of API documentation.

The presentation is on SlideShare: API Technical Writing: What, Why and How. (Note that last night’s presentation didn’t include slide 51.) The slides include a number of links to further information.

The presentation is a technical writer’s introduction to APIs (Application Programming Interfaces) and to the world of API documentation. I hope it’s useful to writers who’ve had very little exposure to APIs, as well as to those who’ve played with APIs a bit and want to learn about the life of an API technical writer.

Overview

Here’s a summary of the presentation:

  • Introduction to the role of API technical writer.
  • Overview of the types of developer products we may be asked to document, including APIs (application programming interfaces), SDKs (software development kits), and other developer frameworks.
  • What an API is and who uses them.
  • Examples of APIs that are easy to play with: Flickr, Google Maps JavaScript API
  • Types of API (including Web APIs like REST or SOAP, and library-based APIs like JavaScript or Java classes).
  • A day in the life of an API technical writer—what we do, in detail.
  • Examples of good and popular API documentation.
  • The components of API documentation.
  • Useful tools.
  • How to become an API tech writer—tips on getting started.

Demo of the Flickr API

During the session, I did a live demo of the Flickr API. If you’d like to play with this API yourself, take a look at the Flickr Developer Guide (and later the Flickr API reference documentation). You’ll need a Flickr API key, which is quick and easy to get. Slide 23 in my presentation shows the URL for a simple request to the Flickr API.

Demo of the Google Maps JavaScript API

My second demo showed an interactive Google map, embedded into a web page with just a few lines of HTML, CSS and JavaScript. I used the Google Maps JavaScript API. If you’d like to try it yourself, follow the getting started guide in Google’s documentation. You’re welcome to start by copying my code. It’s on Bitbucket: HelloMaps.HTML. That code is what you’ll find on slide 28 in the presentation.

More links

There are more links to follow in the presentation itself: API Technical Writing: What, Why and How. I hope you enjoy playing with some APIs and learning about the life of an API technical writer!

Documentation that developers need to do their jobs

A fellow technical writer asked me this week about the documentation that developers need to do their jobs. He was thinking not of the guides people need when they want to integrate their systems with another organisation’s systems, but rather the internal guides developers may write for themselves about their projects and tools.

That’s a very good question. I’ve thought about it over the last couple of days, and pulled together a list of the types of developer-focused documentation I’ve come across. If you have any to add, please do!

The list is confined to documents relating to the role of software engineer/developer. It doesn’t include more general information that all employees need, such as human resources and facilities.

Information about the project and system they’re working on

  • Who the people are: engineering team members, product managers, technical writers, stakeholders.
  • Customers: Who they are and what they do, or would like to do, with the system or application that the team is developing.
  • Goals: Mission, vision, goals for the upcoming month/quarter/year.
  • Product requirements document for the system, application, or major feature that they’re working on.
  • Design documents.
  • Architectural overview, preferably in the form of a diagram.
  • Comments in the code, written by their fellow developers.

Help with their development environment

  • How to set  up the development environment for the application/system that the team is developing.
  • Guides to specific tools, whether built in-house or third party, including the IDE of choice, build tool, source repository.
  • A pointer to the issue tracker used by the team.
  • Guide to the team’s code review tool and procedures.
  • Best practices for writing automated tests, and information about existing code coverage.
  • Links to the team’s online chat room, useful email groups, and other communication tools used by the team.
  • Where to go with technical and tooling problems.

Coding guides

  • Coding style guides for each programming language in use.
  • Guidelines for in-code comments: style; where to put them; how long they should be; the difference between simple comments and those that are intended for automated doc generation such as Javadoc; and encouragement that comments in the code are a Good Thing.
  • Best practices for code readability.

Sundry useful guides

  • Communication guidelines, if the developer’s role will involve significant liaison with third-party developers, customers, or important stakeholders.
  • A map to the nearest coffee machine, preferably reinforced by a path of glowing floor lights.

Too much information can be a bad thing. :) I spotted this sign on a recent trip to Arizona:

Too Much Information

Minimalism (stc14)

This week I’m attending STC Summit 2014, the annual conference of the Society for Technical Communication. Where feasible, I’ll take notes from the sessions I attend, and share them on this blog. All credit goes to the presenters, and any mistakes are mine.

Barbara Beresford‘s session was entitled “Minimalism—It’s Really About the User!” Here is an extract from Barbara’s summary of her session on Lanyrd:

Minimalism is a widely accepted and influential methodology in technical communications, but it is not a simple method to understand or apply. John M. Carroll’s two books on minimalism: The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skills (1990) and Minimalism Beyond the Nurnberg Funnel (1998), provide the best source for the ideas behind the theory.

Minimalism begins with understanding your users—in particular, how they need to use your software in order to accomplish their specific business goals. Designing content that really addresses this problem is notably more difficult than simply documenting the features of your software. But tackling this problem can help you develop much more usable content!

Introducing minimalism

“Minimalism” – It’s seemingly a simple word, says Barbara, but it’s surprisingly difficult to get your head around it.

Barbara talked about her path to minimalism. She says she has some “special expertise as an impatient user”, which gives her a special insight into minimalism. This got a laugh of recognition from the audience. She also gave us a useful list of influences, including books, articles and methodologies. These include DITA, content strategy, Information Mapping, Every Page is Page One by Mark Baker, and more.

Update on 14 June 2014: The above paragraph previously stated, erroneously: “She also gave us a useful list of references to books, articles and methodologies that have influenced minimalism.” I have now changed it to say, “She also gave us a useful list of influences, including books, articles and methodologies.”

Minimalism is a theory of learning developed by John Carroll at IBM in the 1980s. He used the term the Nurnberg Funnel to describe the way people learn. They’re not passive when learning. They want to drive their learning experience, based on what they already know and what they want to achieve.

His study found that when people are handed a comprehensive set of instructions, only approximately 1 out of 20 follow the instructions from beginning to end. The others jump around, do their own thing, make mistakes, get lost, and have trouble finding their way back. People like to do things their own way.

In response, Carroll decided to design tutorials that start users immediately on meaningful and realistic tasks – things they needed to do. He also wanted to reduce the amount of content, and make errors and error recovery less traumatic.

So instead of comprehensive coverage, he aimed for selective coverage based on the user’s goals.

Barbara used the terms “minimalist design” and “systems design” to compare the two approaches. (At first I was not quite sure why the term “systems design” was used here. But later during the presentation, I think I know: it denotes a manual whose structure is based on the structure of the user interface it’s describing, rather than on user tasks.)

Minimalist design

Marta talked through these points of minimalist design:

  • Brief orientation
  • Prerequisite tasks
  • Learn by doing, start straight away
  • Modular, self-contained topics
  • Support error recognition/recovery

We looked at an example of a legacy document, which was organised to match the menu structure of the user interface. Barbara described how she reorganised the document along minimalist principles. She started by identifying the key user roles (booking officer, investigator, administrator) and their key tasks (create booking records, search for new records, etc). The new guide was then organised on sections based on tasks (use the import queue, create inquiry records, create booking records, etc).

Questions from the audience

At this point, a member of the audience said that the minimalist guide would be more of a quick-start guide, but a comprehensive user manual is still required. Barbara’s answer was that a system-organised reference manual is typically not used very much. Users typically want to find their information within the context of the key business task. If it’s important to explain specific elements of the screen, do it as part of the business task.

A number of related questions arose, which Barbara answered authoritatively and clearly. One audience member made the point that you could start with the minimalist guide and allow people to drill down to the more detailed information. Barbara also said that part of the role of technical writer is to point out what the primary focus is: serving the users’ needs based on usability studies. We don’t need to document everything that other people tell us to document.

Psychology of learning

Barbara related the principles of minimalist design to the psychology of learning, which shows that we are complex, emotional beings, not machines that run scripts. We do things for complex reasons, without necessarily understanding the reasons ourselves. We need to act, even to struggle, in order to learn and to retain information. People may even be too busy learning to spend much time on the instructions.

Developing minimalist documentation

Examine the system you’re documenting, decide where it’s not intuitive to use, and help the user with those areas. Discover the user’s mental model, and find out if it matches how the tasks are carried out in the system. If not, help orient them to the system. Find the common error situations, and help users through them.

Thanks Barbara

I’ve never consciously used minimalist design, although I’ve attended a few talks on it through the years. I feel that some of the principles have rubbed off on me. This talk helped crystallise and solidify the concepts and practise of minimalism for me.

Key Trends in Mobile Publishing (stc14)

This week I’m attending STC Summit 2014, the annual conference of the Society for Technical Communication. Where feasible, I’ll take notes from the sessions I attend, and share them on this blog. All credit goes to the presenters, and any mistakes are mine.

During the opening session yesterday, Vikram Verma presented a very interesting snippet on mobile publishing trends. So I decided to attend his full-length presentation today. Vikram represents Adobe, one of the conference sponsors.

Vikram’s session covered the following topics:

  • Why you should care about multi-screen publishing.
  • Key mobile publishing trends in tech comm
  • Challenges and solutions
  • A demo of multi-device publishing with Adobe products

Trends

Looking at the four publishing output formats that companies are using for their mobile publications, Vikram gave the current state and a projected state for the near future:

  • HTML 5 is the most dominant with currently 28%, expected to rise to 48%
  • EPUB is now at 12% and will rise to 24%
  • Kindle is at 5%, rising 10%
  • Android is at 11%, expected to grow to 25%

Mobile publishing and structured authoring are the two strongest trends in technical communication.

How can you make your mobile publications user friendly?

Think about the new formats, rather than legacy formats such as PDF and web help. Legacy formats offer problems like:

  • Difficult to read. Zooming in can be problematic.
  • Not touch friendly. Icons and buttons are compressed on small devices.
  • Difficult to navigate.
  • Offer slow loading on a mobile device.

Be aware that attention spans are short, and design your pages accordingly. Research shows that the smaller the device, the lower the attention span. People are more likely to abandon your mobile content if they don’t like it. Also, people are five times more likely to abandon the task if the site isn’t optimised for mobile. Conversely, people are using their smart phones more than their desktops to browse the web. So you’re losing even loyal customers, who are now trying to access the content on the web.

Another challenge is device fragmentation. Mobile phones and tablets come in all sorts of sizes. People are even watching our content on their TVs.

Potential solutions

This is my summary of the solutions Vikram discussed at length:

  • Use responsive design. This allows the page format to change dynamically, depending on the output device. Vikram showed us a few responsive websites: Time Magazine, Mashable, CSS Tricks. Responsive design is a prominent trend in website design.
  • Use adaptive content. That is,  offer different content for different devices. One way is to have separate mobile websites. This is a very prevalent way of doing it, used by a number of big web companies, such as Google and Facebook.
  • Create mobile apps. This is a good way to offer a good experience for customers. It’s a way of delivering content for users when online access isn’t always available. (If you’re using HTML 5, the user needs to be online.)
  • Adopt a hybrid approach. Responsive design, but with some server-side components: RESS (Responsive Design with Server Side). Examples of sites using this approach: CNN, WordPress, SlideShare, eHow. To publish using RESS, you will define the device categories. For example, define categories for phones, tablets, desktops. For these categories, define the content and the layout. Use a server-side component to merge the content and layout definitions into an output format.

Vikram now talked through a matrix comparing the pros and cons of each approach in the following categories:

  • Mobile users’ needs
  • Ease of maintenance
  • SEO
  • Loading time and performance

The choice depends on the context and the end users’ environment.

Vikram finished with a demo of RESS using Adobe’s RoboHelp.

Thanks

This was an information-packed session, with plenty of opportunity for further investigation. Thanks Vikram!

Follow

Get every new post delivered to your Inbox.

Join 1,488 other followers

%d bloggers like this: