When IsEmpty(Self) returns true and the conditional formatting does not work, the only workaround is to wait until this bug gets fixed.
It is definitely on the known bug list.
As an alternative to Placeholder Text, I've moved to a slightly different approach. Less because of the bug, and more because user recognition and UX.
Here is an article that talks about it: Why Infield Top Aligned Form Labels are Quickest to Scan - UX Movement
Nice link. Thanks, Josh!
I should have checked first.
I've done stuff like this as well. I did find that it meant a lot of overlaid objects that can be tough to manage sometimes.
I'm of two minds (sometimes more depending on the dosage) on the infield method. Having the labels external and to the left gives a nice vertical column to scan down, which is quick, but takes up room. The infield top aligned is nice but can be problematic with small text for the labels.
Nice link Josh.
Jeremy Bante posted that link on Twitter a few months ago.
I've converted a few layouts to use this format of labels. And I've found myself working much faster and with less data entry errors. There are definitely a few things I need to tweak with it's use. Once I have it set, I just set the styles and set them on new objects. It's worked well so far.
I, too, and a little undecided about a few aspects of it. Having the fields tight together to reduce white space makes some things faster to recognize. But sometimes not. There are areas where it seems that having some more white space makes it easier on the eyes.
This particular object is just 2 stylized parts with no overlapping at all. It just looks like a single object.
Form filling is imho different from data representation.
In a database, 95% of the time users deal with an already filled up "form". They need to isolate quickly things like a phone number and if the number is grouped together with its label in the same optical identity, like a white rectangle on a gray background for example, they will be forced to focus on the label every time before being able to identify and isolate the real information.
In other words, optically putting together the label and the data - which belong to 2 distinct kinds of information - into one unit is not very good.
But that's my opinion. Summing it up: what is good for data entry might be less good for data retrieval.
siplus wrote, in part:
Summing it up: what is good for data entry might be less good for data retrieval.
I agree completely. I have a new client who set up single screens for each table in a basic contact file, where his examples use popup buttons to break data entry into grouped data. As he originally set them up, he also had to click each popup-button before he could view the data previously entered, or to even see IF it had been entered yet.
Data Entry and Data Retrieval are different tasks. Both have to be planned for, either with separate layouts or with a layout optimized to facilitate both tasks, which is a bit more complex than either alone.
I don't have a strong scientific argument for either case. What I do know, in the fields that contain the label...I can pick out the data much faster. Especially when we are talking about the phone number, on a layout where there may be multiple numbers.
I felt exactly they way you do, until I used it myself. A mix of grouping fields, and white space is the ideal place to be. As for the label and what's best for data-entry vs data-retrieval, I have an opinion on it, but not one strong enough yet to put up a valid hypothesis yet.
In a case where a user has to think about which 'phone' number they are looking at, the in-field label is faster. Because you focus on the label, then the number...or I guess you may even do them both at the same time. If you focus on the phone number first, you have to look back up to the label to see if its the Office phone, Cell phone, or Fax.
Presumably, there is no absolute right way here. Nor a blanket rule to say one way is always better.
Appreciate the feedback on it. It's great to get multiple insights into user behavior and UX.
Yeah, mind is complex.
Tbh, the phone number example I gave is misleading, because the user already knows he's looking for a string being a sequence of digits, and his mind is prepared to discard anything not being such, so in that particular case he'll be faster at picking the info chunk he's after from the optical cluster.
Absolutely. It's why really good designers make the big bucks!!
Big bux is what I'm after (like everybody else) and the result is being in Layout mode 80% of my time, switching back and forth to browse mode for a split second, in a neverending chase meant to lead to the "perfect" UX, given a specific workflow and needed result set.
I'm sure it does show, as many of my suggestions regarding features to be implemented - see corresponding threads - are related to layout mode... now you know why
Filemaker handles all the rest, that's one of the reasons I love it, but the interface is on me.
Excellent info. Thanks Josh!
1 of 1 people found this helpful
I had a similar need recently and I agree the behaviour does seem like a bug to me.
I'm not going to get involved in the discussion about field labels vs placeholder text as I believe there are pros and cons to using one or the other, or indeed a combination of the two, depending on the situation.
However I did find a fairly simple workaround. It's simply to make the default look of the field highlighted however you like it to appear if empty (whether this is text and / or fill colour).
In the attached sample file I've simply made the default a red fill with white placeholder text. Then you need to make the conditional formatting reflect how it should look when the field has been entered with the conditional being "not IsEmpty ( Self )" which turns it back to a white fill.
The conditional doesn't have to change the text colour in this example because it's no longer placeholder text. You also need to change the fill colour style on In Focus in the Appearance settings as I think once you enter the field it shouldn't be red.
Hope that helps