Development has come a long way – there was a time when we built applications and their associated components from scratch. We spent a lot of time building everything from the ground up.
Today, applications are a complex network of third-party components and APIs that all work together to build a coherent system. Rather than making a payments system from the ground up, developers insert a few lines of code from Stripe or Braintree to accept payments. Instead of writing your own charting library, you `npm` the right package.
This change has allowed us to focus.
As web application developers, we are now in an age where we can focus on developing the bits that we’re most excited about and are most unique to our project. We no longer have to worry about independent inputs and user interactions; and with most solutions already existing somewhere out on the web, we don’t need to be an expert in every piece of software to bring our products to market.
If I have seen further it is by standing on the shoulders of Giants.
A developer’s time is now spent creating a solution to their specific problem, rather than reinventing the wheel. An app starts on a whiteboard rather than an IDE, and the modern developer expects many of the ways users interact with the web to work without any issues. When things start to break, the developer ecosystem and end users start freaking out until it’s fixed.
This is a double-edged sword, especially when it comes to rich text editors. Rich text editors seem deceptively simple to create, but with the burden on each developer to create a state-of-the-art editor, the risk of creating and maintaining a suboptimal component becomes higher, especially when they may not be an expert in the area.
Any broken piece of the experience can have dramatic implications for end users. That includes rich text, our core focus, where any slip-up can damage the experience of millions of user interactions every day.
Here at Tiny, our challenge may even be a greater one, as Microsoft, Google, and other companies have trained users since they were children to expect word processors to work perfectly with very few bugs or errors. When you edit tables or lists, you expect things to work in a certain way. You expect the text cursor to keep moving to the right or left, and to be able to click around to move that cursor. You hope that when you hit the bullet button, you’ll get a bullet point, and when you hit it again, that bullet point goes away. And when you hit enter, you expect to move down the line.
Users expect more today. As we think about how we create the best rich text editor, we have to figure out what users want before they even know what they want themselves. Our development includes integrating more complex ways of presenting ideas, like a way to easily portray equations or add special characters.
We’ve had to rethink the user interface through all of this because, essentially, users expectations continue to go up. It isn’t good enough to just replicate word processors - we’ve also had to innovate on ways to make the experience even better for a browser-based and embedded use case, and change the game when it comes to integrating within our favourite apps and frameworks.
Businesses, too, are adopting this approach of focusing on the problems specific to them, rather than trying to build everything from scratch. Sure, a hospital system could create a new electronic medical records network, but they have to keep up with constantly changing technologies – and not having to worry about a text editor dramatically reduces the burden on developers in that system. If a developer had to work on this on their own, it would take years to build a capable text editor that matches the level of Microsoft Word, which has decades of refinement and experimentation behind it.
As technology continues to advance, faster than ever, now is the right time to think about what we're best at, and how we’re going to leverage the expertise of others to hold us higher than we can hold ourselves on our own.