The major change in this release was the addition of “Roles” to control access to:

• individual surveys
• columns in a survey
• rows in a survey

Only users who have “Security Management” group given to them on the user management page can set up roles.  The steps are:

1. Create a “role” in the roles tab on the user management page.  This is just a name, any name.  For example we could create a role called “District 11”.
2. Give 1 or more users that role.  To do this click on the user name in the “users” tab on the user management page. Then select the “District 11” role.
3. Edit a survey to require this role.  To do this open the survey for editing and select the menu “Files” > “Roles”. Then enable the “District 11” role.

At this point only those users who have the “District 11” role will be able to access the survey.  This restriction also applies to administrators who will not be able to give themselves the role unless they are in the security management group.

To add column restrictions click on either “filter rows” or “filter columns” in the survey editor role management page (where you were in step 3 above).

The following video shows steps 1 to 3.

Amos Doornbos and I gave a 5 minute lightning talk recently at the GeOng 2016 conference in Chambery.  The subject concerned using a Mobile Data Collection tool, such as Smap, as the starting point of a system to manage feedback and complaints.

These slides in google docs contain the content of the talk: https://docs.google.com/presentation/d/1qG_y_4DkZhmeM0B-X-Ibhtqume2jOyjdarOgV5yfdmI/edit?usp=sharing

I just left GeOng 2016 in Chambery which was a really good conference with lots of interesting workshops and presentations.  However I want to comment on one of the final sessions, the subject of which was “Response-effectiveness of new analysis tools for humanitarian professionals”.

In one segment of this session Anwar Mahfoudh from OCHA/Kobo argued for the complete elimination of the “proliferation” of Mobile Data Collection tools used by Humanitarian agencies.  He argued all not for profits and NGOs should use Kobo (maybe there might be some very small usage of “legacy” tools as well).    The rationale was to reap the benefits of standardisation such as lower costs since every data collector everywhere in the world would be familiar with the same tool.

OK I need to declare a small conflict of interest here; if this happened that would mean no more Smap for humanitarian agencies.

Anwar was arguing for standardisation, which is a good thing, he was just arguing for standardising on a tool rather than on the interfaces and processes.  Tools come and go; standards should last much longer.  After all, AOL and Netscape are not so common nowadays, and yet the underlying standards that they and the rest of the World Wide Web were based on have continued to evolve.  Fortunately two of the other panelists in the session,  from UNHCR and ICRC, both made this point and rejected the mono-tool approach.

Some useful standards could be:

• xlsForm and the ODK XForm standard to allow forms to be moved between tools.  Even where an MDC tool does not support ODK natively they can implement these as an import/export.
• Use of HXL to facilitate consistent interpretation and comparison of results gathered by different tools
• The koboToolBox API.  Smap partially implements that so if you are pulling data automatically out of Kobo you can use the same interface to get it from Smap.

Hopefully OCHA/Kobo will soon switch to arguing the functional merits of their own tool and adoption of standards rather than seeming to argue that technical competition is a bad thing and won’t lead to better results for the community.