Matt

That quote is going straight into the top of our marketing. Also, may I recommend: Honestly, though during the initial building phases back in early summer we used to have a weekly sync meeting with Ehren as he's in Australia and everyone else is not and he'd take us through concepts, and ideas and we'd all just say 'wow' for about 20 minutes. Now I just send him badly annotated screenshots and broken HTML I mangled at 2am his time while he's sleeping.

A final supported release is unlikely before 2024 just because we are heading into three consecutive months where there are holidays (Thanksgiving, Christmas, New Year) so releasing a brand new version would increase workload at a time where we want our team to relax and enjoy those holidays. I've patched releases on Christmas Day before and it's not the best time. 🙂 I think we can expect a public preview and some beta releases before then, though.

I'll be doing a dev blog on the significant changes in how you create and edit themes in v5.

In addition, I do want to point out that we have removed a significant amount of JS that is no longer needed including some libraries that acted as shims for older browsers. The entire CSS framework has been rewritten and is more compact, so there are significant savings already.

To be clear, we have no plans to remove jQuery from 5.0.0. We expect to begin a fairly lengthy migration process over several releases where we'll start rewriting our UI and utility classes to use native. That said, I do not think it is critical to remove jQuery to improve page speed scores. We can probably get away with using jQuery slim, which is about 23kb of data sent once, and then your browser caches it. 23kb isn't insignificant but then a single image added to a page will negate any savings. Removing jQuery now would add further stress onto third party developers and delay v5 by 6-9 months given the huge amount of JS we are using for really little gain. Anything significantly new is using native. Here's the result of running Lighthouse for mobiles on my development install running with IN_DEV on (so no caching, no compiled or minified CSS, hundreds of script tags, etc). I would expect that to hit high 90s when not using IN_DEV mode.

I agree. We server a wide variety of communities, some having quite literally hundreds of forums with robust silos of information but there is a growing need for smaller more bespoke communities with a handful of forums. After spending so long on my development installation of v5, I really crave the feed-like view of v5 on the forum index. I find it quite frustrating to only discover the most recent reply. I do find it quite interesting that most regular members live in the streams of latest posts more than clicking through various forums to see what is new. It goes back to that concept of serving past you, current you and future you. Past you is new to the forum and needs the organisation to find a way into what could be an overwhelming amount of content, current you is still involved but likely hangs out in streams to just read the latest content and move on, and future you visits less so is less familiar but still wants to catch up as quickly as possible.

The sidebar menu gives you more space to organise your navigation. The current system of it being in the header means a lot has to be hidden to make it fit, which isn't the best onboarding experience nor does it help highlight important areas of the community. The thought behind the node menu item was to make it easier to add specific forums (or gallery albums, etc) so you can better design your community. You may want to highlight a few key areas (we might choose to feature Community Insider, Support, Feedback) making those areas easy to reach wherever you are and to help new visitors to your community discover what is important. Likewise, you might wish to enable fluid view and list your individual forums in the sidebar so you have the best of both worlds, a feed view index and then easy access to specific forums. The theme for Invision Community 5 is optimising the minutes you spend on a community to make them more impactful. We are considering the various lifecycles of a topic. The initial burst of energy that crackles with noise and distractions and also in the future where future visitors come to it cold and want to extract key information quickly.

Only when using a smaller screen where it drops into the menu button on mobile view. There's no way to hide it using desktop (unless you choose to use the classic view where there is no sidebar!)

Ehren will be covering the theme editor in more depth very soon. I stole a little of his thunder with that gif but I see a lot of concern about new views and how they fit in with their community, so I wanted to show just how easy it is to toggle between them. It's also worth mentioning that these layout options are per-theme and not global as they used to be, so you can mix and match across your community as you see fit.

It is indeed an option.

No two sites are the same, which is why we've made it very simple to switch between layout types. More on that very soon.

Ehren is a superstar, he's barely scratched the surface on what he's been working on for the past six months. I'm really excited by these new views and the sidebar mode gives a very desktop app like experience, whereas the new mobile view is truly fit for purpose and not just a squished desktop view.

I'm honestly unsure. I think it's two factors, the first being that the downtime was intermittent with degraded performance (1-2 mins down, then 5-6 up) - but pages were being returned and that it only affected about 15% of our client sites. I guess Uptime rounds up or down and it wasn't statistically significant when balanced with the entire network and 24 hour period. If you look at our site which was in the affected 15%, then you can see the short periods of true downtime between slower page loads - but it was a few minutes at a time.

When we are hit by a network attack (which happens daily), our automation launches new instances to meet demand. On some occasions (a few times this year) there may be some degraded performance for between 1 and 5 minutes while scaling launches. Earlier in the year we had an outage with our upstream provider which was incredibly frustrating. No one likes degraded performance or downtime, let alone our team who are woken by automated alarms at 2am to come and deal with it, but it's the nature of the internet. When you compile a list it may look significant, but it's still just tiny blips in an otherwise robust service. We really do our best to minimise disruption and we'll continue to revise our alarms, scaling and database instances.

Looking through David's ticket history, I can see there have been some difficult to track issues that impact his community only and aren't indicative of the greater experience, these seem more around database optimisation for his community or slow outbound connections. It's something our support team are working with David on.

Hi David, Any period of degraded performance is frustrating for us all. We have put a lot of energy and cost into ensuring our systems stay online and weather even the most persistent online storms but very rarely some do get through and we need to tweak our protection. Looking back at our independently monitored uptime, we have a 99.9% uptime record with very few periods of significant downtime since Jan 1st 2023. What happened in the early hours of the morning was inconsistent with our long standing performance records and we do not take it lightly. We continue to improve our systems and will keep you updated of any changes. Thank you again for your patience. You, or anyone else reading is very welcome to submit a support ticket if they have any questions or concerns. You are welcome to bookmark and review our independent status page: https://status.invisioncommunity.com P.S. I'm going to move this to the existing topic.

We're still gathering data, but we experienced a significant network attack between 11:00pm and 3:15am EDT which affected roughly 15% of our client accounts who experienced degraded performance and short pockets of intermittent downtime. It has since been resolved but we'll need to do a closer look at the data during US office hours for a more complete and accurate picture.

An update on extensions

Anything significant will be for v5. We have two code bases which have diverged significantly, so it's a fair bit of work to merge v4 code into v5. I currently do this manually with patch files.

We've released some news on Invision Community Five, but third party developers won't have enough information to get started on updating their apps. We're at the peak of the mountain now and ready to start showing more in the coming weeks. I am really excited to start showing off the culmination of just under six month's work from our team.

No dates, but we're unlikely to release a major new version around a public holiday when our team are enjoying time away with their family. You'll definitely see more of Invision Community 5 this year. In terms of the JS bundling changes, the answer is 'no' but not 'never'. We want Invision Community 5 to be the start of something new, and we'll be converting JS over to native and changing how things are bundled over the early part of its lifecycle. We didn't want to add another 6-9 months onto its development schedule to rewrite all the JS which is a massive undertaking and offers very slim benefits to almost everyone outside of Google speed tests.

Hey, the 80s was peak civilisation.

For cloud, we may be able to do this by the realtime system to see who is on the page and actively using the editor.

Automated using various metrics. Yep.

How’s the music on this one @Dll?