[it][en]

Daty, Wikidata for human beings

Daty: main screen
UPDATE: The alpha version is out!

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 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.

Performance

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.

References

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:

ListBox rows can seamlessly become search entries when focused.
ListBox rows can seamlessly become search entries when focused (incomplete mockup: see how results are organized in the next picture).
Creating a new item while searching for it.
Creating a new item while searching for it.

Despite pertaining to data insertion I believe batch editing features deserve their own section.

Batch editing

Simultaneuous items editing is really why Daty is born. This features is so important in the program that the 'open new items' dialog integrates a graphic interface for SPARQL queries just to facilitate this task: pretty much anyone can do constraint-based queries in a single step.

SPARQL GUI editor. Click to see it animated.
SPARQL GUI editor. Click to see it animated.

When multiple items have been opened, clicking on the headerbar 'select button' button will bring Daty into batch mode.

Select button usage.
Select button usage.

Batch mode splits the read/edit view in two columns: on the left there are statements specific to the currently 'activated' item in the sidebar, on the right statements common to all 'checked' items. Statements equal up to qualifiers are put in common view, with the qualifier of the 'activated' item visually reported. We can see an example depicting usage on popular Italian singers in the following screenshot.

Batch mode: single column view.
Batch mode:single column view.

Of course I foresee 'drag and drop' capabilities for this view; implementation details are still undefined through.

Batch mode: drag and drop.
Batch mode: drag and drop.

Finally,horizontally resizing the application would collapse the focused column on the other, moving label and description out of header bar, replacing them with a "specific/common" stack switcher.

Batch mode: single column view.
Batch mode: single column view.

Licence

Daty is released under GNU General Public License v3 or later versions.
Source code release and development happen on its GNOME project page.

Extra material

The slides shown at the Ideathon are available at this address (Italian).

UPDATE: The alpha version is out!

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