How our tools shape how we write

Co-Founder, CTO
You're traveling through a portal into another realm -- a realm made entirely of sight, of color and sound, of ideas manifesting in your mind. A wondrous land, without boundaries. You are… composing a masterpiece of an email. But as you accentuate your prose with stylistic flourishes—bold! italics! emoji!—your text editor gets in the way and helpfully formats your text:
...except, on the receiving end, the reader receives a garbled message, like this:
Well \033[3mhello\033[0m there!
I'd \033[1mlove\033[0m to help you out! ▯
Has this ever happened to you? Different editors often encode text in their own quirky ways. This makes the reading and writing experience consistent—for them, on their platform. But because Yetto messages are sent and received from a variety of platforms, we require a writing system that is useful for the writer and adaptable for the reader, wherever they may be.
Text is more than just words
Many text fields, like the one above, will try to show you what the formatted text will look like when it's published online. But writing on the web is not the same as reading on the web; while the message above may render correctly on the platform it's designed for, sending it via other channels, like a text messages or an Slack message, can yield woeful results. The HTML tags for you bold text get stripped out. Your styling gets implemented with instruction sequences, like \033[1mlove\033[0m
—unintelligible.
Essentially: you can't trust that what your editor shows you will be the same for your reader. This is especially true in support work. Too often, help support systems mangling text formatting in way that only they understand, obfuscating the writer's intent.
Yetto is all about open communication, and we prefer to work with data formats that are ubiquitous and easily rendered by systems beyond our own. That's why Yetto supports CommonMark (née Markdown), to balance the expectations of so-called plain text with text formatting enhancements. With CommonMark, readers can understand text emphasis through glyphs, even without fancy rendering. But we do it a little differently.
A lot of websites that support CommonMark have two tabs for writing: one for the raw text and one for the rendered HTML preview:
Two tabs? In this economy?!
Aside from taking up screen real estate, this UX takes up unnecessary time, as writers bounce between two screens to fully understand what they're writing.
Yetto doesn't copy that. Instead, we show you the expected renderings inline, as you're typing:
Users who are well-versed in CommonMark can write without distractions and, users who are unfamiliar with CommonMark can keeping using toolbars or keyboard shortcuts to format text in a way they're familiar with, aka a win-in with less UI bloat. And! As people unfamiliar with CommonMark see the results applied, they're learning a new markup language. By not hiding the syntax we let the writer see how CommonMark works, which is knowledge that's applicable beyond Yetto.
Introducing Stheno
There's a surprising amount of engineering complexity inside these little text boxes.
From the venerable CKEditor to more recent entrants like TipTap, most editors take the position that text is just text. Even if they do support simple markup like CommonMark, there's no additional treatment or consideration of the raw content.
At Yetto, we believe support professionals deserve an editorial experience that serves them beyond just writing replies. We believe in treating text as code – your editor should assist your writing programmatically, and then stay out of the way. Right now, "editor assistance" happens in two extremes: on the lo-fi side, a spellchecker, and on the hi-fi side, an AI assistants. But between those two peaks is an entire valley of functionality. Concepts like Language Server Protocols (LSPs) to associate your text with a database, slash commands which take into account the context of where commands are being typed, syntax highlighting for phrases, variable substitution through the use of Liquid templates—all of these are enhancements to your text, not distractions, and we think support professionals deserve a sophisticated editor that takes advantage of them.
Enter Stheno, Yetto's text editor. Stheno is a collection of preexisting packages and custom extensions built on top of CodeMirror, a popular in-browser code editor. When we began investigating the text editor landscape, we couldn't find any off-the-shelf JavaScript libraries that struck the right balance between writing and programming. If you treat the written word as a programming language, you unlock possibilities and paradigms that have existed for years—just not for support professionals.
Make Stheno your own
Stheno understands the "metadata" beneath the text—what the text is trying to do, on top of what is actually being said.
At its core, it's just a collection of functions:
export const sthenoConfig = () => [
highlightSpecialChars(),
history(),
drawSelection(),
dropCursor(),
EditorView.lineWrapping,
EditorState.allowMultipleSelections.of(true),
autocompletion(),
highlightSelectionMatches(),
indentOnInput(),
bracketMatching(),
closeBrackets(),
KEYBINDINGS.of(keymaps()),
THEME.of(darkColorScheme ? yettoDark : yettoLight),
LANGUAGE.of(markdownWithJSONCFrontmatterConfig()),
language.language.data.of({
autocomplete: markdownCompletions,
}),
];
These functions are then passed as extensions to the CodeMirror editor:
this.editorView = new EditorView({
doc: initialContent,
extensions: [
sthenoConfig(),
// sthenoToolbar(),
tooltips({
parent: this.editorTarget,
position: "absolute",
}),
// more extensions
]
})
By being able to treat the entered text as code, we're able to implement custom keybindings and autocompletion of text. That means that, theoretically, you can create your own customized versions of these to load into the editor. It's only JavaScript, after all—the world's most popular programming language. Want vim bindings? A keystroke that generates a link to documentation? Your own personal Klingon dictionary? Sure. It's all possible.
Also, treating text as code also like this allows us to create different segments of text. Let's say For example, if we wanted to apply frontmatter, like so:
---
{
"title": "How to write on the web",
"author": "gjtorikian"
}
---
Hello there {{ data.customer.first_name }},
Thanks for writing in!
Other prose editors would treat this as a single blob of text, but Stheno sees three different types of content here:
- JSON frontmatter
- CommonMark syntax
- Liquid templates
All three of these pieces have their own syntax highlighting, their own keybindings, and their own shortcuts. Your cursor, wherever it lies, has contextual awareness of the nature of your text.
Building towards the future
Some of the capabilities we've mentioned above, like Liquid template substitution and loading your own JavaScript to customize the editor, are works in progress. The hard work of determining each language in the editor is finished; we just need to better understand how our users would want to integrate frontmatter and Liquid in their replies. Many of our engineering projects end up open sourced, and Stheno will be no different. We're hard at work cleaning up the code!
While the public API needs a bit more polishing, Stheno is already available to experience now on any Yetto conversation. Sign up today to give it a try!