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.


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?

1 Like

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.


Thanks for your application and focus on user experience!

How do you imagine yourself engaging in TAB discussions around Central’s roadmap given that it and Kobo have similar roles?

I like @dicksonsamwel’s question and your answer so much I can’t help but add a bonus question!

What do you see as the biggest challenges to doing this on an app-wide basis and how do you imagine addressing these as a TAB member?

1 Like

Hi @LN, it’s a fun discussion, agreed!

I would hope that my experience leading KoBo will be useful to make Central a success so we can together learn from our experience and past mistakes. By this I don’t only mean technical but also strategic decisions when it comes to cloud hosting of user generated data. At the end, users need a variety of tools to pick from for different use cases and environments, so I hope to help shape Central to address current / future gaps in the ecosystem. For example, KoBo, as opposed to Aggregate, doesn’t run easily in a small low resource server environment and has a large overhead. I would hope to push in the TAB for keeping Central agile and fast to install so these kinds of use cases are prioritized.

For UX, I would see my role in being a strong advocate for anchoring it at the top of decision making and at the same time devoting as much time as needed to make sure there is funding to make it happen. We can contribute already from KoBo’s side with UX design time but I’d want to expand towards the goal of a regular UX designer with fixed responsibilities vis-à-vis ODK products, especially Collect and Enketo. Grounded discussions within the TAB to make strategic decisions as to where UX improvements are most needed and require most research will be key to using scarce resources most effectively.


Hi @Tino_Kreutzer! Thanks for your application!

Lots of great questions already. One that came to mind for me: as you've said, you and KoBo have been in the ODK scene for a long time. I'm curious why you or anyone else from KoBo hasn't applied to join the TSC/TAB earlier. Is it coincidence or has there been a strategic shift in thinking at KoBo, or is there some other reason?

Hi @tomsmyth, I'm glad you asked that question. In fact I / we've been waiting for about a year now for this election. For the initial wave of TSC elections I was very happy for @martijnr to be there and push for strategic integration of Enketo into the ODK ecosystem. KoBo, through our donors, has invested quite heavily in Enketo-Express version and the thorough documentation of XForms. At the same time, there have been a lot of important discussions on the sidelines over the past year+ about how our tools should fit together, how we can help contribute to the development and financing of Collect, etc.--and it would make most sense if such high level discussions are had directly in full transparency and with the full TAB instead of having them bilaterally and then only indirectly discussing pain points and possible solutions without the KoBo pachyderm in the room, if you will. :slight_smile:

Now that Martijn is retiring I would like us to stay involved and so it makes sense to go the next step and bring our organizations and tools closer for a single ecosystem that strives and grows together.