Display name is reflected in the tooltips of floating action buttons

[Takuya_Miyai]

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.

[tsuji_koichi]

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

[MultiTech_Visions]

Naturally…

[Steve (Steve Coile)]

Escalated. I’d call this a bug.

[Arthur_Rallu (Arthur Rallu [AppSheet])]

It is a bug.

[tsuji_koichi]

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

[Kirk_Masden]

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!

[WillowMobileSystems (John Baer)]

@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).

[Kirk_Masden]

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 . . .

Show action name for "Display overlay" on hover by mouse

@tsuji_koichi and @WillowMobileSystems , @MultiTech_Visions I have some thoughts about this important topic that I’d like to get your feedback on. In regard to user experience I agree that we should be able to provide a sort of “help” text for users in the manner that Koichi has proposed here. However, I’m concerned about this being automatic. Here are my reasons: I have actions that do different things in different contexts. Of course, the action only has one name so I think that we wo…

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

Find names of inline actioins

I have an app with lots of inline actions and, when I need to go back and re-edit or fix something, I’m often unable to remember the name I gave the action so I can find it quickly in the editor. Here’s a simple way to do that with line actions: [Line_action_name2.2021-04-12 11_15_07] All I’m doing here is copying the text around the line action (it may be difficult to select only the action), pasting the text into a text editor, and then identifying the action name that got copied with the …

[praveen (Praveen Seshadri (AppSheet))]

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.

[Kirk_Masden]

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 . . .

[raketa]

Hey!
Please add tooltip fot this type of actions

[WillowMobileSystems (John Baer)]

@praveen

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 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!

[Kirk_Masden]

@raketa

Please add tooltip fot this type of actions

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

[Fabian (Fabian Weller wAPPlabor)]

This bug is solved.

@Will_Witman

Tooltips on Floating Action Buttons (‘Display Overlay’ setting) were updated to use the action’s display name instead of just the name. Deployed to 100% of free users and 50% of paid users.

We can close this feature request.