Case Story: NordSafety - Social Approach To Safety

In 2017 and also briefly in 2018, I had the pleasure to work with NordSafety. Two projects were successfully executed and, in this article, I will tell about a project called SafetyFeed. This was the smaller of the two projects but is easier to explain as the concept is familiar from social media services.

Photo credit: unsplash-logoAnt Rozetsky

Short introduction to EHSQ and NordSafety


To understand better what was built and why, it is important to explain what NordSafety does.

NordSafety brings EHSQ management to the mobile platform

EHS (or EHSQ) stands for Environment, Health, and Safety. It sounds pretty broad, so let's see how Wikipedia defines it:

Environment, health and safety (EHS) is a discipline and specialty that studies and implements practical aspects of environmental protection and safety at work. In simple terms it is what organizations must do to make sure that their activities do not cause harm to anyone.

As you can see from the definition, EHS is a very broad topic and covers almost all industries.

The idea of NordSafety is to have a modern take on capturing EHS-related issues. Once collected within the system, information about issues can be shared and activities to remedy ongoing risks can be tracked.

Safety-related issues can vary from a hole in the pavement to a chemical spill at a paper mill. Large construction companies can have hundreds or thousands of sites that they need to track. The term site refers to one physical location of different forms (a building, segment of a road, etc.).

NordSafety has several client applications, iOS and Android apps that are implemented using React Native and a web client. There is also a Portal that can be used to manage sites, user rights, reporting, etc.

The project we're now going through is part of the Portal and it was undertaken in collaboration with NordSafety's business and development teams and with the design team from Taiste.

SafetyFeed

The idea of SafetyFeed is to provide a specialized feed and commenting system to NordSafety's product. Think of Facebook's wall, but within the context of EHS (explained earlier). The feed can be filtered - for example, if you want to see events from a specific site or only certain type of events (new site created, a new incident reported, etc.). The common use-case is that a person who is responsible for a site, for example, the renewal of a road called Mannerheimintie, can track what kind of activities have happened at that particular site.

Most of the users are not tech-gurus, so the user-interface has been designed taking that into account, for example when thinking about terminology and user-interface controls.

My part in the project

I did all the front-end work and some of the backend APIs, especially regarding reading the data. A lot of work had been done to collect the interesting events that can occur in the system.

The backend implementation didn't contain anything special, just common-sense REST API design and performance optimization understanding from .NET and ASP.NET MVC standpoints.

The SafetyFeed on the front-end had much more work and was also more significant as it was the first project that defined the more modern front-end stack that was going to be used in other areas of the application. Of course we chose stable technologies, but close enough to the cutting-edge to attract people to continue the work.

The front-end is written in TypeScript (💖).

React was the UI library that was chosen, then Redux for the state management together with wonderful TypeScript FSA.

The SafetyFeed uses infinite scroll, which basically means that it automatically loads new updates when the user scrolls near the end of the current content. The front-end implementation uses react-virtualized to keep only currently visible content in the DOM, giving a huge performance boost. The back-end also responds very quickly, so the user can scroll without any lags in loading new content.

Each update type (internally called cards) could contain different data - for example, a URL to the image when person shares a photo or coordinates on an update that has a map - and therefore extra attention was given to how to build a model so that new update types could be added. I was happy with the way data was modeled without a complex inheritance.

I wrote unit tests and component snapshots using Jest.

Conclusion

NordSafety had listened to the users and understood the problem - that information on what was going on at a site or sites should be available with an easy-to-use view. The new feature was launched by putting the feature to the production and informing customers about the new feature via a blog post and newsletter.

Later we added a commenting system to the SafetyFeed, so that each update could have greater interaction between the person who made the update and with those who read it.

I haven't seen the current usage statistics, so I can just hope that many users have found the SafetyFeed useful.

To me, it is important that the client's own developers can continue adding features and fixing bugs when I am gone. Also, it is important that the chosen technology is not chosen just to satisfy my own curiosity towards the new shiny thing: instead it needs to be the right tool for the job and people can be found to continue the work. This isn't always the case when working with consultants, independents or a consulting company.

I was very happy to hear that new additions have been made by a developer who wasn't even working there when I was implementing those features and overall feedback from the code quality standpoint has been very positive. That always warms my heart.

Big thanks to the NordSafety team, and especially for my main contact, co-founder and CTO Jani Virtala, for the pleasant collaboration.