ClanHR: booting the frontend

ClanHR is a new product we’re building to take care of companies’ Human Resources.


Starting a new product gives the opportunity to try and do things differently.

The team started with a power-designer (Mari), a product owner (Bruna) and two developers (me and Marcos). The developers started 3 months later, and that enabled Bruna and Mari to properly prepare story specs and think on a prototype, or a MVP.

Calendar view, with conflict detection

UX before UI

We started using bootstrap and used its default style to build a beta. We skipped wireframes and these high fidelity prototypes allowed us to produce something very quickly. The focus was on usability and having something to show to potential customers.

We also started using marvel to test workflows and new features, allowing us to start showing them to potential clients early on and validate product fit.

Tech Stack

Frontends may have a problem that I like to call if-complexity. Example: if this do that, but if admin also show something, else if it’s Portuguese do something specific. Lots of ifs, basically. On our previous project we used Rails/MVC and felt that it didn’t help us to manage complexity. Starting a single page app, in Javascript and with MVC frameworks that do two-way-bindings we felt like the complexity could be substantial and that’s something we’d like to avoid.

Fortunately, React showed up. With react we can model components as functions of specific data. This makes our view components deterministic and easier to organize and reason about.

People directory

We set up the project and showed Mari around React. She’s a designer still learning Javascript. Now instead of just HTML and SASS she would need to work mainly on Javascript. I remember her being a bit lost on the first days. But by the end of the week she was already creating routes/pages, splitting pages in components, and loving it.

When the developers started on the frontend, we already had a showable version of the app. Buttons working, routes/pages working, everything split in components. We just had to start adding logic.

Mari starting before us and doing so much on the frontend really boosted our productivity. Using React really contributed to that.

I18N

We’re considering internationalization from the start. Based on our previous experience, we know that non-technical people will want to edit copy. So instead of relying on files with tokens, we are based on Phraseapp. We define tokens on the frontend, and later on someone creates translations for the tokens. This is working far better than we expected.

We’ll also follow this path on the app’s transaction emails. The app will just generate events and all the mailing logic will be managed by non-developers at Customer.io. This way they can take full ownership on the copy, format, and rules of the emails.

Staging environment

We had something to show, but we really needed so have it online to pass around. To simplify and make things faster, we didn’t worry about infrastructure at this point, and we just hosted the frontend on Github Pages.

We’re also using SemaphoreCI to test and deploy the project. On every pull request we test scripts generation/compilation, run the tests, and if everything is ok, we automatically deploy to the staging env. This makes our development cycle very agile.

Testing

We’re still experimenting with testing the single page app. Tests on the UI can be very slow and we’re trying to avoid that. Our aim is to have the services fully unit tested, and have the frontend run specific, critical end-to-end tests. We already have several tests for the most important transactions on the site, and they are turning out to be very useful.

We’re using Nightwatch for the end-to-end tests. One of our goals is to be able to run a periodic test suite against production, and we’re still thinking on how to do it.

First internal version

The developers started working 2 months ago. To that time frame, we must add more 3 months of conceptualising the product. At this moment we already have a user directory and simple holidays/absences management.

Follow our next steps at our medium page.

See also ClanHR: booting the services.