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

Tracked in Phabricator
Task T52578

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.

Tracked in Phabricator
Task T42885

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:

I request you to add " in other language" button below as in Wikipedia mobile site to help multilingual community of Wikidata. It will help editors of other languages to edit.-Nizil Shah (talk) 16:20, 27 July 2013 (UTC)

Adding an option to switch languages is already on my list of deliverables. I still need to work out how to do that, but I'll definitely keep it in mind. -- Pragunbhutani (talk) 09:16, 1 August 2013 (UTC)

Thank, Pragun..Is it possible to add Q codes along with item? Btw, i liked your new version.-Nizil Shah (talk) 17:21, 20 August 2013 (UTC)

Thank you Nizil! The Q Codes will already be visible in the URL, but I will experiment with a few different placements of the Q-code in the page as well. If it looks good, it could be included. :) --Pragunbhutani (talk) 07:55, 23 August 2013 (UTC)

I like how "0 sources" sticks out. You could also add the message to "imported from = Wikipedia" sources. Both could say "Source required". --Tobias1984 (talk) 17:04, 16 August 2013 (UTC)

Thank you Tobias. I'll add those messages along with a few different type of cards in the mockup and see how it looks. Will share the progress in subsequent updates. :) --Pragunbhutani (talk) 07:55, 23 August 2013 (UTC)

Developing an extension for Mobile Wikidata

After a discussion with one of my mentors, Jon Robson, we have decided to approach this problem by developing an extension for it rather than modifying MobileFrontend. Below are a few details about the extension and the a short explanation for our decision followed by the progress so far.

The extension would include a skin and css for Mobile Wikidata.
The skin will extend SkinMobile from MobileFrontend and will be tailored for Wikidata.
It'll be included in LocalSettings.php after MobileFrontend.
Once loaded, it applies the mobile skin for Wikidata instead of the default SkinMobile provided by MobileFrontend.

The reason we chose to develop a new extension rather than modifying MobileFrontend is:

Remove the need to tinker with MobileFrontend code, and prevent unnecessary problems.
Having it in a separate extension makes it easier to maintain and develop in the future.
The extension can benefit from upward changes made to MobileFrontend in the future.

Current progress:

A dummy skin has been created.
Prepared an HTML mockup that has been hardcoded into the skin for testing purposes.
I'm going to start developing the extension next.
Work on obtaining the HTML for Wikidata statements from ParserOutput is currently underway and shall be reported separately.
Uploaded things to a github repo : https://github.com/pragunbhutani/WikibaseMobile.
The basic framework for the extension has been created! Please check it out on the repo listed above!
Here's a demo of the extension running with hard-coded html : http://wikidata-mobile-tester.instance-proxy.wmflabs.org/wiki/Main_Page.

Reverting to a single column layout

I tried out the double column layout as has been shown in UI Mockup v3, but it turns out to be hard to work with at the moment. Each column needs to slide down to reveal its contents on being tapped and that's turning out to be a little hard to handle with a double column layout.

Further, after testing the skin on a few mobile devices, I've found a single column layout to be the best suited for mobile phones. Tablets could certainly benefit from a double column layout, but at least we'll have a working skin for now. A double column layout for tablets is one of the things I intend to add to the skin in the future.