Daty, Wikidata for human beings

Daty: main screen
Daty is a free (as in free speech) cross-platform software to read and edit Wikidata.

It is written in Python and uses GTK+ 3.0 as UI toolkit, so is visually integrated in GNOME, the most used desktop environment on GNU/Linux; Daty tries to adhere to GNOME human interface guidelines (HIGs).

Daty development has been announced for the Ideathon of itWikiCon 2018; project's status is pre-alpha.

Should the project receive an official approval from Wikimedia CH, I commit to release it in reasonable time, complete of the features described below and binary packaged for usage on the major computing platforms; I will also try to include it in the GNOME platform, should the requirements meet the goal.

Motivation and features

There is no tool other than the standard wikibase interface of wikidata.org that let its users read and write at the same time on Wikidata without requiring knowledge in programming; at the same time it has several usability issues that prevent even trivial use cases.

Below are listed the problems of the standard editor that Daty deals with, sorted by argument; of course the list comprehends only the ones whose solution is feasible in the context of the Ideathon.

Daty would hugely enhance Wikidata's accessibility for non-wikidatians and offer a better and more satisfying UX to Wikidatians.


The javascript web editor loading time is unbearable on mid/low-end machines on decent sized items; on these computers it is impossible to keep open more than twenty items without chances of freezing the system.

Daty greatly relieves the burden on Wikidata's servers, loading items locally and keeping API requests to a minimum; it handles, with same resources of the standard editor, data in another order of magnitude: if requested, memory requirements could be made independent on the number of opened items, virtually enabling global changes and working on a large number of items without performance issues.

Space management

Some of the default editor issues are really noticeable and one does not need to dig much to perceive them.

Labels' organizations is sub-par.
Labels organizations is sub-par.

The screenshot above, depicting Earth's item (Q2), clearly shows the shortcomings in current space organization: mismanagement often results in a poorly understandable elements hierarchy, too.


In default editor, reference visualization is indepedent on its content, sending the message that all references are worth the same: any Wikipedian can tell the substantial difference between sourced and unsourced statements.
Daty's design visually report lack of references in a claim; moreover, it does not allow qualifier insertion on onsourced statements. The message the user has to receive is clear: no reference = bad reference.

Better safe than sorry.
Better safe than sorry.

In general new references have been given lots of space in the view.

New references for a sourced statement.
New references for a sourced statement.

In-item search

One of my favorite patterns in GNOME is "type to search", so I absolutely had to implement it wherever it was appropriate; this is why it is possible to start writing to filter on whatever view is currently in focus. In the read/edit view the filter is applied on all of its content.

Filtering properties and values.
Filtering properties and values.

Of course the same feature is also available in sidebar to easily select opened items when doing batch editing (see below).

Filtering opened items
Filtering opened items.

Data insertion

Default editor design does not particularly focus on new items creation nor new statement insertion, so at the moment those functions are clumsy, repetitive and stressful after some usage.

The number of steps needed to complete to easiest task is remarkably high (as an example, the reader could try to count the clicks need to create a new item and add three referenced statement); keeping in mind the lack of batch editing features, it is clearly proved how user edits in a given session are bounded above by the number of repetitive mechanical actions the user can withstand before giving up, realizing, often unconsciously, the inefficiency of the whole editing process.

From a technical point of view, what has been described would be equivalent to artificially limit the weekly cumulative size of a Wikipedian user edits to 140 symbols. That's not exactly a good strategy to scale things up.

Daty attempts to minimize the number of steps required to create new elements:

Published: 17 November 2018
Last edited: 20 November 2018
The contents of this website are released under CC-BY-NC-ND