Help and Training Resources

We have been receiving quite a few requests for more training resources and more videos for product training. One of the challenges in creating static documentation resources on a product that is undergoing active development is that the resources run the risk of being outdated soon after you create them!

Another challenge in creating these resources is that it seems like there is a rabbit hole to fall into around every corner. By that, I mean that this project can go deep and wide pretty quickly.

Examples: Do we start with videos or written documentation? Which app to start with iOS, Android, or Mac? Do we start with a new user journey, or focus on specific use cases? Do we wait until everything is polished up nice and tidy, or do we piecemeal it out? So, we decided to take the following approach: Start anywhere, go everywhere.

I’ll be creating a series of posts that might have some random content, but we plan to get these out in rapid succession and then come back and organize the content into a more comprehensive help resource. This is a 1st draft or the beginning in a series of resources that we plan to offer. Your feedback is appreciated, and if you happen to see an error in the video or training materials, please note it in the comments.

Here are some of the videos we have recently created and posted to the YouTube Channel:

Informant 5 for iOS Videos

Informant for macOS

Applicable for both Informant for iOS, Android, and Informant for macOS

Language of Informant (Blog & Video)

Here is a link to our Support portal & FAQ

Pocket Informant Help & Support FAQ

If you have any additional video or help topics that you would like to see discussed, please comment below.

3 Comments

boydston01 on May 2, 2017 at 1:56 pm

Especially considering high activity in development, I say focus on written documentation because it is easier to update (and search). Avoid images for the same reason.

I suggest you go by the mantra: “Incorrect documentation is worse than no documentation.”

I wonder if the most helpful documentation may be very straightforward lists. Like keyboard shortcuts, FAQs, and features. For example, just list all the features and properties of an event, list where they can be syncing from and local sources, and list limitations/issues pertinent to the different sources. Simple lists of features like this could be very helpful because when users want to know how to do something, most of the time, it is really a question of “can it be done?” and “where do you find it?” More often than not, the steps involved become apparent when you know it can be done and where it is. For example, if I am looking at the list of settings on the advanced tab of preferences, and I see application logging, I now it exist and I know where it is. Therefore, I can easily work out the steps to change it. Similarly, if I were trying to figure out how to change sync logging, searched “logging”, the result shows me it is a setting of the advance tab in preferences. Bam. Done.

Lists like these also help surface the things that actually need explanation, like “to change event property abc, setting xyz must first be set to lmnop.”

Keith on May 2, 2017 at 2:54 pm

boydston1,

That is a good suggestion. Here is a 1st draft of some of that type of information.

http://staging.pocketinformant.com/language-of-informant/
boydston01 on May 2, 2017 at 9:54 pm

Yes, that post came to my mind. It is exactly along the lines of what I am suggesting. Notice how simply listing terminology ends up surfacing features and being instructional. Good stuff.

boydston01 on May 2, 2017 at 1:56 pm

Especially considering high activity in development, I say focus on written documentation because it is easier to update (and search). Avoid images for the same reason.

I suggest you go by the mantra: “Incorrect documentation is worse than no documentation.”

I wonder if the most helpful documentation may be very straightforward lists. Like keyboard shortcuts, FAQs, and features. For example, just list all the features and properties of an event, list where they can be syncing from and local sources, and list limitations/issues pertinent to the different sources. Simple lists of features like this could be very helpful because when users want to know how to do something, most of the time, it is really a question of “can it be done?” and “where do you find it?” More often than not, the steps involved become apparent when you know it can be done and where it is. For example, if I am looking at the list of settings on the advanced tab of preferences, and I see application logging, I now it exist and I know where it is. Therefore, I can easily work out the steps to change it. Similarly, if I were trying to figure out how to change sync logging, searched “logging”, the result shows me it is a setting of the advance tab in preferences. Bam. Done.

Lists like these also help surface the things that actually need explanation, like “to change event property abc, setting xyz must first be set to lmnop.”
- Keith on May 2, 2017 at 2:54 pm
  
  boydston1,
  
  That is a good suggestion. Here is a 1st draft of some of that type of information.
  
  http://staging.pocketinformant.com/language-of-informant/
- boydston01 on May 2, 2017 at 9:54 pm
  
  Yes, that post came to my mind. It is exactly along the lines of what I am suggesting. Notice how simply listing terminology ends up surfacing features and being instructional. Good stuff.

3 Comments

Cart

Recent Posts