I've been using 2.0 for a while and I collected thoughts/comments/observations as I went. I thought it might be worthwhile to share with developpers. If anyone else other comments to add feel free to contribute. As for my part:
Various notes on ODK Aggregate 1.4.4
• In Aggregate 1.4.4, when you export a form from the Form Management Menu, it automatically brings you to the “Export Forms Results” where you can see a list of all exports done at this point. I think it is more useful to have user stay in the Form Management Menu: especially with the ability to link forms toghether now, it’s very likely one will have many forms to export (because they contain related data for analysis), so you don’t really want to have to click back to the Form Management Menu every single time. It’s more efficient to Export all the forms, then download all the forms, then check then in Excel/whatever else you do.
Notes on Survey Beta – 3
• Would be nice to have a way to send multiple forms to server at the same time: again we can have linked forms now, therefore it is likely that you’ll have some sort of parent form with one or more child forms, which you all want to synchronize at the end of your day. Just take the Ehtiopia Household form as an example: it has 10 related forms… So it means 10 times going back-and-forth to Send Finalize Form. Would be sweet to have some button “Send all finalized forms”... much like in COllect.
• Would be nice to have Survey and Collect’s UI as compatible as possible. For example, on Collect 1.4.4, if you go to “General Settings” to set the URL, you have to go to “Configure platform settings” in order to change the URL the app connects to (this has changed from earlier versions). In Survey, it is now set the way it used to be in Collect (you get the URL setting straight in the “General Settings”. As a general concept, I feel that having both UI as similar as possible will make it much easier for people to migrate from one another (or used both for different things). From a training point of view, it also simplifies things for users who have little technical abilities and rely on tutorials/formations to use the software.
• Sync now function: unless I am mistaken, when using Sync Now you pretty much HAVE to get an mirroir of the server on your phone, but that is true for all forms simultaneously. What if I have some common information (like picking from a list of surveyor’s who you are so you can link surveyor’s details info with just that field), but I don’t necessarily need to Sync ALL forms on my phone? Because Syncing all implies that the cycle for all your forms on the app are similar. But things like Enumerators/Teams info might not be on the same cycle as your actual data collection (be it nutrition/health or whatever). I am not positive we NEED that option, there might be ways to achieve same results without changing the core code (which is better because then you guys can work on more important issues). But I think the issue is worth considering, whatever solution if found.
Notes on Application Designer
• Great new toy overall.
• Would be nice to have a way to purge database for multiple forms at the same time (or maybe just all). Again with linked_table & forms you sometimes have to make changes to multiple forms and purging the DB 3 times for 3 forms is tedious when you’re developing. I don’t see too much of a potential for mishaps with a “Purge All” option: you’re developing your forms, you shouldn’t have anything critical in there.
w.r.t. the Sync functionality, the aim is to be very frugal with bandwidth
and efficient with time. We are not there yet.
Eventually, if a table has no changes to its rows, the sync of that table
should consist of 2 requests to the server, and that is it. So if you have
team/surveyor information tables, and they don't change often, then you
only waste 2 requests for that table during the sync step. When data does
change, only the rows that changed are exchanged between the server and the
device. And we also want to implement data filtering -- to enable sending
only the relevant data in a table to each device.
w.r.t. "Purge Database" in the Application Designer
As long as you never review or access the revised data tables, you should
be able to update each form, and purge only once. "Purge Database" deletes
all data tables. The tables are only created after you "Follow Link" into
the form.
But even this is a hack -- as we more tightly integrate the various tools,
we should be able to selectively drop the data tables that are affected
when a form is updated. We would also like to support prepopulated data
tables for, e.g., selection lists, within the Application Designer. Right
now, we have a hack for doing this via a special debug output object
generated by tables, but we should be able to mimic the data initialization
sequence of the device within the application designer. If we are selective
about how we drop tables, data initialization becomes feasible.
···
On Tue, Sep 23, 2014 at 4:27 AM, wrote:
Hi all,
I've been using 2.0 for a while and I collected
thoughts/comments/observations as I went. I thought it might be worthwhile
to share with developpers. If anyone else other comments to add feel free
to contribute. As for my part:
Various notes on ODK Aggregate 1.4.4
• In Aggregate 1.4.4, when you export a form from the Form
Management Menu, it automatically brings you to the “Export Forms Results”
where you can see a list of all exports done at this point. I think it is
more useful to have user stay in the Form Management Menu: especially with
the ability to link forms toghether now, it’s very likely one will have
many forms to export (because they contain related data for analysis), so
you don’t really want to have to click back to the Form Management Menu
every single time. It’s more efficient to Export all the forms, then
download all the forms, then check then in Excel/whatever else you do.
Notes on Survey Beta – 3
• Would be nice to have a way to send multiple forms to server at
the same time: again we can have linked forms now, therefore it is likely
that you’ll have some sort of parent form with one or more child forms,
which you all want to synchronize at the end of your day. Just take the
Ehtiopia Household form as an example: it has 10 related forms… So it means
10 times going back-and-forth to Send Finalize Form. Would be sweet to have
some button “Send all finalized forms”... much like in COllect.
• Would be nice to have Survey and Collect’s UI as compatible as
possible. For example, on Collect 1.4.4, if you go to “General Settings” to
set the URL, you have to go to “Configure platform settings” in order to
change the URL the app connects to (this has changed from earlier
versions). In Survey, it is now set the way it used to be in Collect (you
get the URL setting straight in the “General Settings”. As a general
concept, I feel that having both UI as similar as possible will make it
much easier for people to migrate from one another (or used both for
different things). From a training point of view, it also simplifies things
for users who have little technical abilities and rely on
tutorials/formations to use the software.
• Sync now function: unless I am mistaken, when using Sync Now you
pretty much HAVE to get an mirroir of the server on your phone, but that is
true for all forms simultaneously. What if I have some common information
(like picking from a list of surveyor’s who you are so you can link
surveyor’s details info with just that field), but I don’t necessarily need
to Sync ALL forms on my phone? Because Syncing all implies that the cycle
for all your forms on the app are similar. But things like
Enumerators/Teams info might not be on the same cycle as your actual data
collection (be it nutrition/health or whatever). I am not positive we NEED
that option, there might be ways to achieve same results without changing
the core code (which is better because then you guys can work on more
important issues). But I think the issue is worth considering, whatever
solution if found.
Notes on Application Designer
• Great new toy overall.
• Would be nice to have a way to purge database for multiple forms
at the same time (or maybe just all). Again with linked_table & forms you
sometimes have to make changes to multiple forms and purging the DB 3 times
for 3 forms is tedious when you’re developing. I don’t see too much of a
potential for mishaps with a “Purge All” option: you’re developing your
forms, you shouldn’t have anything critical in there.
Let's say I'm working on a "Parent Form" and "Child Form 1" and "Child Form 2". The child form write on the same datatable let's say, and the parent form contain some other level of information, like households & household_members informations.
Let's say that I want to move 1 datarow from Parent Form to one of the Child forms, or maybe I want to add information that implies modifiying both Child Forms. In that case, when I run the converter and go back to the preview to test my modification, I don't think I can just purge the DB from the main menu (i.e. the common JS Framework menu): if I do, I still see all the instances of the Parent & both child forms when I click on them. I have to go to each form's main menu, THEN purge. Meaning that a change involving more than one form/subform requires purging them separately.
···
============
Weird behavior with "integers" data type:
If I have 2 integer datatype on the same screen, and enter some data in the first one, when I move the prompt over to the 2nd box, the numberpad will disappear before I can enter any number. I must tap it again to have it back. As if the fact that I typed in the first one validated, for the phone, that I was done with the number pad.
Might be Android thing, I'm running 4.1.2 on samsung S3.
Thank you for the reproduction case. The code is written to delete
everything, but there is probably an unexpected interaction between the
form you are viewing and the purge button. We should probably load the
framework page before the purge, so that you are on a "safe" screen.
The pop-up keyboard is definitely idiosyncratic and varies with device and
OS version. We will likely need to add hooks to directly control it via
the Java application code.
···
On Thu, Sep 25, 2014 at 6:19 AM, wrote:
On Purging DB:
Let's say I'm working on a "Parent Form" and "Child Form 1" and "Child
Form 2". The child form write on the same datatable let's say, and the
parent form contain some other level of information, like households &
household_members informations.
Let's say that I want to move 1 datarow from Parent Form to one of the
Child forms, or maybe I want to add information that implies modifiying
both Child Forms. In that case, when I run the converter and go back to the
preview to test my modification, I don't think I can just purge the DB from
the main menu (i.e. the common JS Framework menu): if I do, I still see all
the instances of the Parent & both child forms when I click on them. I have
to go to each form's main menu, THEN purge. Meaning that a change involving
more than one form/subform requires purging them separately.
============
Weird behavior with "integers" data type:
If I have 2 integer datatype on the same screen, and enter some data in
the first one, when I move the prompt over to the 2nd box, the numberpad
will disappear before I can enter any number. I must tap it again to have
it back. As if the fact that I typed in the first one validated, for the
phone, that I was done with the number pad.
Might be Android thing, I'm running 4.1.2 on samsung S3.