Uneditable fields not showing. By design? Argh

Found my problem in the forum, and read this from AppSheet staff in response to a commiserator:

“We don’t show empty non-editable fields because forms sometimes can have many of these and they do not show meaningful information.”

I have a problem with the idea that an empty field does not show meaningful information.

The existence of a field remains significant even if it has no value. For an app with many fields and for users with many apps and only occasional use of some, not showing a field has the pedagogically dysfunctional effect of being antimnemonic.

That a field has no value is itself significant, and users should not be expected to remember all the fields that happen to not show up in a view in order to be aware that they have no value!

And since we can control whether the fields show or not, this kind of nihilisitic view of field visibility doesn’t rescue designers from folly, it robs us of options in how we present the very existence of fields to our users.

I have a form that a supervisor views, and numerous fields maintained by subordinates are invisible to him. But that they are empty is significant to how he evaluates the information considered altogether. Should he really be expected to infallibly tally the existence of fields he can’t see in order to evaluate the data he can?

This is a very unfortunate design decision by AppSheet. Apart from this limit, we can determine whether fields show up or not with a great degree of control; what we can’t do, with AppSheet’s imposed design philosophy in this case, is make them show up at all.

If AppSheet allows empty non-editable fields to be visible, we still have the means to make them invisible if they have no content and we wish to do that.

This is the first case I’ve seen in AppSheet of the product “trying to be helpful” in a way that artificially imposes limits on application behavior, when the alternative of allowing such fields to be shown by default would not rob us of the power to hide them if we wish. As it is, we can’t show them if we wish.

Don’t like it.

Status Open
1 9 460
9 Comments
Steve
Platinum 4
Platinum 4

You’ve got a long, tough road ahead of you, then, if this is only the first.

SkrOYC
Gold 5
Gold 5

I think you share some opinions with this case (not already solved)

Maybe you can take some ideas from there.
From my POV, I don’t see AppSheet team changing this behaviour since it serves a purpose and you have workarounds.
The same applies to almost everything that we would like to change when there are some workarounds to acomplish what we want, they won’t change the default behaviour

MultiTech
Gold 4
Gold 4

So true. Welcome to the salt mine!

scott_marquardt
Bronze 3
Bronze 3

Argh.

“The purpose” is to rescue us from seeing fields that are empty – without exception. They already have features that let us do that easily if we wish, so that purpose is served by featured which – coincidentially! – would also let us show them if we wished, if only they’d not suppose we’d never so wish. 😕

Adding spaces to all empty fields we don’t want shown is a dreadful kludge (a bad workaround), and it forces a cascade of accommodations on any post-processing of sheet data that may be necessary. The other ideas in that thread are wildly convoluted compared with the alternative of simply doing a conditional show if one doesn’t want empty uneditable fields not showing up.

This is terrible UX design; heck, it’s not UX design. It’s reaching into a UX designer’s ideas and artificially imposing a “nope”.

scott_marquardt
Bronze 3
Bronze 3

Yeah, I’m a noob.

So far, the flexibility has been excellent – so this first brush with arbitrary limits was a disappointment.

I’m not terribly bothered by products that don’t have helpful features. One suggests the features, lobbies for them, etc. Been around that block scores of times – often successfully. But when a product has a feature (fields show up lol) and then to be helpful they kneecap that feature, that’s a very different thing. It’s not implementing a feature, it’s implementing a ball and chain on that feature.

“I see you’ve got foils on that catamaran. You’re coming into harbor every night, and those won’t help you do that. Let’s just remove them.” 😕

SkrOYC
Gold 5
Gold 5

I feel your disappointment but I can see why this is the way it is right now.
Also I get what you say, it’s also a good point, since we could get this kind of behaviour (the default one) by creating a show_if expression to do so.
Today, I have no need for them to change the default way, maybe in the future.
Maybe as @Steve and @MultiTech_Visions said, there are a lot of limits imposed by AppSheet (mmm… Google?) and we have very litle hopes for them to change so we adapt to it

PJMatelli
Silver 1
Silver 1

Adding my two cents to this conversation - the limits of the forms versus detail view is the issue. In detail view, it easily shows empty fields and you can just change the Show_If option for this situation. However, once we move our Apps to forms (we really like the tabbed form view for many of our apps), we have additional limits. The work-arounds are not going to work for us. For example, the space won’t work on a date and/or time field. I am not understanding why the behavior for the detail view is different from the Form view…this is where I think the development team needs to focus more of their energy. IMO!

Grant_Stead
Silver 5
Silver 5

Not me going to the dictionary…

Status changed to: Open
Pratyusha
Community Manager
Community Manager