Wikidata:UI redesign input/Archive

Development plan Usability and usefulness Status updates Development input Contact the development team

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

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)[reply]
  • 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)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Performance edit

Number of incoming links edit

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Moar language fallbacks! (bugzilla:36430?) Helder.wiki (talk) 16:19, 13 February 2014 (UTC)[reply]
  • 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)[reply]
    • +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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Workflow edit

Suggest missing statements edit

Paper cuts edit

Improvements to work without JavaScript edit

Improvements to sources edit

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)[reply]

Properties with list of values edit

Statement sorting options edit

Back to top links edit

Incorporate gadgets and userscripts edit

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)[reply]

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)[reply]

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)[reply]

Show documentation on property pages edit

  • We now have about 1100 property pages (latest World Athletics athlete 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)[reply]

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)[reply]

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)[reply]

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)[reply]
You can use alias, so you can type "en." for "English Wikipedia", or it. --ValterVB (talk) 08:33, 6 April 2014 (UTC)[reply]