This post is for Day 7 of Merpay Advent Calendar 2023, brought to you by @malli and @ben.hsieh from the Mepay Growth Platform Frontend team.
Preface
We’re from the Merpay Growth Platform Frontend team. Our team has focused on CRM criteria for many years. We build tools and services to help marketers to reach our customers. One of the greatest hits among these tools is a WYSIWYG page builder that allows marketers to create interactive content with small-to-zero engineering effort involved.
https://events.merpay.com/techfest-2023/en/#day-1_session8
Nowadays, Mercari’s marketers are creating web-based content on this platform day by day as an important part of our marketing operations. In order to make this process more efficient, the team continuously introduces handy functionalities to make the experience similar to most of the design tools, like Undo/Redo and cross-application copy-pasting functionality. Those are great but there’s one big missing piece we still need to solve, that’s about team collaboration.
Imagine owning a WYSIWYG application with 100s of marketers editing 1000s of pages every month. As the number of users(marketers) increases, with every page being public and open to edit for all, arises the most annoying problem- users overriding others’ pages unknowingly. Consider this- you are a marketer, you spend 2 hours creating a campaign that will go live soon. Saved the changes, went to bed to continue working from the next day, and when you wake up and see, all your changes are probably gone. Why? Because, someone else who is lazy to create a new page wanted to experiment with something and they felt free to edit on your page which shows on top of the list as it’s recently edited.
We faced a similar challenge. With features ranging from creating UI components, to fetching from APIs/mocking their data, using conditional statements to context and auto completion, EP pages(※) provide end-to-end features starting from implementing a design to publishing it in webviews without writing any code (at least most of the time 😉).
At that point, our page editor only allows a single user to edit the page. Multiple users editing a page could result in conflicts, so people working on the same page need to ask “Can I edit the page now?” over slack when it comes to collaboration. This made us think about the possibility of supporting concurrent editing.
※：EP-Pages is a marketing tool which provides a WYSIWYG editor that is used to make and publish campaigns with close to zero code.
The Ultimate Goal
Achieve Concurrent Editing
For multiple users to be able to edit on the same page in parallel. To achieve this we will have to do the following(in very brief):
- Continuously push the changes from the users’ local machine to the server and conduct conflict resolution if there are any conflicts.
- Most famous conflict resolution algorithms are OTs (Operational Transformation, used by Google Docs) and CRDTs(Conflict FreeReplicated DataTypes, used by Figma). CRDT is more apt for us as our data is mostly in object format. OT is more apt for text-editor kind of applications.
- The above two steps are highly challenging and time and effort consuming, but we wanted to go as close to making the UX perfect! So we broke down the steps. The initial step in the journey towards collaborative editing would be to let the users know that there are multiple users editing the same page. For that we used firebase realtime updates to alert users when there are other users editing the same page.
- Now, the second challenge: someone making changes and saving in the page created by you and you end up losing your work. Hurts the most. So we will need a mechanism in which no user would lose their work. They should be able to see their work and get back to the same point where they left off last time even if there have been newer changes done. And this is when we decided to implement page-history. And the rest of the article explains why we chose to implement this and how we did and what we plan for the future.
Why Page History?
There are two main reasons why we need it. Firstly, it serves to safeguard users’ work from potential loss. Secondly, it provides a means to distinguish and track individual users’ modifications, which can be helpful in resolving conflicts when necessary.
Our Team’s Journey to Enhancing Concurrent Editing and Reliability in Our Page Editor Tool
In our quest to improve the capabilities of our page editor tool, we focused on two key aspects: concurrent editing and reliability.
First and foremost, we recognized the importance of saving every version of a page whenever a user makes changes. Additionally, it was crucial to attribute these changes to the respective user. To achieve this, we implemented a new subcollection within each page document in Firebase. Within this subcollection, we stored the schema of the page along with the user’s ID who made the changes. This way, every time a user saves the page, it is stored separately in this subcollection, ensuring a comprehensive history of changes.
Of course, it was equally important for users to be able to access and view all the versions of a page. To address this, we introduced the history panel in our app. Located on the right side, this panel allows users to easily check and navigate through all the available versions. By simply clicking on a version, users can instantly view the corresponding state of the page in the editor shell.
Now, here’s where things get interesting.
Addressing Unsaved Changes and Bookmarked History Versions
We encountered a challenge: what if a user is currently making changes to a page but wants to explore other versions?
Ideally, we wouldn’t want users to switch versions if there are unsaved changes. However, we also understood that users might want to refer to previous versions while editing. To strike a balance, we made it possible for users to open a different version even if there are unsaved changes. However, to protect their current work, we open the selected version in a separate tab.
While this approach may not provide the best user experience, it ensures that users can freely explore different versions without losing their progress. In the future, we plan to implement a feature that checks for unsaved changes and prevents users from switching versions until they save their work.
Later, to address potential issues with unsaved changes, we implemented a quick fix. If a user tries to reload or change routes before saving their changes, we display an alert to prevent any accidental loss of data. In the future, we plan to leverage the browser’s indexDB to track local changes, ensuring a more robust solution.
We also considered the scenario where users want to discard their unsaved changes and move to a different version. To make this process smoother, we added an option in the history panel that allows users to discard their existing unsaved changes at any point.
As the number of history versions grows, it becomes challenging to identify key or important versions, especially for big campaigns. To address this, we plan to introduce an option to bookmark history versions. These bookmarked versions will be displayed in a separate tab within the history panel, acting as a filter and making it easier for users to navigate through their preferred versions.
Publish desired version and providing description
With the core functionalities in place, we didn’t stop there. We wanted to go above and beyond to provide the best user experience possible. One of our bold ideas was to allow users to publish any version of a page. Why limit them to only the latest saved changes? By giving users the freedom to publish any version, they can experiment and save their work without any worries. But we didn’t stop at publishing options. We also wanted to empower users to create new pages based on previous versions. This way, they can easily move their work as templates and make edits as needed. This feature is currently under development and will be available to users soon!
Lastly, we want to enhance the user experience by adding a description field. This field will provide information such as the page from which the current version was cloned, the parent version from which the current version is copied, and more. This additional context will make navigation between versions even more seamless.
And there you have it! Our journey to enhance concurrent editing and reliability in our page editor tool. We didn’t settle for the basics; instead, we pushed ourselves to implement additional features and provide the best user experience possible. Stay tuned for the upcoming releases, as we continue to innovate and improve our tool!
TL;DR
- Version history is a feature built to provide the best UX to the users.
- It basically saves the instances of the page and keeps them as versions.
- This ensures that any user’s work is never lost!
- Being able to store the journey of a page, helped in bringing additional features such as publishing any of the versions, and cloning any versions(like using templates), etc.
And this brings us to the end of this article. We sincerely thank you for taking out your time and reading till the end. Hope you enjoyed it! Feel free to reach out to us if you want to have a chat.
