Wikidata:UI redesign input/Archive2

UI Screenshots

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

General Comments

Seems to designed by fat screens. So some explanations about your decisions could help. --Succu (talk) 20:10, 16 June 2014 (UTC)[reply]

See above now :) --Lydia Pintscher (WMDE) (talk) 16:50, 18 June 2014 (UTC)[reply]

Current UI needs too much scrolling. This concept makes multiple columns, but place covered by single statement is much more huge than old, so there is no scrolling reduction.
Reducing langlinks to collapsible table is good idea, if there is possibility to default uncollapse (by gadget)
Some "prominent" statements like P31 should be mentioned on the top of the page (as is P18)
Group of identifiers is good idea, but they should be in the same place as statements too.

JAn Dudík (talk) 21:02, 16 June 2014 (UTC)[reply]

re. point 3; There is no easy definition of these properties which can be easily implemented into Wikibase. There is an ordering feature which has been around for most than 2 months which allows users to do this. John F. Lewis (talk) 15:55, 18 June 2014 (UTC)[reply]

Jep what John said. --Lydia Pintscher (WMDE) (talk) 16:50, 18 June 2014 (UTC)[reply]

First: What is the goal to be achieved by this redesign? (could help to understand why you do things the way you do them, and probably also to get some more useful input) On a first look, I have to say, that the current design has a cleaner feel to it. All the highlighting seems to rather distract from the actual content. Also I dislike, that the values of the qualifiers are not aligned, same goes for the values in the identifiers and wikipedia boxes. I do like the grouping of common similar or related statements (like identifiers). Also the "linked to by" box could be useful. 2A01:2A8:8100:7A01:D54F:C1E:9570:1CA8 21:20, 16 June 2014 (UTC)[reply]

See above now :) Wrt cleaner: There are still things we need to polish clearly. Which is why we're publishing it now to get all of the feedback :P --Lydia Pintscher (WMDE) (talk) 16:50, 18 June 2014 (UTC)[reply]

Can you tell us your design decisions?
Here my comments:
comments on the redesign proposal of wikidata ui

--Lbenedix (talk) 08:29, 17 June 2014 (UTC)[reply]

Thanks for the comments. They're useful. --Lydia Pintscher (WMDE) (talk) 16:51, 18 June 2014 (UTC)[reply]

I agree with those comments, except, I like that things are not aligned! Usually I am a fan of alignment but here it looks good and clear without and it benefits the purpose of using space as much as possible. With that in mind, I also don't think that the fav stars have to go behind the text necessarily. --Danwe (talk) 08:01, 21 June 2014 (UTC)[reply]

On general goals: I'm not sure what the implications of the last two are, but I don't particularly like the first 4. All I want, aside from performance, is an interface making it fast and easy to reach the editing features. I wish I could edit Wikidata entries on Wikidata itself, not only with external tools. It should be clear that any other goal, when in contrast with this, must be put aside. --Nemo 15:47, 21 June 2014 (UTC)[reply]

Aspects

Colour

I don't like that pale greenish colour, that's a personal opionion though. Also it emphasizes headers which is not a great thing. I don't see a reason for this colourful boxes. Lazowik (talk) 20:18, 16 June 2014 (UTC)[reply]

Is it possible to apply different colours one for properties, one for quantifiers and one for remaining header bar? When the UI becomes more powerful, this will be helpful for locating parts to edit and allow users to understand any design immediately. 金亦天 (talk) 01:21, 17 June 2014 (UTC)[reply]

We could but it'd make the UI look really really busy and unclean. We'll have to think more about how to solve this. --Lydia Pintscher (WMDE) (talk) 16:52, 18 June 2014 (UTC)[reply]

Header point size

It's the content that should be prominent, not headers. Take a look at [1]. I think it has some good points, one of them that big headers come from old days of default html styling. Lazowik (talk) 20:18, 16 June 2014 (UTC)[reply]

Clutterness

In the second screenshot too much is going on in the editing box. I think that the amount of data that can be stored in Wikibase calls for something more of an web app. That would be probably tough to do though :( Lazowik (talk) 20:18, 16 June 2014 (UTC)[reply]

Reason behind this design shall be interesting to hear

The goal of every design in information system is to place as much information on the screen in a way that it will be simple to find, simple to access, simple to edit, even if we have ~500 interwiki links and ~100 claims with qualifiers and sources. This design does not solve this problem.

First of all, there is too much unused space. Wikidata going to have a lot of structured information. There will be no text to fill gaps between floats, so using 5 rows (two for text + spacing) when we need only one or two (incl. spacing) is very bad solution. I want table representation, as far as it possible.
Actually, we can check how many values one property have and define different kind of representation on per-property level. For example, group "sex, birthday, nationality, etc" into single table, because it is usually 1-2 values + qualifiers. Occupation can have table representation on it's own, i.e. distinguish table with columns "occupation" (main snack), "start date" (qualifier), "end date" (qualifier).
There are some duplicates in the design. No one need item id on the page except rare cases for page linking. We can handle it from address bar. But! It can be interesting to replace "Q1234" with "{{Q|Q1234}}" for simple copy. But it shall be done by gadget and disabled by default.
How can one hide "Linked to by" group? Is it back-references? I don't want to load server by querying this information every time i visit page. And i don't want to see this information every time i visit item page. For popular item there will be dozens of incoming links -- showing 2-3 of them meaningless.
Identifiers. Did you actually manage to group properties somehow? Do you plan to use my script to edit those links in popup window? Well, it very good idea, and i like the compact representation... but what editor is going to do with qualifiers? Sources? Multiple values and order? What other properties can be grouped in such groups? Can we manage it on per-user level preferences or only on per-site scripts? A lot of questions about this group. Well, if it is only representation and duplicates of the actual properties below... i hope it is not.
Wikipedia links... again, how can i compact it to hide from my view? There are only 7 links, but usually there are dozens of them. Did you also success in storing QA/FA flags? Again, how can i edit those links? Popup window? Some animation?
There are discussions and i want to hide it. Okay, let me hide it. And if you can count discussions ("4 topics"), just put the counter on the "Discussion" tab header, like "Discussion (4)", at 6a point.
Again, duplication of information. I don't need second language select. Are those different or the same?

-- Vlsergey (talk) 21:30, 16 June 2014 (UTC)[reply]

Re second language select: That's how the current layout looks for anonymous users. ULS isn't currently able to support switching languages for anons, so for the meantime we have a local gadget that handles it by setting up the dropdown in the sidebar. The button at the top handles fonts and input settings for anons. --Yair rand (talk) 03:03, 17 June 2014 (UTC)[reply]

So, the button for anons can be hidden for non-anons, can't it? -- Vlsergey (talk) 07:06, 17 June 2014 (UTC)[reply]

But! It can be interesting to replace "Q1234" with "seaborgium (Q1234)" for simple copy. But it shall be done by gadget and disabled by default. I don't agree, if we are to manipulate entities, what is copied and pasted shall always be an entity, and take contextually the good form. This should be in the sofware designs, not by a gadget. Not a lot of users really wants to manipulate Ids. Btw.

Comment entity selector : the entity selector should have more usecases : select an item, go to the item page, refer to an item in a discussion. And it should always be available on talk pages. TomT0m ^(talk) 11:36, 17 June 2014 (UTC)[reply]

To 1: We will have whitespace and that is a good thing. It's not wasted space.

To 2: It was specifically asked for.

To 3: The idea is that you can collapse it by clicking on the header. How it's implemented isn't decided yet.

To 4: We will have some grouping. How it's going to work we'll have to see. Also about references and so on. You will still be able to have several. It will not be configured per-user but side-wide.

To 5: Collapse it by clicking on the header. Featured article is there already in the mockup. How it's going to be edited will follow later.

To 6: We wanted to make it more prominent than just in the header. But we'll have to see. --Lydia Pintscher (WMDE) (talk) 17:35, 18 June 2014 (UTC)[reply]

I know whitespace is en voge and helps (sometimes) to keep peoples attention BUT it is wasted space per definition --FischX (talk) 07:43, 23 June 2014 (UTC)[reply]

Comment

Some comments are copy from Wikidata:UI redesign input/Archive and Wikidata:Paper cuts, and they're not resolved in provided UI Screenshots.

We should define that what is identifers. In this picture it seems we can't add qualifiers or references, not muitiple values to these properties. However, sometimes muitiple values can be used, see Property talk:P244.
Some users want to change the property of a claim, like to change intance of to subclass of. Is it possible?
How to change the globe value of a coordinate statement via GUI??
How to set a edit summary via GUI?
When a user adds retrieved (P813) as a statement the default should be today’s date. And it should be possible to changed to other values.
It should be possible to move sitelinks and claims (with qualifiers) to other item.
How to create a item from another item?
It should be possible to remove all claims in a item, like remove all occupation (P106) claim here.
It should be possible to change to the old UI (i.e. the current UI), because it's simpler and a lot of gadgets and scripts are based on it.

--GZWDer (talk) 02:18, 17 June 2014 (UTC)[reply]

Multiple values would be possible. Would it be bad if we don't have references or qualifiers for identifiers?
No and I would be very much against making this possible because there is just too much screwup that can happen conceptually.
That's for detailed mockups later. We've not done them yet.
There is no edit summary to set just like there is none to set now.
Jep defaults for all datatypes are on my list but that's for later in the process.
I'd like to see proposals for how this could be done nicely if anyone has any.
I am very skeptical about/against adding such a feature for fear of too many bad items being created.
Do you mean all statements the item has or all with the same property?
That'll not be possible sorry. We'll have to get this UI into a good state that people can work with. We just don't have the manpower to maintain two UIs in a sane way. --Lydia Pintscher (WMDE) (talk) 17:41, 18 June 2014 (UTC)[reply]

@Lydia Pintscher (WMDE): Re for point 8: In my paper cut, mean "all with the same property". See Wikidata:Bot requests/Archive/2013/09#Removing duplicate statement for the orginal request. However, It's better to have both of them.--GZWDer (talk) 11:33, 20 June 2014 (UTC)[reply]
@Lydia Pintscher (WMDE): Re for point 1: If these claims have references or qualifiers, how to show them? Aren't them inaccessable?--GZWDer (talk) 11:35, 20 June 2014 (UTC)[reply]

My thoughts:

"Identifiers" shouldn't be placed higher up than Wikimedia project links.
The main reason users are going to be visiting the Wikidata pages themselves is to add sitelinks (I presume). Adding them should be as simple and obvious a process as possible. I find the lack of a simple "Add" button in the sitelinks section to be an issue, as well as the lack of prominence given to the sitelinks area.
The removal of other language labels and descriptions is a negative, in my opinion.
Might the removal of the actual language names in the sitelinks list be confusing to some users? Most people don't know ISO codes.
The "Add statement" button doesn't really match the style of the above content.
"0 references - click to add one". I don't think "click to" is really necessary.
Regarding the "Discussions" box, I'm not sure how appropriate that is to have on the content page itself. Wikidata items are kind of on the borderline between "meta" and "content", but free text comments being displayed like that could have some bad results.
"Linked to by", followed by what I would guess is Whatlinkshere. I'm skeptical that this is necessary or helpful. Placing it prominently at the top-right corner seems like a mistake.
We usually don't have one clear image that can be used cleanly as the "default" image for an entity. I don't agree that such an image should be displayed on the page itself.
I like that the current alias editing system has the "new alias" area actually be an edit box itself. I would like to see that system continue in the redesigned version.
Why is "male" under "sex or gender" not linked?

--Yair rand (talk) 03:00, 17 June 2014 (UTC)[reply]

@Yair rand: Re for point 4: Probably we can show it like: zh.--GZWDer (talk) 04:20, 17 June 2014 (UTC)[reply]

Fair enough.
That is an assumption that will not hold in the future.
Ok. Point taken.
Ok.
Ok.
Ok.
My idea was to make use of Flow once it is available. But I am not entirely sure how useful the result would be.
Ok.
My impression is that we do have such an image. I think this part is really important to make the site more accessible
Ok.
Oversight ;-) Thanks for spotting. --Lydia Pintscher (WMDE) (talk) 17:46, 18 June 2014 (UTC)[reply]

Some comments I have on the design:

White space! - Please keep the white space, it's important for making content readable. I know everyone else seems to want "information density", but it's not a good idea in practice.
Gradients! Bad! - While I'm fine with gradients when they're subtle (and usually only when used as shadows), I feel like they're used far too often in this design. When compared with the rest of the interface and the overarching Wikimedia design language, the gradients in the right sidebar are a pretty stark contrast. Entries should be differentiated with background color, lines, or just spacing. Plus, I'm pretty sure gradients take a tiny bit more power to render than simple lines.
Aliases should be differentiated in some way - Right now they're each contained in a separate "box", which I find preferable for the purpose of differentiating parts of the interface. See this MediaViewer mockup for an example of the "containers" I'm thinking of.
The right sidebar's headers shouldn't be so large and should be using a sans serif font - They're already differentiated by the blue background, I don't see a need to make them as large as they are. I also think the font shouldn't be a serif font, as the Typography Refresh on Wikipedia limited serifs to article titles and level 1 section headers only.
1. In the same vein, I feel like the blue color is enough of a differentiator to where the gradients are unnecessary. Depth doesn't really need to be portrayed here for any functional reason. If you really feel the need to show depth, check out how Flow's topic headers do it when scrolled-over.
Q12345 not fully right aligned - While I have other issues as well, it bothers me that the "Q#" isn't fully right aligned. I also feel like it stands out more than it should, given that it's white rather than gray.
The dropdown arrow seems inconsistent to me - Given that Flow uses the three-dot metaphor, why are extra options under a dropdown arrow in this? I suppose this is minor, but it feels like you're diverging from a purposeful design choice for no notable reason.

Anyway, that's all I have for now. If you have any questions about my feedback, feel free to ask! I'm looking forward to this refresh. --Nicereddy (talk) 06:34, 17 June 2014 (UTC)[reply]

Thank you! That's helpful. --Lydia Pintscher (WMDE) (talk) 17:49, 18 June 2014 (UTC)[reply]

Other comments:

Two columns are a bad idea. Use only one column but dendify by reducing the space between lines. The blocks Identifiers and WP links are a good solution for that but these blocks have to be below the statements.
The alignment of the sitelinks and the identifiers is necessary. Same for values in the statements.
The statement and value should be on the same line like the current version and not put on 2 different lines. Use the length of the page but reduce the height of the lines.

Snipre (talk) 14:59, 17 June 2014 (UTC)[reply]

Can you clarify why you think two columns are a bad idea? --Lydia Pintscher (WMDE) (talk) 17:49, 18 June 2014 (UTC)[reply]

Labels and aliases as statements

As said on the mailing list, this design is an improvement over the design that we have now, but there are two things that need major improvement, the space taken by statements, which could be reduced and the way we deal with labels, that also needs UI support.

Regarding the labels I made a mockup, with the following ideas in mind:

Every label is just as any other statement, with references, qualifiers etc. but they are grouped together by language.
There is always one preferred label marked with a star, which corresponds with the page title
Each language is treated as a "tab". Language fallback can be achieved by displaying missing statements from other languages, but with a grayed out color.
Not visible: on save the value of each statement is copied to what we know now as "aliases" (they are no longer directly editable)

--Micru (talk) 09:29, 17 June 2014 (UTC)[reply]

Thanks! I really think we can not go in that direction without making both the user interaction and the code considerably worse. Sorry :/ I'm really trying hard to make Wikidata easier to understand and use. --Lydia Pintscher (WMDE) (talk) 17:52, 18 June 2014 (UTC)[reply]

and the code? Had to laugh hard. Anyhow, here my point of view on the topic: I think aliases should be built from statements like proposed by Micru. In his design, it looks highly confusing to me though. Those statements should just be normal statements down with all the other statements. E.g. birth name and stage name are very valid statements for an actor, so why not show them down there with the other statements? Hiding them behind aliases is confusing. Instead, when editing aliases one should be able to select from which statement-groups the aliases derive rather than directly editing those statements.
But, this is an entirely new feature and has nothing to do with this UI redesign. Also, this might be a lot of implementation work. Doing something similar for the Item's label might be useful too (and easier to implement). Both of those things would probably break quite some things since the API had to be changed. The data model though could just be extended, "aliases" and "label" would still just hold some strings, how they are built would be added to the data model as a new structure. Lots of things to consider here so I just stop going on about that for now.
--Danwe (talk) 10:21, 21 June 2014 (UTC)[reply]

"Discussions"

I don't think it is appropriate to include meta information (meta in the sense it is internal to the project) on the content page, especially above actual content. Legoktm (talk) 10:23, 17 June 2014 (UTC)[reply]

Fair enough. What's others general feeling about that? Would it be more ok for you if we move it down? --Lydia Pintscher (WMDE) (talk) 17:53, 18 June 2014 (UTC)[reply]

For me the best would be to collapse it and show only the number of comments, last modification, and who modified it last. On click, then yes, expand the discussion. If it is collapsed I wouldn't mind that it is where it is now.--Micru (talk) 08:28, 19 June 2014 (UTC)[reply]

"No chrome"

As a counterpoint to the massive use of "chrome" on the proposal, here's current Wikidata, but "collapsed" and statement chrome removed. Just a few bits of CSS were altered. This feels much less bloated to me, without compromising readability. --Magnus Manske (talk) 12:36, 17 June 2014 (UTC)[reply]

I agree that we should remove unnecessary design elements. But I also like the idea of having two columns to reduce the amount of scrolling (experiment with responsive design perhaps?). Users with small monitors might not like the idea of a multi-column layout, but for users with large monitors, it would be very convenient. —Wylve (talk) 16:53, 17 June 2014 (UTC)[reply]

I like the two-column layout as well; I just didn't bother to HTML-fiddle it into place in my screenshot... --Magnus Manske (talk) 15:01, 18 June 2014 (UTC)[reply]

Point about the amount of chrome taken ;-) Thanks. --Lydia Pintscher (WMDE) (talk) 17:54, 18 June 2014 (UTC)[reply]

Since Wikidata is the 'backbone' instead of a client, I think the main point of the redesign should focus on increasing editing efficiency and convenience, instead of aesthetics. Of course, it would be best to have a nice-looking and efficient interface, but in reality that's really hard to achieve. Adding many design elements will slow down the load times for items that have many claims. —Wylve (talk) 20:16, 18 June 2014 (UTC)[reply]

My goal is to make it less of a backbone. --Lydia Pintscher (WMDE) (talk) 20:18, 18 June 2014 (UTC)[reply]

What about "collapsing" at the statement-level? This item has three occupations and collapsing all of them would save a lot of space. The next point is to group statements. If we would say that a property has to be a part of a group of properties, grouping could be possible. At the moment we actually group properties already, see Wikidata:List of properties. And as a eye-candy the head of the page could be done as in the UI Screenshot of Dirk Benedict. By the way, I would prefer the "description" not to be the last column, but a new row below. Because sometimes there are lot of aliases too, maybe there could be an automated change from column to row, if the data exceeds a certain number of letters? --Goldzahn (talk) 13:17, 19 June 2014 (UTC)[reply]

My comments

Labels, Descriptions and Aliases

Getting Labels, Descriptions and Aliases added in other languages will be a big part of making wikidata a success and will be done by the users who are the least experienced in editing wikidata. Make it as easy as possible to do this. Do UI testing on this.

Linked to by

I like that you have "Linked to by" but

It should include the property used to link as well as the item that linked. "The A-Team Cast member" instead of "The A-Team"
These are statements about the item as much as the statements that have the item as their subject. Format them like the statements except with the item before the property.
Put them below the other statements.
Put them in a drop down menu if that will speed up the page display.
Including the descriptions for items in these statements is probably a good thing. If it is a good thing then you should do it for properties and items in other statements as well. The descriptions could be in hover text rather than taking up space.

Claims and Statements

A claim should be one line, not two. "<Property>:<Value> 0 refs [edit]". Clicking on 'edit' should reveal references and options to add qualifiers.
If you are editing a claim then the option to add a qualifier or a reference should be visible, even if you have to save the claim first. The current UI means you don't even see the "add qualifier' option until you save the claim and then edit it.
Qualifiers should be one line each, as you have done, but inset from the main property so it is clear they are a qualifier to that claim.
This may mean you have to repeat the <property> label for the next claim using that property so it's clear it is using that property again. No problem. It doesn't take more space.
The "add" button to add another value for this property should read "add occupation" or whatever the property label is. The current UI is a bit obscure. I realise that this means the I10N for the UI needs to be smart enough to know where the property label goes in the tag. Sorry.
I don't like the block of colour around the properties. I prefer the look of the 'chrome free' layout from Magnus.
I like that the preferred value is at the top. If there are more than 3 values then it does make sense to hide them and have a drop down for the rest of the values but I think that the link to reveal the additional doesn't have to be a separate line. Change "Deprecated Values" to "Show 3 Deprecated Values"
We are going to start to have a lot of items where a property has a lot of values and each of these values has the same 4, 5, 6 qualifiers (Each competitor in a match item, each team in a league item). Could these be shown as a table with the names of the main and qualifier properties as column headers and one line for each claim?
Preferred/Normal/Deprecated values could be indicated by a traffic light symbol next to the value with the appropriate green/orange/red circle lit and a hover text to explain it.
Is the 'subject - verb - object' syntax right for all languages? Does there need to be a different layout for some languages?

Sitelinks

I think these are more important than Discussions and Identifiers and should be above them in the right hand column.

Identifiers

I can see why Identifiers are treated as sitelinks - they are links to non-wikimedia sites - but they are (in my opinion) the part of the site that inexperienced users will be least interested in. In fact I'm not sure who is interested in these apart from bots - both adding them and reading them. They can be at the bottom of the page.

Discussions

I see what you are doing here but I think Discussion pages will be used less on wikidata than they are on wikipedia (for instance) and could be left off. Remember we will be moving to meta:Flow for discussions.

Mobile

Think about the UI on small screens. Do we sidescroll to see the tools/statements/sitelinks columns or do we stack them one above the other with drop down.

Filceolaire (talk) 16:56, 17 June 2014 (UTC)[reply]

Thanks a lot! --Lydia Pintscher (WMDE) (talk) 17:57, 18 June 2014 (UTC)[reply]

My concerns

Here are my concerns:

Wikipedia links to the side and below identifiers?, the Wikipedia article links being off to the side is not something I like, of course I'd have to see how it really is to say for sure. And below identifiers? SMH.
ISO codes??? I know a lot of ISO codes, but I can't say the same for many others.
Discussions? Why is this on the item page? Of course I might approve of it if it was below everything else, but it's above WP links and identifiers.
Linked to by? Putting this on the side above everthing else is insane. Is what other items say more important than the main item's WP links, identifiers, and discussions?
Second language select? What's with the second language select?
Q##### looks out of place The Q# looks very out of place, and wasting a line of space.
Dull color? What's with the dull blue color? Why that color? Why have any color?

--AmaryllisGardener ^talk 17:26, 17 June 2014 (UTC)[reply]

Can you clarify what you mean with 5 please? About color: We really need to get away from the depressing grey block we have right now. It doesn't have to be this color but it has to be some. (Answered the rest in previous comments.) --Lydia Pintscher (WMDE) (talk) 17:59, 18 June 2014 (UTC)[reply]

@Lydia Pintscher (WMDE): About #5, I'm talking about what Vlsergey said (#7). About the color, I guess the gray isn't so bad because I'm used to it. The blue is an improvement I guess. --AmaryllisGardener ^talk 19:24, 18 June 2014 (UTC)[reply]

Ah alright. Now I understand. Thanks :) --Lydia Pintscher (WMDE) (talk) 19:33, 18 June 2014 (UTC)[reply]

An alternative

With the typography refresh and upcoming image border cleanups on Wikipedia, we're actively trying to move toward more whitespace, bigger margins, airyer text, fewer boxes, borders and gradients. My biggest concern for this redesign is that its going further down the road of boxes, fills, and colored backgrounds that we're actively trying to clean up.

Goals

Contextual edit and add actions
Hierarchy of information & context at a glance
Appropriate presentation of ID and local language names
Structure for structured data

Contextual edit and add actions

Instead of the floating edit links per section allow items to be edited in-line with a hover affordance or edit icon which directly prepends the item
Show contextual Add Item, Add Qualifier, and Add Source, even when an item isn't in "edit mode" this allows users to quickly get to the task they need to do without multiple up-front steps.
For items which are not links (title, description, aliases) allow direct editing without an edit button

Hierarchy of information & context at a glance

Highlight page type, Item, Property, Query with color and label, make it glanceable even without seeing the prefix or url.
Use bold dark on light (rather than white on baby blue) text for major sections
Automatically sort Properties in a logical ordering top to bottom
Use indenting and paler text for less crucial secondary information like qualifiers, or sources
Section headers who size shows relative importance, e.g. size and contrast signify importance, items of lesser importance for first read, are deemphasised
A new structure for property importance (preferred, normal, deprecated) which allows for direct manipulation, collapsing of deprecated items by default and sorting based on importance will allow items to be quickly glanceable without having to decipher symbols

Appropriate presentation of ID and local language names

Wherever possible use both the human readable name and ID in conjunction so that users who are aware of the ID number for similarly or same name items can confirm they are correct without hovering, following links, or inspecting the targets

Structure for structured data

While this is equal parts feature and visual design, certain item types could be better visualized with more structure, people, places, plants & animals, could have modules which fetch parent and child relationships to create rich layouts which let users explore how the item fits in a larger context
Move the meta and less "human readable" information into a sidebar. Wikipedia links, similar or related content, discussion, ID and classification systems, parent and child items, and items with special relationships, e.g. Other members of this band, animals in this sub-genus, etc.

I hope this goals based approach to the redesign of the pages is useful, feel free to reach out to me here or on my wikidata talkpage for feedback. Jared Zimmerman (talk) 23:14, 17 June 2014 (UTC)[reply]

Thanks a lot :) Will go through them with Henning. --Lydia Pintscher (WMDE) (talk) 18:03, 18 June 2014 (UTC)[reply]

Lydia Pintscher (WMDE), happy to set up a hangout next week if you want to go over it in more depth. Jared Zimmerman (talk) 01:31, 19 June 2014 (UTC)[reply]

Comments on Jared's alternative

Structure: One of the parts that I like the most of this design is that offers some basic structure. It would be hard to find divisions that would please everyone but: Description, Labels (missing in the mockup), Classification, and Media ("Commons" in the mockup), seems to be some statement groups that every item page could have (or already has). "Family" and "Location" seem to be more specific for a certain kind of items, but nevertheless useful.

Label is the main text in the grey box (box color can signify object type, item, property, query etc)
The structured groups, would only show based on object type, so if… is instance of human, the "person" module shows, no need to show module types that are not relevant, and the modules could be community created and expanded on, e.g. a politician may have both a person module and a public office type module. Ideally there would be no duplication and if a module was used any statements that were part of the module would be gathered into the module rather than showing up twice. Jared Zimmerman (talk) 01:21, 19 June 2014 (UTC)[reply]

Jared, so if I understood right, what you are suggesting is to create a sort of pseudo-CSS that would describe sections titles and which properties belong to each section? I can imagine that it would be possible to maintain such structures with bots once statements are allowed on properties. What I don't see so clear is where to store the formatting templates (I guess on item talk pages?), how would they be processed by the software and, more importantly, how would that affect performance...

OTOH, given that statements can be sorted already, perhaps we can achieve a similar effect just sorting the statements by bot. The only missing part would be the section titles, perhaps with a new delimiter element sortable as a statement? Which again poses new challenges... Anyhow, if you get to talk with the devs, maybe they have other ideas. --Micru (talk) 08:46, 19 June 2014 (UTC)[reply]

Micru, The structured modules should probably not be on the talk pages, I'm guessing. you wouldn't want them on the talk page because you'd want them called from a central place (like a template) since all people should be using the same module. Jared Zimmerman (talk) 19:40, 19 June 2014 (UTC)[reply]

Colors: I don't like the dull colors, but still better than the super-dull colors that we have now. The presence of images might attenuate this effect.

all of the green boxes would be thumbnail images and the light grey ones would be images or other types of media (maps, diagrams, etc) the page structure should be muted and simple color wise, so that any images and rich media content can be the spotlight, no need for them to have to compete with the chrome Jared Zimmerman (talk) 01:21, 19 June 2014 (UTC)[reply]
I have to disagree on this. In Jareds design, basically all colors are taken out. Only black and gray left. The greenish boxes will be replaced by images related to the items if I have understood Jared correctly (I like that). But I think by taking out all of the colors, this design is a lot duller than anything we have now or shown in Hennings proposal.
Moreover, I find the colors quite confusing in this proposal. E.g. the "more" links/buttons on the right side, they look just like the plain text above. Giving a consistent color to the links/buttons could make this proposal a lot better I think. --Danwe (talk) 08:38, 21 June 2014 (UTC)[reply]

Languages: this seems to the biggest weakness of this proposal. How are labels/descriptions shown or edited in other languages? There is no indication about it.

Alternate language items can appear directly below the item in the users primary language. right now only certain attributes show multiple languages at the same time, I don't know if this is changing, but its likely a 10% use case not a 90% one Jared Zimmerman (talk) 01:21, 19 June 2014 (UTC)[reply]

Consistency: I also noticed a lack of consistency that doesn't allow proper evaluation of cluttering. In some places there is "add source" in other "add qualifier". In the custom-made sections is not clear how one edits the Commons category or the location. Maybe the edit link shows on hover?

As I said, just a sketch, plenty to iterate on, the idea was that properties which can only have one valid value wouldn't highlight the "add another" control, maybe just on hover, and properties which can have many valid values would show "add another" at all times

There is no such restriction by the software. Wikidatas software has been designed for supporting "multiple truth", considering there could always be sources featuring contradictive values. There might be a few properties on Wikidata which conceptually have a constraint as mentioned by you, e.g. the items ID in another system. But I think that's for later and not worth the effort thinking about now. --Danwe (talk) 08:28, 21 June 2014 (UTC)[reply]

Agreed, there is a lot of inconsistency here. In addition to the already mentioned one:
presentation of properties as both, ID and label

I like that a lot! I also like the way you present it. Having some nice pictures there where you currently have the greenish boxes is a cool idea. Only criticism here, you didn't do it consistently for some of the item references.

gray boxes

I don't get them at all. They are all over the place but not in any consistent manner. Sometimes they are in front of a property name, sometimes not. Then they are in front of some buttons/links (e.g. "add another property" or "Add a link to Wikipedia article" [right row]) while they are not there for others ("add another alias" or "more..." [right row]). As mentioned above (on colors), the links themselves are quite inconsistent in their color too, sometimes gray, sometimes black.

missing property labels

see instance of / normal values / Welocica, there's a qualifier but without property label. Not sure whether this is a mistake or intentional.

Family, Location and commons

What are those? Conceptually they look like special sections just like those on the right side. Or are they something else?
There are so many different "kinds" of items, consider that there had to be a lot of exceptions to the generic design if you want something like that.
Hennings design didn't include any special sections like that. Instead it just shows how to format things in a generic way. Your special sections here look kind of cool, but I believe their implementation would be too much work for the core team right now. They had to implement a generic way allowing for UI modifications like this as well as a system for defining rules when to apply the special design for a group of statements. This goes hand in hand with what I wrote further down on this page.
Should you adjust your design, I would urge you to take those out for the sake of clear comparison with Hennings design. Right now they are a big distraction and I don't think everyone is understanding the implications when comparing the two. Having another separate mock with those inside would be great, I'd love to see this further level of customization for the software on day. Already taking into consideration how this can be integrated in the new design might be a good idea.

--Danwe (talk) 09:33, 21 June 2014 (UTC)[reply]

Parent/child: very useful! The "connected by" section of the original proposal is also needed, and it could go at the end of the page, like in Reasonator.

Sitelinks: the size of the sitelinks worries me when I imagine how kilometric could be the expanded sitelink list of items with over 100 lines... it needs to be more compact.

I imagine the right sidebar things can have expand collapse functionality, or initially show only a subset (recently added/modified?) with an expand to show all, or collapse to show none, things to look into, but certainly not show-stoppers. Jared Zimmerman (talk) 01:21, 19 June 2014 (UTC)[reply]

I can imagine that this design will please mostly to no-chrome advocates and to the ones that want consistency with WMF sites. Its strong point (hierarchy structure) is something that should be assessed by the development team, it might be to hard to manage by the software, no idea. --Micru (talk) 08:46, 18 June 2014 (UTC)[reply]

Micru, thanks for the feedback, replies in-line Jared Zimmerman (talk) 01:30, 19 June 2014 (UTC)[reply]

I like this sketch more than the one at the top of this page because it adds even more structure to the item's page. Especially the media preview blocks make the site interactive and appealing. However, this structure requires also a way to sort statements which only contain certain identifiers from those which contain information about location and those containing hierachy data. This is also requires a huge improvements of how properties are currently stored and sorted. One step into this direction is to allow claims on properties. However, in my opinion this is the way to go if we want to make Wikidata a real client to consume the data. -- Bene* ^t_a^l_k 19:59, 19 June 2014 (UTC)[reply]

Points of agreement/disagreement

Based on what everyone wrote, I am trying to summarize the consensus or lack of it.--Micru (talk) 09:29, 18 June 2014 (UTC)[reply]

Consensus

Statements should be as (vertically) compact as possible
Collapsible sitelink table
Group external identifiers
Basic item hierarchy needed
"Linked to by" is useful
Parent/children is useful
no discussions on item page

No consensus

Amount of "chrome" (trending towards "better less")
Amount of white space (trending towards "don't overdo it")
Top image/no top image
Position of group of identifiers
Position of "linked to by"
Show item Q-IDs/Don't show Q-IDs

Comments

Thanks! :) However I feel I need to make it clear that we're not doing design by committee/consensus here. That nearly always has a bad end result. I'm taking in all the feedback of course and we'll go back to the drawing board. In the end we'll be making some people unhappy I fear. That's ok. I hope all in all we'll have a very nice and usable new design that is useful to many more people than the current one while still helping the current users. Just like you're used to from the dev team. (Not specifically directed at you Micru. Just wanted to clarify this to make sure there are no misunderstandings.) --Lydia Pintscher (WMDE) (talk) 18:07, 18 June 2014 (UTC)[reply]

I just compiled the list because it seemed that the same things were appearing in different places, and it was not clear what seems right and what not. No need to feel pressured :P--Micru (talk) 18:41, 18 June 2014 (UTC)[reply]

Yes and that's really helpful. Just want to make sure we don't have disappointed people in the end because they think this is something we vote on. All good :) --Lydia Pintscher (WMDE) (talk) 19:04, 18 June 2014 (UTC)[reply]

Lydia, out of curiosity, which options are discarded? It seems to me that parent/children would be better done with a gadget, and that a per item hierarchy modules, as Jared and others suggested, might need more thinking, but what about the rest? --Micru (talk) 08:23, 19 June 2014 (UTC)[reply]

Those pretty much plus extending labels. I have not made up my mind entirely about the rest yet. --Lydia Pintscher (WMDE) (talk) 08:55, 19 June 2014 (UTC)[reply]

Other sites

dbpedia

There are some interesting features in dbpedia, see for instance the new live version of Heidelberg. There is an image, an abstract and a map as header. The layout is like a table, and when a property has more than 5 values, the rest are hidden with a button "show more". The goals are different, but the layout shows that the statements can be quite compact while guaranteeing readability.

Freebase

On freebase (see Heidelberg ) there are four sections Properties (=statements), i18n (=labels), Keys (=external identifiers), Links (=linked to by). For the statements there are templates with predefined values. There is a table of content on the right.

Reflections

The dbpedia map on top seems quite fitting and it would be a nice addition for Wikidata, also the auto-hide more than 5 values of a property. The templates of freebase look really overkill, and the interface is quite bloated. Nothing to be learnt from there other than "stay away".
Looking at these sites I had an idea: it could be possible to simulate a table of content in Wikidata without resorting to "hard-templates" or touching the internal structure. The way to do it would be to have sorting order tables for each "instance of" value (or the most used ones), then a bot would order the statements. Finally a gadget can provide a "table of contents", just by linking to the first property of any "virtual" group. This would be non-invasive and it would have a similar to the table of contents that both dbpedia and freebase have. Actually it could be done already since anchors work (for instance: https://www.wikidata.org/wiki/Q923169#P94).--Micru (talk) 14:18, 19 June 2014 (UTC)[reply]

Alternative comment system

Another way of implementing system could be like in this article. In our case that would mean that each statement (or group of statements) can have associated comments, and if there is any, a little number would show on the right. When clicking it, it would toggle the comments for that section on. I think it would make sense because most comments are relating to one statement. Sometimes I wish I could write somewhere why I entered the statements that way, but I know that if I write it on the discussions, it will be ignored. I think a comment system like this would allow us to work more efficiently. The linked article itself is also worth a read ;)--Micru (talk) 09:23, 20 June 2014 (UTC)[reply]

Micru, thats actually one possible outcome of Flow to allow per section converstaions on articles via a functional right rail Jared Zimmerman (talk) 06:15, 21 June 2014 (UTC)[reply]

Keeping concerns of the Wikibase software and its usage on Wikidata in mind

I just want to point out (as so often before) that you should keep in mind that some things regarding the design might be implemented as part of the Wikibase software but some Wikidata specific things should not be implemented there but rather on Wikidata.org as site specific code/configuration or as a separate extension.

This goes for some design elements of Hennings design as well as for some of Jareds ideas.

Basically, Wikibase should have no knowledge about specific entities. This means the software itself can not know about most of those special sections on the right site ("Identifiers", "Wikipedia", "Wikivoyage", "see also", "child items" and "parent items"). As far as I can see, only the "Linked to by" and "Discussions" sections are basic enough to be part of Wikibase itself.

This also means that there should be a clear API for extending and configuring the Wikibase UI to the needs of projects using it, e.g. Wikidata. --Danwe (talk) 08:17, 21 June 2014 (UTC)[reply]

Lots of goodness here

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

How property IDs have that blue background and are used on top of the statement group rather than as in two columns as with the current UI. Of course, when scrolling down, the property's label should scroll down as well (seriously!).
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 items 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?

What I'd like to see improved:

How Jared designed presentation of item reference labels. 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?

--Danwe (talk) 10:03, 21 June 2014 (UTC)[reply]

Functionality pioneered by Reasonator et al

An UI overhaul should cover all the reasons why Reasonator exists. That does include all the functionalities Magnus has introduced. It is fine when some of them can be turned off or are reconfigured based on individual choice.

Automated descriptions

This is the single most important feature in Wikidata. It helps identify the right homonym from a long list of choices. It is also a powerful motivator to add statements and labels.

When a label does NOT exist, there is language fall back
When a label does NOT exist, a box is triggered by double clicking allowing for adding a label

Automated text

At this time it exists for "human"s and only in a select number of languages. There are two reasons why having automated texts are worth having:

It allows people to experiment with texts that bots are to generate
Text is the format people are most comfortable with getting their information. As the text is generated, the format is the same and that makes it really easy to pick out information

Reasoned information

Often there is information that is generated based on available information in this and other related items

genealogy; based on spouse, father, mother, child
the upper class structure; it is the best way to show how good/silly it is
taxonony; currently Reasonator has it not only based on "parent taxon"
room for other structures..
related information; Reasonator provides information for a maximum of 500 items.. When there is more it often provides with a query to see the complete results
lists; lists and categories can be defined with a query and their results can be shown. This is also the basis for comparing them with the on Wiki categories or lists for completeness.

--GerardM (talk) 08:06, 23 June 2014‎ (UTC)[reply]