Page MenuHomePhabricator

Threading: As a contributor/reader, I want to be able to identify each topic, easily read the full thread of comments and know who is replying to whom under each topic.
Closed, ResolvedPublic

Assigned To
Authored By
OTichonova
Jun 9 2022, 1:26 PM
Referenced Files
F35601097: Screen Shot 2022-10-19 at 3.44.56 PM.png
Oct 19 2022, 8:47 PM
F35601095: Screen Shot 2022-10-19 at 3.40.56 PM.png
Oct 19 2022, 8:47 PM
F35600758: Screen Shot 2022-10-19 at 1.34.41 PM.png
Oct 19 2022, 7:30 PM
F35600751: Screen Shot 2022-10-19 at 1.34.59 PM.png
Oct 19 2022, 7:30 PM
Restricted File
Oct 11 2022, 1:42 PM
Restricted File
Oct 11 2022, 1:42 PM
F35536082: IMG_9166 2.PNG
Sep 27 2022, 9:18 AM
F35536073: IMG_9165.PNG
Sep 27 2022, 9:18 AM
Tokens
"Cup of Joe" token, awarded by JMinor.

Description

Why are we doing this?

Rethinking the visual UI of the threading was done to:
Adapt and implement the new features developed on the web by the Editing team for their Talk pages project
Find a better way of showing nested threads than using indentation. The indentation (as seen on we ) takes up too much space on mobile, shrinks the line width and is less clear on a smaller screen.
Create more visual hierarchy & distinction between topics & threads.

Audience story

As a contributor/reader, I want to be able to identify each topic, easily read the full thread of comments and know who is replying to whom under each topic

Relevant information

Access

  • Topics found on each article talk page will be collapsed when first opened. Contributor/reader can see comments once they tap anywhere on the topic cell.

Once tapped the cell will open (accordion) and display all topics (all comments visible).

Organization

  • Comments will be organized from least to most recent.
  • The contributor will be able to respond to any comment in the thread.

The UI

  • Minimum height of the reply field will be 4 lines. No maximum.
  • Each comment will have a
    • A ‘reply’ button at the end of it.
    • The signature and timestamp at the end of it.
    • Link to the author's username.
  • The ‘sticks’
    • The number of sticks will indicate how deep a comment is nested.
    • Width of all ‘sticks’ cannot take more than half of the available field width.
    • If a comment is nested deeper than can be displayed via the sticks, a ‘+ [ x ]’ value will be shown to indicate how much deeper the comment is.
    • Longest ‘sticks’ are closest to the text, shortest ‘sticks’ farthest from the text.
    • ‘Stick’ height decreases by 8px
    • ‘Sticks’ are 6px apart.
ExampleField: Max. 1/2 field of sticks, and min. 4 line-height fieldShorter comment deeply nestedLonger commentLonger comment deeply nested
Subscribed.png (2×375 px, 189 KB)
Group 427318483.png (214×416 px, 9 KB)
Max nested comments=29.png (131×375 px, 7 KB)
Cell-1.png (382×375 px, 27 KB)
Cell.png (403×375 px, 28 KB)

See more information about the UI in the - Figma file ‘Talk pages screens & specs'

Additional research and resources

Event Timeline

LGoto triaged this task as Medium priority.Jun 13 2022, 6:40 PM
Tsevener updated the task description. (Show Details)

Things remaining to develop:

Finalizing sticks, particularly when the additional indention label appears.

@OTichonova Experimental build 1856 has our final proposed sticks implementation. Details are below for rethinking the requirements in this task description:

  1. Shows up to 10 sticks for compact width size classes, up to 25 sticks for regular width size classes.
  2. Shows a minimum stick height if the comment view is not tall enough to display the entire pyramid.
  3. Currently the "+N" label does not take into account the sticks the label itself hides.

Things that are easily adjustable:

  • Spacing
  • The maximum number of sticks based on size classes.
  • We can easily consider the sticks that the label covers up as a part of the count. This means instead of starting at "+1" it may jump to something like "+3" for the next indentation level. Or we can ensure that the label does not cover any sticks, so that +1 is accurate.

Things that we cannot adjust:

  • We cannot easily measure the width of the whole view or the height of the text for determining the number of sticks to display. It's easiest for us to start with a predetermined maximum number of sticks, based on size class.
  • We cannot force the comment to display 4 lines of text.

Thanks!

Tsevener moved this task from Doing to Needs Design on the ios-app-v7.0 board.
Tsevener added a subscriber: Dmantena.

Hi @Tsevener,
Sorry this took a while I was trying to play around and see what other options we could consider for better visual distinction and consistency.

  1. I think we should keep it to 10 sticks max. at all times.
  2. Sounds good.

Shows a minimum stick height if the comment view is not tall enough to display the entire pyramid.

  1. I think that the label covering some of the sticks is no issue, I think we should start doing the +N label after 10 and not consider the sticks that are being covered in the count.
  2. Can we adjust the spacing between the actual lines to be 8points? Currently it looks like it is 6pts.

While scrolling through the different talk pages I found some UI issues shown below, sorry if these are already being dealt with.

  1. Found an overlap between the thread and new topic on 'Lunar' article talk page under the topic 'Requested move 6 February 2019' (at the end of the topic)
IMG_9164.PNG (1×750 px, 236 KB)
  1. Long threads in article talk pages like on 'Jupiter' with some threads being 40 or even 126 comments long, the card takes a long time to open, maybe we should add a loading indicator (maybe something similar to what was added to the reply card, when its waiting to be published?)
Example from reply card
IMG_9168.PNG (1×750 px, 182 KB)
  1. When I was testing the threading on my own user page 'OT1993' on testwiki the labels were a tiny bit inconsistent. Also I added a super long comment at the very end of the topic thread and I couldn't scroll to the very end of the last long comment in the thread.
Inconsistency with the labelsWasn't able to scroll further & couldn't get to the 'Reply' button
IMG_9165.PNG (1×750 px, 195 KB)
IMG_9166 2.PNG (1×750 px, 293 KB)

@OTichonova

Sounds good, I'll make these changes! I think (hope) a lot of the bugs you found were only on the builds that attempt to fill up 1/2 of the view with sticks - that's where we ran into the most problems. I can't reproduce most of them in our simpler approach in Experimental 1856.

Long threads in article talk pages like on 'Jupiter' with some threads being 40 or even 126 comments long, the card takes a long time to open, maybe we should add a loading indicator (maybe something similar to what was added to the reply card, when its waiting to be published?)

Good find. This one concerns me, because we see the hang upon scrolling too, which isn't easy to get around with a spinner unfortunately. I may need to spend a couple of days tinkering with this and will get back to you.

Hi!
Okay, I was on the wrong build earlier. But for build (1984) I have found the following 2 small things.

  1. The cells don't have the time. They have the date (when the comment was posted) but not the time. Shown below.
Figma designsIn app
{F35562623}{F35562625}
  1. The sticks and numbers look great! The one thing I realized (which is my mistake) is that the numbers by the sticks are too light and was wondering if we could change the color of the sticks and the numbers to #A2A9B1?

Thanks!

Things remaining to develop:

Design review feedback from comment above ^

Hi @OTichonova! I have timestamps mostly working, but so far I've had to stray a bit from the way timestamps are in the mocks, so I thought I'd explain in case you had some tweaks before I open the PR:

  1. I am telling the system we would like the format "hours:minutes timezone, day.month.year" to get close to your mocks (I will talk about timezone in a bit), but I'm using an API that tells the system to adjust it based on the locale (and locale is set from whatever the language the Wiki is). So an EN Wiki talk page would display the date 01/25/2021, whereas DE Wiki would display the date as 25.01.2021.
  1. The API sends us timestamps all based on UTC, which is good because it's consistent. But unfortunately I found on DE Wikipedia that the signatures may be in local time:
{
"timestamp": "2022-04-29T14:43:00Z",
"author": "TSevener (WMF)",
"type": "comment",
"level": 1,
"id": "c-TSevener_(WMF)-2022-04-29T14:43:00.000Z-Test_new_topic",
"replies": [],
"html": "Testing! <a rel=\"mw:WikiLink\" href=\"./Benutzer:TSevener_(WMF)\" title=\"Benutzer:TSevener (WMF)\" id=\"mwBA\">TSevener (WMF)</a> (<a rel=\"mw:WikiLink\" href=\"./Benutzer_Diskussion:TSevener_(WMF)\" title=\"Benutzer Diskussion:TSevener (WMF)\" class=\"new\" id=\"mwBQ\">Diskussion</a>) 16:43, 29. Apr. 2022 (CEST)"
}

Note how the timestamp shows 14:43 (UTC) and the signature shows 16:43 (CEST). I'm guessing the local talk signatures may be a Wiki-specific configuration? I decided to add the timezone to the label to hopefully help prevent some confusion with the offset (iOS displays UTC as a GMT timezone):

Screen Shot 2022-10-19 at 1.34.59 PM.png (173×349 px, 24 KB)

And here's how an EN Wikipedia cell looks:

Screen Shot 2022-10-19 at 1.34.41 PM.png (172×350 px, 24 KB)

Let me know if you think this is a dealbreaker. Also tagging @DLynch in case he has any thoughts on displaying the timestamp vs. signatures. I think the API is working correctly, in that timestamps are given to us consistently in UTC, but it does feel odd when they are displayed together with a local signature like this.

@OTichonova

For the depth indicator and label change, I went with a different semantic theme element from what we had. It has colors set like this:

light: #A2A9B1
sepia: #646059
dark: #C8CCD1
black: #C8CCD1

Let me know if these other theme colors work for you!

@OTichonova Actually it looks like Android is doing local time for this label (I'm CDT):

DE Wikipedia:

Screen Shot 2022-10-19 at 3.40.56 PM.png (171×375 px, 14 KB)

EN Wikipedia:

Screen Shot 2022-10-19 at 3.44.56 PM.png (165×369 px, 13 KB)

So I can just do that, and remove the timezone, if that's better.

Tsevener moved this task from Doing to Blocked or Waiting on the ios-app-v7.0 board.

Hi @Tsevener!

For the depth indicator and label change, I went with a different semantic theme element from what we had. It has colors set like this

Okay sounds good, thank you!

In regards to the timestamp: it is such an interesting and slightly confusing thing.
Let's do local time as well and not have the extra timezone displayed, thank you for looking into this!

As I recall, the reason we return the API timestamp in UTC is that internally we just use the server's timezone, and all the WMF wikis are kept on UTC. On-wiki display of dates is handled via $wgLocaltimezone and LanguageConverter knowing about language-specific date formatting preferences.

ABorbaWMF subscribed.

Looks good to me on 7.0.0 (2003)

JMinor claimed this task.
JMinor awarded a token.