Hi everyone,
The Mobile Apps Team met today to continue our discussion about some of the issues we face with adapting Wikipedia articles to the small screen. In particular, the issues we’re facing in handling tables and infoboxes.
Basically, there are two major design issues with tables and infoboxes right now:
- Infoboxes are very long, meaning that you often have to scroll for an excessively long time to get past them and back into the prose. - Infoboxes don’t look good on the screen because they’re too wide and were constructed only with how they look on large screens in mind.
These issues make article display sloppy and disincline people from continuing to use the app. For example, quite a few staff at the office often save articles to other apps such as Instapaper rather than using the Wikipedia app, because we’ve not handled issues such as these properly.
The latter issue is hard to grapple with as it’s a problem which is compounded by the lack of uniformity in the way infoboxes are used, meaning that for every fix there are thousands of edge cases that are not handled properly. Many of our competitor apps only trivially change the formatting of infoboxes due to the complexity of the problem, for example changing the font and adding or removing some horizontal lines.
The former issue, however, is a bit easier to deal with. Recognising that tables present such large issues for small screens, the commonly taken approach by our competitor apps here is to either totally strip infoboxes and tables from articles, or more commonly to aggressively collapse all tables so that the user has to explicitly choose to open them. The tradeoff here is, of course, that the very useful information contained in the infobox is now hidden and therefore we would have a duty to expose information to the users, but there are lightweight ways of mitigating that which can be considered (e.g. a little tooltip).
At this stage we have no action items out of this, but we’re continuing to explore these things in advance of our two sprints dedicated to design issues.
If you have any questions, let me know.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
I can see how those are difficult issues especially for the smallest screens. Could you do partial collapses, that is, show just the first few rows and columns, and give the user options to scroll OR expand horizontally and/or vertically?
Pine On Oct 9, 2014 11:03 AM, "Dan Garry" dgarry@wikimedia.org wrote:
Hi everyone,
The Mobile Apps Team met today to continue our discussion about some of the issues we face with adapting Wikipedia articles to the small screen. In particular, the issues we’re facing in handling tables and infoboxes.
Basically, there are two major design issues with tables and infoboxes right now:
- Infoboxes are very long, meaning that you often have to scroll for
an excessively long time to get past them and back into the prose.
- Infoboxes don’t look good on the screen because they’re too wide and
were constructed only with how they look on large screens in mind.
These issues make article display sloppy and disincline people from continuing to use the app. For example, quite a few staff at the office often save articles to other apps such as Instapaper rather than using the Wikipedia app, because we’ve not handled issues such as these properly.
The latter issue is hard to grapple with as it’s a problem which is compounded by the lack of uniformity in the way infoboxes are used, meaning that for every fix there are thousands of edge cases that are not handled properly. Many of our competitor apps only trivially change the formatting of infoboxes due to the complexity of the problem, for example changing the font and adding or removing some horizontal lines.
The former issue, however, is a bit easier to deal with. Recognising that tables present such large issues for small screens, the commonly taken approach by our competitor apps here is to either totally strip infoboxes and tables from articles, or more commonly to aggressively collapse all tables so that the user has to explicitly choose to open them. The tradeoff here is, of course, that the very useful information contained in the infobox is now hidden and therefore we would have a duty to expose information to the users, but there are lightweight ways of mitigating that which can be considered (e.g. a little tooltip).
At this stage we have no action items out of this, but we’re continuing to explore these things in advance of our two sprints dedicated to design issues.
If you have any questions, let me know.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Thu, Oct 9, 2014 at 11:16 AM, Pine W wiki.pine@gmail.com wrote:
I can see how those are difficult issues especially for the smallest screens.
For reference, the smallest screens we tend to see on smartphones is 320x480 (CSS pixels|points|device-independent pixels). Vertical space may be further constrained by presence of toolbars and other UI from the browser.
There may be some slightly narrower phones out there though, especially older budget Androids or weird OSs. But targeting 320px width is the main one to hit.
Could you do partial collapses, that is, show just the first few rows and
columns, and give the user options to scroll OR expand horizontally and/or vertically?
Yes, where good CSS/JS support is available (mainline current browsers and the apps) there are a few possibilities here:
* restricting the height and adding a vertical-expand/collapse button could work very well for "super tall" infoboxes that still fit horizontally. This should be doable by setting height and overflow and adding a button to the DOM.
* "zooming out" ("thumbnailing?") a table that's too wide should be possible using CSS transforms, but I'm not sure how easy it is to tell that something "needs" more space automatically.[1]
* "zoomed-out" tables could then be presented full-size in a full-screen overlay that lets you pan around....
* or you could just pinch-zoom *into* the "zoomed-out" table and pan around it. Hmm.
[1] In the apps we use JS in the web view to loop through tables and see which ones are wider than the available space to try to force their width; however that'll probably leave things that "can" render at tiny size but look like crap. This might be more fixable by setting minimum sizes in inline CSS on cells or whole tables that require it.
-- brion
One option for infoboxes might be to provide a toggling option, but keep it expanded by default. This way the useful information is still present initially, but if the user doesn't want to scroll for too long they can collapse it. Alternatively, exploring the use of moving infoboxes/tables to modal dialog windows (with a button to open them where they would normally appear within the article) could prove fruitful.
Thanks,
Jeff Hobson
On Thu, Oct 9, 2014 at 11:03 AM, Dan Garry dgarry@wikimedia.org wrote:
Hi everyone,
The Mobile Apps Team met today to continue our discussion about some of the issues we face with adapting Wikipedia articles to the small screen. In particular, the issues we’re facing in handling tables and infoboxes.
Basically, there are two major design issues with tables and infoboxes right now:
- Infoboxes are very long, meaning that you often have to scroll for
an excessively long time to get past them and back into the prose.
- Infoboxes don’t look good on the screen because they’re too wide and
were constructed only with how they look on large screens in mind.
These issues make article display sloppy and disincline people from continuing to use the app. For example, quite a few staff at the office often save articles to other apps such as Instapaper rather than using the Wikipedia app, because we’ve not handled issues such as these properly.
The latter issue is hard to grapple with as it’s a problem which is compounded by the lack of uniformity in the way infoboxes are used, meaning that for every fix there are thousands of edge cases that are not handled properly. Many of our competitor apps only trivially change the formatting of infoboxes due to the complexity of the problem, for example changing the font and adding or removing some horizontal lines.
The former issue, however, is a bit easier to deal with. Recognising that tables present such large issues for small screens, the commonly taken approach by our competitor apps here is to either totally strip infoboxes and tables from articles, or more commonly to aggressively collapse all tables so that the user has to explicitly choose to open them. The tradeoff here is, of course, that the very useful information contained in the infobox is now hidden and therefore we would have a duty to expose information to the users, but there are lightweight ways of mitigating that which can be considered (e.g. a little tooltip).
At this stage we have no action items out of this, but we’re continuing to explore these things in advance of our two sprints dedicated to design issues.
If you have any questions, let me know.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l