Unexpected behaviour after 1.6.0 update

  • Resolved muppix

    (@muppix)


    4 years ago

    Hey Nick,

    I’m seeing something slightly odd after updating to the latest version of Block Visibility: when selecting a block which has visibility controls applied by a previous version of the plugin, the ‘Enable Scheduling’ switch is always applied even though I’ve never used scheduling in the past. Yes, the ‘start showing’ field is set to ‘now’ and ‘stop showing’ is ‘never’ – so in effect ‘Enable Scheduling’ is logically false, but it’s confusing for me to see it set as true when I’ve never used it. My expectation would be for the ‘Enable Scheduling’ switch to be in the off position unless I have explicitly defined a valid start and end date. Does that make sense?

    To be clear, this isn’t a bug (functionality is not impaired) but neither is it expected UI behaviour.

    Cheers – keep up the good work!
    Mark.

Viewing 1 replies (of 1 total)
  • Plugin Author Nick Diego

    (@ndiego)

    Hi Mark,

    Thanks for the feedback. This is a conscious change, but I can definitely see how this is jarring for current users.

    Now that a user can completely add/remove controls (using the ellipsis), the logic is if a user adds the Date & Time control, then they intend to use it, therefore “enabling” scheduling saves them a click. The option is there for them to disable as needed. This workflow will be expanded upon when I enhance the Date & time control in a few weeks to allow multiple schedules. A user could have a whole bunch of schedules predefined but only a couple enabled.

    That said, if you never use the Date & Time control, it would be nice if that wasn’t enabled by default. In future versions, you will be able to set which controls are enabled by default whenever you edit visibility for the first time on a new block. This will allow you to only enable the ones you use all the time, but all the others are just a click away.

    Lot of enhancements coming soon! ??

    Best,
    Nick

Viewing 1 replies (of 1 total)
  • The topic ‘Unexpected behaviour after 1.6.0 update’ is closed to new replies.