Wikidata:Client editing input

From Wikidata
Jump to navigation Jump to search
Development plan Usability and usefulness Status updates Development input Contact the development team

This page is for gathering input on how to improve the editing of Wikidata's data on a client (like Wikipedia & co.) and make it more accessible. This is relevant to 3rd party sites, special purpose tools and Wikimedia projects although the focus will lie on the latter.

As part of my bachelor thesis I will concern myself with developing a concept to improve the editing of Wikidata's data on a client using a user centered design approach. I'd be happy to get any input and please feel free to add other questions! --Incabell (talk) 12:53, 30 September 2015 (UTC)[reply]

Current state and existing solutions[edit]

prototype from "Facilitating the use of Wikidata in Wikimedia projects with a user-centered design approach" by Charlene Kritschmar, March 2016
18:29:31 <Lydia_WMDE> in the coming quarter we'll publish the click-dummy for editing wikidata directly from wikipedia
18:31:34 <abian> Will the click-dummy have some kind of warnings when introducing constraint violations?
18:32:07 <Lydia_WMDE> abian: the dummy not - too early for it because we're still making sure the general concept is actually viable
This is probably related to the "clickable prototype" from the thesis. --Atlasowa (talk) 22:19, 9 January 2017 (UTC)[reply]
  • your input and signature

What are the major problems you see right now with editing on a client?[edit]

  • Wikipedia editors prefer not to edit and outsource their content on a different Wiki. --Incabell (talk) 12:53, 30 September 2015 (UTC)[reply]
    • The objective with respect to Wikipedia (which should be the entire focus of your project IMHO) should be to make the experience of editing a wikidata item associated with an article so seamless that people do not actually know that they are editing a wikidata item versus the article. The distinction between the systems should be removed from the user experience, as it is removed when they view the page. --I9606 (talk) 16:35, 30 September 2015 (UTC)[reply]
  • The entry barrier is too high at the moment due to a lack of a intuitive editing system in place. --Incabell (talk) 12:53, 30 September 2015 (UTC)[reply]
  • On the French WP the small "+" near any Wikidata value in the infobox ("p.addLinkback" in fr:Module:Wikidata) links directly to the statement, but once on Wikidata finding a value and giving a ref is a more painful process than on Wikipedia just changing the value of the infobox parameter. Oliv0 (talk) 14:29, 30 September 2015 (UTC)[reply]
  • vandalism on Wikidata will increase, if editing the data is easier. The community has to be prepared for fighting back. -- T.seppelt (talk) 14:32, 30 September 2015 (UTC)[reply]
  • Adding citations will be onerous. This is a general problem with Wikidata and Wikipedia, but this will allow editors to increase their editing leverage without citing. Raymond Ellis (talk) 14:53, 30 September 2015 (UTC)[reply]
  • {{#saldfjl:O3847}} - yeah well, what?? "the free encyclopedia that anyone can edit" -->No, you can't. - {{#property:Name of something}} does not help too much. its still some cryptic bubbling for IT-lovers. ...Sicherlich Post 08:50, 1 October 2015 (UTC)[reply]
  • If you find (how ever) your way from the Wikipedia-Artikel Warszawa to Q270 - then what? If I would like to use the coordinates then what am I supposed to do? clicking on it? - no. edit? - no. Well so what? how? ? - "the free encyclopedia that anyone can edit."...Sicherlich Post 08:50, 1 October 2015 (UTC)[reply]
  • In en-wiki, there is no way any ordinary editor would have the slightest clue when creating an article that wikidata even exists and even less than the slightest clue how to create it. I've been editing nine years, nothing to help me other than talk page chitchat and completely incomprehensible instructions. Wiki markup syntax is complex enough for non-programmers, to go to a different web site and input something is too steep a learning curve for me, just make a bot or something; just like File:Name calls upon an image from commons, wikipedia markup syntax needs to be structured so that certain things we must do anyway (infobox content, for example) is just automatically ported to wikidata. Montanabw (talk) 22:36, 1 October 2015 (UTC)[reply]
  • One of the issues there was with the ruwiki solution is that repeatedly it set date of births to the current date. Initially it wasn't clear how to report this to get it fixed (if an incorrect user input is involved, at no point a user should be able to set this through a specialized interface). --- Jura 11:03, 4 October 2015 (UTC)[reply]
  • Even for some of the current modules of "TheGame", it's hard to identify which one cause it and how/by whom to get this stopped and/or fixed. --- Jura 11:03, 4 October 2015 (UTC)[reply]
  • Editors lacks visual cues to where data comes from, and how they can navigate to that place. When they do end up on Wikidata they simply don't know how they can find the correct statement. There are to many steps with no or little explanation. A first quick fix could be to add an edit property function that can take several P-ids and create menu entries to those that exist in the repo, and create links to some way to create values of correct type unless they exist. Such a menu should make edit links/fields for all those properties that otherwise would be reported by the property parser function. In addition it should create edit links/fields for item statements where the target lacks label in the current language. Jeblad (talk) 20:18, 6 October 2015 (UTC)[reply]
  • Something very important is that we should be able to indicate, for example for editing an editions on an infobox, which properties could add datas on the infobox. Now on frwiki we have a link to Modify a statement use to show something, but we don't have a way to know which property to add to show a missing information to the infobox. A similar problem for wikitemplates is solved using templatedata, which the visual editor uses to suggests parameters to add to an infobox for example, but the result is not what we want :) author  TomT0m / talk page 12:34, 15 October 2015 (UTC)[reply]
  • your input and signature

Do you have any general or specific ideas on how editing should work?[edit]

  • We need to make sure that the data quality is not going to be degraded. For example when instead of adding a statement it gets overwritten. --Incabell (talk) 12:53, 30 September 2015 (UTC)[reply]
  • We need to make sure that we don't accidentally facilitate vandalism. --Incabell (talk) 12:53, 30 September 2015 (UTC)[reply]
    • To aid battling vandalism, edits from clients should be tagged (like the current tags “new editor removing statement” etc.). Ideally the tag would include the client (“remote edit via ruwiki”), but I’m not sure if the tag system permits that. —Galaktos (talk) 14:42, 30 September 2015 (UTC)[reply]
    • Having a better client could also mean that 'the good guys' who use it are better equipped to detect or combat vandalism, no? Considering the example that a client would edit it from Wikipedias (like ruwiki), those same people combating vandalism on Wikipedia right now would be able to combat it on Wikidata. An vandalism edit from ruwiki is likely to be spotted later by an editor on enwiki, for example. More exposure = more eyes --BurritoBazooka (talk) 18:32, 30 September 2015 (UTC)[reply]
  • Editing in a client should not attempt to resemble editing at the item level in wikidata itself as a default. Editors should be able to touch a property value and edit it directly without seeing the entire item unless they intentionally expand it.--I9606 (talk) 18:13, 2 October 2015 (UTC)[reply]
  • Anticipate developing this to include developing a Universal Translator eventually, and with many modes of input (keyboard, voice, brain wave headset) --Scott WorldUnivAndSch (talk) 20:23, 1 October 2015 (UTC)--Scott WorldUnivAndSch (talk) 20:23, 1 October 2015 (UTC)[reply]
  • Make it happen automatically, do it once, keep it simple. If wikidata is supposed to go first, then have a window in wikidata open up with a wizard or template as soon as anyone creates an article. Keep in mind that content editors are generally not computer programmers and vice-versa. Montanabw (talk) 22:38, 1 October 2015 (UTC)[reply]
  • When creating a new article in Wikipedia, a tool should search in Wikidata for an item about the same topic. If the search was successful one could directly add the sitelink to the item, otherwise one could create a new item with a instance of (P31) statement. --Pasleim (talk) 10:44, 2 October 2015 (UTC)[reply]
  • For entering specific data/properties/fields, a dedicated interface is almost always preferable to the general Wikidata GUI. If not, it's always possible to go to Wikidata instead. --- Jura 11:06, 4 October 2015 (UTC)[reply]
  • Instructions about the use of properties (and sometimes items) is currently included their descriptions. Sometimes these are needed to do editing. --- Jura 09:46, 6 October 2015 (UTC)[reply]
  • I've been wondering about this and it is not obvious how we should access the entry in the client, how we should edit the entry, and which one of the repo and client should override the other. If we edit a value in the client, then the edited value should become the shown entry at that client, but it should somehow be secondary on the repo. I would tend to say that all reference-less statements should be normal, even if they have Wikipedia as source. If the edited value has a real reference, then it can be hoisted on the repo to preferred. (This creates a problem, how can we create references on a client that can be exported to the repo?) If the rank is set manually, it should not be reset. No matter what we do at the repo with the edited value, it should still be shown at the client. It is their edited value and it is up to the users at the client what to do with it. I have some messy idea that if the new client value is accepted as the new preferred value value at the repo, then we can remove the override at the client and drop the value. It is a little like double accounting, placing two persons in the loop. One very coarse idea I've been toying with is to put the value at the client in a special named tagged element, to make it clear which element that would be removed during an automated editing phase. Note this has some serious problems, like how to add those tagged elements (VisualEditor is not a very popular solution for the moment). ;) Jeblad (talk) 19:19, 6 October 2015 (UTC)[reply]
  • Maybe this is a later development rather than an earlier one, but I find I'm inputting much of the same information into Wikidat that I already do in Wikipedia categories. If there would be some way to extract the implied data in Wikipedia categories that would be really useful and easy. For example, analysis of the English Wikipedia categories for Usain Bolt could easily extract the "instance of", his gender, occupation, place of birth, country of citizenship, two national honours, sport, and event participation. If we can reliably link up this already available data to interface with Wikidata then it encourages predictable, helpful editing while reducing the need for much knowledge of Wikidata's sometimes arcane property system (which is an essential barrier to editing in itself). Sillyfolkboy (talk) 01:17, 12 October 2015 (UTC)[reply]
  • One important principle : It should be crystal clear that we don't always want a change in the value, and that a sourced value should usually not be modified. Editing on Wikidata is made that people who is aware of Wikidatas principle, event if that is not always true, editing on client might be more accessible to newbies who are not really aware of what they are doing, so they might replace a value incorrectly, or delete instead of changing the rank or deprecate. More precisely (and this might be true also for Editing on Wikidata) : Usually a client editing should not replace the value but create a new claim. Maybe a hint popup should explain that to newbies ... author  TomT0m / talk page 09:35, 21 October 2015 (UTC)[reply]
  • When editing items as non-logged-in user in the mobile view, the preferred editing language should be automatically inferred, e.g. from the browser's preferred language setting or maybe the HTTP referer. Right now, it seems the algorithm seems to default to English, which is false for a variety of reasons. The question came up on de:Fragen zur Wikipedia, if anyone is interested. --Prüm (talk) 09:47, 11 December 2016 (UTC)[reply]
  • your input and signature

Other input[edit]

  • Probiert es mal mit dem Übersetzen der Frage in eine andere Sprache. Gerüchten zufolge soll es bei Wikidata Leute geben die eine andere Sprache als nur Englisch sprechen. Die könnten ggf. helfen. ...Sicherlich Post 08:57, 1 October 2015 (UTC)[reply]
  • Anleitungen oder Fehlermeldungen die weiterhelfen. Z.B. hierfür ...Sicherlich Post 09:00, 1 October 2015 (UTC)[reply]
  • There are various ways to link template to Wikidata (using {{#property}}, specific scribuntu module, etc) and there is no standard (and I'm not sure a standard is a good idea), but there should be indications for the editors what fields in template are linked to wikidata when editing. I think the first step here is to define a convention using TempldateData - phab:T69659 and then build the client side tools to use this general convention. Eran (talk) 07:22, 3 October 2015 (UTC)[reply]
  • The sooner it gets done, the better! It's useful to learn from the experience of those who are already doing this (Russian and a bit also Spanish Wikipedia). --Nemo 18:36, 3 October 2015 (UTC)[reply]
  • Some people have slow or erratic connections. The visual editor team should already be working on what is and is not possible with these and may have a list of things not to do. See if there is a way to learn from their work. Ideally your editor will integrate seamlessly into theirs so no one notices the join. Joe Filceolaire (talk) 16:01, 6 October 2015 (UTC)[reply]
  • We need some way to define the connection between properties/statements and TemplateData. To me this is more about integrating with the current template mechanisms on Wikipedia, than editing data in the repo from the client. Client editing starts with a reason to edit, and that is to get some data into a template, and most commonly into an infobox. I've done some experiments with a "SmartBox" that uses TemplateData, and one of the major problems are how to define bindings to data on the repo. It seems like we need some kind of Xpath/Sizzle-expression, and that such an expression should be part of the TemplateData. Perhaps I should fix my examples again, this is not easilly described in a few sentences. Jeblad (talk) 19:24, 6 October 2015 (UTC)[reply]
  • your input and signature
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Client_editing_input&oldid=2066444654"