This guide is targeted at anyone who is creating Tutorials, Videos, and/or Courses for Experience League. If you are a member of a documentation team, or contributing content someone else created or only posting content you create occasionally, we have guides for you! Take a look at these guides,
Now that we know you are in the right place, let’s start with an overview of the various systems you will need to be familiar with.
Git/Github - this where all written content is stored, how we version the content, allow for author collaboration, and even allow for user feedback
Jira - Jira is what we use to manage our content creation efforts. It allows us to track what content is being built, what needs to be built, and also allows us to better understand who built the content, where the assets are, how old the content is, and how much content we have around various topics, solutions, roles, etc. We use Jira to drive the localization process for videos and it ties in with various integrations like Product Adoption Score behaviors, and the monthly Experience League content update.
MPC - Formerly known as Adobe TV, this is the video hosting platform we use to stream all of the videos on Experience League. This is the same platform used by Adobe.com. It leverages Adobe Analytics and provides a robust foundation for streaming.
The goal of this guide is to help learn by using a learn-by-doing approach. When you complete this guide,
You’ll gain the skills you need to work with these systems.
You should understand how the systems relate to the content you will be creating
Have a good understanding how we leverage the various types of content
Learn our tips, tricks, and best practices we have developed around content production.
Understanding the content
There are 4 main types of content you are likely to create,
Video - A video will usually fall in one of two categories; feature video or technical video. A feature video generally shows how to setup, configure and use a particular feature. Whereas a technical video shows the viewer the “under the hood” view of the feature including architectures, technical configurations/extensions, APIs that are used, etc.
Videos are typically 3-8 minutes in length. They should show the product in use, showing the UI, and avoid using PowerPoint. They should also avoid showing the speaker (e.g., talking head).
Tutorial - A tutorial is typically a step-by-step guide that takes the user through a progression with a destination in mind. A good example is the AEM Sites WKND Tutorial
Experience League uses the term “Tutorial” in the site navigation. In the site navigation it is used as a catch-all category that differentiates documentation and how-to content (e.g., videos, tutorials - as defined in this guide).
Article - An article is very straight-forward, it is mostly a page of text that can include visual elements.like an image or an animated gif.
Course - A course is used to deliver self-guided learning generally targeted at helping the customer get to first active use of the solutions(s), general use of the solution(s) or expanding their use of the solutions. Courses also all for badging, are tied to user preferences, etc.
Which content type to use?
This is generally left up to the content author’s discretion. Think about the audience along with the various content definitions, and then consider which medium will be the most effective for the audience given the content you are delivering.
For instance, if you are trying to explain the best ways to code an integration, you most likely will want to display code samples and allow the user to download these samples. Generally, this better handled in a written/tutorial. In a similar way, if you are trying to show someone how to the use the product UI to configure settings, a video can be a very effective way to do this.
It is perfectly ok to mix content types, like including videos in tutorials. A course is usually made up of multiple videos.
Do you know the latest?
It is always best to be sure you have the latest product information if you are going to be building enablement content.
The Knowledge Transfer (KT) wikis are the single source of truth for all things related to the product features. KTs are created and maintained by the product team. You can find KTs for all solutions in the KT repository.
If you are not familiar with the KT process, want more details on how it works, or if you are looking to add the KT process to your product, see this guide for more information.
If your solution doesn’t have a KT repository please discuss with the Product Management team. You can also reach out to Sean Schnoor if you need assistance.
Content creation workflow
There are 3 primary steps in the workflow,
Identify the content in Jira
Build the content
Publish the content
Identify the content in Jira
All Experience League content (with the exception of product documentation) is tracked in the Knowledge Transfer (KT) project. Jira has many advantages,
Creates an accurate repository of all Experience League content
Shows status of content through the content production process
Feeds data to various systems such as the Resource Recommender (used by the global CSM team to guide customers to enablement content) and the Experience League Content Newsletter. (If you don’t receive the newsletter, hop on vpn and sign-up).
If you don’t have access to the Knowledge Transfer (KT) Jira project reach out to Sean Schnoor.
As a content author you will primarily be creating Initiatives when creating Courses, and Stories for all other asset types. Each story or initiative maps to a single asset, 1:1.
The following will give you some guidance on how the status indicators are leveraged,
New - Initial state of any ticket. Means this is this something that we have identified to create, but we don’t have all the details yet (e.g., a product feature still under development).
To Do - This can be worked on, we have the information we need, no blockers. When possible the due date should be set, and factor in + or - 2 weeks of completion accuracy.
In Progress - This is being actively worked on. The due date should be set to with in + or - 2 days of completion accuracy.
Waiting for Input - There’s an external dependency preventing us from continuing to work on the content (e.g., need more information from Engineering).
Blocked - We are not able to publish this item (e.g., system issues, product engineering changes, etc.)
To Document - Ready to be added to git and posted to Experience League
Editorial Review - Assigns the content to the Experience League Editorial team (Blake Frei) to validate grammar, localization, markdown syntax, etc.
Removed - Asset still should be tracked but is not active, not live on Experience League
Done - Asset is publicly available, the publish link is required and should point to the experienceleague.adobe.com page
Take a look at this Quick Start that shows the steps to creating a KT ticket.
Build the content
All content on Experience League is associate with a markdown (.md) page.
A very easy way to get started, assuming you are using a Mac and Chrome,
Navigate to your Jira ticket, and click on the plug-in
Click on Copy Markdown to clipboard
title: Dynamically generating documents with Adobe Document Generator
description: This is the description text that will show on Experience League.
Dynamically generating documents with Adobe Document Genera… (Titles should be no more than 60 characters)