Wikidata:UI redesign input

The development team is working on a redesign of the user interface of Wikidata. This page is for collecting input on the new design.

Development plan

Usability and usefulness

Status updates

Development input

Contact the development team

Previous input has been archived at Wikidata:UI redesign input/Archive and Wikidata:UI redesign input/Archive2.

Mockups

General goals we try to achieve:

• make the UI easier to scan and understand
• make the UI cleaner
• make the UI more friendly and inviting
• make it easier to find relevant information
• remove technical jargon
• rethink individual pieces we've added over the course of the past two years to see how they make sense in the more finished state we are in now

Comments

• Still a lot of whitespace that makes it look "hanging", somehow
• References take up an entire line per statement. Could that move to float right in the same row as the statement value? Could expand into its own row for editing.
• Qualifier properties have the same background as the property headers. That is consistent, but puts a lot of visual emphasis on the qualifiers.
• Just a thought: Qualifier statements could be "inline", so that two/three short ones are on the same line? Check out the Wikidata game for examples.
• The edit button/dropdown in the headings - is that always there? Might be less distracting if it only appears on hovering over the heading.
• The blue is too strong!

So much from me... --Magnus Manske (talk) 16:04, 24 June 2014 (UTC)

Thanks! re whitespace: Will hopefully be mitigated with more widgets for things like geocoordinate added. Emphasis on qualifiers is something we are trying to fix still but it is proving to be tricky :/ Ideas? Doing them inline could work but it feels to me that'll make it harder to scan. I have that issue with the Game sometimes. Button in the heading: Something we'll have to play with when implementing. I want it to be clear that it can be edited. --Lydia Pintscher (WMDE) (talk) 13:06, 27 June 2014 (UTC)

Feedback by Danwe

Updated version of my comments on 1st version:

Overall, I quite like Henning's UI redesign proposal. I especially like:

• A lot of whitespace that makes it look well structured, somehow. (Added)
• How property IDs have that blue background (consistently) and are used on top of the statement group rather than as in two columns as with the current UI.
• That the qualifiers values are not aligned. Gives more space to the text.
• The information on the right side. And in a mobile version where we have less space in width we just move it over to the left.
• The design of the item's head. Using an image there and the formatting. Would put a little more space between aliases and description though. Also, the description text could flow into/over the "action column" in this design in my opinion. Would use space a little better.
• Language links are pretty compact now. Good! Don't care too much about them anyhow when viewing an item.

Things I am not sure about:

• The design now uses link-buttons but also icons. E.g. "click to add one" instead of an icon". And then there is "Add statement" which is formatted in quite a different way again. The design also says goodbye to the idea of the action column it seems.
  Question: What's the reasoning behind those two points? (DONE in 2nd mocks. Done by removing link-buttons)
• Why does the edit view mock only show edit boxes for descriptions? What about labels and aliases? Also, I had hoped for something more intuitive here regarding editing the values in other languages on the same page. And, could perhaps use a little more paddings in the edit view, especially for column headings. (Added)

What I'd like to see improved:

• Jared's presentation of item reference labels merged into Hennings design. Displaying an image, label and ID and using a lot of space for that.
• Button for displaying all language links. Just showing a few on the right side is good I think. But what if I want to see all of them? (DONE in 2nd mocks Though, the link is formatted and placed inconsistently compared to the "show all links" one in the "related items" box.)
• Those x more value(s) link-buttons should be smaller and formatted like the x references ones. (Added)
• Things I'd like to see reversed since they've been better in the 1st mocks compared to 2nd one: (Added)
  • The darker blue in the 2nd mockups compared to the 1st ones. It looks too hard. Someone said the contrast wasn't big enough - might be true, but there are more elegant ways to increase contrast! E.g. put a shadow or a very thin darker outline around the white texts on the blue background.
  • The gray frames on the left of each statement. Adds more clarity to the design.
  • Language links to articles that are not featured articles now have an "empty" star. A little confusing and not necessary. Also, if there are more/other badges, having an "empty" one for each of them might be too much and will look too crowded.

--Danwe (talk) 17:13, 24 June 2014 (UTC)

Does this mean you can edit the label, the aliases and the description all in one edit? That would be a big improvement over the way it is now. Jane023 (talk) 17:18, 24 June 2014 (UTC)

We're trying to achieve that, yes. --Lydia Pintscher (WMDE) (talk) 13:12, 27 June 2014 (UTC)

I have no strong opinion on whether editing label, aliases and description at the same time is desirable or not. In any case though, they should only be shown for edit in the current language when being edited via an items head. Displaying them in several languages as in the mock is too much for the user in my opinion. Editing in other languages should still be achieved in a separate widget or in a more intuitive way than always putting it on the user's screen as soon as clicking edit on an item's head. --Danwe (talk) 09:27, 7 July 2014 (UTC)

Thanks! re showing the IDs of all linked items: That's something I will not ok. We have to combat information overflow. This would increase it considerably for little gain. The gray lines at the side of each statement have also been removed to reduce clutter. Fair enough on the empty stars. --Lydia Pintscher (WMDE) (talk) 13:12, 27 June 2014 (UTC)

For long statements the gray lines could still benefit clarity. One has to see. Ok, showing the IDs might be too much, still like the idea of showing the pictures together with the entity's label though. --Danwe (talk) 09:39, 7 July 2014 (UTC)

I think it is easier to grasp a UI where you do in-place editing and then save the whole thing. It will also be a lot faster than the very tight iterative edit-save sequence used now. Jeblad (talk) 05:37, 12 November 2014 (UTC)

Feedback by Filceolaire (talk)

I think all the comments I made on the previous version apply to this version too . :( Filceolaire (talk) 19:03, 24 June 2014 (UTC)

I'd like to comment on some of your comments, now I am not sure whether to do it here or in the Archive. Moving all the comments to an archive doesn't seem like the smartest idea to me anyhow since lots of them are still very valid :-/
A claim should be one line, not two. "<Property>:<Value> 0 refs [edit]". Clicking on 'edit' should reveal references and options to add qualifiers. - I think that's possible for very small statements, not if there are any qualifiers though. I'd like to see this formatting for small Statements with only one value within a statement group with only one statement though. E.g. gender:male in one line since there is enough space and it will be comprehensive enough this way. [Got to go, will comment more on your comments later.]
--Danwe (talk) 00:18, 25 June 2014 (UTC)

Agree, there are a lot of important stuff in the archives. Jeblad (talk) 05:38, 12 November 2014 (UTC)

Feedback by Nicereddy

I like the darker color being used here. It's a simple change, but makes everything look much better, I can't exactly nail down why. Other than that, most of my prior issues still exist. Gradients, serif fonts, and the dropdown arrow, among some other things.

I personally prefer Jared Zimmerman's mockup, as it has a more cohesive design. Less variation in colors, less clutter, and generally a better flow to the data. The thing about yours is that there's such a huge amount of chrome. While that's not a bad thing, the section headers, blocks of color, lines, gradients, and font sizes used to differentiate different sections of the interface makes everything seem broken up and disconnected. He uses font weights and shades of gray to portray the importance of each bit of the interface, and I think that's a better solution than various headers and things.

However, he didn't really tackle the editing bit of the interface, which is obviously fairly important to Wikidata. Your current design is in a grid pattern, and I'm not sure that's how we should be tackling it. Right now you're very limited in the space given to each editable item, which is my biggest concern. Personally, I think the "x-axis" (Language, label, Aliases, Description) should be removed. Instead, each language would be its own header (like "official website" is now) with "Label: Berlin" in the next line, "Aliases: Stadt Berlin" following it in the next line, etc. Each separate editable piece should be given its own line, since vertical space is often more abundant than horizontal space. Especially when you have columns, as you do now.

For a visual:

Deutsch (de)

• Label: Berlin

• Aliases: Stadt Berlin

• Description: Hauptstadt von Deutschland

English (en)

• Label: Berlin

• Aliases: Berlin, Germany

• Description: A place in Germany

--Nicereddy (talk) 22:34, 24 June 2014 (UTC)

Yes the editing part is the biggest issue. However there are also some fundamental issues with what we can actually do in Jared's design and in terms of understanding the purpose of individual pieces. About the header: Keep in mind that we have several hundred languages. People are already complaining now about the size of the "in other languages" box in the current interface. --Lydia Pintscher (WMDE) (talk) 13:17, 27 June 2014 (UTC)

@Lydia Pintscher (WMDE): Thanks for the response. As to the languages, I'm assuming you mean languages in the editable table? While I agree that with more than 200 languages it would get incredibly large incredibly quickly, I would think a single editor can only be fluent in, at most, five of those languages. Therefore, anything more than those five languages relevant to that specific user would be unnecessary. A simple settings menu to enable only a specific set of languages for the user would fix this issue, I'd think? And if someone wanted to edit a specific language not included in their defaults, a simple spinner could be implemented which would temporarily include the data from said language.

Of course, if my assumption is wrong then I've just made an entirely irrelevant comment, so please correct me if I'm mistaken. --Nicereddy (talk) 21:38, 27 June 2014 (UTC)

Comment by GZWDer

1. At the bottom of "Sitelinks in Wikipedia", a new "Add new sitelink" link should be shown at the right of "Show all".
2. If only several sitelinks are shown, this list of shown sitelinks should be based on geo-IP, previous choices and browser settings of the current user, like what have done at mw:Universal Language Selector/Design/Interlanguage links. This will replace the Main language first gadget.

--GZWDer (talk) 05:21, 25 June 2014 (UTC)

Yeah we're trying to see if we can use the same mechanism as the collapsed language links being developed for Wikipedia. A lot of thought has gone into that so we should reuse that if possible. --Lydia Pintscher (WMDE) (talk) 13:19, 27 June 2014 (UTC)

Feedback by Micru

Compact design

There is one point that has been asked from the very beginning: more compact statements (vertically). Neither this design, nor the old one addresses that. Yes, white space is good, but the mockup seems to be for a very small screen, can you imagine how this design looks in a 19 inches screen? For the eyes it will be like travelling through the interplanetary void. On the alternative mockup on the right you can see another way of sorting the statements as a grid. More compact, less scrolling, and suitable both for tablet and for pc screens. The gain it doesn't seem big, but if you consider a wide screen, the vertical space recovered is much more.

It is also hard to understand why so much prominence to the comments? There are not that many, and when there is one its relevance fades off with time. Better to show how many comments there are, and when was the last one, or at least show it only if it hasn't been displayed before, not always.

And the labels should be statements. Perhaps I should change my signature to "Labelia delenda est" :P --Micru (talk) 07:40, 25 June 2014 (UTC)

About the whitespace on big screens: Yeah what we could do is float the statements into two or more columns there for example. About the comments: My thinking is to only show it when there are current comments. --Lydia Pintscher (WMDE) (talk) 13:22, 27 June 2014 (UTC)

Consider using columns instead of floating, it gives a more predictable layout. Unfortunately columns give a layout the user does not expect, so it must be tested. You change your expectations through learning, but you can't do anything with whether it is possible to predict something. What is more important; expectations or predictability.

Note that columns tend to break inside items, which should be possible to stop according to W3 but it happens in most browsers anyhow, and that will make the layout less usable for the time being. Jeblad (talk) 05:28, 12 November 2014 (UTC)

Feedback by lbenedix

• the properties are highlighted, not the more important values
• the items in the Identifier box and Wikipedia link box should be aligned
• the contrast is very low in the "Berlin, Germany" line

Questions

Is there a good reason for:

• the blue boxes?
• the gradient in the boxes on the right?

• How do you count the number of discussion topics?
  • Why not integrating this number in the discussion tab on the top?
  • Are there so many discussions on wikidata items, that a so prominent discussion box is appropriate?

general notes

Maybe you should consider the the theory of data-ink-ratio: "A large share of ink on a graphic should present data-information, the ink changing as the data change. Data-ink is the non-erasable core of a graphic, the non-redundant ink arranged in response to variation in the numbers represented." http://www.infovis-wiki.net/index.php/Data-Ink_Ratio

Here are two blog posts you could have a look at:

• http://darkhorseanalytics.com/blog/clear-off-the-table/
• http://darkhorseanalytics.com/blog/data-looks-better-naked/

Already answered that on the mailing list :) --Lydia Pintscher (WMDE) (talk) 13:23, 27 June 2014 (UTC)

Please add links to the mailing list if there exist an archive. Jeblad (talk) 02:20, 23 November 2014 (UTC)

Supplementary feedback from Sweet kate

I share all of @lbenedix:'s questions and echo @Jeblad:'s request. I just waded through months of archived discussion around this UI redesign. As a web-designer-by-trade myself who can bring fresh eyes to the mock-ups above, I'm concerned that some of the choices don't reflect current UI best practices/sensibilities. For instance, I initially thought all the blue boxes were showing highlighted-in-the-browser text, like when you accidentally click and drag across an entire webpage. I had to stop and really look closely to realize it was an intentional design choice. That sort of un-clarity is a basic usability problem. Are @Jaredzimmerman (WMF): and @Lydia Pintscher (WMDE): working together on this? Can other voices chime in? Sweet kate (talk) 16:52, 26 November 2014 (UTC)

I share the concern that this looks a lot like accidental highlight. Jeblad (talk) 10:46, 27 November 2014 (UTC)

My thoughts

1. "Linked to by" in previous version would have been useful, "Related items" not so much...
2. grouping/seperation of values and qualifiers much cleaner and therefore easier to read
3. generally looks cleaner than previous version
4. I'd still like to see vertical alignment, makes it easier to get an overview and generally makes it easier to read this kind of data
5. I like that in the wikilinks the stars are always shown, gives a more consistent look
6. still far too much/too prominent highlighting that distracts from the content, especially for the qualifiers (I know that you want to bring some colour into the design, to make the site look less grey. And while I generally agree with this, I really don't think that this kind of highlighting is the right way to achieve this.)
7. not sure if discussion on the content page is needed/useful
8. don't know how well this multicoulumn design works on very small screens (mobile, small tablets, ...)
9. I do like that the values of a statement are all on seperate lines, nesting them horizontally, like others have suggested, could make it quite cluttered and harder to read
10. "filter statements by property" could come in handy on larger items

 – The preceding unsigned comment was added by 2A01:2A8:8401:D701:8876:7293:65C0:86B8 (talk • contribs).

Thanks! re your first point: Hmm it's the exact same thing only with a different heading that doesn't expose implementation details. re highlight: we're trying to improve that but not easy while staying consistent :/ On smaller screens we could just float the sidebar to the bottom. You're the first one who seems to have noticed the filter bar ;-) --Lydia Pintscher (WMDE) (talk) 13:26, 27 June 2014 (UTC)

Ok, since in this mockup only other capitals are shown in the "related items" section, I assumed that it was now showing "similar" items or something like that instead, my mistake... Agree to floating sidebar to bottom on small screens, also +1 for floating the statements into two or more columns (entire statements, not values or parts of statements!) on large screens like you suggested above to avoid excessive whitespace--2A01:2A8:8300:3A01:448E:1C8C:28F:59E5 14:04, 27 June 2014 (UTC)

Feedback by Holger1959

1. the "Commons (category)" widget should be in the same column like other Wikimedia projects; please also remember that category and gallery links are possible for Commons (we even have some items where a Commons gallery but no category exists; maybe better remove "category" from the widget's name?)
2. the "Label", "Aliases" and "Description" areas definitely need more space I think, because there are items with rather long names, and also languages with rather long words which don't allow easy line breaks; maybe make the area for the core information (label/aliases/description/image) full width, and only use two columns for the rest below?
3. what about the images, will you crop any given image to a square one by default (displaying only the centre part), or what will happen when portrait or landscape format images are used? i think most images for geographical items are of landscape format, and portrait format is more common eg. for people or buildings. Really square images are rare.
4. the "Discussions" widget should only give last edit date and maybe the username of the last comment, but no content excerpts nor headings (there are always cases where that would mean displaying unwanted offtopic or "angry stuff" on the item's page); personally i think such a widget is not really needed (we still have the standard discussion tab)
5. i would really like to see mockups for real examples with full statements (not only for a shortened "Berlin" item), let's take Lopado­temacho­selacho­galeo­kranio­leipsano­drim­hypo­trimmato­silphio­karabo­melito­katakechy­meno­kichl­epi­kossypho­phatto­perister­alektryon­opte­kephallio­kigklo­peleio­lagoio­siraio­baphe­tragano­pterygon (Q101) and Taumatawhakatangihangakōauauotamateapōkaiwhenuakitānatahu (Q791)

Holger1959 (talk) 19:42, 27 June 2014 (UTC)

+1 for point 4. Also important to note is that, in many (most?) cases, any given comment will not be in a language that the reader understands. --Yair rand (talk) 05:50, 3 July 2014 (UTC)

by Brya

The one good thing I notice about the design is that the values for the statements are below the statements (rather than besides the statements); this makes it unnecessary to scroll the screen setting until the field for values becomes visible.

What I am really missing is to have the links to the Wikipedia's (and other projects) at the extreme left (below the Tools). On all Wikimedia projects the iw-links are at the extreme left, so it would be really convenient to have them there at Wikidata also. - Brya (talk) 07:25, 29 June 2014 (UTC)

Feedback by Jklamo

• heading box - neutral, picture looks nice, but will decrease loading speed
• property boxes - neutral, should be more compact; collapsability - positive, should be also possible to collapse each ranks of values
• related items, discussion - negative, redundant, just waste of space
• identifiers - positive
• wikilinks - positive, hope that there will be place for "transliteration gadget"
• design - i do not care (as long as it alter functionality)

Overall good impression, hope that there will be as much customizability for users (placement of boxes) as possible. --Jklamo (talk) 12:01, 3 July 2014 (UTC)

Comments

• The sources statement should be red for "0 sources"
• "Start date" and "end date" or qualifiers in general should not be in blue boxes (too much color)
• The "preferred value" doesn't really stick out. Reasonator is currently doing a better job at this by making the preferred statement bold and larger print.
• For geographic objects the geographic coordinates should get a more prominent spot in the interface. -Tobias1984 (talk) 12:25, 4 July 2014 (UTC)

Comments on UI functions

I am not here to comment on the redesign as many interesting ideas have been raised. In my opinion, 3 ui need to be implemented just as Wikipedias do.

• One for reading the article : the new UI could then be use for this purpose and not update available. This has several advantages : only relevant information will be displayed and "update wigets will disappear" => the ui will then be lighter. Ids, links, sources should not appear here !
• One for modifications by unexperimented users : that is what I would used the current ui redesign for.
• One for advanced users : the one that is currently available that is not so ugly as we can imagine, which I would call "Raw UI"

This is just a suggestion and maybe too late to be implemented but that is how I would have seen a perfect Wikidata UI ( suitable for me ! !-). -Thieol (talk) 23:56, 6 July 2014 (UTC)

Comment on order and lists of works

Looks like a great improvent. A bit irritating is the order of the topics. "Related items" for examples should move to the bottom (like "see also" in enWP). Are there any specific plans or ideas how to present lists of works? (See: meta:Talk:Reasonator) --Kolja21 (talk) 02:04, 7 July 2014 (UTC)

"Related items" looks like crap. Of what kind is the relation? Lydia Pintscher is also related to Berlin, maybe she will be shown in the next mock-up? Andrea Shan (talk) 05:03, 18 November 2014 (UTC)

Please keep your feedback constructive. We managed this pretty well on Wikidata so far. What exactly would be shown there is still up for testing/discussion. I had in mind to show the most linked other items that link to this item. Other things are certainly possible. --Lydia Pintscher (WMDE) (talk) 11:44, 18 November 2014 (UTC)

"most linked other items that link to this item" - then show that. "Related items" does not reveal that. Label any content properly and link with definitions. E.g. currently "statements" is not linked, but could be linked to the definition in the glossary. Andrea Shan (talk) 07:28, 19 November 2014 (UTC)

The plan is for these boxes to be movable. Still figuring out how to handle this with caching and all. And I am definitely not set on having it at the top. It'll not be there in the beginning. Same for discussions. Can you elaborate on lists of work please? --Lydia Pintscher (WMDE) (talk) 11:44, 18 November 2014 (UTC)

Updates

I overheard that there were already some intermediate changes to the UI to reach some target... I had no idea work on this had started and I don't see anything, can someone point to a place where there are updates on what was done? A bugzilla tracking bug or other search would be fine.

I'd also like to understand what the target is: #Mockups are just mockups, aren't they? And they are 3 months old. A summary of the conclusions would be useful, either on this page or on Wikidata:Development plan. --Nemo 06:55, 6 October 2014 (UTC)

The changes were mostly "under the hood" preparing/refactoring the code architecture for the visual changes that are planned. Visible changes were the section-edit mode for sitelinks and for the term/language-box. I've now added the relevant bugs as blockers to the UI-Redesign bug. You can see a list of the tasks here. Tobias Gritschacher (WMDE) (talk) 08:35, 6 October 2014 (UTC)

Thank you! The tracking bug is very useful. --Nemo 22:04, 12 October 2014 (UTC)

Authority Control & ID Numbers

My concern is about the growing number of different ID`s. There are thousands of databases out there and the number of properties will be growing and growing. I took the time and printed the whole list Wikidata:List of properties/all in one table, I marked all the ID`s and found about 500 ID´s or authority controll numbers. The IDs are more than 30% of all the properties. I see also a problem in the evaulation process: Someone has to make a proposal, the proposal must be discussed among people who do their best, but do not realy know, what they talking about, and after some amout of time the property is created. I´dlike to handle the whole thing quite differently:

1. Give the whole bunch of Id´s and numbers an own section named as above
2. Change the handling of Id´s. In my opinion we do not need properties to handle the Id's. This makes the whole thing bulky and needs a lot of overhead.
3. Just take the item of the database and link it to the value and make sure there is also a possibility to link to Websites.
4. Database Id´s usualy don´t need qualifiers or sources, as all thats necessary is stored in the database item.
5. If a database has several different ID`s to offer, there must be a possibility to link the same item several times but give it different labels if necessary.
6. In order to maintain some control over the databases, they need their own item and som notability, lets say articles in two different languages about the databases.
7. Delete all the properties of ID`s after migrating it to storage with item and values.
8. Give it an automated order according to the alphabet.
9. Generate a warning is someone tries to store the same databases or values twice.
10. Allow every notable library cataloge to store its shelfnumbers to literary works. We soon will have millions of bot generated edition items we can link to as sources + we create a universal library.catalogue, something I´ve been dreaming all my live.
11. Let the ontology with all the properties, links, sources and qualifiers take place in a different section, not disturbed by ID´s.
12. Make the whole list collapsible for more overview (Opt in).
13. If there is no way around, just make one property named "Authority Control & ID Numbers" and link all the different databases as qualifiers to this one property with database item and ID as pair of item and values.

--Giftzwerg 88 (talk) 16:13, 25 October 2014 (UTC)

Imho there is a missunderstanding in the meaning of authority control. There is no 1:1 relation. Think for example of pseudonyms or companies that change their name or owner. #4: "Database Id´s usualy don´t need qualifiers or sources?" Of cause they do! Think of all the numbers imported by bot from VIAF: They are often outdated or false. So I need to know: 1) from what source the ID was taken and 2) when was the number looked up. Databases are not like tombstones: Numbers change, files getting renamed, merged or separated etc. --Kolja21 (talk) 17:05, 25 October 2014 (UTC)

I mean If you want to know the VIAF or GND ist is enough, when the link is provieded with the number. You can find what you need, without any additional sources or qualifiers. --Giftzwerg 88 (talk) 21:36, 25 October 2014 (UTC)

Yes, I know what you meant, and it's wrong :-) There is GND a) imported from VIAF on Oct. 2012, GND b) imported from VIAF on May 2014, GND c) imported from German Wikipedia on January 2014. GND a) is an other person, GND b) is a Tn (wrong type) and GND c) is outdated. That's why we need sources. Always! And of cause an authority file can change. So we need a date. --Kolja21 (talk) 10:04, 26 October 2014 (UTC)

In this case there would be problematic to checking constraints for certain databases. Many of these properties should have some pattern or should be unique. JAn Dudík (talk) 21:01, 26 October 2014 (UTC)

OK I understand. You have convinced me. My first point is to give all authority controll numbers an extra section. I´d like to seperate it from the "ontology" section wich creates the links between different items. This gives more overview.--Giftzwerg 88 (talk) 07:39, 27 October 2014 (UTC)

Wikidata messes up two central concepts. One is internal identifiers used by an entity itself, the other one is that a lot of linked data sites use a concept of URIs to identify resources. In a whole bunch of cases we take their URIs, which uses internal identifiers, rip them apart and make our own statements with implicit identification of the external site through use of special properties. This is not a viable long-term solution. We must start to use URIs like the rest of the semantic web. There are at least two different implementations, one is to have a URI-datatype, another is to have a external resource sitelink group. Both have their merits, but the last one could be somewhat simpler to implement. For the rest of the identifiers we can have an external identifier with a datatype string, and with a qualifier originating site or identifier type with a datatype item. They should use a reference linking to the actual definition of the string on the originating site. Together this will kill the whole identifier mess. Jeblad (talk) 05:21, 12 November 2014 (UTC)

User:Jeblad - It messes already up with "In other languages" - these are statements too, namely statements about names. Andrea Shan (talk) 20:22, 23 November 2014 (UTC)

Item graphic

Takes away a lot of space and says little about content. "Berlin" fits to its right, but what with the number one from Special:AllPages/?sortby=lengthOfLabel/descending? Andrea Shan (talk) 05:11, 18 November 2014 (UTC)

Maybe the header should be full width. --Lydia Pintscher (WMDE) (talk) 15:40, 18 November 2014 (UTC)

Top-down WMDE dev solution (ages, expensive) vs bottom-up crowdsourced generic solution (fast, cheap)

How about grouping the statements by the data type of each property?

It would be a very fast solution, and would already yield enormous benefits. Using the types from Special:ListDatatypes all statements would be in one of these groups:

• Commons media:
• Globe coordinate: (if present)
• Quantity: e.g. area, population
• String: IDs, names etc. All values used in some environments to identify an item.
• Time: Start/End, e.g. birth/death, established/disestablished
• URL:
• Item:
• Monolingual text:

Inside each group you can sort by occurrence (Wikidata:Database reports/Popular properties) - crowdsourced!. The "instance of" statement would be first in the "item" section. That is the natural way in Wikipedias already. "Berlin is a city."

You could have this very very fast. No need for months with mock-ups, no need for discussions where to place what. It is a generic solution. It works for any knowledge domain.

You could have that within one week probably. Really, really fast and hundreds of users would benefit when they edit. Instead of the current

In other languages | Statements | Wikipedia pages linked to this item | Wikinews pages linked to this item | Wikiquote pages linked to this item
Wikisource pages linked to this item | Wikivoyage pages linked to this item | Pages on other sites linked to this item

you could provide

Commons media | Globe coordinate | Quantity | String | Time | URL | Item | Monolingual text

which is a lot easier to read. Is there any major website offering long top navigation labels like WikiData currently does?

The proposal is not here to provide the best page layout for every knowledge domain. It is not even here to provide the best for any. But it is here, to improve all item pages NOW, with MINIMAL effort. Andrea Shan (talk) 06:21, 18 November 2014 (UTC)

@Andrea Shan: Why don't you just make your own database interface and see if other people like it? Reasonator is also an alternative interface. --Tobias1984 (talk) 10:26, 18 November 2014 (UTC)

Why don't you comment on your own wiki and see if other people read it? Andrea Shan (talk) 22:22, 18 November 2014 (UTC)

I don't know how you get the impression that the proposed solution by me (the community can order in any way they like) is top-down. --Lydia Pintscher (WMDE) (talk) 11:38, 18 November 2014 (UTC)

Because only few people in an inner circle decide about it. Who made the mock-up? People interested in Berlin. "Berlin" is a short label in many languages, so that made you put a image-graphic in front. Also, the Wikipedia links at the right, they display "Berlin" and it fits. But it won't fit with longer titles. Making such a design by hand is expensive. Make a design that works well on all kind of topics. Top label, all aliases, the names of the Wikipedia articles, the in-other-language statements are of type string. They are all names. Grouping by data type would bring all these strings into one section. Coordinates and quantities might be shorter in general, so for these sections one can reduce the white space. But I don't want to judge on that. The software can group the items by data type and look at the length of the statements, create a statistic for this, instead of thinking "Berlin is short, so all places where it appears can be tiny". A new version of my proposal for the top navigation:

Property statements by data type
Commons media (1) | Globe coordinate (1) | Quantity (14) | String (50) | Time (2) | URL (1) | Item (30) | Monolingual text (50)

For the Berlin mock-up it seems someone deemed "official website" to be important. How many discussions and decisions will you make for all the other 10 mio+ items? Of course, some statements will be placed before others, but let users navigate fast to what is of interest for them - each of them. Not only for those that win in discussions and make the decisions. Respect minorities. Create a good generic design and the result will be less biased towards what the control group is interested in. My proposal is a starting point for a generic solution. Within few days, you could have a tremendous improvement. Andrea Shan (talk) 22:22, 18 November 2014 (UTC)

Wikidata:Development plan#UI redesign

• Navigating [...] the website is fast - the grouping and the proposed top navigation does that
• information is ordered in an intuitive way - grouping drastically improves the current situation

Andrea Shan (talk) 22:32, 18 November 2014 (UTC)

Width of search box

Make it as width as the longest label needs to be displayed completely, when typing in the box. Andrea Shan (talk) 07:30, 19 November 2014 (UTC)

Some language can have extremely long labels, they are called agglomerative languages. It will not be possible to satisfy everyone because of this. Jeblad (talk) 02:15, 23 November 2014 (UTC)

That is news, that "agglomerative languages" have longer labels. Can you give an example? How about satisfying 100% of users for y% of searches, instead of x% of searches as currently, with y>X? For desktops the box could be 65em width, like the class wikibase-entityview currently has. Wait for an example by you to demonstrate that there is a label in any language that does not fit. The current implementation is horror. Andrea Shan (talk) 20:21, 23 November 2014 (UTC)

Order of elements in recent changes

As items are sorted by time, put the time in front. Time also has them same width for all items, thus the change would stop the current jumping of the position of the time information. The MediaWiki of LibreOffice does it better, see: https://wiki.documentfoundation.org/Special:RecentChanges Andrea Shan (talk) 20:26, 23 November 2014 (UTC)

i18n

Use ISO 8601 for dates, the MediaWiki of LibreOffice does it more international than Wikidata, see: https://wiki.documentfoundation.org/Special:RecentChanges Andrea Shan (talk) 20:27, 23 November 2014 (UTC)

You can edit the date format yourself under Special:Preferences. If you set no preferences, the date format is adapted to your language settings which is far better than ISO 8601. --Pasleim (talk) 08:58, 24 November 2014 (UTC)

I don't want to edit it myself. I want to see what other people see. "the date format is adapted to your language settings which is far better than ISO 8601" - maybe for you, not for me. I logged in to use English, I didn't decide to see European English. Last but no least - I thought the UI is not only there for logged-in users? Andrea Shan (talk) 07:17, 26 November 2014 (UTC)

You can change your language settings even if you're logged out. Why you want to see what other people see? The UI is not a fixed frame. There are different skins, dozend of languages, user preferences, individual css files... So the UI looks for everyone different, even for logged out users. --Pasleim (talk) 08:51, 26 November 2014 (UTC)

"Why you want to see what other people see?" - Let me clarify, I want to see what the majority of English language users sees. A user that comes to Wikidata and selects English as interface language, and does not change anything else. Why? I assume that's the most used interface, and I want to know how the UI feels to most users. Any problems they have etc. A user that tunes his UI and uses that one exclusively, may not have certain problems that first visitors have. Andrea Shan (talk) 07:20, 30 November 2014 (UTC)

Due to changes in the data model, this proposal is no longer acceptable. Please read m:Wikibase/DataModel and m:Wikibase/Notes/JSON. In the past it had been the practice to store dates in the Gregorian calendar; the Julian calendar could be chosen for input and display, in which case the software would convert Julian to Gregorian before storing, and convert Gregorian to Julian before displaying the date to the reader. But this didn't work out, and now the Julian or Gregorian date is stored and displayed. Since some of the dates that will be displayed will be Julian, they must not be displayed in ISO 8601 format, because that format is only for Gregorian dates (as is stated many times within the standard). Jc3s5h (talk) 12:59, 14 March 2015 (UTC)

Jc3s5h, never seen Julian dates in Special:RecentChanges etc. 77.179.112.1 09:12, 3 May 2018 (UTC)

The conversion from the Julian to the Gregorian calendar occurred from 1582 to 1923. My subjective impression is most of the recent changes are about association football players, so the Julian calendar wouldn't come up much in recent changes. Jc3s5h (talk) 13:16, 3 May 2018 (UTC)

Name statements

There are different kind of name statements,

• outside the area where properties of the property name space appear
  • Label
  • Alias
  • In other languages
    • Label
    • Alias
• inside the area where properties of the property name space appear
  • Property:P225 (STRING) taxon name
  • Property:P357 (STRING) title (string) title of a work (such as a book, a film or a website) original title //comment: "string" appears in the property label
  • Property:P513 (STRING) birth name (Deprecated) DEPRECATED--use P1477 instead
  • Property:P561 (STRING) NATO reporting name
  • Property:P734 (ITEM) surname
  • Property:P735 (ITEM) given name
  • Property:P742 (STRING) pseudonym
  • Property:P743 (STRING) short name
  • Property:P1353 (STRING) original spelling original spelling of a scientific name
  • Property:P1448 (MONOLINGUAL TEXT) official name official name of the subject
  • Property:P1449 (MONOLINGUAL TEXT) nickname the nickname of an entity
  • Property:P1476 (MONOLINGUAL TEXT) title (monolingual text) the title of a work (see also P357) //comment: "monolingual text" appears in the property label
  • Property:P1477 (MONOLINGUAL TEXT) birth name //comment: the second!
  • Property:P1559 (MONOLINGUAL TEXT) name in native language name of a person in their native language
  • and all the IDs (sometimes one can see IDs listed as Alias - indicating of no conceptual difference between the two in the real world [i.e. outside Wikimedia] )

While the properties in the second group are controlled by the property editors the ones in the first group are not. They are set by WMDE and cannot be accessed like regular properties. No qualifiers for Label or for Alias. Suggest to merge all into the regular property space. Andrea Shan (talk) 07:50, 30 November 2014 (UTC)

Concept inconsitency

The current interface and the proposed UIs has the sitelinks on the right side. But in all other wikimedia projects the sitelinks are in the sidebar on the left. So we have no consistency across the different projects.--Giftzwerg 88 (talk) 09:18, 23 March 2015 (UTC)

Tooltips

I'd like to see tooltips on pretty much everything. The interface should be self-documenting. For instance, when I hover over "[add]" for a reference. It should explain what a reference is and any top important things I should know before adding one. Similarly for all elements of the UI. Jason Quinn (talk) 12:49, 8 May 2015 (UTC)

TOC for quick access to sitelinks

I don't remember, is there a way to enable the TOC on items so that I can just click a link to jump to e.g. sitelinks? It's a bit tedious to scroll so much every time. Nemo 06:14, 15 August 2016 (UTC)

And to external identifiers. 77.179.112.1 09:08, 3 May 2018 (UTC)

True, same problem (when I wrote about a TOC, the identifiers were not a separate section yet). --Nemo 17:28, 7 May 2018 (UTC)

Sort external identifier statements

Sort the 1000+ external identifiers. Wikidata:Requests for comment/Sort identifier statements on items that are instances of human 77.179.112.1 09:07, 3 May 2018 (UTC)