The Way You Should Manage UI Content Strings in Your Web Application
How web application developers should handle UI strings (copy) updates in their projects?
Read this post on the new Frontitude blog!
Every product has its language. We at Frontitude believe it’s as important as design and technical implementation. The product language is composed of components called Copy, which is every word or a sentence that is responsible for communicating with the user. It’s what driving users to engage and use your product in the way they should. The process of managing the language of a product is therefore called Copy Editing and involves the writing of copy for new features and also updates of existing ones.
As a developer, although you might don’t want to be a part of it, you are a critical link in this process.
Developers’ Part in Copy Editing Today
Let’s take a look at the average development cycle of a new product feature:
You can see that most of the stages involve writing (or re-writing), which means that UX writers come up with a new word, or revising current ones. Why is it such a repetitive process? It’s simply because in every stage writers (and UX professionals in general) get additional information that helps them to improve the language: Wireframes to Mockups, Mockups to Live elements, Live elements to Production version with usage statistics. On each one of these hops, they get a greater sense of how to product feels like, and go back to their table to revise their work.
Those changes and revisions come with a price for the entire team; a lot of maintenance of strings done by developers, merging it back to the codebase. Not only it takes their time, but it also involves repetitive and tedious work, which can be frustrating sometimes. When developers need to sync new strings, it’s almost always an offline process of asking the product or UX guys where should they take them from — Design tool? Sent over Slack? A spreadsheet? Is it the final version, or they’re still working on them? Then, they copy and paste the new values into a huge JSON file and commit.
Developers were not hired to do that. Instead, they should focus their real work, like building a fast search mechanism or write a cache layer to improve performance.
You Shouldn’t Be Bothered About It
We think that developers should be kept outside of the loop when it comes to copy editing. Period. They can support the process and have the ability to raise flags, but copy editing should not require their time and effort.
First, we assume that developers are not embedding the strings inside the HTML (or any other template engine), which is a really bad practice in big applications. Therefore, the ONLY friction developers should experience during the copy editing process is the transfer of keys that are going to link to the strings in the code, which should happen only once per string. Then, when the keys are in the code, their values should be managed somewhere else by the UX professional. The developer is basically finished now, and ready to work on the really important stuff.
How Can You Make It Work Better?
The optimal workflow lets the UX professionals (specifically UX writers) update and deploy copy changes completely by themselves. We know that as a first step, this isn’t feasible since it’s hard to change existing processes such as CI/CD pipelines. Also, such a high touch solution can bring security and privacy issues, which we prefer to avoid for now.
As a first step, we’d like to ease the process by simply letting developers escape this workflow and in the same breath making copy editing much more efficient and pleasant for the UX professionals, which are currently lack of specific tools for this job.
Core components of our solution
- Cloud-based central repository for all of your copy
- Command-line tool, so that developers can pull string updates right from their dev environment, and commit those changes to the codebase quickly
- A Sketch plugin, so that UX professionals would be able to edit copy even before the feature/product is implemented
- A Chrome extension, so that UX professionals would be able to edit copy right on the application when it’s alive (also in dev environment)
- A web application that serves as single place for everything that’s related to copy in your product that allows collaboration, defining and keeping content style guides, tracking changes, and more…
By using our platform, product development teams would get the following benefits:
- Developers can pull new strings (copy) version from their command-line (CLI), just like they sync with their remote Git repository.
- UX professionals are able to write better copy while composing it right on the design, whether it’s in design tools or the browser.
- UX professionals have a clear overview of their current product language to keep it consistent, collaborate with other peers, and see who committed what.
- Ping pong between designers, developers and UX writers is over. Everyone has a clear view of every copy status, and an easy way to pull it to the codebase.
We believe that giving these tools to product teams will enforce a better copy editing workflow, which eventually will improve user experience and save precious time.
We are currently building the solution and prepare for launching it soon. Submit your details on our website to request early access: https://www.frontitude.com
Feel free to comment here with what you think about our observations of the copy editing workflow, and whether you find our solution relevant to you 😊
