Results table: define fields and options

[abettermap]

Description

The "Results" panel will have a table corresponding with the records currently in the map. This issue establishes what will be shown in the table and how it can be searched (via open-text search box) and filtered (via dropdowns in the column headings).

Width limitation

I haven't pushed the changes yet but slimming it down pretty well seems to fit 3ish columns (whose values are long-ish text, not numbers):

...and that is using a widened sidebar:

Keep in mind their will be icons next to the sort-triggering column headings and the filter boxes below them, so might look kinda busy if the font gets smaller.

Solutions to panel width limitation

"Full size" modal dialog

Obviously the panel is quite narrow and does not allow a ton of info to be displayed without horizontal scrolling. So, how about a button to View full size which would open the table in a modal dialog with much more room (or at least more room on desktop since tables are going to by limited on mobile no matter what)?

If full size option is used, will its table contain the same fields and options as that of the original panel? This is definitely simpler to code and may reduce confusion for the user (no one can say "why aren't the modal columns in the original panel view?").

Expandable rows

Not sure if the Multiple Detail Panels counts as a solution to the width limitation since it could get confusing to Search by a column that isn't shown in the column headings, so let's just call that a wishlist thing. It also seems too redundant and purpose-defeating relative to the Details panel.

Nothing, just don't use tons of columns

Just let the user scroll if they need to. Keep it simple with only a handful of columns, put the most important ones first, and push the others to the end.

What to include

I think it's best to define this in the Data Schema, so let's start filling it out:

I have some assumptions to start with:

• Language, Endonym, and Description will be text-searchable (hopefully no performance impacts with Description).
• No numeric data will be searchable, but it will be filterable.
• All columns will be sortable.
• Any column that can be searched via Search box will also be a column heading (as opposed to, say, a searchable Description via Search box but no Description column, it only searches the data and does not display it, which would get confusing since how would you know there was a Description in the first place?).

Next steps

1. Let's fill out the Schema and see how far that gets us.
2. Decide what order (can also be in Schema) the column headings will be

Considerations

Providing a column-specific filter for a text column in addition to being able to search that column via the Search box above seems somewhat redundant. Should we just have column-specific filter for the text-y columns rather than the Results-wide search?

Informative text

Somewhat related to this issue but slightly different topic: we need to draft some user-friendly wording for this panel that explains in non-technical terms:

• The purpose of the panel, and
• ...that the filter/search in Results has no impact on the "global" app-wide filters

[abettermap]

@rperlin-ela let me know what you think of this and feel free to send questions, there's a lot going on up there.

My vote would be for a Modal that has the same stuff as the Results panel, just a lot more room on desktop. Would put the most important columns first, and maybe limit the number of columns to something that fits on laptop-ish without scrolling horizontally. The Description would be truncated of course, and the other long-ish text fields can wrap to multiple lines if needed.

Slightly related?

What do you think about indicating the presence or number of filters and/or results total through a badge in our navigation tabs? https://material-ui.com/components/badges/#maximum-value

Could do the 999+ for filtered record count, and either a number of filters or maybe a dot badge for Filter tab?

Dot badge could also indicate when a feature is selected in Details tab nav icon.

Might all be overkill but I'm thinking the numeric badge for results count could reinforce what's going on.

Thoughts?

[rperlin-ela]

@rperlin-ela let me know what you think of this and feel free to send questions, there's a lot going on up there.

You're not kidding. Yes, need to wrap my head around this a little more — don't quite understand all the ideas under "Solutions to panel width limitation". Is it right to think in a (very very over-simplified) way that we're giving people access to an embedded interactive version of the spreadsheet (responsive to their filtering and linked to the map), and trying to tailor it given width limitations?

My vote would be for a Modal that has the same stuff as the Results panel, just a lot more room on desktop. Would put the most important columns first, and maybe limit the number of columns to something that fits on laptop-ish without scrolling horizontally. The Description would be truncated of course, and the other long-ish text fields can wrap to multiple lines if needed.

I think this sounds good. I've started taking a crack at it in the Data Schema with a column for the order, don't know if that makes sense as a way to do it. I guess it also depends a little on what we put in the Details panel (more, right?), but what I imagine here is a little more stripped-down to the "basic facts" about a language, starting with the name and neighborhood and then the "local" info (Community Size and Type) and then the "global" info (Region, Primary Country, Global Speaker Total, Language Family).

One very small thing in terms of sorting... for purposes of display with the all-important "Language" field, we've gotten rid of all commas such that "Arabic, Darfuri" is now "Darfuri Arabic" etc. But we still do have the column where it's "Arabic, Darfuri", and that might be a little more intuitive for sorting in the Results panel?

I think I like 999+ and the dot badge.

[abettermap]

don't quite understand all the ideas under "Solutions to panel width limitation"

I'm leaning hard toward Modal. Just picture the About page (a modal) but with the results/data table in it. That's the TLDR, I probably just over-complicated it!

Is it right to think in a (very very over-simplified) way that we're giving people access to an embedded interactive version of the spreadsheet

Yeah that's a good way to put it.

I've started taking a crack at it in the Data Schema with a column for the order, don't know if that makes sense as a way to do it.

Perfect. Much simpler than the 3 columns I added (and since removed). I will use my judgement as to which columns will be searchable and filterable. I think for starters:

• The two numeric columns will need a custom filter (e.g. some type of min/max greater/less than) as an alternative to open-text searching. The table plugin I'm using is quite robust so I'll figure it out.
• The other columns will be open-text filterable (this is the default)
• The columns with a small number of possible values (e.g. Type, and maybe Region) will be fine with open-text filters but maybe a dropdown could be more ideal. I am reluctant to go too nuts on it though, since we'll already have solid app-wide filtering in the Filter panel.

but what I imagine here is a little more stripped-down to the "basic facts" about a language, starting with the name and neighborhood and then the "local" info (Community Size and Type) and then the "global" info

Sounds logical to me. Is it safe to say that this would roughly be the desired priority/order in the Details panel as well?

One very small thing in terms of sorting... for purposes of display with the all-important "Language" field, we've gotten rid of all commas such that "Arabic, Darfuri" is now "Darfuri Arabic" etc. But we still do have the column where it's "Arabic, Darfuri", and that might be a little more intuitive for sorting in the Results panel?

Yes, that would sort better. Not sure if I'd include two separate columns in the final (production/GIS) dataset though. What do you think about Arabic (Darfuri) or Arabic - Darfuri as the Language? Does that mess anything up?

I think I like 999+ and the dot badge.

Excellent. At a minimum I will shoot for the numbers on the Data nav tab button, and play the other three tabs by ear.

[rperlin-ela]

• The two numeric columns will need a custom filter (e.g. some type of min/max greater/less than) as an alternative to open-text searching. The table plugin I'm using is quite robust so I'll figure it out.
• The other columns will be open-text filterable (this is the default)
• The columns with a small number of possible values (e.g. Type, and maybe Region) will be fine with open-text filters but maybe a dropdown could be more ideal. I am reluctant to go too nuts on it though, since we'll already have solid app-wide filtering in the Filter panel.

Sounds good to me, but definitely don't go too nuts. People will have their chance to do all kinds of Filtering in the Filter tab, so to me it makes sense that the Results tab is for more key refinement, or whatever's easiest.

Sounds logical to me. Is it safe to say that this would roughly be the desired priority/order in the Details panel as well?

Yes, good call.

Not sure if I'd include two separate columns in the final (production/GIS) dataset though. What do you think about Arabic (Darfuri) or Arabic - Darfuri as the Language? Does that mess anything up?

Every bit as good, either of those. Something we need to do on our end? The "Original Language Name" column gets it right. For 98% of cases, it's right to assume that the second word could go in parentheses or after the hyphen, but there are a few outliers like Sranan Tongo (which doesn't change) and a few longer ones like North Levantine Arabic.

Excellent. At a minimum I will shoot for the numbers on the Data nav tab button, and play the other three tabs by ear.

Great

[abettermap]

Something we need to do on our end?

Yes, please make the data how you would expect to see it as a user. Let's make the verbatim approach the rule and the code approach the exception (e.g. checking for http as Endonym prefix).

[rperlin-ela]

Yes, I understand the general approach, and I think I understand what you mean in this case — changing the Language column, so that Arabic (Darfuri) is what appears everywhere in all cases, not just in the Results table.

[abettermap]

Correct. It will be shown the same in all instances.

[rperlin-ela]

From discussion with @markturin, it would be great to avoid the table getting cut off in both the small and the large version. What was the logic of having the small version again, where barely 3 columns are visible? Even full-screen version clips off two columns at the end—is it possible to enlarge?

Also discussed the issue of having even controlled-vocabulary columns be text-filterable, but maybe better to understand this when filters are up and running to understand how "Filter" and "Data" will be used in concert.

[abettermap]

it would be great to avoid the table getting cut off in both the small and the large version

Indeed. It's actually not cut off, all the columns are there, but the horizontal scrollbar is way down at the bottom so it's not apparent that there is more to the table (working on that).

table getting cut off in both the small

Yes and that will always happen due to the number of columns you have asked to be visible (10 total). Phones are only about ~300-500px wide, so unless the font size and/or cell padding are dropped down to something illegible, or the number of columns is reduced, or the columns are about 1-character wide, scrolling sideways will always be required on a mobile device.

Even with my current iteration, which includes smaller fonts and less padding, I can still only see the first three columns without scrolling. With some greater slimming I might be able to squeeze a fourth, but that would start to eat into legibility. Tables are challenging to deal with on phones in general, there's always the inherent annoyance factor of scrolling, but doing my best here.

and the large version

You guys are jumping the gun a bit. :) I don't think I put any design effort into the table whatsoever when you first saw it, it was all defaults, hence my request to hold off on commenting on that before I put any work into it. I am reluctant to push in-progress changes for that reason, so a good rule of thumb might be to hold off the longer convos about style and layout until you know I'm at a review-ready stage. I mean feel free to comment all you want, feedback always welcome, but it takes some extra time to explain what's ready and what's not.

What was the logic of having the small version again

I don't think there was much logic! I think the panel came first, then the fullscreen, and it was my suggestion to preserve the former with the potential for some kind of map action when a record is hovered, but there are other ways to go about that.

That said (and I agree that the small table is not very useful), what should happen when "Data" is clicked? Straight to fullscreen? That seems a bit jarring, at least on the first shot, so here is one suggestion:

• In the small table, only display a subset of the fields (or continue to show them all and not worry about the subset) and no filters, banking on the user to click "View Fullscreen"
• Once in fullscreen, have a prominent checkbox somewhere indicating "Always open in fullscreen". That way when they return to that view after clicking "Data" they will know what to expect.

Otherwise the panels nav would feel really choppy since the other 3 nav buttons open their respective panels. The gentle introduction to a completely unexpected fullscreen behavior might soften the transition a bit. I can also make the "view fullscreen" button more encouraging:

Also discussed the issue of having even controlled-vocabulary columns be text-filterable, but maybe better to understand this when filters are up and running to understand how "Filter" and "Data" will be used in concert.

Not sure I understand, but my most recent iterations match the per-column searchability and filterability that makes the most sense, so maybe the point will be moot. As for Filter/Data question, see next section:

Larger convo

The table plugin I'm using is so powerful that I'm starting to wonder if the Filters panel is still useful? With the exception of spatial (geocoding/address search), the table does everything we intend on doing in the Filters panel. It would also firm up the relationship between map and table rather than just internal-table filter.

I don't think it would be viable to go down the road of having the in-table filters affect the global Filters, I think it should be either the way that we have it now or just no Filters panel since the table will cover it.

Here's an idea

...which I think will kill several birds with one stone. Scrap the Data panel as we know it, leaving us with these panels instead...

1. Filters panel

...which would ideally be renamed to "Explore" or something that covers my proposed contents, which are:

1. A "View results table" button (aka our "View fullscreen" btn in the Data panel, which would do the same in my proposed changes). With the fullscreen table, however, those filters would impact the map rather than just the table (the tricky part I'm trying to avoid, which would be the case here, is having TWO sets of filters that both affect the map, and each other).
2. Any filters that are not available in the table (I believe it's just the spatial/geocoding stuff that's left?).

2. Details panel

Samesies as now.

3. Settings panel

Samesies as now.

Even better idea?

Just brainstorming here, gonna keep it rolling...

If my ideas above are agreed upon, we might be able to have just two panels: Explore and Details. The Explore would contain what I suggested above, but will all that extra space we might be able to include the legend and dropdowns as well.

I think to make this happen I would drop the 4-button nav bar entirely and could make the two panel headings the nav instead. This would free up some valuable space on mobile and desktop alike. Like so:

[rperlin-ela]

I haven’t thought through all the implications, but I’m super-excited about the “even better" idea of shrinking down to 3 or maybe even 2 panels. I definitely like the idea of combining Filter and Data, assuming it updates the map in real time like Filter was meant to, for all the reasons you mentioned including how it solves all these issues with the smaller version of the table. Go for it!

If it doesn’t work out, we can go back to some of these issues.

Sorry about any jumping of the gun!

On Aug 14, 2020, at 7:38 PM, Jason Lampel <notifications@github.com mailto:notifications@github.com> wrote:

it would be great to avoid the table getting cut off in both the small and the large version

Indeed. It's actually not cut off, all the columns are there, but the horizontal scrollbar is way down at the bottom so it's not apparent that there is more to the table (working on that).

table getting cut off in both the small

Yes and that will always happen due to the number of columns you have asked to be visible (10 total). Phones are only about ~300-500px wide, so unless the font size and/or cell padding are dropped down to something illegible, or the number of columns is reduced, or the columns are about 1-character wide, scrolling sideways will always be required on a mobile device.

Even with my current iteration, which includes smaller fonts and less padding, I can still only see the first three columns without scrolling. With some greater slimming I might be able to squeeze a fourth, but that would start to eat into legibility. Tables are challenging to deal with on phones in general, there's always the inherent annoyance factor of scrolling, but doing my best here.

and the large version

You guys are jumping the gun a bit. :) I don't think I put any design effort into the table whatsoever when you first saw it, it was all defaults, hence my request to hold off on commenting on that before I put any work into it. I am reluctant to push in-progress changes for that reason, so a good rule of thumb might be to hold off the longer convos about style and layout until you know I'm at a review-ready stage. I mean feel free to comment all you want, feedback always welcome, but it takes some extra time to explain what's ready and what's not.

What was the logic of having the small version again

I don't think there was much logic! I think the panel came first, then the fullscreen, and it was my suggestion to preserve the former with the potential for some kind of map action when a record is hovered, but there are other ways to go about that.

That said (and I agree that the small table is not very useful), what should happen when "Data" is clicked? Straight to fullscreen? That seems a bit jarring, at least on the first shot, so here is one suggestion:

In the small table, only display a subset of the fields (or continue to show them all and not worry about the subset) and no filters, banking on the user to click "View Fullscreen" Once in fullscreen, have a prominent checkbox somewhere indicating "Always open in fullscreen". That way when they return to that view after clicking "Data" they will know what to expect. Otherwise the panels nav would feel really choppy since the other 3 nav buttons open their respective panels. The gentle introduction to a completely unexpected fullscreen behavior might soften the transition a bit. I can also make the "view fullscreen" button more encouraging:

https://user-images.githubusercontent.com/4974087/90298446-8ac26600-de4f-11ea-944b-bd2f98f26537.png Also discussed the issue of having even controlled-vocabulary columns be text-filterable, but maybe better to understand this when filters are up and running to understand how "Filter" and "Data" will be used in concert.

Not sure I understand, but my most recent iterations match the per-column searchability and filterability that makes the most sense, so maybe the point will be moot. As for Filter/Data question, see next section:

Larger convo

The table plugin I'm using is so powerful that I'm starting to wonder if the Filters panel is still useful? With the exception of spatial (geocoding/address search), the table does everything we intend on doing in the Filters panel. It would also firm up the relationship between map and table rather than just internal-table filter.

I don't think it would be viable to go down the road of having the in-table filters affect the global Filters, I think it should be either the way that we have it now or just no Filters panel since the table will cover it.

Here's an idea

...which I think will kill several birds with one stone. Scrap the Data panel as we know it, leaving us with these panels instead...

1. Filters panel

...which would ideally be renamed to "Explore" or something that covers my proposed contents, which are:

A "View results table" button (aka our "View fullscreen" btn in the Data panel, which would do the same in my proposed changes). With the fullscreen table, however, those filters would impact the map rather than just the table (the tricky part I'm trying to avoid, which would be the case here, is having TWO sets of filters that both affect the map, and each other). Any filters that are not available in the table (I believe it's just the spatial/geocoding stuff that's left?).

2. Details panel

Samesies as now.

3. Settings panel

Samesies as now.

Even better idea?

Just brainstorming here, gonna keep it rolling...

If my ideas above are agreed upon, we might be able to have just two panels: Explore and Details. The Explore would contain what I suggested above, but will all that extra space we might be able to include the legend and dropdowns as well.

I think to make this happen I would drop the 4-button nav bar entirely and could make the two panel headings the nav instead. This would free up some valuable space on mobile and desktop alike. Like so:

https://user-images.githubusercontent.com/4974087/90299829-d9263380-de54-11ea-9c0c-2cccf099d26a.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/52#issuecomment-674311711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5FOPBPVA7PBN7HAE3DSAXDF7ANCNFSM4PHSL73Q.

[abettermap]

In the given timeframe there’s probably no going back without losing some hours. On a positive note if we rely on the table as the sole filtering source, then I don’t have to code a second set of controls in the Filters panel. That would literally save me days of coding!

This is a big change since it affects the layout, map, and data table, so hopefully it pans out. If not then blame that Jason guy for suggesting it 👇

If we DO go this route, then one reason (however useful it may or may not be) for preserving the small table (and consequently the Data panel as it is now) is to see the immediate results of table column filtering. If we’re stuck in fullscreen land until clicking a point or manually closing the dialog, then the table-map relationship may not be as apparent since the impacts to the map are not seen while the dialog is in the way.

So, +1 for keeping small table? I feel like on mobile it almost doesn’t matter since so much horizontal scrolling has to be done anyway. But on desktop I could certainly make the panels wider...

Thoughts?

[rperlin-ela]

Understood—and I know it’s a big change, so I leave it to your judgment. I’m all in support of it as outlined.

Re: small table, understand what you’re saying but still don’t see the real +1. Good to make the panel a little wider for desktop if we can avoid a little scrolling.

On Aug 15, 2020, at 1:15 PM, Jason Lampel notifications@github.com wrote:

In the given timeframe there’s probably no going back without losing some hours. On a positive note if we rely on the table as the sole filtering source, then I don’t have to code a second set of controls in the Filters panel. That would literally save me days of coding!

This is a big change since it affects the layout, map, and data table, so hopefully it pans out. If not then blame that Jason guy for suggesting it 👇

If we DO go this route, then one reason (however useful it may or may not be) for preserving the small table (and consequently the Data panel as it is now) is to see the immediate results of table column filtering. If we’re stuck in fullscreen land until clicking a point or manually closing the dialog, then the table-map relationship may not be as apparent since the impacts to the map are not seen while the dialog is in the way.

So, +1 for keeping small table? I feel like on mobile it almost doesn’t matter since so much horizontal scrolling has to be done anyway. But on desktop I could certainly make the panels wider...

Thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/52#issuecomment-674425115, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5GNTKRF6PLZ4CDG7J3SA27CLANCNFSM4PHSL73Q.

[abettermap]

Ok so for clarification, you’re thinking drop the small table on mobile but preserve on desktop if panels are widened on desktop?

Also have you played with the Show/Hide columns button in my deploy? That could make the panel table more relevant since it allows only the desired columns to be displayed. On a similar note, the columns are draggable, so user could technically get them into the desired order.

One more thing- columns can be locked/frozen. So Languages could stay in view 24/7 if needed.

[rperlin-ela]

Haven’t gone deep, but the changes in the deploy are pretty fantastic and it will be good for the whole team to see them. (I’m not sure what you mean by locked, but I’ve at least checked out everything else). At full screen, it’s both attractive and super-powerful. No question that if the map changes with filtering we should have the small version. I could also see having a small version and just showing a couple of columns by default (Language and Neighborhood?) and then letting people add more.

Are bullet points needed for Neighborhoods?

On Aug 15, 2020, at 1:57 PM, Jason Lampel notifications@github.com wrote:

Ok so for clarification, you’re thinking drop the small table on mobile but preserve on desktop if panels are widened on desktop?

Also have you played with the Show/Hide columns button in my deploy? That could make the panel table more relevant since it allows only the desired columns to be displayed. On a similar note, the columns are draggable, so user could technically get them into the desired order.

One more thing- columns can be locked/frozen. So Languages could stay in view 24/7 if needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/52#issuecomment-674429680, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5FC6WQVTF7WSVLW763SA3D7VANCNFSM4PHSL73Q.

[abettermap]

Are bullet points needed for Neighborhoods?

No but I thought this

was easier to read than

because I'm not familiar with the neighborhoods and I'm not sure which ones are just wrapped continuations of the preceding lines, and easier than verbatim

because there's just a lot going on.

I can set it to whatever you want of course, just thought the bullets were cleanest in the small space. Maybe this is a good alternative, I'll use it unless I hear otherwise:

[abettermap]

not sure what you mean by locked

In Excel and Sheets it's called "Freeze" (e.g. freeze columns). Example from the plugin I'm using, in which the first two columns are "fixed":

[rperlin-ela]

Cool— probably missing something obvious, but how do you do it?

On Aug 15, 2020, at 11:40 PM, Jason Lampel notifications@github.com wrote:

not sure what you mean by locked

In Excel and Sheets it's called "Freeze" (e.g. freeze columns). Example from the plugin I'm using, in which the first two columns are "fixed":

https://user-images.githubusercontent.com/4974087/90325992-ea983a00-df3f-11ea-83fc-6c420bbf4378.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/52#issuecomment-674474498, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5ESVKPGPPKRK4JQPATSA5IMDANCNFSM4PHSL73Q.

[rperlin-ela]

Point taken. Forgot about the long ones that would wrap. Maybe bullets best for now!

On Aug 15, 2020, at 11:39 PM, Jason Lampel notifications@github.com wrote:

Are bullet points needed for Neighborhoods?

No but I thought this

https://user-images.githubusercontent.com/4974087/90325762-f8988b80-df3c-11ea-8f06-67254c404ddc.png was easier to read than

https://user-images.githubusercontent.com/4974087/90325756-e0287100-df3c-11ea-9f6d-c1090414c717.png because I'm not familiar with the neighborhoods and I'm not sure which ones are just wrapped continuations of the preceding lines, and easier than verbatim

https://user-images.githubusercontent.com/4974087/90325850-161a2500-df3e-11ea-86d4-6d0fe32ac54d.png because there's just a lot going on.

I can set it to whatever you want of course, just thought the bullets were cleanest in the small space. Maybe this is a good alternative, I'll use it unless I hear otherwise:

https://user-images.githubusercontent.com/4974087/90325970-8ecdb100-df3f-11ea-8392-22c85a8f8c12.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/52#issuecomment-674474400, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5HF2DUTPZBKDWAKZ6LSA5IFJANCNFSM4PHSL73Q.

[abettermap]

Oh the freeze thing? All on my end.

Will keep bullets for now. I don’t think I’m able to get the comma + newline to work consistently anyway, it wants to wrap.

I’ll snug up the bullet padding as much as I can.