Pre-details wrapup #145
Pre-details wrapup #145
Conversation
info: - Tighten/consistentize panel intros, detangle components and styles, etc. - Add Global Speakers to stats/meta section of pre-Details, and Country/Region to its chips - Stop showing repetitive Language icons in mid-level views
|
@rperlin-ela solid progress today, got most of the pre-Details stuff in there (except "Share") and a bunch of UI improvements/consistentizations for the "intro" sections as well. Once it builds, this is a good one to test (probably the only one until Country is populated): https://deploy-preview-145--languagemapping.netlify.app/Explore/Language/Arabic%20(Algerian) I have to say i disagreed with bold-ing the census name instead of its label in the popover. A bold heading is pretty standard, and the value it describes is non-bold:
or
or
or
If you want me to juggle the UI and/or wording, no problem, it just seems like a good standard to preserve. |
|
Looking great to me.
About bold-ing, I understand what you mean, and maybe it would feel different with the popover in, but I think this is a bit of a different case. I don’t think it would be meaningful to bold everything before the colon, so if you’re very anti-, we can just axe bold here altogether unless you have another way to rework
… On Dec 7, 2020, at 5:48 PM, Jason Lampel ***@***.***> wrote:
@rperlin-ela <https://github.com/rperlin-ela> solid progress today, got most of the pre-Details stuff in there (except "Share") and a bunch of UI improvements/consistentizations for the "intro" sections as well. Once it builds, this is a good one to test (probably the only one until Country is populated):
https://deploy-preview-145--languagemapping.netlify.app/Explore/Language/Arabic%20(Algerian) <https://deploy-preview-145--languagemapping.netlify.app/Explore/Language/Arabic%20(Algerian)>
I have to say i disagreed with bold-ing the census name instead of its label in the popover. A bold heading is pretty standard, and the value it describes is non-bold:
<https://user-images.githubusercontent.com/4974087/101414108-b6f06f80-38a2-11eb-9939-466cefb27a0f.png>
or
<https://user-images.githubusercontent.com/4974087/101414120-bc4dba00-38a2-11eb-9e6b-9372607cbeff.png>
or
<https://user-images.githubusercontent.com/4974087/101414135-c2dc3180-38a2-11eb-8ed9-5ea3fcb427d4.png>
or
<https://user-images.githubusercontent.com/4974087/101414177-d8515b80-38a2-11eb-84a3-410d282b4ca3.png>
If you want me to juggle the UI and/or wording, no problem, it just seems like a good standard to preserve.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5CPUN7Q25UM6643DCTSTVLTNANCNFSM4URDVUQQ>.
|
|
you're right, i don't think full pre-colon bold works here so i just went all-in with a different approach, what do you think?
the largest monster of all is this one, and it's still not terrible:
|
|
Approach is good. Just need to clarify and hedge the phrasing a bit because these connections are our based on our analysis, so how about
“Speakers of Arabic (Algerian) are likely to be included within the census category of Arabic, for which ACS 2014-2018 data is available at the tract level."
And maybe “View all census language data”?
… On Dec 7, 2020, at 9:36 PM, Jason Lampel ***@***.***> wrote:
you're right, i don't think full pre-colon bold works here so i just went all-in with a different approach, what do you think?
<https://user-images.githubusercontent.com/4974087/101430914-2c6c3800-38c3-11eb-894a-59a81e7c1266.png>
the largest monster of all is this one, and it's still not terrible:
<https://user-images.githubusercontent.com/4974087/101430986-4f96e780-38c3-11eb-8d6d-4e4efdd18834.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5F5MBYZ6L2JJRUVMATSTWGLDANCNFSM4URDVUQQ>.
|
Replies
k how about this?
hmm, we aren't really showing data in the "data" sense like we are in the table, and either way the link just takes the user to options for interacting with it, so how about:
Alternative words Updatesok gang's all here i think? if we add anything else, she's gonna burst, captain!
i mean it'll "fit" but once any wrap-causing multi-country chips, descriptions, and lengthy language names start crashing this UI party, mobile users might not know about the Neighborhoods gold that lies below. and i'm reluctant to downsize any further, it's got a good snug fit as-is. the only thing i might do is reduce the height of the Descrip preview, although i've already done that a few times. mobile users are used to scrolling, i'm sure they'll fine the treasure below. is there anything else to add or can we call this branch good (after your replies to Replies)? |
|
(btw this whole "Language profile" thing we've got going is pretty slick! much more than the bare-bones Explore's we started with) |
|
i pushed up what i settled on, should build/deploy shortly. also i added Video/Audio cols to Config, and populated Acehnese with video for your testing needs. LMK what to change, otherwise i think we can wrap up this branch? |
|
Banging — I think we can wrap up!
One thing when you click “Share”. I know it makes sense to reuse text, but I feel like this needs a tweak. Like can we slightly modify “Share this Arabic (Algerian) community” to (I’m not totally sure but) maybe just “Share Arabic (Algerian) in New York”? Or “Share this description of Arabic (Algerian)”?
Agreed that these Explore pages have come a long, long way!
… On Dec 7, 2020, at 10:38 PM, Jason Lampel ***@***.***> wrote:
i pushed up what i settled on, should build/deploy shortly.
also i added Video/Audio cols to Config, and populated Acehnese with video for your testing needs.
LMK what to change, otherwise i think we can wrap up this branch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5A4F5DHVJRNXOPW3MDSTWNTTANCNFSM4URDVUQQ>.
|
|
Yeah I can totally set it to that text for Share, it's currently just using the default I set when you share from the sidebar (as opposed to Details). However, it's actually set to use Description (language-level), but I know not all languages have one, so yeah I'll have it fall back to your suggestion and use Description whenever available. Done with computers for the night, will wrap this up tomorrow. |
|
Oh you're talking about the text above the buttons. I was referring to the summary text when you actually click one of them. But yeah, I can change the above-buttons text as well. |
|
Cool, and language-level for the summary text but falling back to instance-level otherwise would be great
…> On Dec 7, 2020, at 11:37 PM, Jason Lampel ***@***.***> wrote:
Oh you're talking about the text above the buttons. I was referring to the summary text when you actually click one of them. But yeah, I can change the above-buttons text as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Reminder for Near-future Jason: make sure the census dropdown value persists between view changes. |
So for this, what if there is more than one instance of that language? Will they each have the same instance-level description and it doesn't matter which one I use? Or, if there's more than one instance can I expect a language-level description to be available? We are just talking about the summary used in the share buttons, but I assume this applies to the pre-Details "read more" description as well? |
how's this?
|
Ultimately, if there are multiple instances and they differ, there should be a language-level Description. I think we're 95% of the way to that goal, but I think there may be a few that aren't yet (e.g. African-American English) and I can't think of an immediate way to check the rest without going through the whole list. I'll try to nail it down soon. In the meantime, I'd say it doesn't matter which one you use.
Makes sense, assuming we want to fill in something for this across the board. So if there's no language-level and only one type of instance-level, just repeat what's in Details? Separately, should have mentioned this before when discussing order, but maybe Global Speakers before Glotto and ISO? Not a big deal either way, just a thought |
Looks good |
Pave the way for hook-based approach to find the feature needle in the features haystack based on non-ID attribute (likely "Language"). Bunch of trivial refactoring/shortening as well.
Details as in what's currently the instance-level Description, show below the intro stuff? Yes if i'm understanding correctly. I think we decided though that I wouldn't have to do any checks to see if a lang-level descrip OR instance-level exists AND see if instance-level count is 1? Either way, i need to be careful with this if we're showing lang-level descrips (when available) in the up-and-coming "Read More" of Details' intro, but at the pre-Details view I got the instance-level fallback working no problem, but i forgot what we decided on the redundancy with the card footers?
we're kind of running out of stuff that's unique to Details, it's mostly covered in the pre-Details now, but for sake of UI consistency i'd rather not leave the card footer empty, so how about something simple like:
or maybe Click to show in map makes more sense?
sure thing, easy fix. |
|
i'm blunt-and-deliberate mode lately, how's this?
|
Right, sorry I meant instance-level Description. And I don't want to make you run more checks. But if instance-level fallback is working, it seems like we're in good shape. To review (so that things are straight in my own head), I see the following scenarios with Descriptions, but let me know if I'm missing something: Distinct Lg-Level and Distinct Instance-Levels: Show each at their level
Yes, assuming the Primary/Secondary split is on the way, I like this.
How about a middle-ground option like "Click to show in map and display details"? |
not sure what you mean regarding "Show each at their level" and similar. do you mean in the pre-Details ("language profile") card footers and Read More? maybe just pick a handful of real-world examples from the data/config (assuming it's current enough to do so) and let me know what those languages are and what their pre-Details would look like.
that works. |
|
No worries. I think I'm clear, and if you're clear on things, we should be good. |
|
i'm not, but it's either down to this:
or this:
the second one is already set up and functioning, so let me know if that's correct. |
|
second one, applied to multi-instance:
|
|
Second one is correct.
… On Dec 8, 2020, at 4:51 PM, Jason Lampel ***@***.***> wrote:
i'm not, but it's either down to this:
<https://user-images.githubusercontent.com/4974087/101545255-3c882400-3964-11eb-98d4-dbd995546bfd.png>
or this:
<https://user-images.githubusercontent.com/4974087/101545414-748f6700-3964-11eb-8a46-767fc10f1586.png>
the second one is already set up and functioning, so let me know if that's correct.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5GQKRAC2RM36TH2E53ST2NWFANCNFSM4URDVUQQ>.
|
… available: Also extract the logic from the language cards list component into a hook.
|
@rperlin-ela ok i think we're at a good point to merge. the Neighborhoods stuff, possibly including your comment: #132 (comment) in that branch i would also like to use language-level Config instead of instance-level wherever possible in /Explore . Should be able to do most or all of that except for pre-Details and
might try to brainstorm some spreadsheet sorcery that would give us a pre-populated "Primary Neighborhood" column in Config, which would be much easier to work with than the primary/secondary parsing shenanigans. just thinking out loud but would it be possible, theoretically, to have a field called "Location", which is the primary neighborhood or town, and then "Other Locations" instead of our current approach? our current approach made more sense before all the Explore and pre-Details stuff joined the party. |
|
I’m not against re-splitting Primaries and Secondaries if it’s useful and maybe even merging Neighborhoods and Towns, though the latter feels messier — but probably not a big deal especially if it’s only on the Config sheet
… On Dec 8, 2020, at 6:00 PM, Jason Lampel ***@***.***> wrote:
@rperlin-ela <https://github.com/rperlin-ela> ok i think we're at a good point to merge. the Neighborhoods stuff, possibly including your comment: #132 (comment) <#132 (comment)>
in that branch i would also like to use language-level Config instead of instance-level wherever possible in /Explore . Should be able to do most or all of that except for pre-Details and /Explore/Neighborhoods. REALLY wish we had a way to do that, starting to question my "Primary + Secondary combined into one column" suggestion. The parsing thing is not terrible with Country, but throwing on the addl concept of "the first one before the comma is special" is quite a little nightmare in the code, sometimes i can't even walk through my own logic that i've already written! i'm sure code just looks like code, but trust me that this is nasty code:
<https://user-images.githubusercontent.com/4974087/101551296-123b6400-396e-11eb-8565-46d19c623b80.png>
might try to brainstorm some spreadsheet sorcery that would give us a pre-populated "Primary Neighborhood" column in Config, which would be much easier to work with than the primary/secondary parsing shenanigans.
just thinking out loud but would it be possible, theoretically, to have a field called "Location", which is the primary neighborhood or town, and then "Other Locations" instead of our current approach? our current approach made more sense before all the Explore and pre-Details stuff joined the party.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5AJQ4WXQNURE6O3H4LST2VXPANCNFSM4URDVUQQ>.
|
|
cool. i think it would probably be a gradual approach, like keep Neighborhood intact first but add Primary so I have something to work with. should be an easy formula: |
|
Go for it any time if you want, I’m confident we can always revert if things go horribly wrong. Or Matt or I can get to it soon
… On Dec 8, 2020, at 6:13 PM, Jason Lampel ***@***.***> wrote:
cool. i think it would probably be a gradual approach, like keep Neighborhood intact first but add Primary so I have something to work with. should be an easy formula:
=LEFT(A1,(FIND(",",A1,1)-1))
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5E55MHS3LTYNNT5PS3ST2XI7ANCNFSM4URDVUQQ>.
|
|
i'm fine editing the Config but i'd rather not mess with your data-data. or are you suggesting i do it ALL in Config? that's an idea but i think i'd want some kind of intermediate importrange sheet first, where Primary gets pulled out and then i have something to use in Config for the pre-populated Neighborhoods column. this concept was very handy with the "Census Pretty" field so i don't have to rely on a second or third sheet, it's already in Config. |
|
Ok there’s a Primary Neighborhood column now, let me know what else you need
… On Dec 8, 2020, at 6:21 PM, Jason Lampel ***@***.***> wrote:
i'm fine editing the Config but i'd rather not mess with your data-data. or are you suggesting i do it ALL in Config? that's an idea but i think i'd want some kind of intermediate importrange sheet first, where Primary gets pulled out and then i have something to use in Config for the pre-populated Neighborhoods column. this concept was very handy with the "Census Pretty" field so i don't have to rely on a second or third sheet, it's already in Config.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5G75IGD7KZ36RTBK5DST2YGDANCNFSM4URDVUQQ>.
|
|
awesome, thanks for the quick turnaround. if you're okay with it i'd say let's include that in the next MB upload and I can use it easily in the Details chip. on the language/Config level, i was able to "roll up" the instances into the Config, with a
interesting formula to make that happen (credit):
i think i need some kind of
and this:
but once that's set, i should have absolutely no conditions to check for in the code (including value existence since many already lack Neighborhood), just a parse on btw one addl benefit i could see with the extracted Primary column is more validation, as i think Neighborhood is one of the only cols that can't be validated. i'm sure there's a way but it seems pretty nasty to validate the current Neighborhood col with all its commas, but a one-per-cell would be simple. so, i added another LUT to the Config, i'm sure there's a way to validate the eventual Bearings/recapJust a recap on why the Neighborhood-in-Config is useful: now i can use Config instead of instances for all 6/6 of the options at the top-level and second-level Interesting that Neighborhoods = 180 in the current UI, but only 161 in the unique instances of them in the LUT i made. i assume this is because the former includes non-Primary?
|
|
Nice, at a glance these are looking right.
All good stuff to know too, thanks.
It makes sense that there would be some neighborhoods which appear only as Secondaries.
Just uploaded new tileset to MB with Primary column
… On Dec 8, 2020, at 11:37 PM, Jason Lampel ***@***.***> wrote:
awesome, thanks for the quick turnaround. if you're okay with it i'd say let's include that in the next MB upload and I can use it easily in the Details chip.
on the language/Config level, i was able to "roll up" the instances into the Config, with a ||| parser so we don't have to be afraid of commas anymore. do these look right at a glance?
<https://user-images.githubusercontent.com/4974087/101584236-6bb98800-399a-11eb-8bf8-666223ca1b53.png>
interesting formula to make that happen (credit <https://stackoverflow.com/a/39399630/1048518>):
<https://user-images.githubusercontent.com/4974087/101584436-e7b3d000-399a-11eb-9958-77372b2675cc.png>
i think i need some kind of IF clause in there to avoid things like this:
<https://user-images.githubusercontent.com/4974087/101584518-2053a980-399b-11eb-810e-d63a1d11b40a.png>
and this:
<https://user-images.githubusercontent.com/4974087/101584549-319cb600-399b-11eb-9972-e2f6a50bbd97.png>
but once that's set, i should have absolutely no conditions to check for in the code (including value existence since many already lack Neighborhood), just a parse on ||| at that point.
btw one addl benefit i could see with the extracted Primary column is more validation, as i think Neighborhood is one of the only cols that can't be validated. i'm sure there's a way but it seems pretty nasty to validate the current Neighborhood col with all its commas, but a one-per-cell would be simple. so, i added another LUT to the Config, LUT_Neighborhood, in case you/Matt want to do something with that.
i'm sure there's a way to validate the eventual Addl Locations column (ha, i think we've come full circle on this approach), but primary is the most important.
Bearings/recap
Just a recap on why the Neighborhood-in-Config is useful: now i can use Config instead of instances for all 6/6 of the options at the top-level and second-level /Explore levels (except for /Explore/Language).
Interesting that Neighborhoods = 180 in the current UI, but only 161 in the unique instances of them in the LUT i made. i assume this is because the former includes non-Primary?
<https://user-images.githubusercontent.com/4974087/101585527-28144d80-399d-11eb-91fb-d42578794360.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNKB5AJEW2SCMEFPZSGGBLST35HTANCNFSM4URDVUQQ>.
|
Summary
Improvements to census popover, wording/blurbs throughout UI, pre-Details. Use lang-level from Config wherever applicable, fall back to instance-level as needed.
Issues resolved by this pull request