Page MenuHomePhabricator

[Epic] Display the categories on the mobile site for everyone
Open, NormalPublic

Description

Categories are currently filtered out of the pages. I think we should add them in a font that is just a tad smaller than the normal text. Needs clear but unobtrusive separation from the the rest of the article.


Version: Stable
Severity: normal
See also: T71984: Category view shows no articles in the mobile app

Details

Reference
bz22660
Related Gerrit Patches:
mediawiki/extensions/MobileFrontend : masterMove Category button to beta

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Florian changed the task status from Open to Stalled.May 19 2015, 4:45 PM

This could be (partially) be fixed by T97581: [EPIC] New Table of Contents Overlay accessed from Sticky Footer, or at least it will help us cleaning up the footer and get some place for the Category button :)

Change 206130 merged by jenkins-bot:
Move Category button to beta

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

Now in beta.
Before even considering pushing this to stable we should investigate A/B testing categories against the browse experiment and we should make sure the category pages render nicely on a mobile screen (currently they are very text heavy)

MaxSem removed a subscriber: MaxSem.Aug 17 2015, 6:36 PM
Jdlrobson renamed this task from Display the categories on the mobile site to [Epic] push categories button to stable.Jan 8 2016, 10:23 PM
Jdlrobson added a project: Epic.

Restoring original bug summary per clarity and demand.

Nemo_bis renamed this task from [Epic] push categories button to stable to [Epic] Display the categories on the mobile site for everyone.Jan 20 2016, 11:03 AM
Nyttend added a subscriber: Nyttend.Jul 8 2016, 3:17 PM

See my comments at https://en.wikipedia.org/w/index.php?diff=728835253; the slow speed of typing would make categories extra useful when navigating on flip phones, so the possibility of putting them on a separate page (per Brion in 2012) would be particularly appreciated.

Nemo_bis added a comment.EditedNov 23 2016, 7:33 AM

The subtasks are not real blockers.

I noticed yesterday how ironic it is that we force users to go through automatically generated links to potentially related articles, in order to compensate for this artificial lack of routes to the certainly related "sibling" articles that we actually know of thanks to categories.

For a moment I forgot this bug and I thought «How could the authors of this article possibly forget to add a link to its obvious sibling X? Is the only option really to go through their "parent" Y (not even an option since there was no link there)?» then I opened the desktop view and I realised: «Of course they felt no need, the category is there to serve this purpose».

Then this morning I was reminded by «Mobile web visitors have fewer pageviews per browsing session». https://wikimediafoundation.org/wiki/Minutes/2016-09-19
Our masochism is always impressing. :-)

There are several subtasks associated with this task that outline the perceived blockers.

None of these are really necessary though. Unless there is a plan to do it within X months in the developers' preferred way, it would be appropriate to do it immediately in the users' preferred way (i.e. the simple one).

Verdy_p added a subscriber: Verdy_p.Apr 8 2017, 7:16 PM

Was referenced in T133411 (with snapshots and more details)

Ideally, categories should be collapsible, and could be displayed from the lateral navigation menu (where you should also find the edit link or other actions on the page, i.e. everything we already have in the side navigation bar or top action bar on the desktrop edition), so that there's NO need of smaller fonts (difficult to read when their title will change on every visited page) as they won't use any space within the rendered page.

I really think that the central page is too much crowded with unneeded features. Even the links to edit sections can be removed (place the list of sections in the lateral pane, and make this pane with collapsible groups to ease its use without having to scroll it too much

Florian removed Florian as the assignee of this task.Apr 10 2017, 7:29 PM

Even if I work on some of the subtasks, I don't feel responsible (anymore) for this epic to bring it to production, unfortunately :(

(Marked Regression for lack of a better way to tag important shortages of MobileFrontend which go counter feature parity.)

Nemo_bis changed the task status from Stalled to Open.Apr 17 2018, 5:51 PM

Doesn't fit the definition of stalled.

Nikki added a subscriber: Nikki.May 20 2018, 9:15 AM

What are the technical limitations why this can't be implemented? As this ticket 🎫 has been open for a couple of years now. Why is the Mobile frontend so inferior?

What are the technical limitations why this can't be implemented? As this ticket 🎫 has been open for a couple of years now. Why is the Mobile frontend so inferior?

Technically it is already supported as beta, and can be rolled out by changing settings, though this is only simple support and may not give good user experience. (category pages doesn't look well in mobile - T142124 )

Some people ( @Nemo_bis ) argue it is good enough to roll out as-is so users will at least be able to access categories, while other users ( @Jdlrobson ) believe it isn't mature enough and blocked by other sub-tasks. (please correct me if I didn't summarize it correctly).

To get it done:

  1. We need to decide what approach we take (Nemo or Jdlrobson)
  2. If we decide T142124 and/or T85495 are blockers we need to get it progress (to avoid off-topic discussions - we can discuss there about the design of categories in mobile)

I never understood the need to severely handicap the mobile experience on Wikimedia, I use categories on mobile all the time but tend to only use the desktop version for things like HotCat and Cat-a-lot. On most other websites the mobile version of the website is just a miniature version with a hamburger menu, but on Wikimedia the mobile version just seems to be "Wikimedia Lite". The inability to see categories severely limits the navigability of the website.

Sometimes the mobile website comes off as a social experiment rather than an alternative view, also for browsing.

I find Commons completely unusable on mobile due to the heavy use of categories for navigation. I can't even work out how to leave an image page without switching to the desktop site.

What makes the mobile category pages so bad that it's better to make people switch to the desktop site until the mobile ones are improved? They seem to work fine for me, I just can't navigate to them.

Yeah, I meant to add how I navigate as an addendum to the above comment but was distracted by something IRL.

Anyhow I usually even have to check the categories in desktop mode to see if I added something in Mobile was redlink or not. If this has been technically possible for years, then why wasn't this presented as an optional feature then? "Related articles" should continue to exist at the bottom, but what benefits does hiding categories and navigational templates have over displaying them if they're not perfect 👌🏻? Maybe a user with the technical skills to improve it would want to offer their time in making it better if they saw the categories at the bottom, but right now all it does is deliberately handicap Mobile devices for no apparent reason.

If this has been technically possible for years, then why wasn't this presented as an optional feature then?

It is presented as optional feature. Menu (top left button) => Settings => Wikipedia Beta (check it) => Categories

what benefits does hiding categories and navigational templates have over displaying them if they're not perfect

This isn't just because they aren't perfect - there are trade-offs between showing everything, and showing only what is important. Benefits could be better performance and or better usability.(though I'm not sure this is the case for this issue, as categories are hidden under some Categories button)

Thanks, it worked. Though the categories aren't immediately visible, it is better than nothing.

FWIW, regardless of the approach taken, this still needs somebody to actually do the work involved and that's the main source of blocking here. The technical team for the UI side of things is small - 5 paid people managing the frontend of Vector and Minerva and categories have never been made a priority. The most helpful thing to do at this point is to use avenues such as the talk page of https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions to highlight this as a thing of importance in particular focusing on the workflows you are unable to do due to its absence.