Page MenuHomePhabricator

Topics: As a contributor/reader, I want to be able to have a brief overview of the main topics on each article talk page.
Closed, ResolvedPublic

Assigned To
Authored By
OTichonova
Jun 9 2022, 12:57 PM
Referenced Files
F35524472: No signatures open thread.jpg
Sep 19 2022, 8:28 AM
F35524470: No signatures.jpg
Sep 19 2022, 8:28 AM
F35524480: No title open.jpg
Sep 19 2022, 8:28 AM
F35524478: No title closed.jpg
Sep 19 2022, 8:28 AM
F35519634: Black.png
Sep 13 2022, 10:19 PM
F35519632: Dark.png
Sep 13 2022, 10:19 PM
F35519630: Sepia.png
Sep 13 2022, 10:19 PM
F35519628: Default.png
Sep 13 2022, 10:19 PM

Description

Why are we doing this?

The intention is to make talk pages less overwhelming, informative, and more timely (help contributors identify recent discussions). Each topic is broken down into a cell that shows information like the title, an overview of the first comment, the timestamp, and how many people are participating in the discussion. This type of summary page for talk pages can be reutilized for user talk pages.

Audience story

As a contributor/reader, I want to be sure what kind of talk page I land on.

Relevant information

Topics page
(Figma slide 4 )

  • Each topic is shown as a separate cell that will always have the same height, and it includes:
    • Subscribe icon and button (only visible to those who are logged in)
    • 2 line-height title, after that it truncates
    • Timestamp
    • 3 line-height preview of the first comment, after that it truncates
  • Avatar icon & the number of contributors; speech bubble icon & the number of comments
  • Tapping anywhere on the cell triggers the cell to open and reveal the whole thread.
Logged outLogged in
background color.png (821×375 px, 70 KB)
background color-1.png (812×375 px, 67 KB)

Notices & alerts (coffee roll) on top of article talk pages

  • Sometimes article talk pages have extra information about the content located above the topics called the coffee roll. This coffee roll often includes notices, alerts, and instructions.
  • The information will be displayed right under the header.
  • The coffee roll content will be displayed in a yellow card.
  • The text will be truncated after 2 lines.
  • There will be a ‘Read more’ button for people to see all of the coffee roll content.
    • Once they tap on 'Read more' all of the content will be displayed in a separate page.
Coffee roll on web article talkOn iOS topics pageTapping 'Read more' takes you to the full content page
Screenshot 2022-07-15 at 15.04.58.png (1×2 px, 395 KB)
background color.png (812×375 px, 68 KB)
Coffee roll.png (812×375 px, 61 KB)

Extra information above topics in user talk pages

  • Sometimes user talk pages have extra information located above the topics.
  • The information will be displayed right under the header.
  • The content will be displayed in a white card.
  • The text will be truncated after 2 lines.
  • There will be a ‘Read more’ button for people to tap to see all of the content.
    • Tapping on ‘Read more’ will show all of the content in a separate page.
User talk topics pageTapping 'Read more' for full page of additional info.
background color-1.png (812×375 px, 54 KB)
background color.png (812×375 px, 26 KB)

Empty state on article talk
(Figma slide 3 )
If the article talk page is empty, show the empty state underneath the article talk page header.

  • Copy: Title: ‘The conversation starts here‘
  • Next: ‘Talk pages are where people discuss how to make content on Wikipedia the best that it can be. Start by adding a new discussion topic to connect and collaborate with a community of Wikipedians.’
  • Next: Button ‘Add a new topic’
Empty state
empty state.png (812×375 px, 53 KB)

Empty state on user talk

  • Illustration: same as the one found on article talk empty state
  • Copy
    • Title: ‘Start a discussion with [username]’
    • Next: Talk pages are where people discuss how to make content on Wikipedia the best that it can be. Start a new discussion to connect and collaborate with Elmo. What you say here will be public for others to see.
    • Next: Button: ‘Start a discussion'
Empty state
empty state.png (812×375 px, 44 KB)

Entry points
(Figma slide 2 )
Article talk pages can be accessed through:

  • Notification center
    • The contributor will tap on a new talk page message, and then tap on ‘View comment’ from the detail page view.
    • Once ‘View comment’ is tapped, the topic inside of which the new comment is located will uncollapse. The contributor will be taken to the correct part of the thread where the comment is located to prevent them from scrolling to find the comment.
  • Article page
    • Accessed by tapping on the ‘View talk page’ at the bottom of any article.

Relevant tickets

Subscribe/unsubscribe to topic

Figma file Slide 8

Audience story
As someone who is interested in a specific topic on a talk page, I want to be able to get notifications when other people comment on it.

Relevant information

  • Subscription is only available to logged-in contributors. So subscribe icon and button are revealed for logged-in contributors next to the down/up arrow.
  • The feature ‘enables you to elect to receive a notification via Echo when someone posts a new comment in any conversation you have decided to "subscribe" to’.
  • This feature is borrowed from the editing team's work.
    • Phab ticket about manual topic subscription T263820
      • In the future they hope for automatic subscription to be possible for the topics one has commented on. Found under T263819

Activation

  • Tapping on the icon & button subscribes the contributor to the topic

Toasts

  • A toast appears at the bottom of the page after subscribing
    • Copy: Filled bell icon
    • Next: ‘You have subscribed! You will receive notifications about new comments in this topic.’
  • A toast appears at the bottom of the page after unsubscribing
    • Copy: Filled bell slash icon
    • Next: ‘You have unsubscribed. You will no longer receive notifications about new comments in this topic.’
SubscribedUnsubscribedLogged out - topic pageLogged out - thread
background color.png (812×375 px, 71 KB)
background color-1.png (812×375 px, 72 KB)
background color-2.png (821×375 px, 70 KB)
Open all threads.png (812×375 px, 72 KB)

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

Additional research and resources

Event Timeline

OTichonova renamed this task from Topics page: As a contributor/reader, I want to be able to have a brief overview of the main topics on each article talk page. to Topics: As a contributor/reader, I want to be able to have a brief overview of the main topics on each article talk page..Jun 9 2022, 3:35 PM
LGoto triaged this task as Medium priority.Jun 13 2022, 6:40 PM

Hi @OTichonova! I have a few extra questions and comments for this task:

  1. Loading state: When the user first lands on the page, we'll need to fetch their talk page data. The header article title and "Article talk" label will be there, but there's a chance we won't have the article description label or the image yet, and we won't have talk page topics or replies yet. In the current talk page we use this blue progressive loading bar right underneath the header view. We should be able to do this again on the redesign if you want, but just wanted to give you a heads up about it.
  1. Error state: There could be an issue when fetching the talk page data (article description, article header image, talk page topics, replies). This could be due to a network connection issue (if we have no older cached data to fall back on), or some failure on the Wikimedia server's side. Can you define an error state for us to use for this? This is what the current error state looks like:

talk page error state.png (998×534 px, 161 KB)

  1. Error state when subscribing / unsubscribing - Subscribing and unsubscribing takes another network call, and it could fail. What would you like to show if there's an error after tapping the subscribe button?
  1. Loading state when subscribing / unsubscribing - generally I think it feels best when we optimistically switch over the button state immediately, even though this subscription call could take a while (this is what we did for Notifications marking as read). This means there won't be a loading state for it. If there's a failure in the call though, the state could be inaccurate, and it will be updated the next time we successfully load the screen. Let me know if this seems like a problem - happy to talk through alternatives.

Hi @Tsevener! Thanks for your notes.

  1. Loading state: Using the existing blue progressive loading bar would work and will be consistent with other times a page is loading the app.
  2. Error state with no fallback:
Unable to load page with no fallback.png (812×375 px, 15 KB)
  1. Error state when subscribing/unsubscribing:
Unable to subscribe to topic.png (812×375 px, 72 KB)
  1. Just to clarify, by 'state might be inaccurate' are you saying it will show that the person has subscribed and show the confirmation snack bar, but when they reload the page the topic will still be unsubscribed?

(there is now a ticketT312314 where you can find the mockups found in this message, and more info can be found in the Figma file slide 15)

@OTichonova sorry I missed your question:

Just to clarify, by 'state might be inaccurate' are you saying it will show that the person has subscribed and show the confirmation snack bar, but when they reload the page the topic will still be unsubscribed?

Yeah, that's what we're starting to think would be the easiest for us. Otherwise we would have to keep track of which topic views have in-progress subscribe calls that must be updated later once the calls go through or not. This model is more of a fire-and-forget optimistic approach.

You can test Notifications to sortof see what I'm going for actually:

  1. Load notifications screen. Enter airplane mode without Wifi.
  2. Swipe some mark as read or unread.
  3. Cell state changes, but user also sees a "No internet connection" banner.
  4. Leave airplane mode.
  5. Pull to refresh. State restores back to original state.

Although I think the "success" banner for this feature might make it feel a bit more awkward, so maybe we can suppress the success banner until we're certain the call went through successfully.

Hi @Tsevener, thanks for the clarification.
I think suppressing it until the call goes through makes sense.

Hi @OTichonova,

Here are a few topic edge cases that I wanted to document. Can you let us know how you want us to display these?

  1. Threads that occur at the top of the screen, before the first official topic. This is different from the coffee roll in that the API is able to parse out individual replies and send it to us because of the existence of signatures, but the title is empty. (example: https://en.wikipedia.org/wiki/User_talk:Brion_VIBBER, the very first bold, signed text. For now it's considered one reply, but it could turn into its own long thread). I don't think we'll have the ability to subscribe to these either, but we still need to do further testing to confirm.
  1. Topics that have no threads. Due to a lack of signatures, it's possible for some topics to have a title and some body text, but that body text has no signatures. (example: https://test.wikipedia.org/wiki/Talk:Meow_Meow_Meow topic "Clarification") The API is not able to parse any replies, so there's no ability to inline reply (so the entire topic is uneditable). It looks like we also can't subscribe to these types of topics.
  1. Subheader topics. It's possible to have subheaders in a topic and reply threads underneath (example: https://en.wikipedia.org/wiki/Talk:Judith_Resnik topic "Worked for JRs scholarship program as an undergrad".) The API returns this to us as a top-level topic; that's also how we handled these on old talk pages and that's how Android is currently handling it. However I notice web doesn't have a subscribe button for these subheaders. Just a heads up that we may not be able to subscribe to these types of topics, but I'll do more further testing to confirm first.
  1. On web, you can add a topic without a title, and it ends up getting appended to the previous topic. As discussed, this is a known bug on web's side. We'll avoid this bug on iOS by forcing the user to provide a topic title before allowing them to Publish.

@OTichonova Do you have per theme colors available for the coffee roll background color?

Hi @Dmantena!
Here they are (the changing background color of the coffee roll is indicated in the squares):

DefaultSepiaDarkBlack
Default.png (1×375 px, 75 KB)
Sepia.png (1×375 px, 79 KB)
Dark.png (1×375 px, 75 KB)
Black.png (1×375 px, 75 KB)

@cmadeo What do you think about this combo? I borrowed the sepia, dark and black from the 'base' row.

Hi @OTichonova,

Here are a few topic edge cases that I wanted to document. Can you let us know how you want us to display these?

  1. Threads that occur at the top of the screen, before the first official topic. This is different from the coffee roll in that the API is able to parse out individual replies and send it to us because of the existence of signatures, but the title is empty. (example: https://en.wikipedia.org/wiki/User_talk:Brion_VIBBER, the very first bold, signed text. For now it's considered one reply, but it could turn into its own long thread). I don't think we'll have the ability to subscribe to these either, but we still need to do further testing to confirm.
  1. Topics that have no threads. Due to a lack of signatures, it's possible for some topics to have a title and some body text, but that body text has no signatures. (example: https://test.wikipedia.org/wiki/Talk:Meow_Meow_Meow topic "Clarification") The API is not able to parse any replies, so there's no ability to inline reply (so the entire topic is uneditable). It looks like we also can't subscribe to these types of topics.
  1. Subheader topics. It's possible to have subheaders in a topic and reply threads underneath (example: https://en.wikipedia.org/wiki/Talk:Judith_Resnik topic "Worked for JRs scholarship program as an undergrad".) The API returns this to us as a top-level topic; that's also how we handled these on old talk pages and that's how Android is currently handling it. However I notice web doesn't have a subscribe button for these subheaders. Just a heads up that we may not be able to subscribe to these types of topics, but I'll do more further testing to confirm first.
  1. On web, you can add a topic without a title, and it ends up getting appended to the previous topic. As discussed, this is a known bug on web's side. We'll avoid this bug on iOS by forcing the user to provide a topic title before allowing them to Publish.

Hi @Tsevener!
*the designs for the edge cases below (and additional designs) can be found in the main Figma file next to slide #5 'Threading'

  1. For this case, I think it is better not to show anything, and just leave the area next to the arrow blank as shown below.
Closed threadOpened thread
No title closed.jpg (812×375 px, 129 KB)
No title open.jpg (812×375 px, 137 KB)
  1. So after running through a couple of options, I landed on doing something similar to what web does, where they just do not display the 'subscribe' or 'reply' button or the date / number of participants in the thread (another option was showing the buttons but having them be disabled). Let's go with the option below but this is something I will test in our next usability test/add to the talk page FAQs.
Closed threadOpened thread
No signatures.jpg (812×375 px, 142 KB)
No signatures open thread.jpg (812×375 px, 147 KB)
  1. Good to know, thanks! This totally fine, I think these subheader's might have been outside the V1 scope.
  1. Sounds good, thank you for documenting this here.

Things remaining to develop:

  • General performance and layout quirk improvements for cell display, cell expand/collapse, new topic insert, and new reply insert
  • iPad tweaks (use readable content guide more)
  • Coffee Roll Read more screen
  • Empty state
  • Deep linking (tapping from notifications center takes user to particular thread and uncollapses)
  • Topic edge case display (see previous comment)

Things remaining to develop:

  • iPad tweaks (use readable content guide more)
  • Topic edge case display (see previous comment)
Tsevener moved this task from Doing to Ready for Development on the ios-app-v7.0 board.
Tsevener added a subscriber: Dmantena.
Tsevener moved this task from Doing to Needs Code Review on the ios-app-v7.0 board.

Hi @OTichonova

I made a few adjustments in this PR (see screenshots at the link) to line things up a little bit better for iPad. Let me know what you think and if there's anything else you'd like us to do for it. Thanks!

Hi @Tsevener !
These look much better, thank you for adjusting the margins.

@OTichonova @cmadeo What are your thoughts about the question raised in https://github.com/wikimedia/wikipedia-ios/pull/4364#pullrequestreview-1157233981? Do the iPad margins look okay with the text? Should the button extend to be as wide as the text? Thanks! 🙏

@Tsevener it looks like this is the standard 'primary' button size, so let's keep this as is for now. We might want to define a new button width for 'large' buttons on iPad in the future, but I'd rather we not 'one-off' edit buttons and text widths (very open to making universal changes though!). @OTichonova please feel free to override though!

Hi @Tsevener,
+1 to Carolyn's comment. We should keep the buttons as it is without extending them to the text width at this time. Thanks!

ABorbaWMF subscribed.

Looks good to me on 7.0.0 (2009)