Ron Rademaker
25.04.2019

Sources, sources and even more sources

story_verbonden

Kiezen in de ggz

In late February 2017, we launched the project Kiezen in de ggz. We went online a few weeks ago. Options in mental health care (‘Kiezen in de ggz’) is a website that helps patients, their friends and family and doctors choose between mental healthcare providers. We started with a design sprint and then developed the website in 13 development sprints of two weeks. A simple calculation suggests that we should have been ready 26 weeks later. However, reality is never that simple and fortunately we took account of this from the beginning.

We implemented the project in a number of blocks: 4 sprints in 2017, 4 sprints in the summer of 2018 and 3 sprints in late September / October 2018. There was time between the sprints to collect and process user feedback. This feedback was then included in the following series of sprints with the aim of improving the website. Involving future users during development helped us to create a website that is better coordinated to the needs of those users. User tests are a valuable instrument during development, particularly in the phase before the launch of the product when you cannot yet receive feedback from actual users.

From a technical perspective, the website can be described with one word: sources. ‘Kiezen in de ggz’ retrieves information from a large number of different sources, combines the information and makes accessing it easy and fast for the user.
We use a source for data on institutions, branches and practitioners; a source with additional information on practitioners; a source with information on insurances; a source with client experiences; a source with information on conditions and a source with the quality charter. The relevant information from all these sources is collected, rendered searchable and presented in a user-friendly fashion.

Speed was given high priority

From the first development sprint, we as a development team prioritised the speed of the website. After all, with so much information from so many sources hosted on what will probably be a much-visited website, you run the risk of the speed of search results leaving something to be desired. Consequently, we made a number of technical choices. For example, we are not using a traditional content management system (for the text pages of the website) that is incorporated in the website. We view content as a source, just like all the other sources. As a result, the content is completely separate from the website and the CMS does not need to be activated for every single request.

A further choice we made is to divide the website into separate front-end and back-end applications. We are applying this architecture increasingly frequently in our projects. The advantage, from a performance point of view, is that a large part of the application is loaded in one go, after which only specific required information is retrieved. A traditionally designed web application often retrieves the same information again with every click the user presses (for example, take a menu structure). It takes this traditional website time to compile this identical information and send it to the user.

The front-end application used by ‘Kiezen in de ggz’ communicates via an API with the back-end. As a user, you don’t notice any of this except that the website responds faster when you click. In the case of ‘Kiezen in de ggz’, however, we don’t have one back-end application, but two: a back-end application from which data can be read from the database and a specific back-end application dedicated to super-fast searching. By separating these functionalities from one another, we have been able to optimise the search function. This means we can start searches immediately without delay from a back-end framework that needs to be started up.

More blogs

Sluiten