Enketo (Web Forms) vs KoboCollect

(Updated for clarity of terms)

I read the article http://xlsform.org/en/ref-table/ which compares the features of Enketo vs KoboCollect.

Our team has been using android tablets successfully in low resource countries with intermittent connectivity, and we were thinking of using KoboCollect for a pilot survey and other projects. However the form seems to work well with Chrome/Enketo on the android (as well as on iPhones, iPads and laptops). I am interested in the community user’s experience. Assuming the forms have the same functionality, which platform have you standardized on (Enketo vs KoboCollect), and why?

KoboCollect takes more effort to set up, but It seems more secure using usernames and passwords. Editing forms seems like an easier process, and it is clear which forms have yet to be sent and how to manually send them.

Enketo has an intuitive interface and seems easier to navigate, but it only requires a link to the survey, so seemingly it is less secure. I see that username and password can be required for all projects, but I am just now looking into this. I am not sure if completed forms can be edited and at times there is wait until forms are uploaded when connectivity is restored. (More to follow…)

I appreciate your thoughts.


Ok, answering my own question. It seems that the answer is… It depends.

I have been researching this, and I thought I would share my findings. This is lengthy and not necessary of interest to all. I think our group will probably start with KoBoCollect due to its simplicity. However, we will look at both as we continue to learn about the product. We are looking at a possible 30 page questionnaire - and it seems to me that this will be much better using Enketo. So, here goes…

The definitive reference for Enketo and KoBoCollect functions in XLS Forms is maintained by XLSForm.org at the following web site: http://xlsform.org/en/ref-table/ In general, there are very few functional differences in the functions allowed on the two platforms.

Name and password
• Enketo:
• The default is to allow data entry by anyone using a web browser as long as they have the URL to the form. This URL is obtained by Form > Collect data > Copy.
• The owner can also “Require authentication to see forms and submit data”. This is a global setting for all forms created by the owner. In this case, use of the above link would require a username and password.
• You can also direct the user to a link through KoBoToolbox. The link is shown in Settings > Sharing > Share by link, and it requires a username and password. You are then taken to KoBoTool box, where you go to Form > Collect data > Open. This is also where the user can see or modify data, depending on permissions. Subsequent use of this link may not require re-entry of username and password. (TBD).
• KoBoCollect
• Server name, username and password are all required.
• In addition, “Form metadata values will be added to forms that have username, email and/or telephone preloaded fields to identify the person submitting the form.” Fields in KoBoCollect are as follows:
o User defined
 Username
 Phone number
 Email address
o Device-defined
 Device ID
 Subscriber ID
 SIM serial number
Some, but not all, of these fields can be specified in KoBoToolbox > Form > Edit > Layout & Settings > Form Style. This would add additional levels of authentication when reviewing data. (Note that the Username will display if authentication is required for viewing with Enketo.)

Grid-theme style:
 Enketo
o This style will display correctly in Enketo.
 KoboCollect
o Although you can build your survey forms in KoBoToolbox with grid-theme style you are not able to collect data using the same format in KoBoCollect

Skip logic inside of a Group
 KoboCollect: There is a bug that does not allow skip logic questions to display without having the form refreshed. There is a workarounds involving displaying the second question outside of the group, but this is not ideal.
 Enketo: Skip logic inside of a form works correctly.

Language support
 KoBoCollect: Settings and prompts are supported in many different languages. This may be a significant advantage for some organizations.
 Enketo: A multi-language user interface is in progress. Currenly the labels are in the language of the browser.

 KoboCollect requires navigation using one of the following:
• Horizontal swipes
• Forward/backward buttons
• User swipes and buttons
This adds many “touches” to navigation, which can be significant in a longer form.
 Enketo uses a single scrolling form.

 Both KoBoCollect and Enketo allow editing of draft forms.


Hi @jblackman,

Thank you for sharing this wonderful information with the community! Should benefit the entire community!

Thanks, @Kal_Lam

Just as a final thought, after obsessing about this for several days, we made the decision to simply go with Enketo for all of our projects. I just see no advantage to KoBoCollect, unless it supports a feature that is essential to the form. And since many of the future projects that are being considered will require grids or at least branching logic within groups, Enketo is the better choice. Plus, and this is important, the tablet format and the PC/Mac (laptop) format is identical with Enketo, making data entry and management more seamless across platforms.

Again, if I am missing something , please let me know your thoughts.

1 Like

Hi @jblackman,

Great overview! Thank you for writing this down. We’re trying to minimize differences between ODK Collect and Enketo as much as we can. (KoBo Collect is just a re-branded, and usually outdated, version of ODK Collect, I believe).

Let me comment on a few things:

You can also use the same pages mode that ODK Collect has. See https://blog.enketo.org/pages/ (TL/DR; in the style column on the settings sheet add "pages")

I think they are functionally similar, but the difference is likely that ODK Collect has a more complete UI language translations and probably for more languages. If anybody wants to help translate Enketo, please do! https://www.transifex.com/enketo/enketo-express/dashboard/

1 Like

Thanks for the comment. Just to clarify about a ‘single scrolling form’… I am designing an attendance form, which has header information about the session, followed by a list of attendees. The attendees are added in a repeating group, and as persons are added, the entire form becomes a long scrollable list. This is far better for our purposes than Collect, as the list can be quickly reviewed and edited prior to submission. I was aware of the pages option, but thanks for pointing it out for completeness.

BTW, I just want to add that this KoBoToolbox project is wonderfully designed and supported. Simple, yet elegant, and it seems very solid. Kudos to the team!


Given the fact that this review is from 2019, is it still accurate?
Also, would you still point to XLSForm.org as the beste documentation reference?
(I also rely heavily on this ODK Collect — ODK Docs for functions etc)