Ginkgo.Your Innovation Partner.
This is a follow up to the previous post about the visual JSON Schema form building tool that I built with ReactJS this summer for my internship project. Now that some time has progressed, the form builder has improved through additional features and polish, and its role within Ginkgo’s larger software suite has become more clearly defined. Because I get to stay on for a few more months (thanks to a virtual college semester and a flexible team!), we’ve been able to plan out more ambitious features for the form builder, with the goal of eventually open sourcing the tool. In addition, we’ve been integrating it into the Servicely SDK, a tool we’re also building which will enable our scientists to manage and write code for laboratory operations and build them into scaled-up "services" in our foundry.
The most visually apparent change to the form builder has been a UI overhaul. Alongside our team’s UI/UX lead, Darek, I participated in conducting user research, where we create a review version of the tool, come up with a set of example tasks, and ask users to perform those with minimal guidance. So many aspects that I took for granted as the creator of the tool quickly became apparent as people with fresh perspectives attempted to use it. A couple of key considerations involved usability on smaller screens, consistency with Ginkgo’s software design paradigms, and enabling a greater diversity of user interactions. While the previous form builder employed side by side editing of a form with a rendered preview adjacent to it, we soon realized that the multitude of scrollbars and fixed widths became a major issue for actual service developers that may have the form builder in a smaller tab while editing their python code alongside it. As for general visual polish, some of the interesting tasks involved introducing tooltips over every interact-able item and better, consistent visual signaling for the buttons. There were also other initially unintuitive, but later surprisingly efficient additions, such as incorporating “add element” buttons throughout the form, drop-downs to reduce component size, and a popup that depicts the form’s output on submission.
Beyond a makeover, though, the form builder has also incorporated some of JSON schema’s more complex features: dependencies and references. One common example of dependencies comes up in filling addresses in many different kinds of forms; filling out a country name like “United States” may cause another input box for “State” to render, but filling in “Canada” may instead require that the user fills in their “Province.” In the biological realm, however, we might ask for some procedure details for one strain of yeast, but perhaps an entirely different set for another. This was a major step for full compatibility with JSON schemas already in use, as conditional rendering had already been deeply interwoven within services coded manually by the software team, and there seemed to be resounding interest from prospective foundry Service Developers to easily create forms with complex logic as well. References were also important for compatibility, as they were a nice tool for people coding JSON Schema Forms manually to define components once and reuse them, so as to reduce the amount of repeated code.
The solution to implementing both of these features involved some heavy refactoring that ultimately boiled down to parsing the structure of the JSON passed into and written out by the form builder into a data structure that involved an array of abstract “Elements.” Whereas before, there was a one-to-one relationship between the children of the JSON object passed into the form builder and their respective components, the form builder now used the JSON code both as a blueprint to draw elements from, as well as a sink to write the arrangement of these elements into. This was an interesting puzzle that presented an elegant example of how adopting a new kind of data structure can open up entirely new use cases for a tool.
While there is still some work for the form builder ahead, with a few tweaks and eventually open sourcing the tool, my work has expanded beyond the confines of my intern project. As the leaves brown, various pumpkin scents fill the air, and we bid adieu to summer, so do I now get to set my gaze towards the greater Servicely SDK containing the form builder, along with other great work from the Impressionists Scrum Team. Discussed in more detail in the previous post, the vision of the Servicely SDK is to shift the capabilities of creating and managing “services,” which roughly correspond to laboratory procedures like transformations or screens, to scientists. While the SDK will introduce a lot of sophisticated features (like serverless operations, shared community codebases, and more visual tools to build out workflows, just to whet your appetite), the ultimate takeaway that I think is most exciting is simply enabling scientists to focus on coding the science, and not much else!
This summer (and hopefully through this fall!), I’ve had a great chance to talk with people from a wide variety of backgrounds taking on synthetic biology, which has helped me in learning how there are many ways to approach the field, and that each path can contribute in interesting and novel ways. One of the trends I noticed was that with all of the data being produced in places like Ginkgo, we’ll soon be able to solve problems that we couldn’t have even thought of before by learning, human or otherwise, from the past. Tools like the Servicely help make sure that this data, one of the distinguishing factors, in my opinion, of a place like this doing biology on a large scale, is handled and stored in ways that are meaningful for future use. The SDK, meanwhile, empowers and makes space for a wider range of antedisciplinary scientists. As someone still navigating this hazy path, with ill-defined boundaries and shifting skill sets, I am grateful for the opportunity I had to work on this project over the summer, and am looking forward to seeing what else I accomplish these next few months!
With a lot of guidance from Ray, another software engineer on the Impressionists team, we were able to construct a fairly robust CI/CD routine for this tool, with an automatically updated demo of the tool hosted on GitHub Pages, Travis CI integration to run tests and do Flow type testing, and automatic updates to the documentation through a Read the Docs webhook. The library definition for the tool is also available as a flow-typed libdef, so anyone using Flow in their developer environments can take advantage of our Flow types in the form builder if they want to incorporate it, too!
Learning how to properly open source a project was quite an endeavor, with so many options for hosting, documenting, and other key components. Indeed, this development pipeline could have been configured entirely differently, using, say, GitHub Actions instead of Travis, or a different documentation suite entirely. Regardless, it was a great learning experience to see how a development pipeline gets crafted from scratch, and how much it can vary, after working with Ginkgo’s own internal pipeline (and it made me appreciate Ginkgo’s platform even more!).
All together, we hope these integrations will make it easier for people to pick up the tool, propose their own changes, and make the form builder better with time. The ability to visually edit forms with a high degree of customization is relevant to almost every industry, and I think that this tool could be a useful widget for many.
(Feature photo by Eco Warrior Princess on Unsplash)
Posted by Nathan Alam
