User:Pragunbhutani/GSoC 2013/Implementation Approaches

This page is created for the purpose of documenting and discussing implementation approaches with the community.

Factor getHtmlForClaims out of EntityView
The idea is to factor the getHtmlForClaims part of entity view into a class of its own. This would allow it to be used in EntityView and also in mobile skins intended to make Wikidata mobile friendly (https://bugzilla.wikimedia.org/show_bug.cgi?id=43065).

Update: The bug has been assigned to me and listed as a dependency for BUG 40885.

The getHtmlForClaims calls getHtmlForClaim, which could be placed into a separate class. Since claims are one of the things that are broken on Mobile Wikidata right now, doing this should allow us to use the class in the new skin that I'll be developing for Wikidata Mobile.

I'm also in favor of re-naming getHtmlForClaims to something like claimGenerator because the current naming is very confusing. (getHtmlForClaims and getHtmlForClaim)

Feedback
Please add your feedback below:

UI Mockup v1
I've created the first UI mockup for how Wikidata Mobile should look. Please forgive the use of pencil and paper, I feel a little more comfortable using those. I've tried to keep the look consistent with how Wikipedia Mobile looks so that it's easy to adapt to.

Here are a few points of discussion that I feel could benefit from community feedback. Please feel free to add more should you discover any.
 * Each individual statement is 'closed' when the page is opened and slides down to reveal content when the arrow is clicked. Upon clicking the arrow gets reversed so that you can close it again. Would it be better to leave them all open perhaps?
 * Clicking on a statement text, e.g., 'country' should lead to the item page for country. I'm concerned that some users might get confused and expect that touching on it should slide down to reveal content of that statement.
 * The placement of [edit], [add source] etc. could be reconsidered.
 * The shades of grey used correspond to those used on the desktop site.

Feedback
Please add your feedback below:


 * The design looks clean and as hoped does match Wikipedia's mobile designs. The edit and add source buttons probably could do with some rethinking about placement. The touching of the properties name can also be confusing especially with small screens so personally only having it linking once the statement is open maybe a good idea. However no main problems with the overall design. John F. Lewis (talk) 17:10, 5 July 2013 (UTC)
 * I've adjusted the placement in Mockup v2 now. I really like the idea of linking the items only when the statement is open. Will definitely keep that in mind, thanks! :) --Pragunbhutani (talk) 20:53, 5 July 2013 (UTC)


 * Please add just "in more languages" button same way as wikipedia mobile do on their Pages. And you can list just collapaed tab for list of interwiki links as most of the time they are not in focus while editing statements. And please dont forget to add "desktop" button below same way as wikipedia do. I mostly edit wikidata nowadays from mobile, so i am eager to release.. -Nizil Shah (talk) 18:37, 11 July 2013 (UTC)
 * I like the suggestion for handling the language switching. I'll mock that up and give it a whirl, thanks. I've also received alternate UI mockups from another user which I really like and I'll share below soon. Hopefully the language switcher will sit well with that! --Pragunbhutani (talk) 17:47, 12 July 2013 (UTC)

UI Mockup v2
Based on some feedback by Denny on the IRC (#wikimedia-wikidata) I've made some changes to v1.

Here's a list of changes made:
 * Tags in 'Also known as' section removed. The values are now shown as text separated by commas.
 * Preview of values shown in each statement. In case of overflow in value, the statement is terminated by an ellipsis.
 * Upon expanding a particular statement, the preview is removed and all values + sources/qualifiers are shown.
 * All the [add], [edit] etc. for labels AND statements have been aligned.

Feedback
Please add your feedback below:


 * Looks pretty awesome! I worry that touch targets may be too small and packed together vertically, so make sure there's plenty of vertical space when expanding those fields... --brion (talk)
 * I will definitely keep that in mind. --Pragunbhutani (talk) 20:55, 5 July 2013 (UTC)


 * Looking good! Any special plans for tablets? Dragging out the boxes over the whole size would probably not the best idea on tablets. Hobofan (talk) 20:42, 5 July 2013 (UTC)
 * Thank you! No plans for tablets thus far. My project only hopes to get the ball rolling on Wikidata Mobile. There is going to be a lot to look forward to from thereon forth! :) --Pragunbhutani (talk) 20:55, 5 July 2013 (UTC)


 * This has been sat in my inbox for a while now and I have been meaning to have a look! The mockups look great :)! Just a thought for tablets (especially if viewed in landscape) it would be great to simply split the information into two collums. The data could then simply be split between the two. :) Addshore (talk) 18:12, 9 July 2013 (UTC)
 * Thanks! Pau Giner from Wikimedia has suggested an alternate UI which should be close to what you're suggesting and I really like it! At first glance, his design does look more usable to me so I'm inclined to use that as a starting point and go on from there. I'll share that below soon and let's see how the community likes it! --Pragunbhutani (talk) 17:48, 12 July 2013 (UTC)

UI Mockup v3
Pau Giner from the design team has suggested the following mockups for the UI. Broadly speaking, I really like them and would like to base my work from here if the community also eels the same way.

Note: The search bar and menu buttons are up along the top, as usual. They've not been included in the mockups. A few points that he mentions about the design:


 * Display information first and provide editing actions in a separate detail view. In the current mockup you can edit a statement such as "main type", modify its value and add more sources (all from the top-level view). Alternatively, in a simplified top-level view you can just show the information, and allow edit actions once the user accesses to it.
 * Allow for richer content. The current format is text based. Statements can be represented in a way that allow for images to be used.
 * The description of the item is grouped together. At a detail view the user can chose which parts to edit. For the case when some part is missing, it may be considered to make the indicator of the lacking information into a call to action for editing such element.
 * I also used text statements but the layout of the statements also allows to fit an image if it was the case.

A few points that I'd like to add on top:
 * We might not have all the edit actions right now, so it's nice to have two separate views, 'with' and 'without actions'. We can keep adding actions to the 'with actions' view as they come along and the standard view can remain the same.
 * When clicked/tapped, the boxes slide and expand to display their content in detail. If the data inside is textual in nature, they can expand horizontally. In case of images etc., we can expand them both horizontally and vertically.

Feedback
Please add your feedback below: