Page MenuHomePhabricator

Display categories for logged-in users on mobile web stable
Open, LowPublic

Description

Story:

As a logged in user, I want the ability to easily view categories for articles

Acceptance criteria:

  • Display categories for logged-in users on mobile web stable
  • Categories will be collapsed under a section
  • Full list of categories will be displayed after uncollapsing

Design

Screen Shot 2021-05-03 at 12.59.45 PM.png (697×413 px, 63 KB)

Event Timeline

ovasileva updated the task description. (Show Details)
bmansurov set the point value for this task to 1.Dec 7 2016, 5:43 PM

I am new to open source contributions, I want to start with this Can you give me the details how to proceed

Hi @Rammanojpotla this is not the best one to start with. We tag tasks with "Easy" or "Needs volunteer" if we think they suitable so please peruse through this list at your leisure.

Jdlrobson lowered the priority of this task from Medium to Low.May 17 2017, 9:22 AM

What does this task need a volunteer for? This is just a setting, AFAICT.

Jdlrobson changed the task status from Open to Stalled.Oct 3 2018, 8:00 PM

Lots of issues with this feature as detailed in T24660. We'll want to fix these before turning this on in stable. It's not production ready.

Why only for logged in users? A lot of my friends that read but do not edit Wikipedia use categories to navigate related topics, there really isn't much use to making non-signed in mobile users complete second class citizens of Wikimedia websites (as is already the case), you don't need an account to view categories on desktop mode, this would probably be best if it were added to ALL mobile users' interface, would probably also require less maintenance.

Jdlrobson renamed this task from Display categories button for logged-in users on mobile web stable to Display categories for logged-in users on mobile web stable.Apr 27 2021, 9:46 PM
Jdlrobson changed the task status from Stalled to Open.
Jdlrobson updated the task description. (Show Details)

No analysis needed here. We can already configure categories on for logged in users. The problem here is more what we want to turn on (T246049) which likely blocks this.

Next steps:

  1. We will start with T246049: Remove the category overlay feature and output html-categories and remove the overlay for AMC only
  2. For all logged-in users, we would like to still provide the full list of categories, but also to have the ability to collapse them. @alexhollender has provided a mock here:

Screen Shot 2021-05-03 at 12.59.45 PM.png (697×413 px, 63 KB)

Currently, we will begin with T246049: Remove the category overlay feature and output html-categories and prioritize 2 at a later time due to other high-priority work

Jdlrobson removed the point value for this task.

Need re-estimate

MusikAnimal subscribed.

@ovasileva @Jdlrobson Community-Tech is hoping to take this on as the solution to the #3 wish on the 2023 Wishlist Survey. The only changes we hope to make from what's outlined here are (a) show this to all users, not just logged-in, and (b) lazy load the HTML for the categories to avoid downloading all that HTML when it won't be seen. Do either of you have any comments or concerns with this? The lazy-loading isn't necessary and we may even change our minds about that.

Note also we plan to add some simple statsv tracking to answer the question of how many logged-out users use categories on mobile. That is tracked at T335037.

@MusikAnimal is this still patch-welcome and of wishlist-interest but needs a community patch?
Or did the analysis turn up some complication?

In T152199#9102296, @Sj wrote:

@MusikAnimal is this still patch-welcome and of wishlist-interest but needs a community patch?
Or did the analysis turn up some complication?

Our team was unfortunately unable to take it on. More info at https://meta.wikimedia.org/wiki/Community_Tech#August_8,_2023:_Wish_Updates

Ouch. This and the lack of public updates about dark mode (with technical discussions explicitly private) feels disconcertingly open-ended. Other than the 150+ people chiming it to say this is important, what sort of research into importance to readers needs doing? How can those who see the need contribute to that research? This does not need to be a big deal; it can be implemented as a [client-side] user option at first if the concern is causing confusion for those who don't expect it, &c.

Unfortunately, our key partner, the Web team, will not tackle this wish now. The importance of categories to readers must be researched further to prioritize this wish

In T152199#9188517, @Sj wrote:

Ouch. This and the lack of public updates about dark mode (with technical discussions explicitly private) feels a bit dystopian. Other than the 150+ people chiming it to say this is important, what sort of research into importance to readers needs doing? How can those who see the need contribute to that research? This does not need to be a big deal; it can be implemented as a user option at first if the concern is causing confusion for those who don't expect it, &c.

Unfortunately, our key partner, the Web team, will not tackle this wish now. The importance of categories to readers must be researched further to prioritize this wish

Hi @Sj - just wanted to chime in with a quick update on the status dark mode. We (the Web team) are planning to build out dark mode for this current fiscal year. Some of our initial documentation is available on this project page. In terms of the development itself, we have been focusing on a pre-requisite for dark mode - building out the ability for logged-out users to set preferences (such as dark mode) (T333867: TDMP Proposal: Preference Persistence For Anonymous Users), which we are currently wrapping up. We have yet to begin more detailed technical discussions on implementation. We plan on starting these within the next few weeks. As soon as we're ready to begin discussions, we'll be updating the project page linked above and launching conversations across a number of communities.

Aha, thanks for the pointers! I didn't know the accessibility project would do more than typography. The reading-settings panel mockup looks practical and lovely.

Screen Shot 2023-09-21 at 22.27.38.png (782×456 px, 38 KB)

There may be an immediate win to be had in deploying just dark mode for logged-in users; just as I imagine a smaller immediate win in adding "show categories" as an opt-in feature of mobile web. Easier than solving the more general challenge [= the default presentation] for everyone... but I realize logged-out prefs is its own long-awaited victory.

just as I imagine a smaller immediate win in adding "show categories" as an opt-in feature of mobile web.

Hey @Sj FWIW (in case it wasn't clear) categories can be enabled for logged in users currently by enabling advanced mode here: https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto=Main+Page

Screenshot 2023-09-22 at 9.40.47 AM.png (630×979 px, 131 KB)

The HotCat gadget also has code that will instruct logged in users to enable advanced mode if they want to edit categories. My understanding with the wishlist item was more about enabling the display of categories for anonymous users.
{F37751308}

Yes, thanks - one of the hangups being the lack of prefs for anons (which I deeply, deeply appreciate is being worked on now.) I clarified my comment above.

But please note account creation is inaccessible on mobile is for many people, based on how we currently handle range blocks. Right now I can't create a new account using a private-browsing firefox tab because the ipv6 involved has been blocked. The error messages don't suggest there may be an easy solution.

<aside style=font-size:small; font-face:questionable>
I suspect one hackish solution to a range of such problems might be offering a smooth ~two-click way to create a new non-editing accounts for the purposes of reading prefs: so that anyone logged out could be shown the same prefs as logged-in users, and on selecting them it asks if they have an account after trying to set a pref, not before showing prefs, and if no account it autogenerates one. But informative elements like categories and navboxes are highly curated, relevant to contextualize pages and help find others like them, useful enough to be mentioned regularly in both research papers and the popular press. Better to simply cache them for all mobile users, and at worst hide them until someone turns on a local "show me" pref... which shouldn't depend on something like "user account status" which can be blocked for any reason.
</aside>

My unscientific attempt to test how long it takes to toggle the pref from scratch, starting on es. ;)

photo-of-mobile-wp.jpg (956×600 px, 127 KB)