Display name is reflected in the tooltips of floating action buttons

Currently, the tooltips for floating action buttons during rollout only use ActionName.

As with Display prominentry, if Displayname is set, we’d like it to take precedence.

Yes, Display name should be used for label on tooltips.




Escalated. I’d call this a bug.


It is a bug.


Thanks Arthur, for the comment, hope it wont be difficult job to bring a fix.


Hi Arthur! I hope that when this is fixed, it can be set so that an expressions such as

=" "

leads to the tooltips for floating action buttons to be completely hidden. There are some situations where I would prefer that it not be shown at all. Thanks!

1 Like

@Kirk_Masden @MultiTech_Visions @tsuji_koichi @Arthur_Rallu

It seems currently the tooltip only applies to Overlay Actions. I think the community needs some input from AppSheet what the intention is for this feature. If it is to be extended beyond Overlay Actions, then careful consideration will be needed for the configurable qualities desired by developers because simply using Display Name to show on the tooltip WILL NOT BE ADEQUATE…for many of the reasons @Kirk_Masden has pointed out.

Always provide Enable/Disable capability for any new visual features.

For all new features introduced into AppSheet, the very first consideration should be, IMHO, to provide a switch to disable/enable within the app. Even if it is a feature only in Beta. From my perspective, just about EVERY visual feature will need the flexibility to enable/disable. This is because there are a wide range of apps being used for many different purposes as well as a wide range of preferences by the app creators. It is almost certain that any new features added will not apply, or developers do not want them to apply, to many apps.

On the flip side, there are some certainly RARE instances where it is evident that the feature does not need an on/off switch. For example, horizontal and vertical scrolling for tables…no brainer right (though momentum scrolling seemed to be inexplicably debatable).


Thanks, @WillowMobileSystems , for your post. Of course, I agree completely.

By the way, in regard to what I wrote about in the following thread about the importance of being able to identify action names when working in the editor . . .

. . . I posted a trick/tip that may be of interest if you are not already aware of it:

Re the original bug, that should have been fixed a few days ago. The floating tool ti now shows the display name not the action name.

Re the ability to hide this if the name is empty, @Summer FYI

Re @WillowMobileSystems , the explicit switches for each feature make sense and are valuable for both flexibility and maintaining prior behaviors in apps. But as I’m sure you appreciate, there’s also a balance because the cross product of switches and features becomes huge to maintain and test and even explain to the next user who comes along. The “simple” and “no-code” message starts to erode. This balancing act between keeping it simple and uniform vs providing flexibility and power has always been the challenge. I don’t have a good answer, but generally I think of the switches we do have in two categories: (a) purely for backward compat but would recommend no new app use it, and (b) truly an option that people could easily go either way on. Many of our switches are really in category (a) and those need to gradually be deprecated.
Also, we’re trying to generate apps that have a consistent behavior for the end-users. Is this the responsibility of the platform or of the app creator or both?
These are somewhat tricky questions that we (all of us) collectively try to figure out as we build out the platform with richer features.


Thanks for your thoughtful response, @praveen . I can certainly understand the dilemma (flexibility vs. no code simplicity).

In regard to the bug, any changes that have been made are not yet evident in my main app. Here’s an example:

Yet . . .

Screen Shot 2021-04-14 at 12.43.29

1 Like

Please add tooltip fot this type of actions


I absolutely do appreciate the challenge that AppSheet faces making these decisions. I think AppSheet has grown beyond catering ONLY to the “simple no-code” approach to building apps and believe AppSheet can achieve both - and in many respects has done so! And yes I completely understand what that means from a testing perspective and the associated burdens that come with it. Please continue to leverage us in the community to help alleviate those burdens. We do have a vested interest and it seems many of us are willing to help!

1 Like

Ah, inline actions? Yes, I agree, as long as we can control it (turn it off, etc. when we don’t need it).


This bug is solved.

We can close this feature request.

1 Like