Page MenuHomePhabricator
Create Task
Maniphest T258382

Fix the display of tables on mobile (responsive web design: when the user taps on a table rotate the screen for a fullscreen view)
Closed, DuplicatePublic
Actions

Description

The problem:

Currently tables are highly unusable on mobile. Depending on the width of the table, most tables are cut off on the right on mobile and other small screens.

Why it is a significant problem:

A large and growing share of readers access Wikipedia articles using mobile phones (which can be verified with the pageviews tool for some popular pages). This is why good support for mobile phones is very important. Some websites go so far as to design with an increasingly popular "mobile first" approach that ensures that the display on mobile is at least as good as the desktop one.
Tables are important content of Wikipedia, featured in many articles and often displaying very useful, well/better-structured content that is sometimes making up most of an article's content and often of high interest to the readers of the article.

This is one of a series of tasks that would allow (/ improve) converting the Events list of https://en.wikipedia.org/wiki/2020_in_science to a table as suggested on the page's talk page. It would also allow many more features and could make the article shorter for the reader and more useful. Table-features suggested there could also be useful in many other articles. However, the advantages of responsive web design in respect to tables are not limited to these new features - they would be very useful for the standard display of common, unextended, tables already. Other issues of this series are linked under "Further issues" below.

Suggested solution:

As a solution to this problem I suggest the following responsive web design:

  • When the reader taps on a table rotate the screen and show the table in fullscreen. Don't show any other content of the table except eventually preceding or succeeding text that is directly referring to the table / descriptive of the table. The tap could be anywhere on the table but there should be a small image that indicates that the table has to be taped to be viewed better.
  • When the table is displayed in rotated-screen-fullscreen show a large horizontal scrollbar at the bottom if some columns are still cut off. Maybe the scrollbar could be hidden until the user taps the screen. Maybe it would be best to allow scrolling horizontally by swiping left and right - if no scrollbar is displayed to indicate that columns are cut off and that scrolling is possible there should be some other small icon/image, like a small arrow, to indicate this.

Additional suggestions/requests beyond the basic solution:

Additionally there could be a way to "prioritize"/tag columns so that if columns are cut off on mobile (or small screens) it's not the most important columns. This could be achieved by either hiding columns with less important data (and showing a [show] button) and/or placing the "field of view" of the table so that the tagged columns are visible and the less important ones are cut off.

Further issues:

https://phabricator.wikimedia.org/T233340 (sortability)
https://phabricator.wikimedia.org/T181452 (sortability)

Related Objects

Event Timeline

Prototyperspective created this task.Jul 20 2020, 10:10 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 20 2020, 10:10 AM
Prototyperspective mentioned this in T258417: Add "add table entry" and "edit row" for the wikitext editors as well as "edit with VisualEditor" functions to tables for simplyifing editing tables.Jul 20 2020, 4:34 PM
Prototyperspective mentioned this in T258421: Adding row categories/tags to tables that enable filtering displayed rows.Jul 20 2020, 5:32 PM
Jdlrobson subscribed.Jul 21 2020, 4:11 PM

Tables are problematic yes and this is a long standing problem but there is no silver bullet I can see. We have been aware this is a problem since 2011, but a big part of this requires the work of editors. Part of the problem is tables are used for other layouts and it's impossible to differentiate these. What would be helpful (and what has worked well in the past) is to point to specific widely used templates in articles and think about smaller problems in isolation.

When the reader taps on a table rotate the screen and show the table in fullscreen.

That sounds unexpected and not a very friendly user experience. From a technical pov this would also be tricky - as it would require rotating the entire screen 90 degrees on behalf of the user to get the right effect.

When the table is displayed in rotated-screen-fullscreen show a large horizontal scrollbar at the bottom if some columns are still cut off

If we forget the rotated screen part, this is the status quo. A horizontal scrollbar should already appear on tables and if it doesn't thats a bug.

Additionally there could be a way to "prioritize"/tag columns so that if columns are cut off on

This requires editorial support which has been the biggest challenge in making editor content mobile friendly. There's some good discussion on https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Avoid_tables_for_anything_except_data

Jdlrobson closed this task as a duplicate of T66577: Large tables created by editors are not responsive.Jul 21 2020, 4:12 PM
Prototyperspective added a subscriber: TheDJ.EditedJul 22 2020, 1:03 PM

Thanks for the input and the related issue.
@TheDJ commented "4. Personally I do think that having some sort of 'make this table fullscreen' option is required. [...]" there.
I think my suggestion above would be the most effective implementation of such a fullscreen option in terms of eventual usefulness.
This fullscreen-rotate-screen option is already implemented in many apps including the YouTube app which rotates the screen for a fullscreen view.

Part of the problem is tables are used for other layouts and it's impossible to differentiate these.

Part of the problem is tables are used for other layouts and it's impossible to differentiate these. What would be helpful (and what has worked well in the past) is to point to specific widely used templates in articles and think about smaller problems in isolation.

Maybe the "tap on table to un/make it fullscreen" could be made an option to tables which is enabled by default but could be disabled by setting e.g. {| class="no-rotate" on the table so that it could be added manually for exceptions.

That sounds unexpected and not a very friendly user experience.

It's already implemented in many popular apps as explained above so people should be fairly accustomed to it. It could be undone fast and easily with another tap or by taping a button that appears in that view. Also, as in the issue, there should be a small image in a corner that indicates that the table has to be taped to be viewed better / that the screen will rotate for a fullscreen view when it is taped.

Technical implementation

From a technical pov this would also be tricky - as it would require rotating the entire screen 90 degrees on behalf of the user to get the right effect.

Maybe a technical implementation would require tasks in external software and standards. Maybe transform: rotate could be used (e.g. see this and the next link). The proper way would be using the Orientation Lock API. The latter is still experimental and requires the web page to be in full-screen mode. See "Locking to a specific orientation and unlocking" here. Here is a demo which didn't work in the Firefox Focus mobile browser but could set the full-screen mode.

If we forget the rotated screen part, this is the status quo. A horizontal scrollbar should already appear on tables and if it doesn't thats a bug.

No, it's not a large scrollbar and it's only at the bottom of the table, not at the bottom of the field of view.

Additionally there could be a way to "prioritize"/tag columns so that if columns are cut off on

This requires editorial support which has been the biggest challenge in making editor content mobile friendly.

It would not be necessary but only be an additional improvement over the suggested fullscreen-rotate solution. Imo it wouldn't make much sense as a standalone solution without first increasing the field of view via the fullscreen-rotate solution.

There's some good discussion on https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Avoid_tables_for_anything_except_data

Thanks for the relevant link. Imo the "Avoid tables for anything except data" recommendation there is mostly due to technical barriers which imo should be solved (instead and asap due to increasing access via mobile browsers).

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL