Conditional Formatting Dialog is highly misleading

James Garrison 11 Reputation points

The Conditional Formatting dialog includes a button with tooltip "Enabled"

It seems to toggle the status of the conditional formatting based on its effect on the Preview example:



The problem is that this button refers to the enabled/disabled state of the control, not the formatting.

The issue is that the preview behavior seems to imply it enables or disables the formatting. This is because it does not take into account the locked/unlocked status of the control. If the control is locked, then the preview is incorrect - the formatting WILL be applied and will not look like the preview.

As far as I can find, the Access documentation on MS's website provides only a very cursory description of conditional formatting, and does not describe the rule editing dialog (where the "Enable" button is) at all.

This situation really needs to be corrected:

  • Modify the dialog preview to take into account the locked status and display the actual formatting that will be applied
  • Provide better feedback on the current state of the "Enable" button
  • Update the documentation to describe the rule editing dialog
Access Development
Access Development
Access: A family of Microsoft relational database management systems designed for ease of use.Development: The process of researching, productizing, and refining new or existing technologies.
858 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Albert Kallal 5,231 Reputation points

    Well, I can't say this is huge misleading.

    I mean, everything in software, and in life has a context. That dialog is dealing with formatting a textbox. So you have settings for bold, for underline, for font color, for background color etc. And thus in that context, then enable + disable ALSO applies to that control.

    I mean, if there was say 10 other places in which you could create things, but then disable that setting AFTER you create it? Then users would build up such expectations for most settings.

    I mean you can enable/disable a control.

    However, I am NOT aware that you can say for example set a control to "bold", and then enable + disable the bold setting?

    In other words, where and how often does access behave this way?

    I mean, we don't set a box to have color on a form, and then dis-able or then enable that color setting?

    (but, some platforms DO work that way!!!! - web based software often works that way!!!)

    But, in Access? If we don't want that setting?

    We would remove the setting, or not create the setting in the first place. But VERY rare do we, and even can we create a setting, and then after all that efforts made? We can't enable, or disable that setting, can we?

    So, we have in software what is called the "user mental" model.

    In other words, how most features work, and in fact near every feature you set in access is a setting you apply. It is quite rare in which you are setting up a feature, go to all the trouble of using and setting that feature, AND THEN DISABLE the setting! I can't think of any other place this occurs in Access.

    I mean, would we setup enable/disable for a control, but ALSO have a enable/disable for the enable/disable feature? does that make sense???

    Why not then have the above?
    Because everywhere else in Access the feature settings don't work that way.

    But, the reverse is also true!!! If every other setting and in most places in Access you could have a setting and then ALSO enable/disable that setting?
    yes, then what you suggest makes 100% sense. and in fact for the sake of consistency and that so called 'user mental model" we have in software?

    Then your suggestion would make perfect sense, since everywhere else in Access if it worked that way, then the expectation would be the same in this case and context.

    So for example we can set the startup form setting in access.. We THEN don't have a option to enable or disable that startup form setting. If you don't want a start up form setting, then you don't (and can't) disable that setting, you REMOVE that setting. You don't make the efforts for that setting in the first place.

    So, when talking about a control and settings like bold, color, enabled? That context applies to the control and not that we going to use or not use the conditional format. If you don't want that conditional format to be used anymore then delete it, and don't create it in the first place.

    You also have to think of user's mental model. if one could enable/disable that CF setting, then imagine the boat-loads of people that would come here to ask why their CF setting is not working? Only to find that they did not enable the setting? In other word, you can ask, what were the developers thinking here, and what would a user think?

    CF came out in Access version 2000. That is 20 years ago. And it turns out that's also the time that I started to be active in on-line community's and Access forms. And in that 20 years I not seen this issue come up, or even be pointed out.

    In other words, I not seen this issue as being a source of wide spread confusing in the Access community.

    That does not mean this is not confusing for some, but it not a wide-spread common issue.

    As for suggesting better documentation? Sure, that's always welcome!
    (but keep in mind FEW people read that stuff!!! - but improving such documentation is always a good idea).

    But, do keep in mind the context of what you doing in software. if you are say using a file dialog, then the concept of "selecting" means we talking about choosing a file.

    However, if we talking a about a combo box, then the concept of "selecting" now means something different (you selecting a value from a list).

    And same goes for this CF dialog. That context is about setting things like color, like bold, like underline and that of enabled/disabled for a control. The context is applying settings to control.

    So, just like I can say we are "selecting" with a combo box? Well that means we are selecting a value from the drop down. However, if we have a file dialog open, then selecting does not mean we selecting a value but now selecting a file.

    So, software, and even this discussion? There HAS to be an assumed context of things, else it would be impossible for me to communicate any concept here. Or we could ALWAYS have a response that explains every single assumption being made here, and this response would then be 1000 pages long.

    So, in general discussions (like this one), or even in general when using software? There is a given context and meaning. So the term "selecting" in regards to a combo box, or that of a file dialog is the same term (selecting), but the context defines that "selecting" has a context and meaning in both cases.

    The same applies here. The term enabled has meaning, and that meaning is a result of the context of the action you are doing at that point in time.

    Since everything else and every other setting on that page is being applied to the control, then it is a reasonable expectation that enabled/disabled ALSO applies to that control.

    And that assumption is reasonable based on your current actions, current task, and current GOAL.
    So that goal is to apply settings to a control.

    And thus your current context is assigning features to that control.

    As noted, this concept of context by intention is a basic requirement for software but also that of most things we do as humans. In other words, if I tell you to turn a knob?

    Well, if you standing in front of a stereo, and we noting that the music is too loud?
    That that means the volume control knob on the stereo.

    On the other hand if you are standing in front of a door, and I tell you to turn the knob and pull? Well then that knob means we are talking about a door knob, and not the one for the stereo in that SAME room.

    Now we could ALWAYS say the knob on the door, or the knob on the stereo . But then again, it would be every word, every thing, every statement would require 2 or 3 times as much wording to explain anything!

    (I mean, even this post here of mine is getting too long!!!). If I have to explain EVERY bit of context here, then communication and having a great happy life is not really possible. (takes too long to achieve any goal, or communicate anything of value to anyone).

    So, actions and intentions of what you are doing is what creates the context here. This not only applies in this software, but even that of talking about a knob in a room? Which one, the volume knob on the stereo in that room, or the knob one on the door?

    Well, if we in the process of opening/closing a door, then the concept of "knob" applies to the door. if we are in the process of standing in front of the stereo and adjusting volume, then "knob" applies to the volume knob.

    This assumed context applies here. On the other had, if there was 5 or 10 or 15 previous settings and those Access settings allowed us to create the setting and THEN have to enable that setting? Then yes, the dialog should be more clear.

    So if we were to set bold for a control, but ALSO have enable/disable that setting? Then such a context makes sense. But as a general rule, we don't and can't do that in Access, so no expectation or assumptions as such should arise. (and be a source of confusing).

    And what about a enable/disable setting for the enabled/disable control settings?

    If all settings worked this way? Yes, I would then even suggest that having a enable/disable option for the control enable/disable option makes PERFECT sense. However, since 99% of settings don't work this way in Access, then it is a rather simple assumption to make that other features in Access will also continue to work this way.

    So, I don't think that setting in that context is a large and wide spread source of confusing. That of course does not mean some are not confused by this setting, and does not mean in the past that some have not been confused.

    However, this is the first time in 20 years that someone has brought this issue to light.

    So, I think the dialog and context here is self explain, but improving documentation? Sure that always a good idea for improvements.

    Albert D. Kallal (Access MVP 2003-2017)
    Edmonton, Alberta Canada

    0 comments No comments