ACCS Web and ACCS App | Garry Yeatman

Asbestos Contamination Collection System

About the project's roots

To start my time at ENGEO I was tasked with helping the company build an asbestos surveying solution to provide the team with a more customised and refined solution to help them conduct asbestos surveys on site.

I was quite fresh out of my first development job and I was the only developer on the team initially. I had only worked with Wordpress and Silverstripe and I was quite wondering how those two frameworks were going to fit the needs of this system. I decided they didn't.

I ended up settling on Laravel to help me build this application. I had zero experience with Laravel or building web applications so I knew I had a steep hill of learning ahead of me.

I jumped into Linkedin Learning (then Lynda) to try and get ahead of some Laravel tutorials. I felt after a week I had enough of a grasp of the framework to make a start.

Three weeks had passed and I had a basic form set up with enough functionality to get the team started with using this new web app.

We had a pretty big contract looming over our heads and the team really wanted to use this web app, The particular site had around 100 surveys to complete.

This project was in a very agile stage. We managed to get a working iteration ready to start these surveys.

The web app functionality

The first iteration of the app

A four stage form to ask questions for the survey
JS to pre populate answers based on which type of asbestos is selected
The ability to link one sample to a historic sample (as they will have the same answers to the form
The ability to provide a sample code to match samples collected
The ability to write comments for samples and edit items in the report
the ability to draw on a preloaded floor plan where you took the survey from
Ability to approve reports by a supervisor
Ability to generate an asbestos survey report pdf based on the results (This was done by wkhtmltopdf)
- Cover photo is generated by a cover image of the survey.

The second iteration of the app

After meeting the initial requirements for the big project, there was a lot of feedback received for the app. The biggest feedback were around the layout and usability but also a few bugs that were in the system.

After this feedback I decided to create new ways to view the surveys, you could order them by location (Auckland, Wellington, Christchurch), by the surveys assigned to the user or all of the surveys.

I also tried to simplify the flow of the survey, there were four steps.

Click on the survey you need to complete, or create the survey you need to complete.
Set up the layout of the site. EG set up the levels, floors and rooms (to help identify where samples are taken from), you can also load in the floor plans for the floors.
Collect samples, when you create a new sample you
1. draw it on the floor plan
2. label it and select if you are presuming asbestos or are collecting a sample
3. Answer questions based on if it is a new sample or an assumed asbestos
4. complete the flow and return to the floor plan
Once you have collected all your samples and completed your survey you then send it to the 'waiting on results' stage. This is the stage where a survey sits while the samples await results from the lab.
Once the results are back, a surveyor can enter them into the system and then submit the survey for approval.
A supervisor can then sign in to the system and review a report. They can send it back with comments or approve the report. If the report is approved the surveyor will be alerted to complete the process.

To reduce the load on the survey I decided to add in a form of pdf caching to the system. This reduced server load by a lot as the system by this point was in full use. If a pdf was present in the file system the user would download that file. The user also had the option to request a redraw of the file if they'd made changes and needed that to be reflected.

I wrote a bash script that took database snapshots to help retain backups of the database after I'd accidentally deleted the production database instead of UAT (I think everyone has done this once!). I'd taken a backup that morning so not many surveys were lost.

We wanted to sell this solution to external companies to use. The way the application was built it was only for internal purposes. I needed to refactor the system to allow the separation of clients. I needed to make sure no sensitive data was exposed in this process.

I also needed to create a process where my manager was able to create these accounts on the fly, Giving users the ability to manage their own surveys, access for their own members etc. It was quite a big refactor in the end. The system was built when I was a young laravel developer so I had to bust through a lot of technical debt.

Xamarin

While the web app met most of the needs of our surveyors there were a few problems we needed to solve.

One was that we needed to be able to allow our surveyors to work in locations out of service, and the other is that the surveyors weren't too happy using their personal data plans to conduct the surveys. This would likely also be true for any external users who wanted to use this system.

We decided we were going to build an android app first and then when we could, one for iOS. After some research I stumbled across Xamarin and was intrigued.

I was in a similar position to when I started this project. I had no idea how to develop in Xamarin, I had not programmed with C# in a production setting and the only application I have ever developed was during my studies where we added an android front end to a Java application back end.

My thirst for knowledge kicked in and I once again spent a week on Linkedin Learning getting my head around Xamarin. Luckilly I found C# is a very close language to Java so I did not have many issues there.

After around two months I had a working system ready to test. The reception to the app overall was pretty good. A key difference to the app over the web app was that users could not draw their own floor plan for their surveys (This was a custom solution I developed myself).

Users were able to complete the surveys on their respective devices and then upload them to the web app via a rest api I'd developed. This worked quite well overall but unfortunately I left ENGEO before the app was more widely used.

I really enjoyed using Xamarin as a system because it reduced a lot of code overheads, allowed for custom functionality based on the operating system (Eg I could have developed force touch for iOS) without too much hassle.