Toggling the filters is symmetric… clicking a category will show that category if its hidden, or hide it if its displayed. So if you reverse it you’ll end up with the same behaviour :).
However, the page loads with all categories ‘enabled’ (or the filters disabled, depending on how you look at it). So you could ask that the page loads with all categories ‘disabled’ (or all the filters enabled). But this would mean you end up with a blank page until some of the filters are removed.
If that’s what you’re after you could add some javascript to programatically ‘click’ the filters, but otherwise there’s no option for setting this behaviour.
Hi Stephen,
once again, via another channel. Would it be possible to have an ‘all’ option for the posterboard, since, as you can see, not everybody is well and familiar with those buttons being toggled in order to reset the filter :)?
Thanks in advance
physalis
And furthermore, some people just don’t want to disable each and every venue in order to see the one they are looking for, especially with tons of different venues given. Wouldn’t a reverse button, i.e. click on the venue to only see the clicked venue’s dates?
Hi Stephen,
I know you have already answered this question before but, just for the records…
After few moths using the posteboard one of the most recurrent feedback is about the filters. Visitors expect to see events under a certain category when they click on the filter (ie. If I click on Pubs I want to see all pub related events) but they get a bit frustrated because they don’t realise what happen when they click on category buttons, when you explain them that those buttons actually hide that category the next question is Why would I want that for? I want to see what I selected. In our case to see events under one particular category only you need to disable 15 other categories.
Would this be something that you rethink and change the filters behaviour altogether?
Thanks
David
Hi David,
Yes, I think this will be something that changes. It breaks backwards compatibility so it would be 3.0.0 (and unless there are any bugs to address, it might be that 2.0.0 jumps straight to 3.0.0).
There’s no timeframe for this unfortunately, it will be when I have the time. (The code is also on GitHub, and a pull-request would also be welcome ;).
I’d still like to support existing behaviour, but the default behaviour would change.
