I will add more examples of how issues will look inside modals

For responsive web only, not desktop.

The link Learn more about fixing this issues comes from the inside of the issue template HTML.

If it is the same for all the page issues, it should be uniquely extracted and shown in the footer of the list of issues.

@Nirzar will provide more mocks with multiple issues to clarify.

Also on what happens if the links are different on the different issue templates.

We should be very strict and gracefully bail out when parsing / changing the HTML as the issue template HTML can change at any point or in any wiki and could have very bad consequences if we have an exception in this view (unresponsive JS, so can't get out of modal, etc).

Open Questions

Q: should we do this work before we structure page issues semantically
A: As a cosmetic update, I think this design can be implemented without having to change much of the existing page issues functionality.
That being said, we should be aware of the limitations of that functionality to determine wether or not to work on this now.
The current limitations are such:

• The ambox type property, which ultimately results in which icon to show, is language specific. Even if wikis use the English ambox templates, the type property is input by users in their language. So for example on English wikipedia, the deletion ambox uses type=delete which results in class="ambox-delete" in the HTML. Spanish Wikipedia however, uses type=serious (probably just to change the icon) for their deletion templates, which results in class="ambox-serious" in the HTML. French Wikipedia on the other hand, uses entirely different templates with (very pretty) icons that don't use the type property at all. Italian wikipedia uses class names like avviso-contenuto etc... For this task however, the language variety might not be a problem since the languages that don't use the English templates don't show up on page issues anyway.

Q: is date tag easily scrapable.
A: nope. On English at least, it's in html like this

<small>
    <i>(April 2010)</I>
</small>
<small class="hide-when-compact">
    <i>(<a href="/wiki/Help:Maintenance_template_removal" title="Help:Maintenance template removal">Learn how and when to remove this template message</a>)
    </I>
</small>

Which could feasible be targeted with a query like $( ".mbox-text-span small:not('.hide-when-compact') > i" ) but that's far from stable or performant.

Design feedback
We probably don't need the lock or move icons, since protected page show up with the lock icon (beside the download/star icons) on mobile, and the type=move templates currently don't show up on page issues.

Misc

@Jhernandez here are some screenshots of the differences in the HTML output & these are the selectors we're using for scraping.

Wow, sad news then... From the description changes proposed:

cc/ @ovasileva @Nirzar to update or split task or delay it until page issues HTML is better structured/annotated.

Props to @Jdrewniak for the docs linked and the comment, very useful

@Jhernandez this sounds reasonable. 4 out of 7 :)

The fourth one was an important one but we can wait till we fix the html structure.

this task was meant to be fixing styling (as part of design debt) so these changes seem minimal but also add value by having long descriptions. I will update the card and create subtasks for ambox-type, help-url, date-tag.

thanks for clean way of conveying what is possible and thanks for the work on docs Jan! :)

We should be very strict and gracefully bail out when parsing / changing the HTML as the issue template HTML can change at any point or in any wiki and could have very bad consequences if we have an exception in this view (unresponsive JS, so can't get out of modal, etc).

This. We've already got lots of cases where this doesn't quite work e.g. T184421

Page issues was always a temporary hack, so limiting what we change here is a good idea. Definitely long term, we should provide editors the tools to tag articles in a mobile friendly way.

Change 419328 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] CSS tweaks to issue overlay

https://gerrit.wikimedia.org/r/419328

Change 419330 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Improve issue overlay

https://gerrit.wikimedia.org/r/419330

Okay! I've got some patches up and on staging for design review.
@alexhollender @Nirzar:

• http://reading-web-staging.wmflabs.org/w/index.php?title=Telecommunications_network&mobileaction=toggle_view_mobile
• http://reading-web-staging.wmflabs.org/w/index.php?title=Rex_Tillerson&mobileaction=toggle_view_mobile

To aid discussions with editors, I've revealed the issues boxes in staging. Where issues are long - this suggests we need to update the underlying template. hopefully with this demo, we can aid that conversation.

Right now, it's not possible to get severity from the templates, so the icons is not going to be possible right now.

@Nirzar @alexhollender let me know if any css tweaks are needed to the issue overlay
With your approval engineers can start reviewing https://gerrit.wikimedia.org/r/419328 and https://gerrit.wikimedia.org/r/419330

@Jdlrobson, @Nirzar, @alexhollender - I'm a bit confused. This task is only in reference to the page issues modal, we shouldn't be making any changes to in-article issues yet. Am I missing something?

Perhaps T187916#4048427 will help when it comes to planning for T159262: [EPIC] Improve page issues.

@Jdlrobson - also noting that we removed the severity from the acceptance criteria when estimating the task, so we don't have to worry about it for now

"To aid discussions with editors, I've revealed the issues boxes in staging. Where issues are long - this suggests we need to update the underlying template. hopefully with this demo, we can aid that conversation."

I am aware this card relates only to issues overlay

Change 419330 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Improve issue overlay

https://gerrit.wikimedia.org/r/419330

Change 419328 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] CSS tweaks to issue overlay

https://gerrit.wikimedia.org/r/419328

Had a chat with designers. I'm blocked on @Nirzar providing me with some icons and then we can wrap this work up!

@Jdlrobson

one small style fix with the styles
hide-when-compact computed font size is 14.4 in your change. it should 13px. same for the date and the "learn more" link as well. 16px for the main title and 13px for everything else

Change 419644 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Add icons for all the types of issues

https://gerrit.wikimedia.org/r/419644

Tweak taken care of:
https://gerrit.wikimedia.org/r/419645 CSS tweak: Drop issues font-size for hide-when-compact

Icons are taken care of:
https://gerrit.wikimedia.org/r/419644

Both patches on staging:
http://reading-web-staging.wmflabs.org/wiki/Telecommunications_network?useformat=mobile

Change 419644 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Add icons for all the types of issues

https://gerrit.wikimedia.org/r/419644

• The icon types are missing on staging. I could see them before i can't now
• The modal title is issues instead of page issues
• the alignments are off
• the font size needs fixin

This is not ready for sign off. I think we need to talk about the process here. few cards have gone through the same thing, where they went to sign off and even to production. also we need a criteria for assigning design for sign off for user facing cards like this one.

@Nirzar can you be more specific?

The icon types are missing on staging. I could see them before i can't now

Looks like staging was running outdated code. Please check again. Not sure what happened there. The icons are showing for me now.

The modal title is issues instead of page issues

Again outdated code.

the alignments are off

the font size needs fixin

Can you be more specific? Which font-size? What is it? What should it be?

.overlay-cleanup .issue-details {
padding-left:55px;
}
.overlay-cleanup .cleanup li .issue-notice .mw-ui-icon {
top:3px; 
}

font size for date should be 13px. same as other smaller text on the screen.

.overlay-cleanup .issue-details {
padding-left:55px;
}

Is the purpose to align it with the X (close) icon? In which case it looks like it should be 54px, no (that's it's width)?

.overlay-cleanup .cleanup li .issue-notice .mw-ui-icon {
top:3px; 
}

That would be incurring tech debt which I'd rather avoid. Can this not be fixed in the icon glyph itself? Why is this happening ? cc @Volker_E

font size for date should be 13px. same as other smaller text on the screen.

Looks like the date does not have the hide-when-compact class. Only way to style date right now would be to style all small tags this way.
I'm a little worried about side effects... should we rely on "> small" (I think this makes sense?) or "small". @Jdrewniak did you get a sense of how frequent small tags are used in these templates?

Is the purpose to align it with the X (close) icon? In which case it looks like it should be 54px, no (that's it's width)?

the purpose is to align the Page Issues title to the content.

That would be incurring tech debt which I'd rather avoid. Can this not be fixed in the icon glyph itself? Why is this happening ? cc @Volker_E

the glyph should not have paddings according to our guidelines

let me tinker with it too, the paragraph does not look like it is top aligned for some reason.

Looks like the date does not have the hide-when-compact class. Only way to style date right now would be to style all small tags this way.

smaller font size for <small> tag does make semantic sense. even if it gets applied to non-date elements, it still should not mess things up because <small> tags intended purpose is to make things small, 13px is small :)

Change 420129 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Tweaks to issue overlay

https://gerrit.wikimedia.org/r/420129

^ That fixes 2/3 of the issues and is on staging for you to vet (you'll need to do that today or early Monday). I'm not sure why the paragraph is not top aligned. When I inspect the icon and the paragraph, their elements are aligned. Could be a rendering bug?

Change 420129 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Tweaks to issue overlay

https://gerrit.wikimedia.org/r/420129

Tested... Looks great! a minor followup would be the top alignment of icon and the text but not a blocker.

QA has already passed this already. do we need QA again after the tweaks?

otherwise we can resolve this!!!

Tested on staging and looks good. As this is a bigger change, let's wait until it hits production and test again.

@Nirzar - should we set up a separate task for the followup changes?