Here’s the story of how we took the Creatubbles kids’ creative platform app, and breathed fresh life into it - with an Ember.js Single Page Application frontend, for awesome User Experience and a fast and responsive interface. Shout out to working with an excellent global software development team on this project!
Building a safe global community for creators and artists of all ages
A cool online artist-space for kids? Whether it’s poems or paintings, music or craft, Creatubbles is the online global community for creators and artists of all ages - with a bent on a fun, safe space for kids to share and interact creatively.
The platform allows children, families and teachers to showcase, share, discover and interact with creative analog and multimedia creations online. Users are able to share their making in more than 50 countries - whether they’re at home, school, or attending an interesting event - with a desktop and mobile app.
iRonin & Creatubbles
We came on board with Creatubbles in 2015, tasked to re-write the platform’s existing front-end interface from Ruby on Rails server-side rendered views to a client-side (in browser) rendered app.
The iRonin developers were part of a remote team of 20 talented people from different parts of the globe – our team was located in Poland, while other teams were in Belgium, Germany, Philippines and Japan.
The initial code we were provided with was a pretty standard Ruby on Rails approach, where views were rendered on the server with jQuery on top. While this allows for rapid web application development (that’s where Ruby on Rails shines!), it started to become more and more difficult to maintain and extend. Difficult to trace errors also started to creep in.
As such, the Creatubbles app was becoming more complex. Compared to Single Page Applications, it simply wasn’t as performant, and didn’t have as good a user experience either.
The goal was to make the app fast and responsive, with beautiful User Interface transitions providing excellent User Experience.
Our team’s goal was to enable all of this and to support different use cases, like:
- User sign up and sign in
- Account management
- Preview of creations (videos and images)
- Upload of new creations
- Update of existing creations
- Interaction with website’s content by adding a comment, reporting inappropriate content, all without leaving the main app flow
And, last but not least, the content had to be SEO enabled.
A Single Page Application with Ember.js FTW!
Back in 2015, after making an initial assessment of the front-end frameworks available, together with the client, we decided to go with Ember.js - which calls itself "A framework for creating ambitious web applications.".
At the time, Angular 2 was in the alpha stage, and it was incompatible with the existing application and libraries (any upgrade path wasn’t viable) - and we were not fans of Angular 1.x. React.js’s ecosystem wasn’t as rich and popular as is is today (plus its license has to be considered for any serious project), while Ember had batteries included from the go.
Ember is an open-source JavaScript MVC web framework. The framework is geared towards being able to build large, interactive apps and comes with an extremely handy dev toolkit.
This, we decided, was a perfect choice to build scalable single-page web applications, like what we wanted to achieve with Creatubbles.
The nuts and bolts
The Ember front-end application was written in CoffeeScript - which "is a little language that compiles into JavaScript". CoffeeScript was a very popular choice amongst Ruby on Rails developers before ES6 or TypeScript took over the scene.
Initially we chose to go with Emblem as a templating language. However, it caused us some problems as we went along. We soon found Handlebars to be the better alternative. While Emblem was nicer to work with (and compiles to Handlebars), it was always lagging behind in terms of features, and extended functionality that would help us on the project. In the end it’s usually better to stick to the built-in language of the framework!
Mobile devices support
Creatubbles’ Ember web application had to be usable and performant on mobile devices - after all, kids, parents, and teachers were wanting to be able to show off their work anywhere at any time!
In order to achieve this, we created a custom Ember service for checking the client type (mobile or web) and its type (smartphone or tablet). Once we detected the client type, the frontend was able to serve different views and styles, truncate long texts, use different components (e.g. change a dropdown component to a toggle), and simplify animations to ensure the performance and user experience on a mobile device was excellent.
Multi language support and working with Japanese language
Initially, the platform had to support 3 languages: English, Japanese and Italian, with ability to use the OneSky translation service for an easy update of existing translations, and the ability to introduce new languages at a later stage.
To achieve this, we developed custom scripts which allowed all texts from the Ember web app, the API (eg. error messages), and the mobile app to be translated and placed into a single JSON file. We also used a dedicated Ember library which can translate texts as whole sentences, with support for different plural and singular forms, eg.:
Ember.I18n._n("There is {{ count }} apple", "There are {{ count }} apples", { count: 42 });This was very important, as nouns in Japanese are the same in singular and plural form!
A well-designed Ruby on Rails REST API for future development
The initial application that we received was accompanied by a REST API built on top of the existing Ruby on Rails back-end. The API was not only used by the web app, but also by native mobile apps and Creatubbles partners' applications and integrations.
This approach simplifies the development because there is only single code base to maintain. It’s always better to have a well designed API built before the clients are written. Any change to the API may affect the clients, and versioning the API may be required - which in turn requires maintaining API code branches for clients using older API versions! We already had a solid API, which avoided these complications, so it was important to use it.
Writing a new Ember.js front-end with the existing REST API
Since the API had already been created for mobile clients and integrations, we had to use exiting endpoints for our Ember Single Page Application. Because of this, Ember's default strategy for managing our model’s endpoints had to be modified.
Defining a common URL template for resources (single URL for CRUD operations - Create, Read, Update and Delete) was insufficient, since some of the actions (i.e. Read and Update) required different a URL than the others. We decided to use the ember-data-url-templates add-on, which allowed us to create different templates for different actions.
Only necessary configuration details and data were loaded during the initial page render. All extra details were loaded lazy-loaded (on demand) when they were needed (i.e. opening a detail view for an object from a list). This allowed us to reduce the number of requests to the API, improve the page load speed, increase perceived performance and enhance overall User Experience!
What was in iRonin’s project toolbox?
You always need to have a solid toolbox for any project you embark on - especially if you’re working with a remote team.
The main tools we used on a daily basis were:
- GitHub as our Git code repository and for code review
- CircleCI for Continuous Integration and offloading test suite runs
- Heroku for hosting
- Amazon Web Services mostly for file storage
- Slack for daily communication and standups
- ScreenHero for remote pair-programming sessions (ScreenHero is now a part of Slack)
The separation of frontend and backend code
Nowadays, we promote developing Single Page Applications separately from the back-end application - they live in their own code repositories and can be deployed separately from the server app - thus optimizing all the development, deployment and content delivery processes. However with Creatubbles, because of how the existing app’s code had been set up, we had to follow a more monolithic approach. Consequently, the Ember front-end would live together with the Ruby on Rails backend in single Git code repository.
We used the ember-cli-rails gem for managing the front-end part of the app. This allowed developers to setup the whole stack easily and quickly run the whole platform locally. However, this setup slows down the build process, especially during the initial build. The subsequent builds were faster, but it still wasn’t ideal. We were able to improve the build speed by turning `config.cache_classes` on (for developers who worked only on the front-end part).
Since the codebase has grown so much since the initial launch, our recommendation for future work would be splitting the app into 2 separate frontend and backend parts.
Better for kids, better for the client!
Working on the Creatubbles project was an absolute pleasure for the iRonin team. We really enjoyed the chance to help out with this unique and interesting platform for kids to share creatively.
Embracing Ember and its strengths to provide great UX not only gave us a great sense of accomplishment, but made the client very happy too! We had the opportunity to introduce design patterns and good coding practices to the code, which makes it a solid base for future development as the platform grows.
Working with the team globally, especially in Japan, proved a fun challenge and made us even more confident in the benefits of global concurrent collaboration.
If you’re looking to move your web app to a Single Page Application, need help with frontend or backend development or redesign, or looking to scale a project, then make sure to consider iRonin for your project. Whether you’re in Bangkok, Berlin, or Boston, we can help with your development or DevOps solutions.
