For the past few months we've been working on bringing Unsplash into Trello. Check out Trello's blog post announcing the launch if you missed it! It was a great experience because Unsplash is really cool and we knew our users would love it (I know WE do ❤️). It was also a great experience because we followed a simple and effective development process using Trello. What follows is my take on the integration work and process as a developer on Trello's Web Team.
Taco-fooding
See what I did there👆? Nice, right!? 😅
For those who don't know, we use Trello for everything. From project management to simply organizing ideas—we do it with Trello. Every day on the engineering team we have many cross-functional teams working on a number of projects.
We knew early-on that we wanted to give every Trellist (a Trello employee!) the opportunity to try out every team's features while they were under development; this is called dog-fooding. To achieve this we built the notion of channels into the Trello web client. A channel represents a different version of Trello, usually with some set of new features.
We have the Stable channel which is what you see in production on trello.com. We also have a staging channel known as Alpha which most Trello employees use. For specific features we can enable them too on their specific channels, called Heads. For instance, for the Unsplash integration we created a Head called unsplash.
Everyone on the team working on the integration used it as their primary Trello channel and we also had a number of Trellists outside the team who were excited about the integration using it too!
One board to rule them all
One key aspect of what we did, from my point of view, was to create a specification board named Unsplash Spec. The board was used to centralize everything related to the integration:
- a space to receive feedback from the whole Trello team
- ideas being researched
- technical details like the API keys
- scope and behavior
- mockups for web/iOS/Android
- bugs/feedback being worked on
- released Heads with changelogs
This helped keep all the information centralized, categorized, and easily accessible to everyone on the Trello team. As a developer, I deeply appreciate this organization because I don't have to waste time chasing someone to get some piece of information. I know that all the information on the board is not out of date. Although we had a HipChat room dedicated to this feature, we kept some conversations to the cards' comments to provide better context on the whys and hows of the project.
My weekly workflow comprised of having two quick feature meetings about the integration, a regular team meeting, iterating over specification and design changes, and going through the feedback list. The board helped keep the integration-specific tasks organized and easy to follow.
Remember when I talked about dog-fooding? We used the Unsplash Spec board to test the integration, so the background was constantly changing! 😄
The Unsplash team
The folks at Unsplash were awesome helping us deliver this. Not only did they love the idea, but they also helped us with all of the technical details. One thing that I greatly appreciated was that they made themselves available to everyone on the team; no one needed to go through any red tape to talk to an Unsplash expert. We also shared with them the unsplash Head so they could help us test it and give feedback.
The web implementation
The implementation was very simple. We built the background selector as a React component so React did most the heavy lifting when it came to the DOM node manipulation. unsplash-js managed all the communication with the Unsplash API. Using the wrapper, it's easy to fetch collections and do searches in Unsplash. We are already thinking about improvements on the UI to make use of more funcionality from Unsplash's API.
Infinite scroll
The biggest challenge we faced during implementation was making the infinite scroll for the list of background options. Luckily, the new IntersectionObserver API came in very handy. It's very simple to use and helps with the performance which can take a hit if you're using the scroll event. Browser support is not that great right now, as you can see on the image below, but there is a polyfill available in WICG from W3C.
You can find more broswer support information for the IntersectionObserver API here.
With IntersectionObserver all set, it was just a matter of inserting a zero-sized marker <div> at one point of the list and calling on the list to update itself when the marker became visible. Simple, right? Well… when you have to deal with cross-browser support, things get a little messy—especially if you are using flexbox to keep that search box on the top of the page:
Layout calculations differ from browser to browser and if you have display: flex element inside of a display: block element inside of a display: flex element and the widths and heights are all relative sizes things get messy. Of course, when things get messy the design looks weird and the polyfill stops working as it should. Fortunately, without hacks, we solved the issue by turning everything in the DOM element tree into display: flex elements.
Pre-launch
Before launching the feature to all users, we released it to 5% of the users and also gave special access to members of the Trello Community, which I encourage you to join! You'll be able to interact with us and get previews of what's to come 😉. This soft-launch helped us find and squash a few more bugs before officially launching the feature.
Launch day
It's been a wonderful experience developing this feature and I'm kind of sad it's over. All of the internal testing and community feedback paid off—the launch day went smoothly and reception was great!
Couldn't ask for a better way to finish this project. 😀