Some articles have tabular or non-textual data in the first section or in the search results snippet. In QuickView, we plan to show an expanded version of the snippet (T307052) and any sections mentioned in the search results (T307061). Should we show that type of data in Quickview, and if so, how should we handle it?
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T307038 [Placeholder EPIC] SDAW Search Improvements | |||
| Resolved | None | T306341 [EPIC] Quickview/Search Preview panel on the special:search page | |||
| Open | Sneha | T311161 Design: consider if/how to show tabular/non-textual data from articles in quickview |
Event Timeline
Comment Actions
Here are some explorations for non-textual/tabular data.
From my explorations it seems like there are two types 1. Bulleted lists 2. Table
In case the snippet is from a table (which I am unable to reproduce), we should show the name and section of the table and a direct link to it rather than the table itself as it would be unusable to show the entire table in the quick view.
Comment Actions
Based on this thread, it looks like we are not able to identify 1) if the certain snippet is from table 2) if the snippet has any formatting (as it is usually stripped out). It means that we may not be able to present such snippets in a more usable way (as shown above) in the quick view. Given most of the top results won't have such snippets we can assume that this will not happen very often however can't be sure of smaller wikis. Is there a hack we could employ or other thoughts the team has about this given the lack of feasibility?
@Seddon @matthiasmullie
Comment Actions
We probably can't really use the search snippet for these purposes: the content of the article is split up into different fields, and markup is removed.
We could try to use the snippet text to try to find the relevant portion within the full article content (incl. markup), but it will never be 100% accurate.
Whatever content is in a snippet may not be a totally accurate/complete representation of the article content (e.g. there can be significant gaps in the snippet, like a removed table) that would affect our ability to find the exact portion in the full article content.
But even if we would know where exactly in the article (with markup) the snippet was from, it would still be a struggle to do something useful with it.
Unlike a snippet without markup, we can't just break it off anywhere: we would have to expand up to and including all opening/closing HTML tags (or start cutting content in between, or manually insert at some point - either way, we'd have to make sure all tags match and manipulate some content to make that happen)
Even then, we'll probably find ourselves dealing with suboptimal data (e.g. massive tables with hundreds of rows/columns) that we may need to manipulate further. All of this risks either cutting out important information, or leaving in too much where it's not even useful anymore.
I can't really think of a feasible approach to expanding the snippet, or preserve the markup.
Comment Actions
Given the constraints mentioned in this thread I think we may not be able to address presenting tabular data in a comprehensible format in preview. Looks like we should first resolve the problem of expanding snippet and then come to this if it is even possible to tackle this use case. I suggest we move it back to backlog @CBogen
cc @TJones mostly fyi