Repurpose column description as helper text

[fdmsaraiva]

I find the current implementation of the column description field to be strange, and I think it could be repurposed to a much better end.

As is, both display name and description populate a column’s label, and one is shown instead of the other depending on the context. If you fill in both a column’s display name and description, then the display name shows up in static renderings of the column, meaning anywhere the column is not editable, and the description shows up in editable renderings, meaning form views and editable columns in detail views.

How unintuitive is that? What I’d expect is that both fields are displayed at all times and assigned different ux functions.

Display name is fine as is, but description should populate a helper text below the field input in form views, and optionally in detail views as well, like so:

Right now the only way to display inline contextual information about a column in a form view, is to create a virtual column, then a slice to put the virtual column next to field the help is for, then reorganize your views to accommodate the new slice, and then update ref fields linking to the source table to make sure they point to the slice: cumbersome and prone to loose ends. A helper text field would improve this and other use cases a ton.

[Henry_Scott]

@praveen I agree with @Filipe. If not as he suggested, then surely a way to display Helper Text for a Field so that Users know what should be the relevant input in the fields
Is something like this planned for Appsheet?

[WillowMobileSys]

I like the suggestion of Helper text and I would like some way to make it user switched on or off. Initially on but when they need it an off when they no longer do.

But repurposing the Description property would take away a feature I have been making use of.

A fairly straight forward example is a Quantity column. I want the column in my datasource to be fully named as Quantity. In the UI, when a user is entering a value I also want to make its clear what they are entering so I use Description to make sure “Quantity” is shown as the label. However, when it comes to table view (and especially inline table views) I want to preserve screen real estate so I don’t want the lengthy column name displayed. I set the Display property to simply “Qty” to give a narrowed column since most Quantity numbers are single or double digits.

To take this one step further, when entering Quantities of different types of items, like above I’ll use the Description property to add or even change the label to things like “# of Items”, “# of Rolls”, “# of Bottles”, “# of Bundles”, etc and then let tables show simply “Qty” when all line items are shown together.

So again… I would love to have a Helper text property but in addition to those properties already there.

[fdmsaraiva]

@WillowMobileSystems For that situation I’d recommend using the CONTEXT() expression, and its View and/or ViewType options, to output different Label texts. Seems like a more straightforward and intuitive solution to that use case, that dispenses using the Description.

[Former Community Member]

I politely am inclined to disagree for two reasons:

1). This is a No Code/Low Code platform and it needs to find ways to make app creation simpler, if not as simple as possible, and faster.

2). Having a verbose label for input and a shorter version for display is common among many development platforms. Since they may potentially be needed for each column, it makes sense to have them as column properties.

I whole-heartedly agree a Helper Text property is useful but I feel it should be in addition to the two properties already present.

[fdmsaraiva]

I can see the validity of having both a “Short label” and a “Verbose label” as separate fields for a bit of no-code fun. But if they are to remain with that purpose in mind, at least they should be named as such. “Display name” and “Description” evoke properties that live side by side and complement each other, like “Title” and “Subtitle”, they not seem like variations of the same property.

But yes, the main point is that a helper text field is needed. Repurposing the “Description” just seemed like the easiest way to go about it.

[WillowMobileSys]

I totally agree about the names.

[Lucinda_Mason]

I was really hoping the Description property would serve as a Help Tip for input. I need a way to tell the user what type of data is needed, at least as they first use the app. Having that show all the time in the form view is a waste of precious real estate. Please add some way to display extra info for any given field. Thanks.

[Ewout_van_Zonne]

Can’t wait for a proper solution! It’s really missing.

[retailpartnerco]

Yes, I have a table with 99 columns, not because I need them all, but because half of them are show columns. I use them as descriptions for each of the corresponding above columns. But they are like an inch below the column, and it takes up so much space. Helper text would be a game changer.

When I first saw “description” in the app, I thought it was helper text. Thanks!

[Greg_Pommen]

Agree. Right now the Description just replaces the Display Name, which is kind of useless. When I first saw it, I thought it would & should function more like the Label/Hint of something like Open Data Kit:
<label>Is the water clear?</label>
<hint>e.g. vision not blocked by mud, plants, etc.</hint>

[Pejme]

@Pratyusha Any plans on implementing this? 

I know, Description is intended for longer/multi-line text, whereas Display Name is for a shorter single line of text, but I don't get why both would be needed. Can't Display Name be used for longer/multi-line text (which would also cover single line of text), and Description be used as a hovering helper text?

[SkrOYC]

Description is for forms, Display Name everywhere else.

I'm happy with that