Hey Romain :)
Wow. That is a long list. Thanks a lot for taking the time to write it
all up. Find my comments below.
Cheers
Lydia
On Thu, Apr 2, 2015 at 3:41 PM, Romaine Wiki <romaine.wiki(a)gmail.com> wrote:
Hi Lydia & all,
As promised before, I have collected a list of suggestions of what I noticed
myself or others have noticed to be unhandy or something that would be great
to be improved. The suggestions and ideas have not been searched for in
Phabricator (as that is still difficult), so it is possible that some of the
points are already in Phabricator or is already worked on.
The suggestions are not sorted by importance, but tried to be grouped by
subject/area.
I have tried to describe them as clear as possible, some with examples.
Maybe some of them can be connected with Phabricator tasks.
I hope these ideas will help improve Wikidata to make the use of it better
and easier.
Thanks!
Romaine
A. General
A1. loading: large item pages with much statements and sitelinks are too
heavy to load. For example items about countries, like Q30 (USA), make my
(up-to-date) browser freeze (not responding) before it is loaded.
We've considerably improved loading times over the past 5 months. With
the next deployment it should again improve some more. We'll keep
pushing on this but it has taken a bit less priority after the
improvements we've made until now.
A2. missing labels: show on more places that the shown
label of an item is
not in the language of the user, but that the English version of the page is
shown. (In the statements section it is shown that the label is not
available in the language of the user, but is in English. Such is
recommended to do on more places.) Like in the contributions page, there it
is not shown that the shown label is in English instead of the language of
the user.
Noted. Adrian was working on this recently. Not finished yet though.
A3. overview: make the overview of pages more compact
(read: less white
space, resulting in less annoying scrolling and having a full overview of
all statements at once), or have a gadget/skin who can do that. If 10
statements have been added to a page, too much scrolling is needed because
most of the page is empty with white.
The labels & descriptions section has been made more compact recently.
However, full labels of statements have to be shown in future as well.
We'll be working on this as part of the redesign of the statements
section. One big piece will be separating out the identifiers as
discussed over the last days on this list.
A4. search: make it easier to search in the fields of
other languages,
especially when no label and/or description is given to an item, but also in
other cases. (Regularly a subject is more known by the name in the other
language than in the language set for the user.)
https://phabricator.wikimedia.org/T76150 should get us a long way here.
A5. search: make it possible to switch of searching in
statements section
(or something like that), because searching for example for "Gemini" gives
too much noise. Each page that has as statement something with (in this
example) Gemini, pops up in the search and makes it difficult to find the
right item.
Ok.
A6. search: make it possible to easily search for
where a specific property
with a specific Q or input is used. Like filling in P717:032 or P131:Q3150.
That'd be queries we are working on.
A7. tool request: tool to give an overview (table) of
all items with a
certain property (or Q, or label, etc.), and in a second column being able
to set to show a specific statement (if added) to each of the rows. Example:
municipalities in Brazil (Q3184121). In the fist column all pages with
P31:Q3184121 (instance of: municipality of Brazil). In the second column
being able to set P17 (country). A third column being able to set P131
(located in the administrative territorial entity).
It should be possible to sort the overview (table) by column, so that it is
possible to group all municipalities by state (and if none added empty, so
these missing ones can be fixed).
That might already be possible with one of Magnus tools? Maybe someone
else knows.
It should also be possible to import data from an
external source to match
the items on Wikidata with the external source (and to see where the
differences are).
Example: it would be great to be able to match the municipality names of
Brazil with data from an external source. Like for example population
numbers, height of the town, km², ID code, and so on.
That is what a team of students is working on right now: checks
against 3rd party databases.
A8. tool request: having a list of items with
coordinates but no country
added, and a tool that gives a suggestion based on the coordinates in which
country this subject is situated, a map of the coordinate on the country and
buttons to confirm/reject the country. (Likewise WikiData Game)
Ok. Probably not going to be done by the dev team but maybe someone
else wants to pick it up :)
B. Labels/descriptions section
B1. labels in other languages: make it possible (again) to see the full
label in other languages, instead of only a part ending with ... .
Especially with long labels we should not press edit and do something clumsy
to be able to read the full label
Example: less than half of the label is visible:
https://www.wikidata.org/wiki/Q18032311?uselang=de
Or:
https://www.wikidata.org/wiki/Q18032986
Yes. Should get better with next deployment.
B2. missing labels/descriptions: make it possible to
have one click in an
empty field ("No label defined yet" or "No description defined yet")
to edit
that field (and making that section full edibale), without having to press [
edit ] on top first.
Ok.
B3. confusion: I still keep having that I click in the
title field to add a
title to an item in my language. (Maybe something so solve in combination
with B2.)
Noted. I realize there is still some usability issue there.
B4. other languages: maker it easier to change fields
for other languages
which are not set in my preferences. Maybe this can be done by a second
collapsible box, so that "In more languages" shows the languages a user has
set in his preferences, and in the collapsible part of "All languages" (new
part) all other languages can be changed. (instead of not so handy label
lister)
I think this is covered by
https://phabricator.wikimedia.org/T92759
B5. auto adding: make it possible to add the name of
the person or the
scientific name of species to all of those languages with the same
alphabet/script.
Example:
https://www.wikidata.org/wiki/Q7298502 -> The name of this genus is
for many languages the same and results in the same label for all of these
languages.
Ok. I am undecided if this should be built into Wikibase or a gadget.
I am leaning towards the latter.
C. Statements section
C1. order: make it possible to set a certain order of how statements are
shown.
Example: someone who adds often Commons categories if those are missing,
that that user can set that Commons is shown first on every item. (And
second Commons gallery, third ..., etc.) Having to search for a statement
that varies on what position it is shown is really annoying after some
items.
That's a big one to tackle. There are a lot of open questions that we
will need to tackle. I am hesitant to make this user-dependent. That'd
imho be better done in a gadget. But I do want us to make pages more
easily scannable and so on. Separating out identifiers will help here
but there's more we can do. We just have to find a way to do it
without compromising some of the other core principles of Wikidata
like the software not knowing about classes.
C2. order: make it possible to alphabetize the order
of the statements (like
a wikitable).
Hmmm. Is alphabetical really a useful sort order for statements? If
you know the labels by heart it can help obviously but for most people
it probably wouldn't be too helpful? My feeling is we're serving
everyone better with a more useful ordering.
C3. duplicate: give a notice with selecting the right
property, when a
certain property is already used on that item.
That's a good idea.
C4. suggester: if no statements have been added, the
suggester should
suggest P31 (instance of) and P373 (Commons category) as those two are
(almost?) always needed or possible and are generic.
I think we've also fixed this one for the next deployment.
C5. suggester: if I select a certain property as
statement, and I start
typing the first character(s) of the name of the subject, the suggester
should actually suggest something that matches with the property. This is
especially wanted with the use of P17 (country).
Example: if I want to add the statement that a certain subject is located in
country (P17) Albania, and I type an A, the suggester should give me first
actual names of countries that start with an A instead of starting with A
(letter of the alphabet), ampere, etc. If other suggestions are given when
no (known) country names begin with the characters typed in the field it is
fine, but please start first with actual names of countries that begin with
the A, etc.
We should have something like that indeed. It'll require quite some
expansion on the work the students team did last year I believe.
C6. suggester: better suggestions requested. Example:
when I have added as
statement P31:Q62832 (instance of: observatory), the next suggestion for a
property should be P717 (Minor Planet Center observatory code).
That should become better automatically as more statements are added
to Wikidata.
C7. feature/gadget request: having one or more buttons
on a page to repeat
the one of the last 5 actions I have done on another page, like adding [
country: US ], or just [ country: ]. This would be especially handy for
statements, but maybe elsewhere too.
That should indeed be a gadget I believe.
C8. character sensitive: make characters not sensitive
for diacritics,
ligatures, dashes (-), etc. Maybe this suggestion does not count for some
other languages, but in Dutch the a and the ã (as example, also ä á à â etc)
are considered to be the same character. For many words it is not always
clear if it is written with or without diacritic. For example: is it Sao
Paulo or São Paulo in Dutch? Also with or without a dash, example: Sint
Maarten or Sint-Maarten. The second one (with -) is how we normally write it
but the island name is without - is the official name. This issue concerns
thousands of pages, but if we type it with or without a
diacritic/ligature/dash/etc while it should be with it, or the other way
round, the suggester does not suggest it.
Makes sense yeah.
C9. missing statements: give a notice on items which
statements are missing.
On the talk pages of properties (example P717) it is stated with what
statements a property must be combined. If on an item a notice is shown or
invitation is given to add the missing statements, it would make it easier
to have more items more complete.
After we've overhauled the statement section we could for example add
a section at the bottom showing the top 3 suggestions that you already
get when clicking edit. This would make it more visible.
C10. quick adding: have a tool/pop-up/etc to be able
to add quickly the
country to an item based on a suggestion.
That'd go into a gadget.
D. Sitelinks section
D1. language codes: if someone adds a language code in the field to add a
new sitelink to an item, please interpret this actual as a language code.
Users are used to use the language code and then add the sitelink.
The language code is more common for many users: it is used in the url of
the wiki, it is used with local interwikis, users have set in their
preferences to show the language code only, have preferences to show the In
other languages section on Wikipedia in their own language, and more. Users
are used to use the language code, and this works also fast. Also the name
of the language a language code is belonging to, differs for each language.
Users often only add the language code and then press tab to go to the next
field, but then get the wrong language.
Examples:
If you add "es" for Spanish to add a page on a Spanish language wiki,
however the language suggester gives first the suggestion "Esperanto" (eo)
and not "Spanish" (es). (Also español is normally alphabetized before
Esperanto!)
If you add "ro" for Romanian to add a page on a Romanian language wiki,
however the language suggester gives first the suggestion "Romani" (rmy) and
not "Romanian" (ro).
If you add "ru" for Russian to add a page on a Russian language wiki,
however the language suggester gives first the suggestion "Runa Simi" (qu),
second "rumantsch" (rm) and not "Russian" (ru).
Thanks. Will look into it.
D2. language suggester localisation: have the language
suggester using the
language a user has set in his own preferences. Many users are multilingual,
but not everywhere in the world people speak/write in English well.
I'll have to look into it more. The issue here is that language !=
site. For example we have Commons, simple and Wikidata in there.
D3. adding new sitelink: on the Dutch Wikipedia
multiple times various users
have indicated that they find themselves unable to add a new sitelink when
they wrote an article, as they experience this section too difficult to use.
Even while multiple other users have helped and explained this to them.
Maybe this is because 1. users need to squeeze in a code and 2. the field to
add the actual pagename is too few remarkable, users do not see where to add
the sitelink..
That's not good. I will investigate more.
D4. faster saving: make saving faster, long list of
interwikis slow down
adding an interwiki very much. Now it seems the software checks if any field
has been changed, every row. Saving can maybe go faster when only those
fields are checked where the cursor has been. This is also something that
consumes much time in the labels and descriptions section if someone has 3+
languages set in his preferences.
(In the previous version of the labels and descriptions section the alias
fields coloured white when the cursor was put in that field.)
Making that faster is on my list but other things take priority
(statement section redesign, queries, unit support, better watchlist
integration).
D5. easier Commons selection: make it easier to add a
new Commons sitelink
to the section Other sites.
I assume the issue is that one needs to know that Commons is an
option. Will look into it more. Maybe for this section suggestions can
work.
E. Outside Wikidata
E1. Commons: show on Commons somewhere when a category, gallery page,
institution page, template, file etc is used in a statement on Wikidata. If
a page is renamed or deleted, this must be changed on Wikidata as well, but
noticing where a page is used is not easy.
If an image is linked in a statement on Wikidata, on the image page this is
shown. Somehow this should also be implemented for categories, gallery
pages, institution pages, templates, and others.
This should be added to pages like Special:WhatLinksHere, Special:MovePage,
Special:GlobalUsage
Makes sense. I think this is something best tracked by a bot at this point.
E2. Wikipedia/other wikis: develop an extension, that
communities can
enable, that shows on the bottom of articles, in the style of the category
box, an automatic box with all the identifiers used for authority control to
replace templates like
https://www.wikidata.org/wiki/Q5153934.
Sounds like a nice project for a hackathon :)
Thanks again for taking the time to write all this down.
Cheers
Lydia
--
Lydia Pintscher -
http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.