Timeline for Wiki needs picturesEdit
|First planning of the work, together in Alexmar983 house||4-6 December 2015|
|Test of the beta version of the tool during wikimeting in Florence for 15° Wikipedia birthday||15 January 2016|
|Studied how to interact with Wikidata and prepared SPARQL queries.||30 May 2016|
|Github repository 100% complete, updated online and copied over to server.||15 August 2016|
|Bug-fix and tested compatibility with all platforms||30 August 2016|
|Final Report submitted||14 September 2016|
Please prepare a brief project update each month, in a format of your choice, to share progress and learnings with the community along the way. Submit the link below as you complete each update.
During this month we had a preliminar brainstorming about how to start and which tasks could be problematic, stressing the demo.
We understood that the main point of the tool is providing alerts that an image is missing with a strong geolocation component. So we analyzed the state of the art of coordinates among Wikidata and Wikipedia. Looking at the data, both with SPARQL queries at he Wikidata endpoint, both with API call to local Wikipedias, we noticed that there are many uncertainties concerning geodata:
- sometimes Wikidata entities have more than one lat/long value;
- sometimes the value on Wikidata is quite different from the value on Wikipedia and, moreover, it could be different again according to a certain language version;
- sometimes coords are simply wrong (the tool is very useful to locate immediately wrong coordinates in the area known by the user);
- sometimes coords are not enough to describe the position of very large entities.
Seeing these problems we thought about:
- a way to use those data with our tool idea (e.g. doing avarage or display all these dot with a connection);
- a way to improve the quality of geodata, drafting another possible tool.
Thinking about which kind of Wikidata elements we consider without image (as you know, at the moment Wikidata not fully represent the amount of images that Wikipedia and Commons have). So we established that we can start with items without image property, without commons interlink and gallery and with coordinates.
- We thought about a way to make a simple configuration file to produce the highest possible number for translations
- The demo version uses the type provided by Extension:GeoData to generate the filter menu. We thought that we could ask an improvement of those categories or we could simply use the "instance of" property of Wikidata.
Thinking about which API the tool may expose we focused on two main aspect:
- Data API: this would returns at least the Wikidata item, its coords, its type (assembling all our data, not just the one currently on WD)
- Statistics API: this would returns the numbers of new and processed items and some metrics about where this happens
- during the 15th birthday celebration in Florence, the beta of WNP was shown to a group of it-N users active on itWikipedia, itWikiversity and Commons. Reactions were very interesting.
- the problem of obsolescence and limited coverage of local templates could be explained in few minutes, many users were completely unaware of this issue but soon realized its existence with a simple look at the distribution of the flags, the lack of superposition and the prcentage of false negatives;
- the flexibility of the tool was also easily understood. It has been specifically requested, for example, to overlap the "unused" commons images on the map. I think that in the future commons files with geolocation but not used on any project could be display as well on the map;
- the use of the "house" icon for the places (towns, villages, neighbourhood) was confusing, it should be replaced with something else.
- I have started to contact "local" users, i.e. focused on regional and subregional topics on itWiki, on wikidata. I showed to them the wikishootme software and tried to understand if they were willing to play with it. This was a test to analyze their interest on the topic and their tendency, to cooperate from a local to a meta-wiki perspective. I have selected about ten users from at least 6 different Italian regions (Piedmont, Ligury, Tuscany, Umbria, Abruzzo, Sicily), approximately one half showed interest. They all agree that wikishootme was full of flase positives and false negatives but they were willing too cooperate to fix the situation. This means that even users with a specifically local focus are interested and a more elaborated tool specifically aimed to constantly improve the census of missing images will be well received.--Alexmar983 (talk) 22:12, 7 February 2016 (UTC)
- This type of analysis is part of the budget item "Analyze how each community face the problem and survey of all other existing image tools to better interface with them". I have already sampled the different cat system on local Wikipedias and I am expanding on the "sociological" aspects of the tool--Alexmar983 (talk) 02:36, 8 February 2016 (UTC)
- I have started with Incola the first wikimetrics analysis on commons users. Please take look here and here . By the time the tool will be ready a specific targeted message presenting all tools for images can be delivered to interested users.--Alexmar983 (talk) 12:25, 13 March 2016 (UTC)
- Found contacts to translate the interface in Modern Greek.
- Studied how to get data from Wikidata via SPARQL queries. We find out that is not possible to grab all the data, quickly (via query, not dump) and in a granular way. So, as we imagine from our previous attempts, we have choosen a compromise: not all places (timeout errors) but only buildings with a low granular level to reduce the number of query and their complexity.
- Studied and drafted code to load a big quantity of pins in the map. Lot of problems here. The solution found is to use a library written for Leaflet (the engine we choose to display the map) that make clusters. The UX is nice when all is loaded. Beta testers didn't feel confuse and everyone understand immediately how to use the interface. However we suffer of a very slow start and high usage of CPU while loading. This leads to some seconds to wait in a desktop experience (not so bad, and we added a loading bar to feel the app is moving) but to some alert message (about freezing) while using mobile. This problem is linear correlated with the dimensions of the dataset.
- Deploy on the server of the code prepared, enabling all the services needed (web server and cron jobs).
- I have interacted with others on github that open issues about the tool.
- Performance test & fixes.
- Final spreading of the tool.
New end dateEdit
30 August 2016
Our testing period takes longer than we expected.