When Evernote launched in 2004, the world was a different place: “Shrek 2” dominated the box office, people still drove Hummers, and the must-have cell phone was a Motorola Razr. Though all of those things are past their prime, the note-taking app Evernote is as relevant as ever, thanks to the company’s willingness to evolve with its users and anticipate change.
While a necessary part of life for those in tech is adapting to and setting the curve for new technology, change is no easy feat. That’s how the engineers at Evernote recently found themselves at a crossroads: Should the team keep working with increasingly incomplete solutions to legacy issues, or should they focus on building something new?
Identifying the problem (and swallowing the frog)
You’re an Evernote user who opens a note on your laptop to jot down some project details you don’t want to forget. Later, you open Evernote on your phone to add a few more ideas. You might not know it, but you were using two different editors to access that same note.
As oblivious as the user might be in this scenario, Evernote engineers were painfully aware of the issue. If they wanted to make an update or ship a new feature for notes, they would have to build different versions of that product to fit the different codebases for every type of device the app runs on — iOS, Android and the web, among others. As a result, they couldn’t innovate and improve the app in the way they wanted.
To get the full story on the importance of the new product, how it came to be and what it means for the future of Evernote, we spoke to three engineers who played a pivotal role in its development.
The who’s who of Evernote’s engineering team
Director of Engineering Travis Huber: As the leader of the team, Travis isolates ways to improve the Evernote experience. He prioritizes innovation so he and his team can ship exciting new features that enhance the app.
Senior Software Engineer Chris Johnson: Chris’ focus is on the editor’s functionality, which involves fixing bugs, testing and code reviews. In his role, he looks for opportunities to collaborate with other teams like marketing, support and design.
Software Engineer Jesse Jorgenson: Like Chris, Jesse spends a lot of time working on the common editor. One of his goals is to keep a close eye on tech debt — a task that benefits the whole company and its users.
A need for change
Together, Huber, Johnson, Jorgenson and the rest of the engineering team opted to set their sights on something new — a module that would use the same logic for the app’s note editor across any device. Their vision? An end product that promises a more consistent user experience and would set up opportunities for the engineers to release products faster than ever.
As if that wasn’t reason enough, having one editor would immediately allow for a cleaner, more uniform user experience.
Travis Huber: As our user base has grown — and grown more sophisticated — we evolved from a world of “one user, one device” to a world where everyone wants all their information available on whatever device they’re using. That is one of the promises of Evernote: your information at your fingertips, wherever those fingertips are. But, as with every platform team building their own version of the note editor, our features, implementation choices, delivery schedules and the overall experience of using Evernote diverged wildly from one device to the next. Since the note is the primary way most users interact with Evernote, it made sense to start there in an effort to unify and improve that situation.
Chris Johnson: Before the common editor, each client was responsible for implementing all editor logic independently. That carried a high cost in terms of consistency and maintainability. I never thought about it much before I joined Evernote, but it turns out there are an incredible number of interdependent decisions to be made in the editor domain. It’s very difficult to strike a balance on simplicity vs. usefulness, behaving predictably vs. allowing diverse content, and more. The new common editor would enable Evernote to be more intentional and more consistent about the tradeoffs we make for editing interactions.
Since the note is the primary way most users interact with Evernote, it made sense to start there in an effort to unify and improve that situation.”
Jesse Jorgenson: Rich text editors are often considered one of the more complex pieces of software that you can write. Rewriting an editor for many different Evernote clients would mean that we would virtually never ship new features in the editor across different clients. Instead, it would make more sense to use a single technology that could be run on each client and to have a common component to maintain the complexity.
Laying the groundwork
Before they could begin building the editor, the team poured energy into planning how they were going to pull it off. If they were going to overhaul such an important component of Evernote, they needed to ensure their approach set them up for future successes. Through research, discussion and critical thinking, the team began to chart a course of action.
Travis: As we began this project, we decided what features to implement and what new designs to move forward with based on a combination of usage data, surveys, user research, industry research and a dash of gut instinct built off years of experience in the arena.
We are fortunate enough to have our suggestions fairly heard, challenged and considered.”
Chris: It took many debates and experiments to agree about the path forward, but eventually we converged on an approach with a nearly complete rewrite of the editor with certain key changes in code and functionality. We are fortunate enough to have our suggestions fairly heard, challenged and considered. We tend to share “strong opinions, weakly held.” Since we’re very honest about our disagreements, we’re able to focus on the discussions that matter most. It makes our team decision-making stronger than our individual perspectives.
Let the building begin
After much planning and deliberation, the team had finally mapped out a path to the new editor. And that’s when the real work began. Projects like this one rely heavily on the unique knowledge and experience that each team member brings to the table. In this case, the engineers were encouraged to contribute to areas they were particularly skilled and interested in. With a combination of collaboration, discussion and creative perspectives, a new editor slowly began to take form.
Chris: We are constantly trying, debating and evolving the tools we use. For me, programming is a means to the end of creating a great user experience. That’s how I prefer to work. For example, we once had some menus and pop-ups for a feature that we were supposed to implement in HTML/CSS/JS since that was the best option we had at the time. I wasn’t satisfied with how the interaction felt on iOS and Android, so I suggested that we find a way to make those interactions use native components. We ended up having to define and implement several new API methods to make it work, but the end result was a more usable experience that everyone felt better about shipping.
For me, programming is a means to the end of creating a great user experience.”
Jesse: We often have eureka moments where I found myself on my feet, high-fiving everyone on the team. For example, we had a constant stream of drag-and-drop bugs being filed in the classic editor and we knew we wanted to lay a proper foundation in the new editor. We were able to set up a system that could accommodate nearly all of the complexity of drag-and-drop, and those systems can be reused for newer features down the road.
I tended to focus a lot on the foundations of the editor. We’ve had an accumulation of tech debt in the past due to how many corner cases and duplicated code we had to write. Many projects get to a point where modifying the codebase is like pulling teeth, but I’ve done all I can to make sure that doesn’t happen by simplifying various systems as we are building the new editor. Finding simpler ways to accomplish a task or removing extraneous processes in a system helps with clarity, performance and new features.
The future of the editor — and Evernote
After some long days and plenty of ups and downs, the new common editor is now in beta. While the infrastructure is built and the possibilities for future iterations are materializing, the engineers can begin turning their attention toward other goals and projects they’d like to introduce. 2019 has been a busy year of rebuilding, but the team isn’t planning to rest on their laurels.
Jesse: Because Evernote has historically been an app to store and archive any type of content that you can dream of, we’ve had a hard time balancing control with flexibility. This has caused us to hit plateaus with our feature sets. Now, I think we finally have the tools and the architecture in place to bust through plateaus and deliver a high-quality, feature-rich tool that still retains what users originally loved about Evernote.
It will be a phoenix year for Evernote, and the new editor will help introduce the first visible stirrings of new life.”
Travis: We’re putting out a platform that truly allows us to come forward over the next year with interesting and often highly-requested new features that just weren’t possible with our old architecture. And, we’re doing it in a way that teams all over the company can contribute to with their own features and improvements — all without compromising the integrity of the note data or the experience of editing and viewing the billions of notes our users have collected over the years.
Chris: Looking toward 2020, we’re counting on the new editor as a way to drive new functionality. We're spending a lot of time stabilizing the code for release, but we’re also putting a lot of effort into foundational tools that will enable us to adapt more quickly. It will be a phoenix year for Evernote, and the new editor will help introduce the first visible stirrings of new life.
