For pie charts based on an enum field, the value key associated with each chart section appears in the legend, in the tooltip that displays when hovering over the section, and if selected as the Label type property also on the chart section itself.
However, for pie charts based on yes/no fields the value key doesn’t display anywhere–regardless of whether custom values are entered for the column’s Yes/No display values property. The chart appropriately creates a chart section for each value, but there’s no indication of which section corresponds to true vs. false. It’s extra confusing that only the false section’s color appears in the legend, which doesn’t even include the color for the true section. If there are blank values, that is labeled and also assigned its own color, which appears in the legend.
Is there a setting somewhere that governs this? Is this a bug?
For reference by anyone interested: If you don’t need more than just “Y” and “N”, your shadow column for the workaround can just use the TEXT() function:
FYI for anyone following this, here’s an update. I heard from AppSheet Support a few days ago. This is partially fixed, and maybe sufficiently for certain use cases (e.g., no custom display values, no blank values). You can see specifics in the following screenshots and exchange with AppSheet Support from 7/1/2022.
Hi, this is to inform you that the issue has been fixed.
Could you please confirm at your end?
Me
Thanks for working on this. The behavior has changed and is moving in the right direction, but is not fully fixed. A pie chart accurately represents explicit true and false values from Yes/No column that does not include custom “Yes/No display values”. However, I observe 2 lingering issues. First, a column’s custom “Yes/No display values” should replace the “Y” and “N” labels in the chart, but they don’t; the chart uses “Y” and “N” labels regardless of the presence of custom “Yes/No display values”. Second, the chart inaccurately represents blank values. Rather than being labeled “[blank]” as occurs for blank values in charts based on other column types, in this case the blank values are labeled “N”. Furthermore, they’re also aggregated separately from the explicitly false values. So, the pie chart ends up with a “Y” section for the true values, an “N” section for the false values, and another identically labeled “N” section for the blank values. If you’re still referencing my app, see the “BooleanCol1” pie chart view and its underlying data.
AppSheet support contacted me again today saying this was fixed. It remains partially fixed. Now, blank values are not both segregated and mislabeled, but rather segregated and accurately labeled. Non-blank values have suboptimal but not inaccurate labels, which may be sufficient for many use cases.
Following is are the latest details. I reported this issue in May, and then was contacted on June 2, July 1, and August 2. So, if you’re tracking this issue for some reason, maybe anticipate another update in early September.
Hi, this is to inform you that the issue has been fixed.
Could you please confirm at your end?
Me
Thanks for the continued progress on this issue.
I’m glad to see that blank values remain segregated and are now appropriately labeled.
However, the issue is not entirely fixed because the non-blank values remain inappropriately labeled. When you wrote a month ago to say this issue was fixed, the column’s true and false values were labeled in the pie chart using AppSheet’s default “Y” and “N” labels that appear elsewhere throughout the platform. Now, they’re labeled literally “true” and “false”, which is inconsistent with the rest of AppSheet. Furthermore, the pie chart labels should actually use the column’s custom “Yes/No display values” to override the default “Y” and “N” labels; see more explanation in our prior communications regarding this issue. Moreover, this intended behavior is explicitly cited in the AppSheet editor UI itself, which says those “Customizable values are applied accross all app views that have Yes/No data types”. For example, in the column in my app that I pointed you too, “Custom False” and “Custom True” should appear instead of “false” and “true” (and even instead of “N” and “Y”).
FYI for anyone who happens to be tracking this, here’s what I heard from AppSheet Support today–the issue is apparently acknowledged and being considered in some fashion.
AppSheet Support
please be informed that this issue is currently under clarification. I will update you as soon as possible.
Thanks for the updates @dbaum
You are doing an excelent job to help this platform.
If only there were actual AppSheet creators/users in charge of the backend, this kind of problems could be solved by common sense instead of sweat and tears from people like @dbaum
Thanks for the kind words, @SkrOYC . I’ve been here just a few months and already learned tons from you and others–not just about how to use AppSheet effectively, but also about how to contribute to the community.
AppSheet Support leaves plenty to be desired, and I do think being transparent about that reality is worthwhile–both to encourage improvements and to make new users aware. I’ll also note that I understand there can be myriad challenges to providing effective support and I have tremendous empathy for those responsible for doing so. As a software product owner in the company I work for, I certainly wish that I had greater capacity to remediate more bugs as well as to maximize all staff’s proficiency in communicating to users about the status of issues in the process of resolution.
Support, Marketing, Sales and more, basically the Google Team that took AppSheet as a platform.
Even the new community is nowhere near as useful as Discourse. I mean, we all know how support is slow, marketing is selling us smoke (look at the about.appsheet.com page) and sales takes weeks to just tell people the enterprise plan pricing. The community team is doing it’s best to make this GCC platform a little bit more useful by coping some of the basic features of Discourse but to be honest, we can make something look like other thing, but won’t be that thing ever
Hi, please be informed, that the issue has been resolved. Please confirm on your end.
Me
The issue is not fixed yet–at least not for the very scenario I detailed for you the last time you reported it was fixed. Here’s the behavior I observe.
Test case A: Yes/No column does not include custom Yes/No display values
Chart labels use “Y” and “N”
This is consistent with the rest of AppSheet.
Test case status: Pass
Test case B: Yes/No column includes custom Yes/No display values
Chart labels use “true” and “false”
This is inconsistent with how these values are displayed throughout the rest of AppSheet, where “Y” and “N” are used in the absence of custom Yes/No display values.
This contradicts the AppSheet editor’s description of custom Yes/No display values, which says that they are used in “all app views”.
Test case 2 status: Fail
Here are screenshots to illustrate these test cases using the following Yes/No columns:
BooleanCol1 includes custom Yes/No display values
BooleanCol2 does not include custom Yes/No display values
Table view showing values for both columns as expected
Meanwhile, in case it hasn’t occurred to others: I recently realized that there’s some complexity to this given that Custom False and Custom True values are expressions. It may be most typical to simply use a single explicit string value for each, but theoretically at least the custom false values could vary across rows, and likewise for the custom true values. In such cases, there’s not an obvious custom label to use as a chart label. The recently updated behavior of using “Y” and “N” might be the best available option. That said, the vast majority of use cases might likely involve only a single custom value for false and a single custom value for true and would benefit from those custom values being applied as chart labels.
AppSheet Support
please be informed that this issue is currently under clarification. I will update you as soon as possible.
My point was that, in this case, it’s not straightforward what the the pie chart label should be for the pie section representing the false values. For sure, the multiple custom labels for false values should be used when displaying row-level date; however, there’s not a clean way to handle determining the label for values aggregated across rows.
I get it, since it’s aggregated there can be multiple false.
In this case, I think we should have a field inside the localize tab for a default true and false
