A smoother user experience with new technology

The Aava Medical Centre is one of our customers with very high expectations concerning user experience. In order for us to meet these expectations in a cost effective way, it’s important for us to utilize the most modern tools when building their services. Luckily for us, for the whole duration of our cooperation, Aava has committed itself to adopting new technology. This way Aava has also avoided excessive expenses during updates.

At the end of 2016 we set a goal with Aava. We decided to combine the frontend solutions for Aava’s different services, all of which have been created using different backend systems. At present, all of the systems have their own user interfaces, which has led to maintenance being cumbersome and non-scalable after the systems have expanded. Despite the fact that we have utilized modern tools building the current systems, the work always has to start from scratch for each system. The development of the user experience is also hindered, since the systems look very different from each other.

We began with building Aava’s “Terveytesi” (Your health) service. The goal of the project was to quickly create a new service from which customers would be able to easily find information on their health, for example diagnoses and appointment reservations.

Why did we end up using React?

Building the service required changes on the architecture already in place. For the development to be cost effective in the long run, we decided that all of the functionality available before the architecture overhaul would also have to be available after the overhaul. Because of this, we ended up focusing most of our effort on forming functional interfaces. For this project it was only natural to create a browser application, since the service would not require a lot of business logic outside of the interfaces.
 

Ember.js and React.js were both picked for consideration, since the team members had had positive experiences with them previously. Initially we tried to estimate which of the two systems would be easier to adopt into the current architecture, but we had to accept the fact that the comparison would be difficult, since neither seemed to fulfill the requirements we set at the start of the project. We therefore ended up comparing their community support and they way each of the systems had been implemented. In the end, we chose React, since we believed it would have more support in the long run.

How did the project run?

Adopting new technology always creates challenges. On this project, the most prominent challenge was how modern technology would merge with the infrastructure and programs Aava already had in place, even though the whole in itself had already been modern, per se. Also, not all of the team members had previous experience with modern JavaScript (es2016+). But we’re all for challenges, so during the project we made sure that each team member would have the same level of readiness to take part in the development of the project.

The infrastructure in place for Aava has been kept up to date for the whole length of our cooperation, but despite that, at first the development seemed to advance slowly, because we had to concentrate largely on developing the previous architecture; groundwork takes time. The main reason for this was that Aava did not have similar JavaScript implementations in use. When we completed the first components, we begun to pick up the pace, and new functionality started cropping up very rapidly.

Because we wanted to expedite the start of the project, we took a lot of our cues from boilerplate solutions. This proved to be a mistake at a later stage, when we had to sort through bugs found in the copied parts. The sorting was a challenge since we weren’t completely up to speed with all the choices and weaknesses in the code.

In the end, the project took about two months, approximately half of which was used to developing the previous infrastructure. We have now released the application for internal testing and it is soon going to be released for public.

Technical choices

Since PHP 5.6, which is still in wide use, is starting to fall short of Aava’s high standards, we decided at this point to update the service to PHP version 7.1, so that we could benefit from the increase in speed and amount of features. Many PHP libraries have already ceased to support PHP 5 versions, which complicates developing new things on top of PHP 5 versions. Aava was our first client to adopt PHP 7.1 into an existing project. This raised a lot of interest also outside of Druid.

For the moment we are using Drupal 7 as a backend system for the application. The API we’ve designed works so that the frontend application will be easy to move onto any platform. This way Aava’s technical choices will not be restricted by the technical choices we’ve made. We came to this decision because there was a substantial amount of functions already built for Drupal, which would speed up the development of the software.

We used the Swagger tool for the API documentation. Swagger documentation has been compiled from JSON data. The same file was also used to generate the interfaces.

Summary

As a whole, the project proved to be very interesting. Particularly the constant utilization of new technology keeps the mind sharp and the team motivated. It also ensures good mileage for our customers’ systems, and as low a cost as possible during the development phase.