@Nirzar - will we have separate/new styles for:

• tables and other templates?
• footnotes and references

What about tables and other content elements?

1. Do we go directly to media such as images when clicked?
2. Are we skipping lazy loading references and images for now? What about page previews?
3. Should the table of contents be collapsible?
4. What about the legal footer?
5. Is there any special iconography needed like edit pencils?

In T176958#3653821, @Jhernandez wrote:

What about tables and other content elements?

We should include all content elements - will add to description.

In T176958#3656053, @Niedzielski wrote:

1. Do we go directly to media such as images when clicked?

I think for now images should not be clickable until we get the multimedia viewer built.

1. Are we skipping lazy loading references and images for now? What about page previews?

We currently don't have page previews on mobile (and no plans on including them for the future). In terms of lazy-loading images, they are currently in the acceptance criteria.

1. Should the table of contents be collapsible?

We are planning on redesigning the table of contents. We will not be adding any toc for the first iteration.

1. What about the legal footer?

Footer should be present. I think it belongs in the chrome epic that @Nirzar will be setting up, separate from article content.

1. Is there any special iconography needed like edit pencils?

I think this is a question for @Nirzar, but as we will not have any editing functionality to begin with we can:

• display edit pencil and forward back to mobilefrontend
• display nothing - I would say let's do this to begin with and add editing later once we have the opt-in/opt-out flows settled (which will live in a separate epic)

See T177367: Initial version of Marvin user interface chrome for the chrome epic

I think for now images should not be clickable until we get the multimedia viewer built.

@ovasileva, I looked into this a little more and our current presentation of image file pages isn't so bad! ...Except that it doesn't actually include the image 😄 This is a known issue (or declined feature request?) of Parsoid, which the Mobile Content Service uses, as documented here, T153801, T148118, and elsewhere. However, the Mobile Content Service supplements the Parsoid responses for these pages with the actual image so clients like Marvin can manually add it to the page content if they want to. My proposal is that we simply add the image instead of trying to remove all the image links! My reasoning is that these pages as currently rendered look decent, it'll be just as much work to neuter image links otherwise, and the experience without clickable images is lousy. So, are you cool if we just add images to these pages?

Technical note for my own posterity:

https://commons.wikimedia.org/api/rest_v1/page/mobile-sections-lead/File%3AThe_World%E2%80%99s_Tallest_Mountain_(15473492788).jpg

{
  "ns": 6,
  "imageinfo": {
    "thumburl": "https://upload.wikimedia.org/wikipedia/commons/e/eb/The_World%E2%80%99s_Tallest_Mountain_%2815473492788%29.jpg",
    "thumbwidth": 720,
    "thumbheight": 480,
    "url": "https://upload.wikimedia.org/wikipedia/commons/e/eb/The_World%E2%80%99s_Tallest_Mountain_%2815473492788%29.jpg",
    "descriptionurl": "http://commons.wikimedia.org/wiki/File:The_World%E2%80%99s_Tallest_Mountain_(15473492788).jpg",
    "descriptionshorturl": "http://commons.wikimedia.org/w/index.php?curid=43724251"
  },
  "id": 43724251,
  "revision": "203344675",
  "lastmodified": "2016-08-07T09:00:57Z",
  "lastmodifier": {
    "user": "Till.niermann",
    "gender": "unknown"
  },
  "displaytitle": "File:The World’s Tallest Mountain (15473492788).jpg",
  "normalizedtitle": "File:The World’s Tallest Mountain (15473492788).jpg",
  "protection": {},
  "editable": true,
  "languagecount": 0,
  "image": {
    "file": "The_World’s_Tallest_Mountain_(15473492788).jpg",
    "urls": {
      "320": "//upload.wikimedia.org/wikipedia/commons/e/eb/The_World%E2%80%99s_Tallest_Mountain_%2815473492788%29.jpg",
      "640": "//upload.wikimedia.org/wikipedia/commons/e/eb/The_World%E2%80%99s_Tallest_Mountain_%2815473492788%29.jpg",
      "800": "//upload.wikimedia.org/wikipedia/commons/e/eb/The_World%E2%80%99s_Tallest_Mountain_%2815473492788%29.jpg",
      "1024": "//upload.wikimedia.org/wikipedia/commons/e/eb/The_World%E2%80%99s_Tallest_Mountain_%2815473492788%29.jpg"
    }
  },
  "hatnotes": [],
  "sections": [
    {
      "id": 0,
      "text": "<span></span>"
    },
    {
      "id": 1,
      "toclevel": 1,
      "anchor": "Summary",
      "line": "<span>Summary</span>"
    },
    {
      "id": 2,
      "toclevel": 1,
      "anchor": "Licensing",
      "line": "<span>Licensing</span>"
    }
  ]
}

In terms of lazy-loading images, they are currently in the acceptance criteria.

Cool, I've added some subtasks on this.

Is there any special iconography needed like edit pencils?

In our last design meeting with @Nirzar, we agreed on going with the "display nothing" approach currently implemented.

In T176958#3726720, @Niedzielski wrote:

I think for now images should not be clickable until we get the multimedia viewer built.

@ovasileva, I looked into this a little more and our current presentation of image file pages isn't so bad! ...Except that it doesn't actually include the image 😄 This is a known issue (or declined feature request?) of Parsoid, which the Mobile Content Service uses, as documented here, T153801, T148118, and elsewhere. However, the Mobile Content Service supplements the Parsoid responses for these pages with the actual image so clients like Marvin can manually add it to the page content if they want to. My proposal is that we simply add the image instead of trying to remove all the image links! My reasoning is that these pages as currently rendered look decent, it'll be just as much work to neuter image links otherwise, and the experience without clickable images is lousy. So, are you cool if we just add images to these pages?

That's okay with me, so long as we can present the actual image. I think the page looks neat as well, at least for the time being!

In T176958#3728229, @Niedzielski wrote:

@ovasileva, assigning to you for further fleshing out! I believe article titles, lead paragraph, article text, and quotations are done. I've made subtasks for hatnotes and lazy loading.

Multiple scripts

What's wanted for this feature? MobileFrontend seems broken to me (see screenshot below). These fonts appear to be hardcoded to one of the following: 'Menk Hawang Tig', 'Menk Qagan Tig', 'Menk Garqag Tig', 'Menk Har_a Tig', 'Menk Scnin Tig', 'Oyun Gurban Ulus Tig', 'Oyun Qagan Tig', 'Oyun Garqag Tig', 'Oyun Har_a Tig', 'Oyun Scnin Tig', 'Mongolian BT', 'Mongolian Baiti', 'Noto Sans Mongolian', 'Mongol Usug', 'Mongolian White', 'MongolianScript', 'Code2000', 'Menksoft Qagan', none of which my system has and the characters are undefined in the default.

There might be little we can do about this. There was an old bug T98565: [4hrs] Mongolian text not displaying correctly in Chrome on Android at the English Wikipedia on Mongolian scrips that we concluded was due to the scripts not being available in the operating system itself. The requirement here would, in that case, refer more to making sure that we can test these scripts on a device that has them installed or if there's anything else we can do in terms of Marvin.

That's okay with me, so long as we can present the actual image. I think the page looks neat as well, at least for the time being!

Cool, I've opened a subtask for this.

@ovasileva, @Jhernandez, continuing the multiple scripts conversation, I think there are some things we can do in the future but they're probably out of scope for this quarter, especially considering the initial deployment is English-only. Please let me know if you disagree.

In T176958#3737468, @Niedzielski wrote:

That's okay with me, so long as we can present the actual image. I think the page looks neat as well, at least for the time being!

Cool, I've opened a subtask for this.

@ovasileva, @Jhernandez, continuing the multiple scripts conversation, I think there are some things we can do in the future but they're probably out of scope for this quarter, especially considering the initial deployment is English-only. Please let me know if you disagree.

I think this makes sense. Let's ignore the scripts requirement for now and we can go back and re-test later.