We are excited to announce that we have received supplemental funding that enables us to expand the functionality of the Network Canvas suite. The ‘Fresco’ project will bring Network Canvas Interviewer to a web browser.
The project team recently received funding for a 12 month targeted pilot that will deliver the full Network Canvas interview experience as a web application that can be deployed on your own server, or in the cloud. This will enable exciting new possibilities, such as remote self-administration, and the ability to conduct interviews where app installation is not possible (such as on participant devices).
Continuing our commitment to open-source software, the project will be developed openly and with community involvement under the GPL license, and will be free to use (although you will need to provide your own cloud hosting - more on this below).
The first phase of the project will modify the fundamental way the Interviewer app works to accommodate this new model. Once this is complete, we will share an alpha version of the app to gather user feedback and shape the direction of development.
We will regularly release updated versions of the app during the development cycle, culminating in a stable release in the fall of 2023.
In the sections below you can find more information about the project and its aims. We are very excited by the potential of this new direction, and we would like to thank the community for their continued support.
To deliver ‘Interviewer in the browser’ there are a number of fundamental changes that we need to make.
- User interface - Supporting self-administration, but maintaining existing strengths
- Data Storage - How (and where) will participant data be stored?
- Deployment - How can we make it simple for researchers to deploy a cloud app?
The current version of Interviewer is designed to be a co-production environment, where a trained researcher manages the interview experience. This key design decision enabled us to create extremely minimalist user-interfaces, which in turn allow the participant to focus entirely on the task at hand.
In the new model, we want to support self-administration while maintaining the strengths of our existing approach. To do this, we will modify the core interview UX to support enabling user ‘nudges’ and more detailed explanatory text. We will also support stricter interview navigation and stage-level validation, which will ensure data integrity.
Finally, we will implement participant onboarding ‘flows’, which guide a participant through the study recruitment process. This will include the ability to require a participant have a valid ID before being able to begin an interview, as well as dedicated views for agreements required by ethics committee/IRB.
One of the key principles of the existing Network Canvas suite is that the researcher is always unconditionally in control of their own data. We do not collect, store, or manage any data (interview, analytics or otherwise) when you use the software.
In the context of a cloud version of the interview app, this poses some logistical challenges. Where and how will interview data be stored? How will it be exported?
Our plan is to leverage the security features of ‘containerised’ apps in order to (1) separate out the application from the data storage container, (2) create a private tunnel between the application and the data storage that cannot be access from outside of the application, and (3) strongly encrypt data ‘at rest’ within the container with a key known only to the researcher.
Once securely stored within the application container, a strong user-based authentication system will allow the researcher to securely export the data in the same way as is currently possible.
Perhaps the most significant challenge we face in this project is to design a deployment system simple enough to use that it is viable for researchers who are not IT professionals, while also complying with institutional requirements for deploying cloud apps. We are also mindful of the need to to have the new platform integrate with our existing protocol management workflow.
A cornerstone of our solution is to use cloud-agnostic technologies, which will enable the app to run on personal, commercial, and institutional cloud infrastructure. In practice this means that as a researcher you will have complete control over where you deploy the app, letting you choose the appropriate weighting of cost, level of support, geographical proximity, and so on.
On the subject of cost, we are endeavoring to create a ‘one click’ deployment option that will be compatible with the free tier of one or more cloud providers. While we recognize that costs associated with software deployment create inequalities, we are also aware that many academic institutions are able to support the deployment of cloud apps with little or no direct cost to the researcher.
With the above in mind, we are proposing the following intended workflow for deployment:
- Create your interview protocol in Architect
- Deploy the fresco app container to the cloud provider or your choosing
- Log in to the app, configuring participant access settings, and uploading your protocol
- Collect data
- Export data from the container
When the Network Canvas project began in 2016, the web (and web applications) were very different. The web browser ‘platform’ was in fact a fractured mix of browser vendors (Microsoft, Google, Mozilla, Apple, etc.) all using their own proprietary rendering engines. This meant that even basic layouts would display differently (or not at all!) depending on the browser that was being used. Although techniques existed to normalise the majority of these inconsistencies, the sophisticated and polished interactions we wanted to implement within the interview software in particular simply could not be made to work across all contexts.
To make matters worse, the notion of the web as a first class platform for applications had not yet fully taken hold, and API support for key functionality such as reading and writing files did not exist. Furthermore, the process of deploying applications to the web was rooted in traditional sys-ops workflows, meaning that non-technical users would not have been able to deploy the software themselves.
Because of these issues, and more, we made the decision to distribute the app by wrapping it inside of a specifically controlled version of the Google Chrome rendering engine, and creating a standalone desktop binary.
Unfortunately, supporting mobile phones would require a complete rewrite of much of the user interface of the app, and is beyond the scope of the project.
There are a huge number of possibilities enabled by taking this work further, and we are actively applying for further funding to hopefully complete this vision.
The technologies we intend to use are cloud-agnostic, meaning that you will be able to choose where and how to host your version of the app. Depending on your use-case, you might find that you can use the free tier of one of the main commercial cloud providers. You may also find that your institution or organization can deploy the app for you.
If you find that you do need to pay to deploy the app, these costs are typically based on the resources you intend to use and are dynamic (so-called ‘elastic’ pricing).
No! Each instance of the cloud app will be completely unique and separate. During the deployment process, you will create encryption keys for your data that will prevent any and all access by anyone other than you.
At present we do not plan to integrate the new version with Network Canvas Server. The new app will provide much of the same functionality of Server, including data management and export views.
Data exported from the new version of the app will optionally be compatible with import into Server.
A key strength of the existing desktop app model is that it supported offline data collection. Although it is technically possible to implement an offline mode for a browser-based app, this falls beyond the scope of this initial project.
The short answer is that these apps will continue as they are currently. Architect will still be used to create and modify interview protocols, and data can be manually imported into Server if you wish.
Our vision is for the Fresco project to produce a new deployment mechanism for Interviewer – not to replace it. This will give researchers a choice in how they conduct their interviews.