Thanks for asking; it was related to having disabled the ‘online presence’. Enabled it, and I get modals
Now the Theme Component is working, but only through the expand button. The row functionality issue seems to be related to the Horizon theme this time.
I wonder if a mobile/desktop switch can be added? I like what it adds to the mobile experience, where users tend to swipe and scroll all the time, but on desktop, I like the forum’s old-school behavior.
Do I have wrong expectations, or do I miss something really obvious now? I used pure theme without other theme components, and I’m using iPad/iPhone (PWA, Safari and the Hub, same-same)
edit
I tried with more virgin account, and it got very first post as expected. So earlier situation matters only when opening a topic, that is already red.
I noticed an issue where the Topic Preview Modal doesn’t work properly on the Horizon theme when “topic card high context” is enabled. Is this intentional or a bug?
Also, as a feature request: would it be possible to add a setting to enable this component only for specific categories?
Additionally, when opening a preview from the related/suggested topics section at the bottom of a topic page, clicking ‘Open full topic’ inside the modal fails to navigate to the target page.
Thanks, ah, that was the missing piece! I didn’t notice the issue because this setting was disabled… sorry @satonotdead
So the issue was that Horizon, in high context topic card mode, does not render the topic-list-item-before plugin outlet, so the theme component could not work.
I moved it to other plugin outlet, it works fine now.
Thanks, I’ve fixed it.
Hmm, I’m thinking about this. How do you imagine this working? Should it work on /latest as well (checking the exact topic category) or only inside the selected category? Should suggested topics in that category also keep the modal?
I thought about this quite a bit, and I’m not sure swipe-right would be the best solution here. It could easily conflict with native navigation gestures on mobile where horizontal swipes already have other meanings.
I ended up going with a slightly different approach instead. The modal footer can already be dragged down to close it, so I added a small grip to the footer to make that interaction more discoverable.
This way, even if you’re scrolled all the way down to the last post, you can simply drag the footer down to close the modal without having to scroll all the way back to the top or reach up to the top of the modal.
I think this feels a bit more natural for this type of modal.
I have to disagree after using this for over a week now. It is so fluent to use the phone one handed and the way 90% of users just absorb content it is perfect and so easy to use the site. I also added an animated 3 second timer with the message at the top 5px above the modal which explains that this is the gesture to close. Test it for a bit and you’ll see how well it works without having to move your thumb far.
Also if that is what your sticking with will it be a toggle button to turn off or on?
I tested it, but there is a difficulty: the same gesture is used in Safari on iOS to go back a page. This often causes the problem of navigating to the previous web page instead of closing the dialog.
I’ve been thinking about this a lot, and I added three configurable options:
None: no additional dismiss gesture
Grip: a visual grip is shown in the footer
Gesture: the modal can be dismissed by swiping down when at the top, or swiping up when at the bottom. The native Back gesture/button also dismisses the modal on mobile.
I tried to make it work somewhat like Facebook’s comment modals.
The most interesting part is the native Back handling. Rather than navigating away from the underlying topic list, the modal consumes the Back action and closes itself, while keeping the user’s position in the list.
Latest iPad: only swiping up closes the modal. If I swipe from left to right it doesn’t do anything inside modal and outside it acts as normal back and I find myself at the frontpage of the creator.