Tino Kreutzer - TAB Application - 2020-09-01

Tino Kreutzer (@Tino_Kreutzer)

KoBoToolbox / KoBo / Harvard Humanitarian Initiative (HHI)

What contributions (e.g., issue triage, tech support, documentation, bug fixes) have you made to the ODK community?
I have added documentation to xlsform.org, mobilized funding for the creation of Enketo Express, the XForms spec documentation, as well as for new audio recording features as well as improved data protection of media attachments.

How do you believe your contributions have benefited ODK?
Through my work leading the KoBoToolbox project I believe we introduced many thousands of new users to the XForm/ODK/XLSForm universe, many of whom may otherwise have chosen to use commercial tools--especially in the humanitarian, human rights, and research sectors. This means that in these fields today ODK/KoBo is by far the most widely-used toolset. Whether someone chooses to host forms on KoBo or ODK or other compatible tools, I think creating a user friendly entry point to switching from paper or commercial tools to ODK-compatible open source software has had a great impact for the work of these organizations.

What do you believe the top priorities for ODK are?
avoid fragmentation, investment in online-only / remote surveying methods, sustainable funding, investing in UX research and UI design, record updating / case management feature, easier encryption / decryption method

How will you help the ODK community accomplish those priorities?
I will work to reduce redundancy/friction between KoBo, Enketo and ODK; mobilize additional core funding for ODK Collect maintenance and development; secure funding for UX/UI as well as features that improve user friendliness of ODK Collect, work to find a common way of introducing case management / record updating, and finding an alternative to the current encryption method.

How many hours a week can you commit to participating on the TSC?

What other mobile data collection projects, social good projects, or open source projects are you involved with?
I support a number of large data collection projects at HHI and have personally managed survey projects with more than 40,000 interview responses in the past.

Please share any links to public resources (e.g., resume, blog, Github) that help support your application.


Hi @Tino_Kreutzer :wave:
When it comes to reducing redundancy/friction between KoBo, Enketo, and ODK... do you have nay ideas for what's one quick win? and one painful but much needed action?


Hi Dan :wave:

I'm guessing by "painful but much needed action" you mean KoBo's Collect fork? We've had number of good conversations and idea exchanges over the last year and I know these came up at times during the TSC/TAB (white labeling, ongoing maintenance support costs, terminating the fork). My priority would be to explore each option openly and define the best course of action as soon as possible. I think such an action plan would be a quick win :slight_smile:

Regarding Collect vs Enketo my feeling is that a frank analysis of the technical and user experience aspects would be helpful for planning the next years, if this hasn't already been discussed. The slight differences between them (UX, functionality, XForm interpretation) are frustrating for some users in my experience while there is a clear need for people to move between platforms more frequently than ever due to remote data collection.

1 Like

Hi @Tino_Kreutzer

Thanks for the detailed application.

From your personal experience, what do you consider to be the main challenges of ODK Collect user-friendliness?

Hey @dicksonsamwel!
I would start out by saying that although (or because) I've been using Collect professionally for more than 10 years I strongly feel we should invest in solid user research to go beyond any of our collective personal experiences. It helps anchor discussions based on concrete observations and to justify particular UX and UI decisions more transparently. I love seeing what @seadowg has been doing to improve the UI and obviously we've seen some important improvements big and small over the last year or so.

I'll just quickly concentrate on some big issues that affect first time users.

  • Onboarding new users: Whether they are first time survey administrators or enumerators, the current flow after installing the app is unintuitive (and often disappointing) for many. In short, the app doesn't provide any onboarding help and users need to Google for help or ask a colleague to know what to do next.
  • Connecting to online account/getting forms: Connecting to the user's account on Central/KoBo/Ona/etc. is the first thing any user would have to do, therefore there should be clear directions indicating how to do this. This could be as simple as a ‘setting up your account’ banner or a ‘get started’ automated screens the first time to open the app. For many modern apps the solution is to requires a username/password after download before anything can be done, after which forms are loaded from the server. We know why this was not a requirement to date (complete offline users sideloading XML forms) and we should continue to support this, but I think we should have a better, more streamlined first use experience for the majority of users.
  • Buttons in main menu: The meaning of the buttons in the main menu (Fill Blank Form, Edit Saved Form, etc.) is unclear to regular users until they've learned it through training or trial and error. That's because both the labels of the buttons are confusing (Blank vs Saved Form) and because the six buttons on the same screen are used in very different frequencies and points during the survey process. Making a clear distinction between the first four (related to data entry) and the last two (related to obtaining and managing forms) will be important. This whole screen requires a complete rethinking as many people have been saying for years, but this requires a good UX process.
  • Sliding between screens: It's the most central thing to the app, but the fact that users need to slide between questions/groups to advance is not obvious. It's the first thing we teach in trainings, but it is surprisingly unintuitive even to technically advanced users. One possible solution would be buttons that allow moving to the next or previous question/screen, which could appear faded (if a required question hasn't been responded to) and that only unlocks once there has been an answer. Phones are bigger than in 2007 so we can have more functionality.
  • Saving/submission screen: This is confusing to most new users. What does it mean to 'Name this form', to 'mark as finalized', and does 'Save and Exit' mean I will close the app?
  • Saving and closing functionality within a form: This gives many field enumerators great anxiety: How can I close the form I am in without going to the final screen (as there is no 'close' button in the form/app)? What do the three options mean when I hit the Back button on the device? When I open a form draft to review and want to get out without saving, should I hit Back > Discard or Back > Save--neither of which sound like what I want (just exit)? This always requires hands-on training and should be intuitive (e.g. a new close button and a well tested confirmation dialog).

None of these are new and surprising for those of us who've been working with Collect for a long time. But they are crucial if our goal is to make the first use of Collect a positive one. My strong suggestion is not that we change them but that we start using a rigorous UX design process to 1) learn what the biggest pain points are (as opposed to starting from a list like the above!) and 2) iteratively test proposed changes with the right kinds of users (i.e. not Dickson and Tino :wink:) before implementing them.