Rikki

11 hours ago, SUBRTX said:

@Jordan Invision 

can we disable this option though?

You just wouldn't set up rules/badges 🙂 

4 minutes ago, Real Mythotical said:

I'm excited for 4.6 now, you guys are doing great.

We aren't sure if this will make it into 4.6 or be a later release, but it shouldn't be too long until it's available in any case 🙂 

13 minutes ago, jair101 said:

Any further details how points can be obtained? Is it going to be through regular content creation - i.e. number of posts, articles, images, etc.? Or it will be more flexible, for example based on where the topic is located (post in professional category might be worth more than one in humor section), or based on word count or number of attachments? Even better if we can set the weight of points ourselves 🙂

There'll be more details soon, but it's very flexible. We have over 15 different rules built-in right now, for common actions across the community. Most can be limited by quantity and/or location.

Here's a look at configuring a "Award points when a user posts 1000 topics" rule:

Some rules can award different users too - for example, we have an action that fires when someone votes on a poll, but you can choose to award the voter and/or the poll author. I think this sort of flexibility will open up some really interesting engagement possibilities!

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.

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 🙂 

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.

On 1/21/2021 at 11:01 PM, AlexJ said:

No - that doesn't work. IPS Support staff told me that once you do that, you need to unfollow each and every single topic that you have followed. That button is just for show and I actually clicked on that link like 5 times and it doesn't stop all emails. 

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 🙂 

11 hours ago, AlexJ said:

No - that doesn't work. IPS Support staff told me that once you do that, you need to unfollow each and every single topic that you have followed. That button is just for show and I actually clicked on that link like 5 times and it doesn't stop all emails. 

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.

On 1/18/2021 at 10:34 PM, AlexJ said:

2. Email notification: If user doesn't want email notification they should be able to do one click - disable all email notifications. As of now, they need to visit each topic and 'unfollow' each topic manually. That's just ridiculous. No matter how you dice it. If their is better way, please, please tell me and I will share same with our website users. 

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.

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;
}

17 minutes ago, kmk said:

I can't see any PWA guide setting option in ACP. 

It's under Customization -> Appearance -> Icons & Logos.

As for push notifications, I'm not sure what our plans are on that.

17 minutes ago, kmk said:

Thanks for the share, but it sound long time... Before that, is possible give us PWA support? Or I missed something... 

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 🙂 

10 minutes ago, Morgin said:

That’s right - I think you also had directed me how to use the media query or viewport check or whatever to ensure this was only applicable if it was a phone size device, as I was trying to do it by targeting the responsive classes which was the wrong approach. 

Oh that's right, this is what you'd need:

@media screen and (max-width: 767px) {
	body {
		zoom: 0.8;
	}
}