Writerside: The Name, the Vision, and Plans for 2024
The winter holidays have historically been a time for magic and stories. With this in mind, I’d like to share a little story of my own – one with more than just a sprinkling of magic.
Have you ever wondered where the name of our product came from? I’ve been asked this question many times on different occasions.
When the project started, we were often referred to internally as the “IDE for technical writers.” That’s understandable because JetBrains’ flagship products are integrated development environments (IDEs). But we needed a good, humorous, and catchy name for our product.
There is a process at JetBrains for product naming. The research team places the suggested names onto a value-driven association map. Then, there is a linguistic check to ensure the proposed names don’t have negative connotations in different languages. This is followed by research to see if the name appeals to potential users, and of course, there’s a legal compliance check.
We had a lot of fun brainstorming names. We played with associations, indulged in creating puns, and came up with a few dozen options. At the final stage, we had the following four candidates to choose from:
When the time came to make our final decision, none of the names felt like a perfect fit. At the same time, we were about to release our first landing page, and it needed a name on it. The “IDE for technical writers” seemed too long to me, so I started using “Writers’ IDE” – and there it was staring us right in the face.
WritersIDE. Or WriterSide. The perfect name had been right under our noses all along.
We conducted the linguistic and legal checks – and, miraculously, the new name passed them all.
We immediately fell in love with the new name. It had all the ingredients – a built-in pun, the “IDE” part that resonated with the JetBrains brand, and the two-word formula that’s often used in our products (for example, RubyMine, PyCharm, WebStorm, DataSpell, etc.). And most importantly, it conveyed our mission of helping writers do their jobs and being on their side. It has even inspired all kinds of jokes referencing “Come to the dark side” (a line from Star Wars).
Yes, we celebrated our first Early Access release with cookies – so predictable.
2023 was a good year for Writerside.
Now, with 2024 right around the corner, we are setting goals for the next year. In the spirit of making New Year’s resolutions, we would have loved to share our roadmap with you, but uncertainty abounds.
Writerside was born out of our internal practices, and our team is excited to see how it resonates with you. We don’t have a fixed in-depth roadmap just yet, but we’ve been listening to your feedback, and your insights have outlined our path.
There are a few strategic directions that we are committed to. We would like to hear your thoughts on these. To share any ideas you may have, just click on the link to the ticket and leave a comment.
A polyglot editor
Writerside already supports two markup languages: Markdown and an XML-based semantic markup. Each of these can be developed towards polyglot capabilities. For Markdown, AsciiDoc seems to be the logical next step. For the XML-based flavor, it’s DITA.
After all, why should you have to migrate from one language to another to use the docs-as-code approach, automated doc quality checks, or single-source capabilities?
Comment and vote 👉 WRS-3735 DITA support
Tell us about your DITA case 👉 Book a short call with us
Documentation often goes through several steps before it gets published: peer review, editor review, stakeholder review, and compliance review – this all takes time.
If we automate what can be automated, writers and reviewers will not have to rely on their eyes to spot typos, grammar errors, and style-guide violations. This will help writers avoid errors before they are even seen. Letting mistakes slip through can be embarrassing, and we’re on the writers’ side, remember?
For steps that cannot be automated, we want to give reviewers a staged HTML version of the docs. They won’t just review the text – they’ll experience the documentation as readers would, evaluating the overall user experience. This means the exact same layout, appearance, and navigation as the end users will see when your docs go live. And no reviewing in Google Docs – all revisions and edits are tracked in the version control history.
Comment and vote 👉WRS-28 Writerside Review
Better content reuse and single-source
Writing in Markdown often makes it hard to reuse content. And Markdown is a common choice in docs-as-code. We’ve tackled this issue with XML snippets, but we can do much more. To reuse content, you need to know what’s available, where it’s stored, and how it’s organized. Otherwise, you might end up duplicating existing texts. We’re working on a duplicate analysis tool that will not only help writers identify shareable content but also alert them about similar existing content as they write.
Comment and vote 👉WRS-86 Single-source improvements
Docs and code
If you’re writing for developers, your docs most likely include code samples. These samples must be functional, which means they need to be tested. Writerside, being developed on the same IntelliJ platform as JetBrains’ IDEs, could potentially enable you to test these code samples directly in your content files.
But sometimes storing code samples separately is easier. Developers can maintain them without cloning the entire documentation project or having to edit or review them in an unfamiliar environment. One step even further would be to alert the writer if the code changes, so that documentation can be updated accordingly.
Comment and vote 👉WRS-3736 Better support for code samples
🙏 Help us with details!
All these features are in the discovery and research phases, and we’re asking for your help here. If any of these resonate with you, or if you are trying to come up with a solution or workaround to any of the problems outlined above, we’d be happy to schedule a short call with you.
You can also send us a direct email at email@example.com
Download Writerside standalone or install the Writerside plugin 👇
Subscribe to Blog updates
Collaborating on Docs: Best Practices and Strategies From JetBrains Writers
Our first blog post on Git sparked discussions among different communities of tech writers. Many questioned the described workflow and highlighted that having to collaborate on the same file, pull and rebase changes daily, and resolve conflicts may be a sign of organizational and content management …
Harnessing the Power of the Kotlin DSL for Documentation
DSL? What DSL?The essence of the Kotlin DSLDemonstrationThree key strengths of our approachSeparation of ConcernsDocs-as-Code on a whole new levelExtensibilityWhy Kotlin?Do I need to be a coder to use the Kotlin DSL?Conclusion This material was initially presented at the API The Docs Conference i…
Field Notes: The Writerside Team at Write the Docs Portland and soap! Krakow
Write the Docs Portland Not that I can judge, as I'm not a frequent conference-goer, but Write the Docs (WTD) stands out from all others I have attended – the good, the bad, and the corporate. A friendly and open community was eager to accept anybody who writes docs, whatever their o…
Tech Writer’s Git Story: From Isolation To Collaboration
When I joined JetBrains back in 2014 as a senior technical writer, our team consisted of 5 documentarians covering 6 products. We sat together in a separate room and kept our door closed most of the time, rarely mingling with any developers. We’d see them at the daily IntelliJ IDEA standup,…