Short Descriptions on "/Explore/Language" pages

[rperlin-ela]

Description

A note from Dan on something I think we at least touched on before

Now that we have a great sort of landing page for every individual language that includes all its communities (e.g. for Amharic, /Explore/Language/Amharic), is there a way to have a short bit of overview description here that differs from an individual description (e.g. /details/1089). If this is doable, would I just add another column to the spreadsheet (e.g. Overall Description)? It wouldn't be required, and it will take a long time to fill all these in, but it would be great to have the capability.

[abettermap]

This would be a good UI improvement for sure. I think it belongs in the config sheet you and Matt are putting together though.

How different are the instance-level Descriptions vs. Language-level? Not to bite off more than I can chew here, but just wondering: could the vast majority of the current Descriptions be moved over to the config sheet?

I know that there will still be some instance-level neighborhood-specific descriptions that would override the language-level, but I could handle that somewhat easily in the code. The check would be something like, "if instance-level description exists (aka what we have now), use that, otherwise default to language-level (aka config sheet)".

Assuming I'm following correctly so far- for Dan's suggestion, instead of something new, could the language-level description I proposed above be used in a truncated manner instead? Basically a much longer version of what I have in the footers of the individual cards, like maybe a paragraph's worth, and a "Read more..." to toggle the full view. And the card footers would simply be removed or replaced with something that's not redundant.

Let me hop on my computer and I'll get you a screenshot.

[abettermap]

Oh I just read your "that differs from individual description" part. Does that mean my truncated suggestion wouldn't fly?

Either way, this is something that would go into the language config sheet. Feel free to make a column and start populating it.

As for my suggestion of moving many of the instance level descriptions into the config, I could see that helping performance a bit as that column is by far responsible for the bulk of the MB tileset size.

[rperlin-ela]

I think your suggestion could still make sense, if I understand right, because there won’t always be a difference between overall and individual description. Presumably there never will be, when there’s only record and there might not even be much of a need for some other cases. And in any case it will take a while to write new descriptions.

Regardless, it would be nice to have something for people to bite into at Explore/Language and truncated could work. And as you say the card footers are almost always repetitive as it stands, so not crucial.

So for now leave Description where it is in the main sheet, but start an Overall Description field in the config sheet so we can try it out?

On Nov 20, 2020, at 12:27 PM, Jason Lampel notifications@github.com wrote:

Oh I just read your "that differs from individual description" part. Does that mean my truncated suggestion wouldn't fly?

Either way, this is something that would go into the language config sheet. Feel free to make a column and start populating it.

As for my suggestion of moving many of the instance level descriptions into the config, I could see that helping performance a bit as that column is by far responsible for the bulk of the MB tileset size.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/136#issuecomment-731300266, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5ARWKLEA653O7E3BCTSQ2RHDANCNFSM4T5AY37Q.

[abettermap]

FUN FACT: If it's relevant to this talk, you have about 464 unique Descriptions currently.

And in any case it will take a while to write new descriptions.

For what, the language or instance level?

Regardless, it would be nice to have something for people to bite into at Explore/Language and truncated could work. And as you say the card footers are almost always repetitive as it stands, so not crucial.

The data for this must be at the language-level config then. I wouldn't be able to just grab the first instance of that language and use its Description if some of the Descriptions are different for that Language.

Another way to look at this from the code side is to simply use both the instance-level and language-level description. If the former is empty, then so be it, the JS won't care. What I'm seeing as candidates for migrating to an approach like that is Descrips like this:

A wide range of New Yorkers across the metropolitan area speak some form of Persian, including Bukhori (Uzbekistan), Dari (Afghanistan), Tajik (Tajikistan), and Hazara (Afghanistan). The largest centralized Iranian community in the region may be the Iranian Jewish community in Brooklyn and Great Neck which formed after the 1979 Revolution, where there are several other Jewish languages spoken but standard Persian (based on the Teheran variety) is a lingua franca. Although Iranian Muslims, many of them middle-class professionals who came after 1979, are not concentrated in any particular neighborhood, there are hubs in eastern Queens (where the Imam Al-Khoei is one religious hub), Manhattan, and elsewhere.

...which is nearly identical to another, except for the last sentence. So, conceivably you could put everything up to "Although" into the language-level Descrip and everything after it into instance-level?

Not sure if that makes sense or is relevant but just a thought.

So for now leave Description where it is in the main sheet

yep.

but start an Overall Description field in the config sheet so we can try it out?

i'm one step ahead of you. ;) yeah go ahead. it's kind of a stretch to squeeze into this SOW as it's way beyond "see related" at this point, so i'll slap a Wishlist label on it for the time being.

[rperlin-ela]

FUN FACT: If it's relevant to this talk, you have about 464 unique Descriptions currently.

That is useful, thanks — a normal-sized book's worth!

For what, the language or instance level?

Well, hopefully with the right setup it won't affect you, but it's kind of both or either. In some cases, an instance entry can actually serve as the language entry and then ideally I would write an instance entry. In some cases, an instance entry should stay an instance entry and we should write a language entry. Or split a current entry in two.

The data for this must be at the language-level config then. I wouldn't be able to just grab the first instance of that language and use its Description if some of the Descriptions are different for that Language.

Ok, so language-level descriptions in the config sheet and those will go to Explore/Language. Instance-level descriptions in the spreadsheet and those will go to the Details panel. And if there is no true language-level description, would I just stick the instance-level descrip in the config too (or do you pull it from the tileset)?

Another way to look at this from the code side is to simply use both the instance-level and language-level description. If the former is empty, then so be it, the JS won't care. What I'm seeing as candidates for migrating to an approach like that is Descrips like this:

A wide range of New Yorkers across the metropolitan area speak some form of Persian, including Bukhori (Uzbekistan), Dari (Afghanistan), Tajik (Tajikistan), and Hazara (Afghanistan). The largest centralized Iranian community in the region may be the Iranian Jewish community in Brooklyn and Great Neck which formed after the 1979 Revolution, where there are several other Jewish languages spoken but standard Persian (based on the Teheran variety) is a lingua franca. Although Iranian Muslims, many of them middle-class professionals who came after 1979, are not concentrated in any particular neighborhood, there are hubs in eastern Queens (where the Imam Al-Khoei is one religious hub), Manhattan, and elsewhere.

...which is nearly identical to another, except for the last sentence. So, conceivably you could put everything up to "Although" into the language-level Descrip and everything after it into instance-level?

Yes, there are some of these and that would work.

i'm one step ahead of you. ;) yeah go ahead. it's kind of a stretch to squeeze into this SOW as it's way beyond "see related" at this point, so i'll slap a Wishlist label on it for the time being.

Great, understood, I'll try a few language-level descriptions in the config sheet.

[abettermap]

Ok, so language-level descriptions in the config sheet and those will go to Explore/Language.

yes, and ultimately if we/I get to that point, would it go into Details as well, like for the ones that could be split up? or is that a bad idea? like this:

Instance-level descriptions in the spreadsheet and those will go to the Details panel.

yes but don't mess with those yet. let's ease into this whole language-level config thing slowly.

And if there is no true language-level description, would I just stick the instance-level descrip in the config too (or do you pull it from the tileset)?

hmm, i'm leaning towards no. that has a bad smell to it, and seems hacky. it would also eliminate the option i proposed above (using lang-level and instance-level for Details).

in that scenario, what would i use at that /Explore/Language/Something level? the description from the first instance of Something? or in that scenario would it always be the only instance of Something?

from a data and code standpoint, it sounds messy to fall back to an instance-level like that, but i understand the issue of not having true lang-level descrips. the reverse (where we fall back on the language-level if no instance-level exists) makes more sense to me code/data-wise so i'm okay with that approach.

i think in the interim the easiest will be at the /Explore/Language/Something level to simply not show any descriptions if there isn't one at the language level. if it makes sense to eventually use the description of the first (only?) instance of that language, it might be easier than i'm envisioning and we can give it a try.

recap

1. don't mess w/instance-level descrips yet
2. lang-level in the config: go ahead with those descrips, but you won't reap the rewards until after this branch.
3. we'll start with /Explore/Language/Something level and see how it goes. will hold off on Details for a bit.
4. let me know about the hybrid lang-level/instance-level in Details
5. ...and about the reverse fallback (fallforward??) of using first/only instance-level descrip at /Explore/Language/Something level

[rperlin-ela]

yes, and ultimately if we/I get to that point, would it go into Details as well, like for the ones that could be split up? or is that a bad idea? like this:

This makes sense to me, sure.

i think in the interim the easiest will be at the /Explore/Language/Something level to simply not show any descriptions if there isn't one at the language level. if it makes sense to eventually use the description of the first (only?) instance of that language, it might be easier than i'm envisioning and we can give it a try.

First instance sounds totally fine to me and not having anything also not a big deal.

[abettermap]

@rperlin-ela

Now that I've wrangled the Languages Config into submission (aka converted to JSON on the fly), it's plenty easy to work with throughout the app (or at least the spots I've tried it in). This will open up a new can of worms, so let's start small with some Description considerations at the /Explore/Language/LanguageName level. Let's use Ilocano as an example:

Bear in mind that the decisions for some of the considerations will affect the others.

Position/order

The main options that seem to make sense to me are:

1. Immediately after title/subtitle, like I have it, OR
2. After glotto/iso, OR
3. After the "X items". The way I have it set up, this one is hardest, and actually what if we just axe the item count for this level? It's not really doing much.

Truncation

Obviously we're not going to show the full thing, so what's a good ballpark cutoff? 5 lines before we show a "Read more"? I can't really do lines in JS per se, so it's going to be a character count instead, but we're just going for ballpark here.

This is at 330 chars, and I think this position/order is the best of the three options (pretend that the break is at a whole word, not a single char like "b", just haven't wired it up yet):

"View census" link (btn???)

1. Where are you thinking of a home for this?
2. What should the text be?
3. What if Ilocano is already the active census layer? Should the text change, and the link become non-clickable? Like Census: currently showing Ilocano in map or ideally something less verbose?

How about this (but better wording hopefully, maybe like Census layer: show in map or Census: show Ilocano in map):

These guys

I know this is part of a much larger convo we've had a few times (and probably an internal one you've had with yourself, ha), but can we do something better with the "secondary, nth-ary" neighborhoods repetition? Like this maybe?

(the woodside link would go to /Explore/Neighborhood/Woodside)

Similarly, in Details

instead of this:

something like this:

Clicking the "Woodside +1" would trigger a popout menu with clear indications of what's up, more or less the same info conveyed in the /Explore/Language/LangName shots above.

thoughts?

[rperlin-ela]

I like it exactly as you have it, around this cut-off, axing the item count, after the ISO/Glotto!

Bingo, this is a great spot for the census stuff in Explore/Language. Can we also get it into Details? I realize it makes things busy, but I guess there under the line of options that begins with "Clear Selection" and ends with "Share"?

In terms of the text, maybe "Display related Census data (in map?)". Also not super elegant, but we need "related" because part of the idea is to show Italian data for Sicilian, Chinese data for Fujianese, and so on. Assume non-clickable if there is no census layer to show. If it's not hard to make the text change, that sounds like a cool option to have the text change to something like "Displaying Italian Census data", even with Italian bold or highlighting? Just thinking out loud, but I like where you're going with this.

I know this is part of a much larger convo we've had a few times (and probably an internal one you've had with yourself, ha), but can we do something better with the "secondary, nth-ary" neighborhoods repetition? Like this maybe?

(the woodside link would go to /Explore/Neighborhood/Woodside)

Similarly, in Details

instead of this:

something like this:

Clicking the "Woodside +1" would trigger a popout menu with clear indications of what's up, more or less the same info conveyed in the /Explore/Language/LangName shots above.

thoughts?

I also really like all of this, go for it, feels like it could really help clarify things. I'm probably the only one who would notice but I did go through the Secondaries recently and made a few dozen of them into new Primaries that I thought were justified and where we could find a legit location. Fwiw I especially focused on making sure that Secondaries are pretty much all adjacent or at least not too far from Primaries. But again, probably way too subtle and doing something in the UI to really express the difference (besides the bolding we currently have) seems all for the good. I like the text you have ("this baby") but happy to help tweak. The basic idea is that a Primary is the place, usually one per borough/county, either estimated to have the largest concentration of speakers or with a key community institution.

(Btw, when I went to go see what we had in the Glossary on primary/secondary, I got an error at https://map.languagemapping.org/help)

[abettermap]

I fixed the Help issue in my branch, will be in production after this PR merge. LOVE Sentry! Knew about that error days before you mentioned it.

Yeah I should be able to get the language-level description into Details. I'll just reuse the same component as Explore, which will use the one from the world map toggle.

If we're doing language-level where you suggested in Details (agreed on placement), does that mean I don't need to check for existence of language-level vs. instance-level? I don't think that's relevant now if we're showing each one in different spots in Details.

These should all be relatively easy to implement as I've got much of the supporting structure in place. I'm up in the mountains today but I should be able to dig into it this weekend. Looking forward to UI stuff instead data config for a change! 🚀

[abettermap]

If you have some good wording for the primary and secondary hoods, preferably something I can reuse in the Details popout I suggested, feel free to put it here or in the Sheets metadata tab.

[rperlin-ela]

If you have some good wording for the primary and secondary hoods, preferably something I can reuse in the Details popout I suggested, feel free to put it here or in the Sheets metadata tab.

If clicking "Woodside +1" leads to this pop-up, I assume that means it no longer functions as a chip taking us to Explore. Is there a way to keep something like this for the Primary in the pop-up. I know you're planning on it for Secondaries.

Might have to see it in action, but I think you should be able to reuse this text:

Primary Neighborhoods Major site for use of the language, usually one per borough

Additional Neighborhoods Other selected locations where the language is used — not represented on the map

Learn more about the other languages spoken in these neighborhoods (needed?):

If we're doing language-level where you suggested in Details (agreed on placement), does that mean I don't need to check for existence of language-level vs. instance-level? I don't think that's relevant now if we're showing each one in different spots in Details.

I don't think I see a need to check. For now I'm basically not going to mess with the instance-level descriptions, I'm just going to try to make more language-level ones.

Is it possible also to have the "Display Related Census Data" link in Details?

These should all be relatively easy to implement as I've got much of the supporting structure in place. I'm up in the mountains today but I should be able to dig into it this weekend. Looking forward to UI stuff instead data config for a change! 🚀

Hope the mountains were good!

[abettermap]

Question. If clicking "Woodside +1" leads to this pop-up, I assume that means it no longer functions as a chip taking us to Explore. Is there a way to keep something like this for the Primary in the pop-up. I know you're planning on it for Secondaries.

Yeah totally, I won't remove any functionality we already have, I just forgot about it in the suggestion.

Additional Neighborhoods Other selected locations where the language is used — not represented on the map

Hmm we might have to work on that wording. It could come across as "there are no communities for any language in that neighborhood, period". Or I might just be reading it weird, not sure.

Learn more about the other languages spoken in these neighborhoods (needed?):

Yeah some kind of "Learn more" link in this panel in general would be good. In the spirit of id'd links, could do /help#neighborhoods or something similar?

What do you think about combining the two blurbs into one intro, and putting the "Learn more" link in there? The combo would go above "Primary Neighborhoods".

I could go either way on that but if we don't do combo blurb but include "Learn More" in Addl Locations, then seems logical to include "Learn More" link in Primary blurb as well. We are going to end up with very educated users. :)

Is it possible also to have the "Display Related Census Data" link in Details?

Yep, I forgot that one in my screenshot as well. Can we just use the same exact thing we're using in Explore intro's census stuff?

On that note, how would you feel about chipping it in both spots? The chip (or link, if we don't chip) would simply say Census (ideally w/an icon) that triggers a popout with these things:

1. heading, like "Census data" or something
2. a small blurb about what's going on, like a really slimmed-down version of the blurbs in Spatial
3. ...and a Learn More link to /about#census
4. possibly an indication of source type (puma or tracts)
5. btn or link that triggers the census language dropdown: disabled if said language is currently selected in dropdown. more or less what we already discussed.
6. btn/link to clear the selected census language
7. btn/link to "view more..." or similar, which takes you to Spatial

[rperlin-ela]

Additional Neighborhoods Other selected locations where the language is used — not represented on the map

Hmm we might have to work on that wording. It could come across as "there are no communities for any language in that neighborhood, period". Or I might just be reading it weird, not sure.

Good point. Is something like this too explicit/wordy?

Primary Neighborhoods Major site for use of the language, usually one per borough. Communities are always displayed on the map in their primary neighborhoods.

Additional Neighborhoods Other selected locations where the language is used. Communities are never displayed on the map in their additional neighborhoods.

Learn more about the other languages spoken in these neighborhoods (needed?):

Yeah some kind of "Learn more" link in this panel in general would be good. In the spirit of id'd links, could do /help#neighborhoods or something similar?

Oh with this I was trying to tee up your

• Woodside
• Pretend There's Another

Maybe it should be more like "Click a neighborhood below to see a list of its languages"?

I'm fine to do a /help#neighborhoods if there's something to say, but I don't want to give people too many links.

What do you think about combining the two blurbs into one intro, and putting the "Learn more" link in there? The combo would go above "Primary Neighborhoods".

Seems fine to me. You mean like

A Primary Neighborhood is a major site for use of the language, usually one per borough. Communities are always displayed on the map in their primary neighborhoods. An Additional Neighborhood is another selected locations where the language is used. Communities are never displayed on the map in their additional neighborhoods.

Yep, I forgot that one in my screenshot as well. Can we just use the same exact thing we're using in Explore intro's census stuff?

I think so

On that note, how would you feel about chipping it in both spots? The chip (or link, if we don't chip) would simply say Census (ideally w/an icon) that triggers a popout with these things:

1. heading, like "Census data" or something
2. a small blurb about what's going on, like a really slimmed-down version of the blurbs in Spatial
3. ...and a Learn More link to /about#census
4. possibly an indication of source type (puma or tracts)
5. btn or link that triggers the census language dropdown: disabled if said language is currently selected in dropdown. more or less what we already discussed.
6. btn/link to clear the selected census language
7. btn/link to "view more..." or similar, which takes you to Spatial

Great call, I like it. (Though this would be the only chip in /Explore/Language/LangName?). For icon, something like https://iconmonstr.com/clipboard-6-svg/?

[abettermap]

Good point. Is something like this too explicit/wordy?

Better, but something still seems off to me with the explanation of how they're displayed in the map. If anything comes to me I'll play with it and send you back a draft.

Oh with this I was trying to tee up your...

Ah, gotcha, yeah that would work, although probably moot if we roll with the combo blurb.

I'm fine to do a /help#neighborhoods if there's something to say, but I don't want to give people too many links.

Fair enough, I had assumed what you wrote in Methodology and Glossary might cover it a little more, but if it's pretty sparse on the Neighborhood front then we can certainly omit the over-linkage. Your call if you want to add more to either of those, write a new section, have me link to one of them as-is, or just scrap the Learn More here.

Seems fine to me. You mean like

A Primary Neighborhood is a major site for use of the language, usually one per borough. Communities are always displayed on the map in their primary neighborhoods. An Additional Neighborhood is another selected locations where the language is used. Communities are never displayed on the map in their additional neighborhoods.

Yep, exactly. If we can describe the relationship w/the map a bit more clearly, all the better, although I'm short on words for that at the moment.

If it fits neatly with the rest of the wording, we should also consider indicating the NYC-only-ness of Neighborhoods.

Great call, I like it. (Though this would be the only chip in /Explore/Language/LangName?). For icon, something like https://iconmonstr.com/clipboard-6-svg/?

excellent selection, very census-y! i think it might be too detailed for chippery though, and also we should stick with react-icons whenever possible (i don't have to download stuff or track anything extra in Git this way). maybe this one?

or

or

[rperlin-ela]

I vote for FaClipboardList. Everything else here sounds good — don’t want to bog us down into too much more back-and-forth, and I think we’re on the same page, so I’d say just go for it

On Dec 5, 2020, at 9:11 PM, Jason Lampel notifications@github.com wrote:

Good point. Is something like this too explicit/wordy?

Better, but something still seems off to me with the explanation of how they're displayed in the map. If anything comes to me I'll play with it and send you back a draft.

Oh with this I was trying to tee up your...

Ah, gotcha, yeah that would work, although probably moot if we roll with the combo blurb.

I'm fine to do a /help#neighborhoods if there's something to say, but I don't want to give people too many links.

Fair enough, I had assumed what you wrote in Methodology and Glossary might cover it a little more, but if it's pretty sparse on the Neighborhood front then we can certainly omit the over-linkage. Your call if you want to add more to either of those, write a new section, have me link to one of them as-is, or just scrap the Learn More here.

Seems fine to me. You mean like

A Primary Neighborhood is a major site for use of the language, usually one per borough. Communities are always displayed on the map in their primary neighborhoods. An Additional Neighborhood is another selected locations where the language is used. Communities are never displayed on the map in their additional neighborhoods.

Yep, exactly. If we can describe the relationship w/the map a bit more clearly, all the better, although I'm short on words for that at the moment.

If it fits neatly with the rest of the wording, we should also consider indicating the NYC-only-ness of Neighborhoods.

Great call, I like it. (Though this would be the only chip in /Explore/Language/LangName?). For icon, something like https://iconmonstr.com/clipboard-6-svg/ https://iconmonstr.com/clipboard-6-svg/?

excellent selection, very census-y! i think it might be too detailed for chippery though, and also we should stick with react-icons whenever possible (i don't have to download stuff or track anything extra in Git this way). maybe this one?

https://user-images.githubusercontent.com/4974087/101269579-80ddaf00-372d-11eb-85a1-c34c6dd2b43a.png or

https://user-images.githubusercontent.com/4974087/101269588-a36fc800-372d-11eb-8e5d-b2945804db9b.png or

https://user-images.githubusercontent.com/4974087/101269592-acf93000-372d-11eb-9a54-1395a08d7293.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/136#issuecomment-739444060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5AW7IXDMX2WF2OUY5LSTLR57ANCNFSM4T5AY37Q.

[abettermap]

sounds good. one question on /Explore/Language/LangName intro Description though: it can get pretty meaty and, either way, i don't think the "Read More" will be as applicable here as "Show/hide World Map", especially on mobile:

if i move the toggle to the end, you potentially wouldn't see it until scrolling to the end:

...which is fine but feels a little unnatural if the user wants to jump ship and backpedal on the commitment to read more.

so, any ideas on what to do with that? i can cap the max height and allow it to overflow perhaps:

but maybe only for mobile since overflow scrolling is hideous on desktop:

and it's not terrible on desktop to begin with, although it might be a bit much for larger descriptions:

so i guess that's more like several Descrip questions than one:

1. should it always be shown in full when Read More is toggled?
2. if not
   1. should there be a max height and overflow on just mobile or also desktop?
   2. and how tall should it be allowed to get?
3. where should the "Read more" toggle be positioned relative to the text it toggles?
4. are any of the Descrips big enough to justify a full-on modal or is that excessive?

mainly i just don't want the Neighborhoods cards/info to get lost in the shuffle or make it hard to get back to them on mobile.

[abettermap]

here are some inspirations: https://codepen.io/tag/read-more

none of them are mind-blowing but they do seem pretty consistent in that the toggle is always below the text, which is easier to work with in the code anyway, so i'll roll with that and let's call the overflow thing on mobile a wishlist until you have strong feelings against.

[rperlin-ela]

Do what you gotta do, I don't have strong feelings. I feel like we do have some room to work with on these, but you're right that the cards need to be at least a little visible. Neither always showning in full nor full-on modal feels necessary— max height / scrolling on mobile could be ok. Of the inspirations, offhand I kind of dig Mahtan Alab's fadeaway lines and "Show More" but all look fine.

[abettermap]

agreed on fadeaway, was thinking of that before you mentioned the example.

i'm thinking no special handling on mobile for two reasons:

1. user will have definitely seen the Neighborhood section before they decide to click Read More, so they know there's something there
2. unless the Descrip is REALLY long, the inertia scrolling on touchscreens will make it easy to scroll down to Read Less.

if that doesn't have a good feel on mobile, i can tweak, but it should be good enough.

[abettermap]

@rperlin-ela

What do you think about including not just glotto/iso but all of the non-census, language-level info in a chip-triggered popout (or toggleable section like our Read More) in the pre-Details view? Aka everything that's not instance-level chips in Details (no town/neighborhood, and obviously not Language since we're already at that Explore level):

• Country
• Language Family
• World Region
• Macrocommunity (not sure if this is language-level)

...which would all be linkable like the current Details chips, followed or preceded by some kind of meta/stats section with non-clickable:

• Global Speaker Total
• Glottocode
• ISO 639-3

This goes hand in hand with the VLOOKUP suggestion I just emailed you and Matt, but if that heads to the backburner then I think config-wise it would just require adding the missing cols to Config:

• Country
• World Region
• Macrocommunity (not sure if this is language-level)

This would keep our "everything is related and linkable" exploration encouragement going, and wouldn't drown out the census, descrip, or neighborhoods of the pre-Details view if I hide it all behind a popout/toggle. Or, if you're keen to make this view a true "Language Profile" page, then maybe that stuff shouldn't be hidden at all. Just depends what your goals are for that level.

Thoughts?

[abettermap]

Oh and one other question that ties into all of this: how would you feel about showing all values 24/7 at the /Explore/Something level rather than leaning on what's currently filtered? I can't remember if we're using filtered because it prevents the scenario of an empty pre-Details or because it was convenient in the code, or both, but now that we have all these goodies in Config, it's certainly more straightforward to use that than to obtain the values via instance-level, not to mention it would promote even more exploration and maybe be a bit more performance as the lag is noticeable, at least at /Explore/Language.

I think just about anything from Explore down to pre-Details could be driven by Config, so let me know what you think.

[abettermap]

Re: all language-level non-census info, i'm thinking the chips would flow better with the census chip than the plain glotto/iso currently do:

i got the menu wired up, now it's just down to wording and UI layout/placement. i have a few small design tweaks to make but overall does anything seem insanely off here?

and once you click "Set" it looks like you'd expect:

[rperlin-ela]

i got the menu wired up, now it's just down to wording and UI layout/placement. i have a few small design tweaks to make but overall does anything seem insanely off here?

and once you click "Set" it looks like you'd expect:

Seems great — the only essential thing is to make clear what language the census layer is. In this case, that we're showing you "Arabic" census data because that's the most closely related data we have for "Algerian Arabic". I guess we can get away with the chip saying just "Census", though I don't want people fooled by that, but then definitely in the pop-up we have to make what we're doing clear. I'm not sure "Census options" is necessary, and instead of "Census granularity: Tract level", we could have something like:

Related Census Data: Tract-Level Arabic

[rperlin-ela]

What do you think about including not just glotto/iso but all of the non-census, language-level info in a chip-triggered popout (or toggleable section like our Read More) in the pre-Details view? Aka everything that's not instance-level chips in Details (no town/neighborhood, and obviously not Language since we're already at that Explore level):

Cool, sounds like a great suggestion if I understand it, basically beefing up pre-Details but in a way that's unobtrusive, brings out stuff which is languishing in the Data table, and doesn't affect Details

Oh and one other question that ties into all of this: how would you feel about showing all values 24/7 at the /Explore/Something level rather than leaning on what's currently filtered? I can't remember if we're using filtered because it prevents the scenario of an empty pre-Details or because it was convenient in the code, or both, but now that we have all these goodies in Config, it's certainly more straightforward to use that than to obtain the values via instance-level, not to mention it would promote even more exploration and maybe be a bit more performance as the lag is noticeable, at least at /Explore/Language.

I can't remember either. I can't totally wrap my head around all the different potential use cases right now, but if we can't think of a reason why someone would need to go deep into Explore with their filters on— since drilling down into Explore is basically like filtering away— then you're totally right, let's clear those filters. Would the map stay in a filtered state or would it revert back to the full thing?

I think just about anything from Explore down to pre-Details could be driven by Config, so let me know what you think.

Ok, seems like you and Matt are on it, but I can help if needed

[abettermap]

Cool, sounds like a great suggestion if I understand it, basically beefing up pre-Details but in a way that's unobtrusive, brings out stuff which is languishing in the Data table, and doesn't affect Details

Sounds good. So are you leaning towards displaying those chips 24/7 or hiding them behind a toggle?

Would the map stay in a filtered state or would it revert back to the full thing?

Stay in filtered state. The Explore's wouldn't have much relationship with the data-data until the pre-Details I think, since that's where the instance-level stuff comes in.

Also we'd still have our handy little orange dot, warning text, and clear/view filters links, and I think those would be just as applicable in the 24/7 scenario. Might need to reconsider the wording a little, or maybe it's fine as-is. We'll see how it feels.

Seems great — the only essential thing is to make clear what language the census layer is. In this case, that we're showing you "Arabic" census data because that's the most closely related data we have for "Algerian Arabic". I guess we can get away with the chip saying just "Census", though I don't want people fooled by that, but then definitely in the pop-up we have to make what we're doing clear. I'm not sure "Census options" is necessary, and instead of "Census granularity: Tract level", we could have something like:

I sort of replied to this in Sheets Chat (ha) already but just for posterity: yes, totally agree, I was just taking the lazy way out since there's an extra step to jump out of Config land and into LUT_Census-something_Fields. I'm stumbling through a formula to add a Census Pretty column to Config-via-LUT, so that will make the census indication a cinch.

Last thing- you know my affinity for icons, so i went with these guys:

If you're going through any react-icons withdrawals, holler if you find any better ones, or even just the concepts/topics (e.g. i search for "list" for the All languages icon.

[abettermap]

ok pretty ugly formula to make my little convenience field work:

=IFS(
  E2<>"",
  INDEX(
    puma_pretty,
    MATCH(E2,puma_original,0)
  ),
  F2<>"",
  INDEX(
    tract_pretty,
    MATCH(F2,tract_original,0)
  ),
  "Ain't never"<>"gonna be equal", ""
)

and it relies very much on a named range, and i don't know how to avoid the fragility of this besides adding a Note in the column heading, but without the named range i wasn't able to auto-fill the formula in the 655 rows, and i wasn't about to hand-jam it.

totally worth the effort though, got a fine-looking chunk of data to work with now:

Winner of Top Poor Man's DB award, 1 year running 🥇

Sorry to jump back on the blurb train but the current "Related Census Data" doesn't convey the "granularity" or "level" or "source" -ness of what's going on. If you or any of your fellow language nerdos have any suggested alternatives for this or any other blurb, holler and i'll change it.

Not really satisfied with my UI blandness in that popout either, will improve it if i think of something.

[abettermap]

I'm not sure "Census options" is necessary

i overlooked this, will leave it in for this PR if no major changes, then rm in the next one. if major changes then will rm in this one.