> For the complete documentation index, see [llms.txt](https://docs.userlane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.userlane.com/assistance/a-tour-of-the-editor.md). # A tour of the Editor The Editor is where Userlane content is built, separately from the portal where it is targeted and measured. The Editor is where Userlane content is built. It opens on top of the application you are documenting, so a guide or a tooltip is created against the real screen rather than a mockup. The portal[^1] handles what happens next: who sees the content, in which language, and how it performed. ## Opening the Editor You can open the Editor from a few places. A button in the Assistant, reachable from anywhere in the application after signing in to Userlane, opens the Editor panel over the application. The Userlane browser extension icon in the browser toolbar opens the same panel without going through the Assistant.

Starting the Userlane Editor from the Assistant — Open the Editor from the Assistant or the browser extension icon.

## What is built in the Editor Six content types are created in the Editor. Each one produces something different for the end user.

Content type	What it produces	What the end user sees
Guides	A recorded tutorial of a process, built by clicking through it once in the live application.	Step-by-step prompts on the screen, in order, from the first action to the last.
Validators	A check on what someone types into a form field, with three modes: Measure, Visible, and Warning.	Nothing at all in Measure mode. An inline hint in Visible mode. A warning at submit in Warning mode.
Tooltips	An explanation attached to a single element on the screen, set as either a hint or a beacon.	A hint appears on hover. A beacon marks the element so it gets noticed.
Tasks	A definition of a multi-step process, with a start and an end, built from scratch or from an existing guide.	Nothing. A task is a measurement definition and shows no content.
Tags	A definition of a single tracked action on one element.	Nothing. A tag records the interaction and shows no content.
Contextual Actions	A link between one or more conditions and one or more responses.	Whatever the action launches, at the moment its conditions are met.

{% hint style="warning" %} **Not all Assistance elements live in the Editor.** The following are set up in the portal: announcements and other in-app messages, audiences, display rules, languages and translations, Assistant settings, knowledge connectors, and content analytics. Surveys, including Net Promoter Score (NPS) and customer satisfaction (CSAT), are also set up in the portal and are part of Intelligence. {% endhint %}

The Userlane Editor with the sidebar and content list — The Editor with its sidebar of content types on the left.

## How the Editor is laid out ### The sidebar The Editor sidebar runs down the left edge. It shows icons only, so hover an icon to see its label. The six content types sit at the top in this order: Guides, Validators, Tooltips, Tasks, Tags, and Contextual Actions. Settings sits at the bottom. Across the top of the panel, **Search for Userlane content** finds anything that already exists, and **Create** starts something new. ### Guides A guide walks someone through a process one step at a time, on the real screen. This is where guides are built and organized. The list groups them into chapters, with anything ungrouped collected under **Unsorted Guides**, so a long process can be split into several guides that still read in order. Building a guide means recording it. Click through the process once in the application and each click becomes a step. A left click makes an interactive step, where the user has to do the action themselves. A right click makes an explanation step, which just tells them something. The **Control** key pauses recording and **Escape** stops it. Afterwards the steps appear as a list that you can reorder, rewrite, or add to. **Preview** runs the guide without publishing it, so you can check it before anyone sees it.

Recording a guide in the Editor — Each click during recording becomes a guide step.

### Validators A validator checks what someone types into a form before it is saved, so a mistake gets caught where it is made rather than cleaned up later. How much the user notices is a choice. **Measure** records errors silently and shows nothing, which gives a reading of how often something goes wrong before anything is changed. **Visible** shows a hint next to the field. **Warning** waits and warns at submit. Every validator needs a completion button, meaning the control the user clicks to submit the form. Without one the validator cannot be edited, and the list shows a banner when any are missing.

Creating a validator in the Editor — Choose how visible a validator is to the user: Measure, Visible, or Warning.

### Tooltips A tooltip explains one thing on the screen. It suits cases where a full guide is more than the situation needs, like a field whose label is not obvious. There are two forms. A hint shows the text when someone hovers over the element. A beacon places a marker that draws the eye to it. Both can carry an icon, and the hint can be positioned automatically or by hand. You write the text directly on the page, in a box beside the element it belongs to, so it is clear what it will look like in place.

Creating a tooltip in the Editor — Tooltip text is written in place, beside the element it explains.

### Tasks A task marks out a process worth measuring: where it starts, where it ends, and the steps in between. Nothing appears on screen for the end user. The point is to find out how many people finish and where the rest give up. There are two ways to make one. Build it from a guide that already documents the process, or define it from scratch. **View Analytics** shows the results once the task has been running. ### Tags A tag tracks one action on one element, such as a click on a particular button. Like a task, it shows the end user nothing. It answers a narrower question: did this get used. A tag points at an element on the page, so the main work is making sure it still finds that element after the application changes. **Test tag** confirms it fires, **Reselect element** points it somewhere else, and **Refine selector** adjusts how the element is identified by its selector[^2]. Tracking can be limited to certain pages or left on everywhere, and the **Active** toggle in the list switches a tag off without deleting it. ### Contextual Actions A Contextual Action makes content appear on its own, instead of waiting for someone to go looking for it. It pairs a situation with a response: when this is true, do that. The panel splits in two. Contexts on the left are the conditions. Actions on the right are what happens when those conditions are met. **Match all** decides whether every condition has to be true or just one of them. **Activate** switches the action on, which is separate from saving it, so you can set it up in advance and turn it on later.

Contextual Actions panel with contexts on the left and actions on the right — Contexts set the conditions; actions set what happens when they are met.

## Relevant articles {% content-ref url="/pages/OUb4HG9RxVliztfFeCLm" %} [What Assistance is](/assistance/what-assistance-is.md) {% endcontent-ref %} {% content-ref url="/pages/ekWOHrKxU3Yp6xV24fPM" %} [Userlane content types](/assistance/content-operations/authoring/userlane-content-types.md) {% endcontent-ref %} {% content-ref url="/pages/VZqRoAJSjPm9ZGD2jNVG" %} [Create and manage content](/assistance/content-operations/authoring/create-and-manage-content.md) {% endcontent-ref %} {% content-ref url="/pages/1S0Ysrf45iMPMs4rp5yk" %} [Creating guides](/assistance/in-app-guidance/creating-guides.md) {% endcontent-ref %} ## FAQ

What is the difference between the portal and the Editor?

The Editor is where Userlane content is built. The portal is where that content is scoped to an audience, translated, scheduled, and measured. They are separate interfaces and can be open at the same time.

How is the Editor opened?

Signing in to Userlane inside the application shows a launcher in the bottom left corner of the page. Select **Start the Userlane Editor** to open the Editor over the application.

What content types are built in the Editor?

Six: guides, validators, tooltips, tasks, tags, and Contextual Actions. Announcements and surveys are written in the portal instead.

Can announcements be created in the Editor?

No. Announcements are written, targeted, and scheduled in the portal.

What is a chapter?

A chapter is a named group of related guides. Chapters keep a long process in order when it is split across several guides, and you create them from the guide list in the Editor.

Does every content type have the same tabs?

No. Guides, validators, and tooltips each have four tabs, though the first two differ by type. Tags and Contextual Actions have no tabs and show everything on a single panel.

[^1]: The portal is the Userlane web interface where content is configured, targeted, and measured, separate from the Editor where it is built. [^2]: A selector is the rule Userlane uses to find an element on the page. If the application changes, the selector may need refining so it still matches. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.userlane.com/assistance/a-tour-of-the-editor.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.