We have a new EmberJS front-end!
Around May 2015, we decided to redesign our product management dashboard (i.e. the web interface in which you can manage your enterprise app store). We didn’t think it would be easy and quick (…actually we did 😂), but we didn’t know it would be this hard and long. Now that we are almost done, and very proud with what we have achieved, we would like to share our experience.
Technical stuff put aside you need to start with the why. Why change? We could have spent hours in meetings and customer interviews but let’s be honest, a screenshot of Appaloosa’s admin interface speaks for a thousand words.
Now that the “why” is behind us, let’s talk about “how” we decided to do it.
The world loves frameworks
We naturally started looking at front-end frameworks, predicting the high learning curve as our skills were focused around anything besides JS.
Back in 2015, we already had a lot of options but we took a closer look at AngularJS, ReactJS and EmberJS.
While we did some research online, we also asked our community and other startups about opinion and advice. As we ruled out ReactJS because of its lack of mileage, we investigated AngularJS deeper but feedback we received was a mixed bag. At the time, the AngularJS developers we were talking to were trash-talking AngularJS as they were transitioning from v1 to v2 and had very negative feedback how the version change was breaking everything they had done before.
We settled for EmberJS for three reasons: an efficient community, LTS support and the existing bridges between Rails and Ember core teams.
Let’s start working
The team started working with caution on the project. After all, it was something new on top of the pile, in a language we weren’t familiar with.
Two developers started learning and prototyping every Friday afternoon, then we called an EmberJS expert as backup for tutoring. There were many unexpected obstacles. How to authenticate requests with our back-end? How to access and use resources or data? How to use our existing API?
We had more fails than wins and even experiments were hard to deliver. We weren’t at all using JSON API, lacked the knowledge, the help from the then dormant local community. We were stuck with no more than a nice UI template.
Months later, we received a much welcome boost with the hire of Benjamin, our EmberJS expert. We also embraced JSON API and Benjamin suffered the heavy task of converting everything to the JSON API spec. The back-end team also used rails gems outputting almost standard JSON for use with our project.
How did the project move forward with an expert with the right practices? Faster.
Still we had to rebuild everything from ground up. We have learned a lot and wanted to share our learning.
Where we got stuck:
- JSON API: we didn’t stick to the standards. We should have. We faced loads of issues with relational data which needed to be paginated. It wasn’t clear in the spec. If you need to pull data such as users then their related groups, then retrieve each data set individually, then assemble and paginate.
- Asynchronous: some of our admin dashboard features required to wait for other tasks to complete. For instance when an admin uploads a new app, our back-end triggers an asynchronous job which analyzes the app and retrieves its metadata for storage and display. This wasn’t included in the JSON API spec so we submitted this change which ended up merged into the official project.
- Large JSON files: our product integrates with some of Google’s APIs for app configuration on Managed Google Play. This integration returns a large JSON file for most queries (100 lines+ with a nesting straight out of hell). We had a hard time integrating with this third-party as we needed to retrieve, validate and maintain the payload.
What worked really well:
- short cycles between back- and front-end developers & design in a client/supplier kind of relationship. There was only one owner per topic.
- using Percy to quickly uncover visual diffs between each project’s page.
What we’re really proud of:
- Our team’s recommendations for asynchronous tasks have been accepted into JSON API specs.
- We created a very well designed page to manage app configurations in the Android Enterprise context, using Google’s APIs and before Google even released their UI.
A non-exhaustive list of what we have learned
- Whenever there’s a new frontend framework available, the hype climbs at the highest rate. Take your time to install, test with single page deploys. Ask the community whenever you are stuck and verify if you have timely answers. Also, look how often and how good it is maintained. One of the reasons why we chose EmberJS was because of its vibrant and responsive community.
Also, EmberJS wasn’t only just hype as it is trusted by large companies such as LinkedIn, Netflix and Intercom. - Migrating from something you have that works to something completely new take continuous time investment. Our migration was too often considered as a side project so it first moved slowly, like any side projects.
- If ever you had to scale on this new frontend tech, would you be able to scale the team with it? We went through quite a few hurdles when we wanted to hire experts on this brand new framework. Check if there’s enough candidates for you to hire.
- Record and play user sessions to check the new UI result against your assumptions. We always think we provide simpler but real users might think and act differently. FullStory enabled us to verify that we actually improved the user flow and not made it worse.
- When you think about front-end change, you might think you only need the shiny new framework, a fresh new layout and everything will deploy smoothly. While working on this “side project”, we quickly realized the work required on the back-end and the lack of resources available for it. While front-end devs can easily mock back-end APIs, they aren’t supposed to make up real ones. Someone real is needed there and you need to plan for it.
- Instead of releasing the new front-end to everybody, we used our feature-flipping system to activate it to selected customers. Those customers could fall into the following categories: admins using the interface everyday & intensively, fed-up with the existing front-end, new customers who wanted a glimpse about what comes next, existing customers who were curious and often made feedback.
- For a project this wide — replacing every feature on every page — your front-end developer needs to split every task thin and in advance in order to avoid backlog stuffing with heavy tasks…and a burnout.
- The designer must iterate on smaller portions of the app first, those with the least features.
- Speaking about design, nail the full design guidelines before development. Think in detail about all design components you might need at a later date. Things like buttons, spinners or modals.
- Find a tool such as Zeplin to make it easy for the designer to hand over its work to the developer — assets & code. If you can, make use of another tool such as Abstract to be able to show differences between versions and overall design evolution.
- Before all, iterate quickly with short feedback loops, directly with the end-user.
On top of giving birth to a much better product interface, we think we managed to make our B2B product simpler and probably much simpler for admins than other products in the space such as AirWatch or MobileIron. Anyway, try it and let us know what you think!
This article was written by Benjamin Jegard, Benoit Tigeot & Valerian Menard from Appaloosa’s dev team.
Want to be part of Appaloosa? Head to Welcome to the jungle.
