From the beginning, we at HelloSign have been 100% optimized for a desktop signing experience. As we’ve rocketed in usage and popularity, it became more and more imperative that the signing experience be mobile optimized as well. A new HelloSign user experience version called UX Version 2 was brought to market in 2015. While users on hellosign.com were able to enjoy the mobile-optimized signing flow immediately after the release, we gave API customers the ability to opt into this new experience by using a ‘uxVersion’ flag.
And now the time has come. After over 2 years of supporting both UX versions, we will be sunsetting UX Version 1 as of July 19, 2017. UX version 2 is the experience that we will continue to make product investments in as part of the Hellosign roadmap. UX version 2 supports features such as white labeling, decline to sign, signer reassignment and a mobile experience in a clean, elegant interaction.
Most of our customers will be unaffected by this update, but the select customers who implemented the HelloSign API before November of 2014 may be affected. The best way to ensure that you and your users will not be affected by the sunset is to ensure that your app utilizes our latest version of the hellosign-embedded.js client library.
There are three ways to incorporate the library:
Linking to the latest version in a script tag
Adding a specific version as an NPM dependency and including in your front-end build process
Building from the source repository
For more detail please read the “Getting Started” section of the github repo.
TL;DR:Elixir, Phoenix, React, and Redux are mature and productive technologies for building incredibly fast, massively concurrent, reliable, real-time web applications. Nothing else comes close.
In Engineering Terms, Where We Are and Where We Want To Go
HelloSign been able to build a successful business based on a simple set of technologies: PHP, Symfony, and jQuery. To this day, these technologies serve as core parts of our stack and work quite well. We do not see us ever completely removing these parts of our codebase.
Yet we’ve had some issues in terms of maintainability, performance, and productivity, especially with jQuery. Maintaining complicated imperative jQuery code can be something of a nightmare. Plus there were parts of our architecture that were not giving us the performance our customers needed. This led us to a search for some long-term solutions to these tricky problems.
Ultimately, we embraced a few approaches to our problems as we started to scale.
For greenfield projects, we settled on a new tech stack consisting of Elixir, Phoenix, React, and Redux. But the tech stack is really an outcome of a shift in philosophy at HelloSign toward functional programming and immutability, and event driven architectures. This new approach allowed us to build a massively concurrent, fault-tolerant, real-time application at scale.
In October, I gave a talk at API World called “10 Mistakes to Avoid When Building an API,” which was a compilation of mistakes and missteps the HelloSign engineering team made while building our API. It was a hit!
But wait, why would we want to share mistakes?
Our engineering team has embraced the company values of “Transparency” and “Constant Improvement.” We regularly hold post-mortems to brainstorm ways to fix, improve, learn, and grow. This talk was actually a result of many post-mortems that were boiled down to a handy list of not-so-obvious lessons that others might be able to benefit from.
Below are the mistakes and lessons covered in the talk at API World:
I’m a senior part of HelloSign’s API support team, so I see a lot of different API use cases. Each new customer brings a unique set of variables to the table. But despite the differences per customer case, there a few core questions that unfailingly come up. These questions need to be answered before we can get the ball rolling.
We thought it would be helpful to add a top-level overview of some of the core components of our API with some of the basic questions that need to be asked as you plan your integration.
If you’re a developer, you likely spot (and ignore) irksome bits in your code or product regularly. Perhaps it’s an excessively long if-block or a border offset by 1 pixel too many. Maybe you manually run through 5 steps every week to get your test database just right.
We let these annoyances slide because we might not have time to fix them. We also understand that what seems small isn’t always a quick nip-tuck fix.
Last year, the HelloSign engineering team started holding a quarterly Bug Squash to clean up these exact types of issues. Like the name implies, it’s a two-day event to fix small bugs but we also use the time to make workflow enhancements, perform housekeeping, create developer tooling, fix broken windows, and tinker with small projects.
It’s had a positive effect on team morale and satisfaction, and resulted in improved product quality and provided useful improvements to the team and our users.