Help APIs and UI tooltips

Full code demo of content API

You can create a help API that developers can use to pull in content.

For the full code demo, see the notes in the tooltip demo.

In this demo, the popovers pull in and display content from the information in a mydoc_tooltips_source.json file located in the same directory.

Instead of placing the JSON source in the same directory, you could also host the JSON file on another site.

Additionally, instead of tooltip popovers, you could also print content directly to the page. Basically, whatever you can stuff into a JSON file, developers can integrate it onto a page.

Diagram overview

Here’s a diagram showing the basic idea of the help API:

Is this really an API? Well, sort of. The help content is pushed out into a JSON file that other websites and applications can easily consume. The endpoints don’t deliver different data based on parameters added to a URL. But the overall concept is similar to an API: you have a client requesting resources from a server.

Note that in this scenario, the help is openly accessible on the web. If you have a private system, it’s more complicated.

To deliver help this way using Jekyll, follow the steps in each of the sections below.

1. Create a “collection” for the help content

A collection is another content type that extends Jekyll beyond the use of pages and posts. Call the collection “tooltips.”

Add the following information to your configuration file to declare your collection:

collections:
  tooltips:
    output: false

In your Jekyll project’s root directory, create a new folder called “_tooltips” and put every page that you want to be part of that tooltips collection inside that folder.

In Jekyll, folders that begin with an underscore (“_”) aren’t included in the output. However, in the collection information that you add to your configuration file, if you change output to true, the tooltips folder will appear in the output, and each page inside tooltips will be generated. You most likely don’t want this for tooltips (you just want the JSON file), so make the output setting false.

2. Create tooltip definitions in a YAML file

Inside _data > mydoc create a YAML file called something like mydoc_definitions.yml. Add the definitions for each of your tooltips here like this:

basketball: "Basketball is a sport involving two teams of five players each competing to put a ball through a small circular rim 10 feet above the ground. Basketball requires players to be in top physical condition, since they spend most of the game running back and forth along a 94-foot-long floor."

The definition of basketball is stored this data file so that you can re-use it in other parts of the help as well. You’ll likely want the definition to appear not only in the tooltip in the UI, but also in the regular documentation as well.

3. Create pages in your collection

Create pages inside your new tooltips collection (that is, inside the _tooltips folder). Each page needs to have a unique id in the frontmatter as well as a product. Then reference the definition you created in the mydoc_definitions.yml file.

Here’s an example:

---
id: basketball
product: mydoc
---

{{site.data.mydoc.mydoc_definitions.basketball}}

You need to create a separate page for each tooltip you want to deliver.

The product attribute is required in the frontmatter to distinguish the tooltips produced here from the tooltips for other products in the same _tooltips folder. When creating the JSON file, Jekyll will iterate through all the pages inside _tooltips, regardless of any subfolders included here.

4. Create a JSON file that loops through your collection pages

Now it’s time to create a JSON file with Liquid code that iterates through our tooltip collection and grabs the information from each tooltip file.

Inside your project’s pages directory (e.g., mydoc), add a file called “mydoc_tooltips_source.json.” (You can use whatever name you want.) Add the following to your JSON file:

---
layout: none
search: exclude
---
{
"entries":
[
{% for page in site.tooltips %}
{% if page.product == "mydoc" %}
{
"id"    : "{{ page.id }}",
"body": "{{ page.content | strip_newlines | replace: '\', '\\\\' | replace: '"', '\\"' }}"
} {% unless forloop.last %},{% endunless %}
{% endif %}
{% endfor %}
]
}

Change “mydoc” to the product name you used in each of the tooltip files. The template here will only include content in the JSON file if it meets the product attribute requirements. We need this if statement to prevent tooltips from other products from being included in the JSON file.

This code will loop through all pages in the tooltips collection and insert the id and body into key-value pairs for the JSON code. Here’s an example of what that looks like after it’s processed by Jekyll in the site build:

{
  "entries": [
    {
      "id": "baseball",
      "body": "Baseball is considered America's pasttime sport, though that may be more of a historical term than a current one. There's a lot more excitement about football than baseball. A baseball game is somewhat of a snooze to watch, for the most part."
    },
    {
      "id": "basketball",
      "body": "Basketball is a sport involving two teams of five players each competing to put a ball through a small circular rim 10 feet above the ground. Basketball requires players to be in top physical condition, since they spend most of the game running back and forth along a 94-foot-long floor."
    },
    {
      "id": "football",
      "body": "No doubt the most fun sport to watch, football also manages to accrue the most injuries with the players. From concussions to blown knees, football players have short sport lives."
    },
    {
      "id": "soccer",
      "body": "If there's one sport that dominates the world landscape, it's soccer. However, US soccer fans are few and far between. Apart from the popularity of soccer during the World Cup, most people don't even know the name of the professional soccer organization in their area."
    }
  ]
}

You can also view the same JSON file here: mydoc_tooltips_source.json.

You can add different fields depending on how you want the JSON to be structured. Here we just have to fields: id and body. And the JSON is looking just in the tooltips collection that we created.

You can store your mydoc_tooltips_source.json file anywhere you want, but to me it make sense to store it inside a tooltips folder for your specific project. This way it will automatically be excluded from other projects that are already excluding that project directory.

Note that you can create different JSON files that specialize in different content. For example, suppose you have some getting started information. You could put that into a different JSON file. Using the same structure, you might add an if tag that checks whether the page has frontmatter that says type: getting_started or something. Or you could put the content into separate collection entirely (different from tooltips).

By chunking up your JSON files, you can provide a quicker lookup, though I’m not sure how big the JSON file can be before you experience any latency with the jQuery lookup.

5. Build your site and look for the JSON file

When you build your site, Jekyll will iterate through every page in your _tooltips folder and put the page id and body into this format. In the output, look for the JSON file in the mydoc/tooltips/mydoc_tooltips_source.json file. You’ll see that Jekyll has populated it with content. This is because of the triple hyphen lines in the JSON file — this instructs Jekyll to process the file.

6. Allow CORS access to your help if stored on a remote server

You can simply deliver the JSON file to devs to add to the project. But if you have the option, it’s best to keep the JSON file stored in your own help system. Assuming you have the ability to update your content on the fly, this will give you completely control over the tooltips without being tied to a specific release window.

When people make calls to your site from other domains, you must allow them access to get the content. To do this, you have to enable something called CORS (cross origin resource sharing) within the server where your help resides.

In other words, people are going to be executing calls to reach into your site and grab your content. Just like the door on your house, you have to unlock it so people can get in. Enabling CORS is unlocking it.

How you enable CORS depends on the type of server.

If your server setup allows htaccess files to override general server permissions, create an .htaccess file and add the following:

Header set Access-Control-Allow-Origin "*"

Store this in the same directory as your project. This is what I’ve done in a directory on my web host (bluehost.com). Inside http://idratherbetellingstories.com/wp-content/apidemos/, I uploaded a file called “.htaccess” with the preceding code. You can view it here.

After I uploaded it, I renamed it to .htaccess, right-clicked the file and set the permissions to 774.

To test whether your server permissions are set correctly, open a terminal and run the following curl command pointing to your tooltips.json file:

curl -I http://idratherbetellingstories.com/wp-content/apidemos/mydoc_tooltips_source.json

The -I command tells cURL to return the request header only.

If the server permissions are set correctly, you should see the following line somewhere in the response:

Access-Control-Allow-Origin: *

If you don’t see this response, CORS isn’t allowed for the file.

If you have an AWS S3 bucket, you can supposedly add a CORS configuration to the bucket permissions. Log into AWS S3 and click your bucket. On the right, in the Permissions section, click Add CORS Configuration. In that space, add the following policy:

<CORSConfiguration>
 <CORSRule>
   <AllowedOrigin>*</AllowedOrigin>
   <AllowedMethod>GET</AllowedMethod>
 </CORSRule>
</CORSConfiguration>

Although this should work, in my experiment it doesn’t. And I’m not sure why…

In other server setups, you may need to edit one of your Apache configuration files. See Enable CORS or search online for ways to allow CORS for your server.

If you don’t have CORS enabled, users will see a CORS error/warning message in the console of the page making the request.

7. Explain how developers can access the help

Developers can access the help using the .get method from jQuery, among other methods. Here’s an example of how to get a page with the ID of basketball:

<script type="text/javascript">
$(document).ready(function(){

var url = "mydoc_tooltips_source.json";


$.get( url, function( data ) {

        $.each(data.entries, function(i, page) {
            if (page.id == "basketball") {
				$( "#basketball" ).attr( "data-content", page.body );
            }

        });
    });
 
});
</script>

View the Tooltip Demo for a demo.

The url here is relative, but you could equally point it to an absolute path on a remote host assuming CORS is enabled on the host.

The each method looks through all the JSON content to find the item whose page.id is equal to basketball. It then looks for an element on the page named #basketball and adds a data-content attribute to that element.

Why data-content? Well, in this case, I’m using Bootstrap popovers to display the tooltip content. The data-content attribute is how Bootstrap injects popovers.

Here’s the section on the page where the popover is inserted:

<p>Basketball <span class="glyphicon glyphicon-info-sign" id="basketball" data-toggle="popover"></span></p>

Notice that I just have id="basketball" added to this popover element. Developers merely need to add a unique ID to each tooltip they want to pull in the help content. Either you tell developers the unique ID they should add, or ask them what IDs they added (or just tell them to use an ID that matches the field’s name).

In order to use jQuery and Bootstrap, you’ll need to add the appropriate references in the head tags of your page:

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.2/css/bootstrap.min.css">
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.2/js/bootstrap.min.js"></script>

<script type="text/javascript">
$(document).ready(function(){
    $('[data-toggle="popover"]').popover({
        placement : 'right',
        trigger: 'hover',
        html: true
    });

Again, see the Tooltip Demo for a demo of the full code.

Note that even though you reference a Bootstrap JS script, Bootstrap’s popovers require you to initialize them using the above code as well — they aren’t turned on by default.

View the source code of the Tooltip Demo for the full comments.

8. Create easy links to embed the help in your help site

You might also want to insert the same content into different parts of your help site. For example, if you have tooltips providing definitions for fields, you’ll probably want to create a page in your help that lists those same definitions.

You could use the same method developers use to pull help content into their applications. But it will probably be easier to simply use Jekyll’s tags for doing it.

Here’s how you would reuse the content:

<h2>Reuse Demo</h2>


<table>
<thead>
<tr>
<th>Sport</th>
<th>Comments</th>
</tr>
</thead>
<tbody>

<tr>
<td>Basketball</td>
<td>{{site.data.mydoc.mydoc_definitions.basketball}}</td>
</tr>

<tr>
<td>Baseball</td>
<td>{{site.data.mydoc.mydoc_definitions.baseball}}</td>
</tr>

<tr>
<td>Football</td>
<td>{{site.data.mydoc.mydoc_definitions.football}}</td>
</tr>

<tr>
<td>Soccer</td>
<td>{{site.data.mydoc.mydoc_definitions.soccer}}</td>
</tr>
</tbody>
</table>

And here’s the code:

Reuse Demo

Now you have both documentation and UI tooltips generated from the same definitions file.