Jump to content
Announcing Achievements! ×

Community

Rikki

Invision Community Team
  • Posts

    24,312
  • Joined

  • Days Won

    79

Rikki last won the day on April 20

Rikki had the most liked content!

About Rikki

  • Birthday 08/17/1983

IPS Marketplace

  • Resources Contributor
    Total file submissions: 3

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @opentype Fixed the duplication when dragged (in 4.6, so won't show up here immediately) @DawPi Fixed
  2. That will be an option in the upgrader. It will create a single rule where 1 post = 1 point, then keep your current rank names. For all intents and purposes it'd then work the same as the old system (plus the new stuff like notifications and user menu summary, which didn't exist before).
  3. You can also email support@invisionpower.com 🙂
  4. Yes, this isn't a bug per se. Jqmigrate is a tool that allows us to polyfill some APIs that changed in the latest jQuery releases, without having to make large changes to our own code immediately. Think of it as a compatibility layer. The logging you see simply indicates when Jqmigrate has needed to polyfill some behavior.
  5. In 4.6 the "Stop all email notifications" link will correctly stop any notification emails from being sent. In 4.5 there is a bug that allows digest-type emails to still go out when they shouldn't - but that isn't intended behavior.
  6. It will "just work" on self-hosted, but only for users who have supported browsers/devices. That's basically all of them except Safari/iOS. Apple has its own web push notification system for desktop Safari but we have decided not to support that right now, and of course iOS doesn't support web push at all. It's only tied to existing notification types for the time being, but a 'bulk' option sounds like a useful tool to me, so we might be open to that in future. You cannot make Push enabled by default because users must subscribe to them in an opt-in fashion. You can allow/disallow push for any notification type though. The banner that shows up explains the benefits of accepting, but you can of course adjust if you like. It's the same banner (with some updated copy) that shows in the 4.5 notification list for new users.
  7. 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!
  8. 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.
  9. No, our Enterprise plans are only cloud-based. We do offer some custom services outside of Enterprise plans (SSO, conversions, etc.) but those would not be considered part of our Enterprise offering.
  10. 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.
  11. 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.
  12. You should also just be able to email support@invisionpower.com if you send from the address associated with your license 🙂
  13. 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.
  14. 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.
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy