Propag8; Proof-of-concept
Towards better record-keeping.
At the beginning Propag8 was envisioned purely as a record-keeping solution. The traditional method of keeping records in a lab-book comes with a lot of drawbacks.
Initial database design showed that the data model is complex, with 15 entities some of which show a sub-type relationship. Because of the complex data model, ease of database interaction was a top priority when choosing Elixir Phoenix as the technology stack.
The Proof-of-concept formed the basis of early user conversation, which pointed to data robustness and privacy as key requirements for future iterations.
Iteration User Goals
How to effectively keep records
Alternative Solutions
Lab-book
Excel
Notes on Tubes
Iteration Requirements
Cross-platform
Data security
Early User Conversation
When I started talking to students and supervisors about line-generation each group had their own most common talking point. Students frequently report keeping line-generation records split over multiple locations, with most students keeping notes in Excel, on seed bags and the lab-book. On the other hand, most supervisors told me in frustration how they had struggled or had failed to piece together what stock corresponded to a certain line after a student had left.
Both points indicate that there are shortcomings record-keeping. Some supervisors demonstrated their system of record-keeping. These systems needed a lot of discipline to implement, required good picture of all the work required from the beginning and were tailored to specific protocols. For early to mid-level researchers it is often probelmatic to work out how to keep effective records.
When explaining that I was intending to write a line-generation app mid-level researchers were enthusiatic about the prospect of seeing the histroy of any line they were to generate. Most requested Propag8 to be accessible on the desktop and mobile. Many stressed the importance of data security, mentioning the risk of their research being "scooped" if the Propag8 was to be hacked.
Initial Database and UI Design
From working in plant research for several years I had a good idea about what the data model would be required. After drawing an entity relationship diagram I realized how complex the data model was. The initial database design had 15 entities, with 16 relations and five subtypes.
For the proof-of-concept (POC) I created a simple CRUD interface for most entities. I added a cart with a multistep forms for some groups of entities (aggregate roots).
Choice of technology stack
Early on I decided that Propag8 would be a web-app rather then a native app. The main reason was the cross-platform requirement, but the complexity of the datamodel also played into this decision.
Form the inital data model exploration it was clear that an SQL database was a good match. I found the Elixir database wrapper Ecto was declarative, with similar syntax to SQL and would make interacting with the complex datamodel easier.
Further I chose to add Bootstrap to Phoenix (the de-factor Elixir web framework) to keep UI development simple.
The Result
Elixir Phoenix allowed me to build the POC quickly. I appreciated the "no magic" philosophy of Phoenix and could envisage adapting patterns like the user authentication for other purposes.
There was no pre-build cart functionality in Phoenix so I used OTP Genservers to implement them. In later iterations I replaced all carts with other patterns, however the state was still kept in Genservers (another time "no magic" was beneficial).
Ecto made writing complex queries and commands easy. By dropping back to raw SQL I was able to implement subtype relations and interacting with them from Ecto was straight forward.
Most importantly the POC allowed me to explore how to address the security concerns many target users had mentioned. At this point it was technically the biggest unknown whether I could implement something to fulfill this requirement. Using Elixir with the Erlang 'crypto' libaray it was straight forward to implement a user-specific encrytion algorithm, akin to the zero-access encryption used by Proton Mail.