Open Data Editor user testing: feedback from the StoryData team

The Open Data Editor (ODE) is the new Open Knowledge Foundation’s app that makes it easier for people with little to no technical skills to work with data. Since January, it’s been developed thanks to the kind support of the Patrick J. McGovern Foundation and has become a central product for putting our The Tech We Want vision into practice.

After the ODE pre-release last October, our team has been collaborating with data practitioners to gather feedback from potential tool users. To do this, we divided the process into two parts:

Individual and group testing sessionsto systematise quick insights on possible problems and potential improvements
Two pilots with organisations that work with data but with different expertise: StoryData (Barcelona, Spain) and Asociación Civil por la Igualdad y la Justicia – ACIJ (Buenos Aires, Argentina).

We wanted to learn how a tool like ODE integrates into everyday data workflows, what are the possible challenges when using it intensively, and know hands-on recommendations to unleash its full potential.

Based on real users’ feedback and insights, our team has already made some improvements to the app for its stable release. You can check more here. We are also systematising recommendations and suggested changes for next year.

About StoryData

In this blog, you can read the feedback from StoryData, a Barcelona-based data communication project combining research, analysis and visualisation with narrative to tell the stories behind the data.

Their mission is to fill a gap in the current communication offer through a rigorous exercise in data journalism and defend the need to open data to citizens in order to socialise public information and combat post-truth.

Why StoryData?

We picked StoryData as one of the organisations to conduct the ODE pilot because they are a multiplier hub and can offer the perspective of other organisations they work with to help them enhance their data culture, clean, maintenance, and systematisation.

Here’s their structured feedback:

*StoryData team during the testing phase*

General Assessment

Open Data Editor can become a useful tool, provided that many functional bugs, which we have described in the recommendations, are fixed.

First of all, right now the tool detects errors that come from the configuration of the software itself, and therefore, it wastes a lot of time in detecting errors that are not dataset errors.

On the other hand, it has usability problems, for example, in navigation. It is very difficult to locate the cell where the error is due to the system of location through pages. It would be much better to be able to go directly to the cell.

The tool can be very powerful, although it still has a long way to go to become really useful.

Regarding usability

There’s a lack of terminology that’s more appropriate for non-advanced users. Most people and technicians who work with data without it being their specialty do so with Excel datasets or Google Spreadsheets. If the tool is designed for this type of user, bringing the terminology closer to what they already know will make it easier to understand and use (for example, instead of talking about a field, the term column can be used, which is more recognizable).

Most users rush into using the apps without looking at the guide. It would be interesting to include the option of popups with usability and meaning aids, for example saying that the green dot means there are no errors and the red dot means there are errors, which is quite obvious, but confirmation is needed that this is the case.

Also add warnings for steps that cannot be reversed: for example, that you can only perform one step back and that when you save a change you cannot go back.

Along the same lines, we think the terms used should be more descriptive and clear: for example, calling the folder where copies of the datasets are saved ‘temp’ is confusing.

Functionality

Moving through the table’s cumbersome and in a dataset with thousands of rows and many columns it’s difficult to locate the error detected by the application. The ‘Errors Report’ could be used as a means to directly access the cell with the error that has been detected.

Having the metadata at hand is a resource that, depending on the user level, complicates access to valuable information such as the format of the data in each column. Perhaps access to all the metadata could be accessible through an advanced user or developer tab and leave the most valuable information at the first level of access, in this case I think it would be the format of the data.

The issue of data formats needs to be further refined, since it’s a fact that the decimal symbol in the Anglo-Saxon and Latin systems is different, dates can be expressed in many formats that are correct, latitude and longitude data have their own formats… A first option is to be able to choose which language the dataset is in, and in this way it would be known to which decimal, date, etc. coding system it belongs. This is important because the more precise the data format is, the more errors can be detected. It’s missing being able to download some kind of doc with the error report.