-
Posts
24,413 -
Joined
-
Last visited
-
Days Won
84
Content Type
Downloads
Release Notes
IPS4 Guides
IPS4 Developer Documentation
Invision Community Blog
Development Blog
Deprecation Tracker
Providers Directory
Projects
Release Notes v5
Invision Community 5 Bug Tracker
Forums
Events
Store
Gallery
Everything posted by Rikki
-
Web push notifications, native sharing & offline support
Rikki posted a blog entry in Invision Community
As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device. Web push notifications For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices. In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep. We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications. Choosing push notifications For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types. Push notifications enabled Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade. Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum. Grouped push notifications And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out. We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone. On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance. Splash Screen Images When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app. Sharing using native share options Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note. Offline support With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community. We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6! -
jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll. So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that". Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.
-
Augment the Moderation System to be More Refined?
Rikki replied to Charles Fischer's topic in Feedback
Hi Charles, Firstly, thanks for spending the time sharing your thoughts. The impression I get from your posts in this topic is you feel your way of moderating is the correct way and that our platform isn't fit for purpose if it doesn't facilitate that approach. Forgive me if I've misinterpreted, but I wanted to share our perspective: we've been powering thousands of diverse communities for nearly 20 years. A lot of those communities are in industries that would typically be considered ripe for toxicity (e.g. gaming, sports), and have many millions of posts (50+ million in some cases). Many of these communities are run by brands that care deeply about their public image and simply would not allow the perception of toxicity to exist in their name. Moderation is one of the key priorities for these sorts of communities. We therefore have a pretty well-tested understanding of the needs of sites when it comes to moderation, toxicity, guidelines and so forth. It's what we work with customers on every single day. Put simply, manually reviewing every post made in a community in a 'just in time' fashion isn't sustainable or scalable. On a very small community with a couple thousand posts and a few users active at any one time, it may be an approach that can work, but it simply wouldn't be viable on communities that receive thousands of posts an hour and have hundreds of members online at any one time. Some of our customers have entire salaried community moderation teams and even they don't have the resources to attempt that. The implication that unless every post is reviewed by a moderator, a community will inevitably descend to chaos and toxicity, is wrong. Moderation is a much more holistic endeavor than simply reading every single post. You are absolutely right that users want to see their post immediately, so pre-moderating content usually isn't the best approach. We tend to suggest a reactive approach instead, where content is posted freely but problems are identified and then acted upon. We have a very robust warning system that can head off many problems, or put troublemakers in a timeout so they can't cause further issues. We have automatic moderation tools that can take actions on content depending on how other users interact with it. We have a very powerful permissions system that allows you to gradually (and automatically) grant more access to users once they've proven themselves. We have a built-in spam service that can prevent many spammy registrations before they even make it to your community. All of these tools have been developed with the lessons we have learned over the years. Obviously, there is always room for improvement and we take ideas and problems on board to figure out what to do next. I am certainly not suggesting your approach is wrong. If you've made it work for you, then all the more power to you. However, it is not an approach that in our experience would be useful to most communities. It seems to me that the custom app approach is going to be the best fit for you, and I hope it works out. -
On this site we use the system font stack, which means Windows/Mac+iOS/Android use different fonts. That can make the resulting content look slightly different across devices.
-
You should also just be able to email support@invisionpower.com if you send from the address associated with your license 🙂
-
Demoing the Record Feed block to someone, did not go well
Rikki replied to socceronly's topic in Feedback
We have some ideas on making blocks and pages more flexible, though they are in their early stages. As things stand right now, custom templates are your best approach, but I certainly hope we can provide something more intuitive and robust in future. -
The fix for disabling email notifications I mentioned will be in our next release, but I don't know when that will be. We are continuing to discuss the other issues brought up here, particularly separating some of the notification types.
-
We investigated this and it turned out to be a bug whereby daily/weekly digests were not disabled when the link was clicked. The fix will be in the next release 🙂
-
I have logged an internal report for investigation because if that is what is happening, it isn't intended. The link should stop all emails without any further action.
-
There's a link at the bottom of the notification settings page to disable all email notifications 🙂
-
Google has strict guidelines about how their logo shows on social sign in buttons, so we're following those guidelines - in the past some customers received automated warnings that they were not compliant.
-
font-display: swap won't really give any benefit to that particular font since it's used for icons - there would be no system font it can use temporarily. We can certainly experiment with font-display: block and see if that would improve how lighthouse sees the page though.
-
I'm not familiar with how MathJAX works, but it sounds to me like you'd need a plugin that listens for our Javascript events to reinitialize content when the page updates.
-
Recent U.S. legislation affecting forum owners
Rikki replied to TheWorldNewsMedia.org's topic in Feedback
You're likely thinking of Section 230, which makes users responsible for posted content, not the sites that host it. Understandably, removing that protection would be a significant problem for most small, independent communities. -
Some browsers block all cookies unless you allow otherwise. I'm not sure if Opera is one of them, but your user may need to adjust their settings on your site. I think typically you click the padlock in the address bar and allow cookies or similar.
-
Unless I'm misunderstanding your report, the email address you see is that of the user that is checking out - i.e., their own email address.
-
Right now that's not a feature, but it has been mentioned several times and I could certainly see the usecases for it.
-
While TestFlight (and Android) allow you to submit feedback, honestly the best way is to submit a ticket in the usual way. Thank you!
-
CSS is flexible enough to allow you to do that without needing unique classnames. For example: .ipsType_richText a { color: red; }
-
It's under Customization -> Appearance -> Icons & Logos. As for push notifications, I'm not sure what our plans are on that.
-
We already have PWA support, though that doesn't include push notifications yet.
-
We are a way off of offering a white label service still - we plan to get the main app stable and add more functionality first. We'll post an announcement when we're ready to accept some interested sites 🙂
-
Oh that's right, this is what you'd need: @media screen and (max-width: 767px) { body { zoom: 0.8; } }
-
1) In your mobileNavBar template, add this just before the closing </ul>: <li> {template="mobileNavigationIcon" app="core" group="global" params=""} </li> 2) In globalTemplate, find the <header> tag and change it to: <header class='ipsResponsive_hidePhone'>
-
@opentype to the rescue 🙂