Page MenuHomePhabricator

Mobile page issues - visual changes for multiple issues
Closed, DuplicatePublic

Description

Background

We will also be changing the treatment for multiple issues. To provide less distraction to the reader, we will not be providing information on the individual issues themselves but will indicate their severity.

User Story

As a reader, I want a summary of issues for pages with multiple issues, so that I am not distracted from individual issue descriptions

Acceptance Criteria

  • Issue severity level will be derived from the severity levels of the individual issues. If an article contains the template {{Multiple issues}}, the issue level of the article will be the highest issue level available

Example: if template {{Disputed title}} has level high, the article https://en.wikipedia.org/wiki/Chinese_unification will have issues appear at high level

  • Each multiple issue level will receive unique copy, appearance, and position within the page (as defined below). Individual descriptions for issues will not be used.

Design Criteria

Multiple issues, where at least one is severe (type=speedy, type=delete)

Multiple issues, where at least one is medium (type=content, type=pov)

Multiple issues, where at least one is low (type=style)

Multiple issues, where all are notice (type=notice, type=move, type=protection)

Notes/Open Questions

Is it possible to have logic that allows us to show/hide section issues?

  • sections can be treated differently than the main section

From user testing: possible confusion around "multiple issues" notice meaning that there are multiple issues listed throughout the article (e.g. a bunch of section issues to be found)

Event Timeline

ovasileva created this task.Apr 5 2018, 2:10 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 5 2018, 2:10 PM

We could also split this up into two tasks, one for the styling and one for severity, but don't know if it will be necessary. Let's keep it all in one place for now and we can decide later.

ovasileva updated the task description. (Show Details)Apr 11 2018, 4:20 PM
Jdlrobson added a subscriber: Jdlrobson.

Likely to need some changes to the underlying templates. Could we link to what those templates are in the description, it's not clear right now?

How is this different from T191528 ? Not at all clear... in fact I'm getting muddled up with both of these tasks. It feels like these two tasks can be merged and worked on together, unless I'm misunderstanding something.

How is this different from T191528 ? Not at all clear... in fact I'm getting muddled up with both of these tasks. It feels like these two tasks can be merged and worked on together, unless I'm misunderstanding something.

Sorry, I'm a bit confused about the parts that are confusing in particular, but let me give this a try: This task focuses on two things: applying the visual changes for multiple issues and the logic around how severity level is displayed only for pages with multiple issues. It follows task T191528  which is about building the logic for the severity levels by the type of the issue itself and applying it for pages with single issues.

This task defines how the severity built in  T191528 can be used to display multiple issues. For example, if a page has two issues, one with medium severity and one with high severity, we would like to display the multiple issues visual treatment with high severity. Does this make sense? Let me know what I can clarify further. In terms of two versus one tasks - whatever makes more sense. I made it more granular but if that's causing confusion maybe a single task would make more sense.

applying the visual changes for multiple issues and the logic around how severity level is displayed only for pages with multiple issues. It follows task T191528 which is about building the logic for the severity levels by the type of the issue itself and applying it for pages with single issues.

Okay. Yes, I don't see much benefit in separating these two things. We'll want to use the style changes to the guide the necessary severity logic so let's merge them together. The danger of not doing that is we'll waste time building something that doesn't quite do what we want it to do. When building the implementator may find it easy to operate in this way, but in terms of scheduling the work, I feel having 2 tasks is just going to cause confusion similar to my experience here.

I wonder if the 3 point estimate on T191528 includes the design element? Let's group chat about it at next opportunity.

applying the visual changes for multiple issues and the logic around how severity level is displayed only for pages with multiple issues. It follows task T191528 which is about building the logic for the severity levels by the type of the issue itself and applying it for pages with single issues.

Okay. Yes, I don't see much benefit in separating these two things. We'll want to use the style changes to the guide the necessary severity logic so let's merge them together. The danger of not doing that is we'll waste time building something that doesn't quite do what we want it to do. When building the implementator may find it easy to operate in this way, but in terms of scheduling the work, I feel having 2 tasks is just going to cause confusion similar to my experience here.
I wonder if the 3 point estimate on T191528 includes the design element? Let's group chat about it at next opportunity.

That makes sense - I merged the acceptance criteria and will close this. Let's try to reestimate at next grooming, assuming the estimate will probably grow.