Together with my team, we would like to share our ideas on how to improve ODK Aggregate and how the future development and maintenance might look. We've based our thoughts on the experience that we’ve gained during our work with ODK for Poverty Stoplight project for the last months and what we found on the ODK forum and Slack channels.
First of all, we need to simplify deployment process. That would fasten our work on the next improvements, and also it would make easier deploy for you after final version is released. When searching the ODK forum, a majority of questions and topics related to Aggregate are connected with problems during the deployment for both users and developers so we believe that it is an issue worth addressing.
Fresh UI - we could create simplified, more user friendly UI, for all aggregate users. We are aware that the design of the UI hasn’t changed much since it was first implemented. We believe that redesigning it would make the Aggregate more usable as the user experience has changed during the last few years and the current UI was often misleading and unintuitive. A great example of what can be done was presented by the Caden Howell’s work on ODK Hamster (https://github.com/benetech/odk-hamster and https://github.com/benetech/odk-hamsterball-java).
RESTful API is highly requested change when talking about Aggregate. It would enable easier integration with other tools by setting up a modern way of connecting services. Currently, Aggregate uses a lot of different technologies like servlets, REST API for ODK Tables, GWT. Using only one and the most popular solution would make a huge difference in terms of integration and maintenance of the code. We could use the JAX-RS and Jersey for achieving it just like it is used for ODK Tables. Additionally, when the RESTful API would be finished, we would suggest to document it with for example Swagger. Process of switching to the RESTful API would definitely be time consuming but the effort is worth taking.
We could also create offices, so there will be no need to use many deployed aggregates if you need to split the aggregate content (forms and instances). Admin would be able to see all instances and forms. The idea of splitting the content of a single Aggregate instance with permissioning depending on the user rights was successfully implemented for ODK 2.0 during our work with Benetech so it shouldn’t be difficult to achieve a similar result corresponding to our needs.
Apart from the above, we could think of changing the authentication to a token based one instead of the old basic authentication over HTTPS. I've seen this topic being raised here.
Another smaller things worth considering are:
- Submissions counters to measure and visualize the growth of the number of submitted data records.
- Filtering of the instance IDs based on submission date as currently there is no such functionality within the ODK.
At last we could create possibility to edit data on Aggregate side. If office manager/admin sees any mistake on the instance side, he can correct it. This in fact, should be discussed if it is even a desirable feature.
I would highly appreciate your feedback about our ideas.