Wikidata:UI redesign input

From Wikidata
Jump to: navigation, search

The development team is working on a redesign of the user interface of Wikidata. This page is for collecting input on what is working well and what is not working well in the initial user interface. This will then be taken as input for the redesign.

This is good in the initial user interface - please keep it[edit]

  • It is really great to have a link with the languages people know (Babel) this has to stay ... GerardM (talk) 15:34, 13 February 2014 (UTC)
    • I don't agree. It would be better to show all labels, although in a more compact form, and maybe collapsable.--Pere prlpz (talk) 11:31, 18 March 2014 (UTC)
  • I think the whole internationalization thing with language selection works very well already. The property and item selection works also good with the new search engine (neglecting minor bugs).  — Felix Reimann (talk) 15:43, 13 February 2014 (UTC)
  • On an item page, editing item name and description works very well. So is editing site links to other languages. --Amir E. Aharoni (talk) 16:10, 13 February 2014 (UTC)
  • I am happy that it is no longer necessary to switch between language interfaces for adding descriptions in several languages. Z. (talk) 12:09, 14 February 2014 (UTC)
  • Setting "no value" and "some value" is cool. Infovarius (talk) 21:11, 27 February 2014 (UTC)
  • Original data model and user interface was very good. Extending it (qualifiers, ranks, order buttons and etc.) made the interface less clear and decrease usability. These features brings some benefits. But from my perspective the benefits are less than usability degradation. — Ivan A. Krestinin (talk) 21:07, 13 March 2014 (UTC)

This is not good in the initial user interface - please change it[edit]

New Users[edit]

  • Wikidata is pretty not new user-friendly: something like Wikipedia:GettingStarted (Q15726977) must be created to prevent that; and a lot of users asked how to merge items in items' talk page, Project chat, Administrators' noticeboard, user talk page, and Wikidata talk:Main Page.--GZWDer (talk) 16:05, 7 March 2014 (UTC)
  • Hi! Wikidata lurker and n00b (fresh eyes) here. Here are a trio of my intial impressions related to the Main page:
    • Color scheming documentation page groupings. The Main page currently looks cluttered and text-heavy...and color-coordination could help! A redesign that more closely reflects the design of pages like Help:Contents would look clean and beautiful. Playing with this example, one could group documentation categories (such as "help" or "community portal") into one color scheme. For example, the Main page box for "help" could be blue (and all relating articles would have a blue article header/flag/...); the "community portal" box and its pages could have a green color scheme; and so on.
    • Simplify and merge (some of) the documentation of Help:Contents and Main page. Help:Contents was actually a better "front page" for me in my own experience getting oriented with this project. There is some link redundancy and definitely the possibility of simpler documentation.
    • Reduce link redundancy through ToC hierarchy. A more hierarchically-structured ToC might help to resolve some of this issue (I think...). For example, links for Community portal and Project chat appear on the same list. Upon visiting Community portal, it seemed to me that this was/should be the parent page for Project chat. Either removing a Project chat link from the front page or hiding/ranking it under Community portal might make that more obvious.
I hope this helps! Cheers! - Eekiv (talk) 08:13, 11 March 2014 (UTC)

Layout[edit]

  • Too much scrolling when viewing items with many values. Perhaps some parts (or all) could be collapsible/expandable? Danrok (talk) 14:51, 13 February 2014 (UTC)
    • +1. A step towards Reasonator would be great. (For example: birth/death date/place and the authority numbers listed together in a kind of infobox.) --Kolja21 (talk) 21:52, 14 February 2014 (UTC)
      • This is a good point. Reasonator has a very nice interface, and duplicating that appearance on-wiki would be awesome. Ajraddatz (Talk) 00:54, 18 February 2014 (UTC)
    • Yes, we need a design less based on (generously padded) boxes and more focused on compact tables. --Waldir (talk) 16:30, 16 March 2014 (UTC)
  • I am missing a default or user setting of a human readable layout (with pictures and maps visible when available in properties, with some headers/sections based on presence of groups of properties). Should also include an improved ordering of (groups) of properties Michiel1972 (talk) 15:35, 13 February 2014 (UTC)
    • Try Reasonator. Correct me if I'm wrong, but I don't think it's the purpose of Wikidata to provide a human readable interface. --Wylve (talk) 03:53, 14 February 2014 (UTC)
      • I am probably Reasonator's biggest fan but the edit interface is for people to use. They are human. Consequently the interface NEEDS to be a human readable interface. Thanks, GerardM (talk) 11:19, 14 February 2014 (UTC)
        • Agree with GerardM, if wikidata.org is editable, it is by definition meant for human consumption/interaction. This is not a mere dump of data to be consumed by some tool. --Waldir (talk) 16:32, 16 March 2014 (UTC)
  • Too much scrolling while viewing (make it more compact), too much clicking while editing (mainly while adding sources). Poor performance for larger items (slow editing). --Jklamo (talk) 16:44, 13 February 2014 (UTC)
    • +1 for compactness, and a smoother (less clicking) editing workflow. --Waldir (talk) 16:32, 16 March 2014 (UTC)
  • The current implementation of the beta feature "Typography refresh" suggests that the Wikimedia wikis are going to switch to a more narrow layout for content. If there is any chance that something like this is going to be publicly applied to Wikidata item pages, their layout has to work much better with reduced space. The current UI can't stand this, breaking many qualifiers and all sources into maaaanyyyyy extremly narrow lines. --YMS (talk) 16:49, 13 February 2014 (UTC)
  • On item pages with a lot of statements it's not fun to scroll for a long time to the sitelinks list. A button to hide the statements could be a solution to this. (From Yona Bendelac in the Hebrew Wikipedia.) --Amir E. Aharoni (talk) 19:37, 13 February 2014 (UTC)
  • The item pages are full of blank space. It could be compressed, mostly the statements section, but also the "In other languages"section. HenkvD (talk) 19:44, 13 February 2014 (UTC)
  • Make design more compact. I have 24" display and I have 5 languages in babel - and I see only first interlang link when there are no statements. I have measured height of single parts of designs (vector, standard font, standard size, Opera):
    • One-language label+description = 23 mm
    • One interlang link = 9 mm
    • Single statement without source = 38 mm
      • with collapsed source = 33 mm
      • with source and qualifier = 46 mm
    • Empty section with interlanglinks to S/VOY/COMMONS = 38 mm
So it seems to me that statements should be more compact (e.g. [Add] should be under name of property instead uned values), interlanglinks have fine size.
JAn Dudík (talk) 08:42, 14 February 2014 (UTC)
  • The width of the individual components should have better alignment or more compact. When there are qualifiers the qualifier value field is only one character wide, splitting each character in separate lines. — Finn Årup Nielsen (fnielsen) (talk) 10:45, 14 February 2014 (UTC)
  • There should be a search box in item page to search statements for a item, like who is the head of state of China, or what's the relation (property) between Li Keqiang and China, by inputing Pid/Qid/Label. This is different from querying: One can search it on-the-fly, no need for opening a new page.--GZWDer (talk) 04:08, 9 March 2014 (UTC)
  • It should be possible to set ranks of several values of claims in a property. e.g. set all claims of contains administrative territorial entity of USA except q547795 and q1811372 to preferred rank.--GZWDer (talk) 04:13, 9 March 2014 (UTC)

Performance[edit]

  • performance, performance, performance AND it takes up too much space. GerardM (talk) 15:33, 13 February 2014 (UTC)
  • The page loading should be more efficient. Items with a large number of statements take long time to load (at least with the JavaScript components I have enabled). — Finn Årup Nielsen (fnielsen) (talk) 10:44, 14 February 2014 (UTC)
  • It takes a ridiculously long time to load, especially on pages with lots of attributes (like the showcase items). Maybe there could be a faster way to load it? Jc86035 (talk) 14:55, 15 February 2014 (UTC)
  • Labels loading shouldn't wasting times when loading an item. see here as an example to load contents before all labels are loaded.--GZWDer (talk) 16:47, 15 February 2014 (UTC)
  • Per GerardM, performance is a major issue: the GUI relies too much on JavaScript IMHO; and also the claim view should be shrunk. --Ricordisamoa 19:52, 15 February 2014 (UTC)
  • Loading times! E.g. Q42 regularly times out my browser. /Lokal Profil (talk) 08:27, 17 February 2014 (UTC)
  • If I type Q### to a value box, the "save" button don't turn blue until labes of Q### is loaded. That's completely unnecessary.--GZWDer (talk) 16:01, 7 March 2014 (UTC)

Number of incoming links[edit]

  • Next to the label and the Q-code it would be good to show the number of incoming links (from other items). That would be helpful when deciding which direction to merge. While editing the number would be useful, because it shows how well connected an item already is. --Tobias1984 (talk) 15:39, 13 February 2014 (UTC)
    • +1 --Ainali (talk) 21:30, 13 February 2014 (UTC)
      • @Tobias1984, Ainali: I have created User:Bene*/usage.js for that some time ago. Add importScript( 'User:Bene*/usage.js' ); // [[User:Bene*/usage.js]] to your common.js page. -- Bene* talk 23:14, 13 February 2014 (UTC)
        • @Bene*: I might. But I think this should be put into the UI for everybody, not requiring to have a user script. At least it should be made as a default enabled gadget. --Ainali (talk) 18:13, 14 February 2014 (UTC)

Multi-language enhancements[edit]

  • In "Reasonator" we always show a label.. It helps understand what is going on so much better. The language fall back is by using the #Babel information. GerardM (talk) 15:46, 13 February 2014 (UTC)
  • There are many properties and items the names of which are not translated to my language. I couldn't find a convenient way to have a list of properties to translate. I am a heavy user (and developer) of the Translate extension, and I believe that something similar can be made for names of properties and items. --Amir E. Aharoni (talk) 16:10, 13 February 2014 (UTC)
  • Definitely there should be a bridge to use Extension:Translate with all labels and descriptions. Sometimes property labels or descriptions are changed beyond their original scope and it is hard to keep track of outdated translated labels.--Micru (talk) 21:57, 2 March 2014 (UTC)
  • Moar language fallbacks! (bugzilla:36430?) Helder.wiki (talk) 16:19, 13 February 2014 (UTC)
  • Multi-language support for labels, descriptions, aliases input. It's obviously totally unclear to many beginners, for which language their input fields are and how they can change it. This is resulting in masses of wrong-language input (Special:AbuseFilter/8 alone, which only covers the insertion of language names in those fields, is triggered every 30 minutes). Even if I know how to change the ULS language and how to control the language selection by babel boxes, it's not possible to see (let alone edit) labels/descriptions/aliases in all languages without the use of an external tool. There has to be a way to see and edit the complete content of a Wikidata item, and it has always to be clear which language I edit if I change something in a certain edit field. --YMS (talk) 16:31, 13 February 2014 (UTC)
    • +1. When I maintain the template items, I have to edit massively the labels to put "Template:X" instead of "Template:X/docs", for average 5 labels languages per items, for approximately 500 or 1000 items. I didn't do it, because it's to awful... --Nouill (talk) 13:51, 22 February 2014 (UTC)
  • Internationalization is using too much ways of indicating a language, like Universal Language Selector, Babel, and Assistant languages. See details at Help:Multilingual. HenkvD (talk) 19:44, 13 February 2014 (UTC)
  • The extension Label list should be replaced by onscreen lists like all other sections. Labels, descriptions and aliases should be editable that way. HenkvD (talk) 19:44, 13 February 2014 (UTC)
  • Could there please be something to suppress the "in other languages"-obstacle? Of the time I spend on Wikidata something like 5-10% is taken up by navigating around this dominant feature or by correcting the errors it causes. Also the time taken up in loading this onto the screen is not helpful. A method to suppress the TOC or any of the non-claim, non-Wikipedia sections would also help, although these are not nearly as aggressive. - Brya (talk) 18:35, 14 February 2014 (UTC)
  • The itemByTitle page is good, but it's not really enough. A Wikitext syntax to refer to an item or property in our languages instead of learning the property numbers when we write things, or a insert an entity or property in the Wikitext toolbar would be great. TomT0m (talk) 15:08, 15 February 2014 (UTC)

Workflow[edit]

  • You can directly add a source by clicking "add source" but you have to click twice to add a qualifier. Reducing the number of necessary clicks is important. Moreover, it would be great if adding a whole batch of information could be supported somehow. Now, whenever you want to add all the information, a single source typically contains, you hopefully know Widar or own a bot or you will click forever. Perhaps, properties could be minimized such that only the currently interesting properties show all claims, sources, and qualifiers and that this decision is kept also for other items.  — Felix Reimann (talk) 15:55, 13 February 2014 (UTC)
  • Once a claim have been created, say with references, sources amd all, we can't correct a mistake on the property value without creating a new claim. For example if we used the wrong beginnig time property, and there is several of them, or change intance of to subclass of. TomT0m (talk) 13:29, 15 February 2014 (UTC)
  • It should be possible to create a new item without a label; copy/paste a statement; add qualifier when adding statement; set edit summary; change claims' property; search if there's some property; remove all statements of one property in one item; search keywords containing punctuation; create items from the property value input box. all are in Wikidata:Paper_cuts.--GZWDer (talk) 16:47, 15 February 2014 (UTC)
  • To change a statement from “Q1: P1 => Q2” to “Q1: P2 => Q2” (i.e. change only the property but leave the referenced item), one currently has to remove “P1 => Q2” and then add “P2 => Q2” as a new statement. It would be great if this could be done in a single step. --mxmerz talk 04:40, 16 February 2014 (UTC)
    +1. Meets this frequently. Infovarius (talk) 12:13, 22 February 2014 (UTC)
  • Minor but frustrating : we cannot change the globe value of a coordinate statement through the UI. --Zolo (talk) 17:31, 15 February 2014 (UTC)
  • When a user adds date retrieved (P813) as a statement the default should be today’s date. It is so annoying to enter that. --Tobias1984 (talk) 10:13, 20 February 2014 (UTC)
    @Tobias1984: Yes, but it should be optional. Sometimes are we using downloaded material, and then at least I prefer to use the date of the download. -- Lavallen (talk) 12:15, 21 February 2014 (UTC)
  • I have a number of things but they are all in WD:Paper cuts - display and edit reverse properties, copy/paste source statements in one click, show qualifiers when adding a new statement, etc. Filceolaire (talk) 18:03, 24 February 2014 (UTC)
  • Possibility to change edit summary (not only when reverting). Infovarius (talk) 21:11, 27 February 2014 (UTC)
  • Notorious "{{source}}" :) It should be possible to challenge (without changing) at least claims. Infovarius (talk) 21:11, 27 February 2014 (UTC)
  • Internal possibility to move sitelinks and claims (with qualifiers) to other item. Infovarius (talk) 03:02, 28 February 2014 (UTC)

Suggest missing statements[edit]

  • I think suggestions for missing statements would be useful, maybe based on instance of (P31)? For example, instance of (P31) book (Q571) suggests there should also be P50, P98, P357, P364,… As a new user, I find it very difficult to find out about how to tag things, what properties are there, etc. (The OSM iD-Editor [1] is very good at that, btw.) --mxmerz talk 16:16, 13 February 2014 (UTC)
    • +1 --Ainali (talk) 21:30, 13 February 2014 (UTC)
      • +1. I still don't use properties because of that. --Nouill (talk) 13:21, 22 February 2014 (UTC)

Paper cuts[edit]

Improvements to work without JavaScript[edit]

  • I am often without JavaScript, so I would appreciate some improvements of this interface. For example possibility to add properties. Also removing links doesn't work for me, only replacing and adding do. Matěj Suchánek (talk) 17:48, 13 February 2014 (UTC)

Improvements to sources[edit]

  • Add complex source: can be useful add a copy/paste of the source. --ValterVB (talk) 18:01, 13 February 2014 (UTC)
    A drag and dropable recap of the sources used in other claims of the item would be nice :)
    +1. A copy/paste mechanism for sources is essential. Pichpich (talk) 00:10, 14 February 2014 (UTC)

Launch item creation from suggestion list[edit]

  • Facitities to create new item / new source item with a couple of statements when needed, it's a pretty common use case when adding statements, with the ability to use the newly created item immediatly (I mean something like "new item" if the suggestion list is empty for example). TomT0m (talk) 18:41, 13 February 2014 (UTC)

Properties with list of values[edit]

Statement sorting options[edit]

  • It's unclear what is the order of the statements. Seems random. There could be an order of importance, or alphabet or a personal customization. (From Yona Bendelac in the Hebrew Wikipedia.) --Amir E. Aharoni (talk) 19:39, 13 February 2014 (UTC)
    • +1: Ordering for presentation could be determined by "instance of" (P31) or "subclass". When a claim has been set for this, the item pointed to could have an ordered list of properties of relevance to the "instances"/"subclasses". So if we know, that Douglas Adams is an author, the properties for genre, used language and works should be displayed in that order. Furhter authors are human, having a surname, gender/sex, date of birth etc. Claims not specified from instance or subclass should be shown last. Maybe expected but yet empty properties should be displayed to logged in users. Poul G (talk) 08:48, 17 February 2014 (UTC)
  • Statements should be sortable. See my proposal at Wikidata:Project chat/Archive/2013/03#Order of "statements" and duplicates. HenkvD (talk) 19:44, 13 February 2014 (UTC)

Back to top links[edit]

  • Link [back to top] in every section . JAn Dudík (talk) 08:42, 14 February 2014 (UTC)

Incorporate gadgets and userscripts[edit]

  • There are many useful gadgets and userscripts (usage, merge, preview...). What about make some of them standard part of UI? JAn Dudík (talk) 08:44, 14 February 2014 (UTC)
  • Magnus Manske's valuable missing-props tool is sometimes broken. Perhaps because of changes in the Wikidata interface? A better integration with Manske's tool would be nice. — Finn Årup Nielsen (fnielsen) (talk) 10:44, 14 February 2014 (UTC)

Nomenclature[edit]

  • I think that "Wiki" should never be used as an abbreviation for Wikipedia or Wikimedia. Still, I see expressions like "dewiki" or even "commonswiki". Why not de.wp and commons? Or even the name of the language; in the section "Wikipedia pages linked to this item" it is clear anyway that a Wikipedia language version is meant. Z. (talk) 12:34, 14 February 2014 (UTC)

Mobile improvements[edit]

  • I mostly edit from Mobile. Wikidata can be easily editable for mobile users and in comparison to Wikipedia, wikidata is quite easy editing project. Why we should not include large number of potential mobile/tablet editors? So can we make easy interface for mobile editors too? And please collapse long list of language links. Just show the babel box languages. -Nizil Shah (talk) 16:13, 16 February 2014 (UTC)

Wikipedia redirects[edit]

  • An automatic way for getting to the underlying wikipedia entries would be desirable. E.g. wikidata.org/wiki/Q42/w:en would take you to the corresponding en.wp article (if existing). With this we could get external partners to switch their links from wikipedia to wikidata. /Lokal Profil (talk) 08:27, 17 February 2014 (UTC)

Show documentation on property pages[edit]

  • We now have about 1100 property pages (latest IAAF ID (P1146)). The pages glue Wikidata together. I don't know how many views the properties get, but what the viewer gets is not really a lot of information. Some time ago I added an option to the software to be able to add some more information (see OMIM ID (P492) and Property talk:P492/footer for an example, cc @Emw:) but I never came around to actually start using it. We should go through a design process to define the users of these pages, what the goals of these pages are, what kind of information we want to include etc. Multichill (talk) 13:14, 17 February 2014 (UTC)

Group statements according to property metadata[edit]

Provided that some day property pages will host statements, that information could provide a hint about how to group statements on item pages and automate the sorting. For instance the properties "date of birth", "sex", etc could have a statement "subclass of:intrapersonal property", and on any item they would be grouped as such.--Micru (talk) 22:26, 2 March 2014 (UTC)

Authority control IDs as (external) sitelinks[edit]

Authority control properties take a lot of page space and they are not that important to consider them properties. If possible it would be great to have a system to consider these IDs as sitelinks. Instead of "creating a property" we would need a way to whitelist a site and enter the URL formatter (now done by MediaWiki:Gadget-AuthorityControl.js).--Micru (talk) 21:27, 9 March 2014 (UTC)

Improving repetitive sourcing[edit]

  • We need an improved interface for sourcing, specifically with suggesting. When you input "Imported from", the second input box should be more likely to suggest things like "English Wikipedia", "Russian Wikipedia", etc. This would facilitate sourcing of items which a much faster pace, currently you have to type "English Wi" for it to suggest the right page, and that gets repetitive very quickly. --Nicereddy (talk) 05:57, 6 April 2014 (UTC)
You can use alias, so you can type "en." for "English Wikipedia", or it. --ValterVB (talk) 08:33, 6 April 2014 (UTC)