You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should start by analyzing what are the common needs between the different countries to know what we really want to build.
Should we keep Kobo?
Kobo has lot of weaknesses: uncomplete api, poor documentation, not evolving quickly, etc.
We should reassess if we want to build a more complex system based on Kobo.
It's worth investigating and benchmarking the different existing form apps to be sure to make good architecture decisions.
Other question: how many countries use Kobo?
If we keep Kobo
Idea 1:
One can retrieve the forms structure from kobo with : https://kobo.humanitarianresponse.info/api/v2/assets/<form id>/content
Check if the structure is easily parsable
Find out all the possible fields for this form (what are all the possible fields types in Kobo?)
Based on this schema we could automatically reproduce the form:
option 1: we pass it to the frontend to generate the layout
option 2: we add it to the repo as a static asset
list all the degrees of freedom we want
Challenges:
translation
manipulating multiple forms
the groups are the groups of the original form, if they are big, the tables in the frontend will be big too. e.g. do we want to display the form the same way it is displayed in kobo?
What are the fields we want to display in the Home page? the filters we want to use ? (could come from a config file)
The typing will be looser
Changes in the code:
Backend:
DTO
filters (disaster selection etc)
the user roles and the access control logic
Frontend
the common fields
the filters
the 3 disasters
the typing
the table config files
the queries (we will not have strong type check anymore)
Idea 2
Create a boilerplate based on the current repo
The text was updated successfully, but these errors were encountered:
Here are a few ideas to build a more generic app:
Redefining the product
We should start by analyzing what are the common needs between the different countries to know what we really want to build.
Should we keep Kobo?
Kobo has lot of weaknesses: uncomplete api, poor documentation, not evolving quickly, etc.
We should reassess if we want to build a more complex system based on Kobo.
It's worth investigating and benchmarking the different existing form apps to be sure to make good architecture decisions.
Other question: how many countries use Kobo?
If we keep Kobo
Idea 1:
One can retrieve the forms structure from kobo with :
https://kobo.humanitarianresponse.info/api/v2/assets/<form id>/content
Challenges:
Idea 2
Create a boilerplate based on the current repo
The text was updated successfully, but these errors were encountered: