Dreadknux

The scroll-padding and scroll-margin properties handle all of this for you, and are already built into v5 via a simple CSS variable. No need for pseudo elements or negative margins 🙂 
 
Are bios a custom profile field which you've made? By default, they'll be displayed below other stats with both the name and value of the field. Location is an example in this screenshot:

I have a general question relating to the new V5 design philosophy/restructure if that's okay @Ehren.
I've been using sticky nav headers in my current V4 setup, where the navigation strip underneath the header area follows the user as they scroll down. That's working very well, with one caveat; I've had to try and shoehorn in a bunch of additional CSS for as many anchored areas on-page as I can think of(i.e. pagination rows, anchored H2s etc) to ensure those anchored areas do not appear hidden behind the sticky navbar.
Unfortunately it's a little bit of a janky/inelegant solution - my code for each anchored part in my custom CSS goes something like this:
[data-resort="listResort"][data-tableid="topics"]::before, [data-resort="listResort"]::before { display: block; content: " "; height: 60px; margin-top: -60px; visibility: hidden; pointer-events: none; background: none; } The above code tends to help make sure that anchors are set underneath the sticky navbar (which is 60px in height), but it has the side-effect of pulling the ipsBox design up and above its container, which makes sense logically but is a little annoying (and I've had to find alternative way to fix this by modifying the container CSS further to resolve, on a per-section/per-anchor area basis)

So basically what I'm interested in knowing about is, do you think there is something in V5's design approach that accounts for this kind of customisation that a community admin might want to do, without requiring custom CSS for a hundred different containers to make it work?
I don't necessarily mean that there needs to be an option for sticky headers in the theme editor or anything (because there are too many variables at play - different heights of sticky containers, whereabouts that sticky area might be, etc), but perhaps there is a custom CSS variable baked into V5 for advanced CSS editors, where they can input a value for a sticky anchor height, and then the admin can add one additional line of custom CSS to set their desired navbar/area as 'sticky'... and then the set variable would ensure that all anchored on-page areas would be automatically adjusted to account for the sticky header (so nothing appears hidden behind the sticky container).
It's probably quite a complex thing to ask about, but interested to hear your thoughts on feasibility etc?

Hi IPB Team & Community ^_^
As images are essential part of forum topic it would be great if uploading of topic images and resizing would be more optimal
Right now it is quite hassle for first time user of website.

As admin or Moderator we all know how to upload image and resize but for first time user  it is quite unfriendly.

As user i have to first "choose files" then click on insert then i have to double click to resize it, if i just single click it do nothing as shown below.












Even if user able to figure out how to resize image, putting numerical value is kinda odd procedure 





However if we see at other forum software they made this process very user friendly as follows  
Simple "insert image" button on editor that show upload option









Automatic Blue resizing border around image once it is uploaded  that user can use to resize the images easily 





if there is any way we could customize editor to make image upload and resizing as above please also let me know.

We hope IPB team will take note on this and make it more optimized. 

Thanks 
Gill

I might be missing something in the AdminCP, but it would be great to have the option to allow certain usergroups to upload particular file types/extensions to the community.
At present, there's a global option in ACP to allow users in general to upload files (and further set which filetypes they can upload). I use this to forbid regular users from uploading non-video/image files (like .zip or .exe files). But I would like the option for only Administrators to be able to upload .zip files to Downloads app (and other areas of the site), and there doesn't seem to be a way for me to do that. I trust the zip files I upload for my community, but I don't trust regular users with the same.
Can this be something that is added to V5 perhaps? Or if it's already a thing, please let me know! 😄

You're not missing anything. There is no way in which to do this by group at present

The current lightbox is not mobile-friendly. I often end up opening the images instead of tapping on the next/previous button.
Swipe gesture would be much better.

It's been so quiet any more teasers or show & tell? 

Custom fields for every content type.  I don't know why IPS gave us custom fields for Downloads and Page Databases, but not for other content types. I can see real value in adding custom fields to Forum Boards, especially if you have certain boards that are highly-organized that can be filterable, searchable, indexable, etc.    

If you are interested in switching in the future, just let us know. We can help you get your data migrated. We're fully booked this side of Christmas and New Year is already busy for self hosted to cloud conversions but we'll always do what we can to help.
 
It is indeed. 🙂 

Sadly not a feature that I will be able to take advantage of, being self-hosted, but still a nice addition.
I did notice a new icon in the userbar in this video though, right next to the profile picture. I'm guessing this is where users can quickly check the Activity Feed in V5? That'll be quite useful 🙂

This is a very interesting development on the SEO/Google Search side. I definitely hear the concerns about opening things up so wide, but on the other hand if it can help position my community's content on the same level as content posted on social media that can only be a good thing in my eyes.
Since we're talking about this, I figure it might be worth asking a (sort of) related question to IPS: are there any considerations being made as to how different node content is being served/displayed on Google Search results? For example, how prominently a community's forum topic might appear under a search result as opposed to an Event entry, or a CMS Pages record?
One reason why I ask, is that I have CMS Pages databases that have relationships with certain forums (so comments on the CMS Page record and the Forum Topic are practically identical), but in the case that someone searches for some terms I'd rather the CMS Page record be the primary result (and maybe a nested result for the forum topic version of that same content underneath). But I don't know how much control IPS has over that sort of thing, or whether that's something that it entirely in Google's power/wisdom to design.
So call it a question of curiosity rather than a proper SEO-related feature request. 😄

Just for clarification, Pages is getting a substantial update for v5 and is a core part of our community platform strategy.

Hm, I can see why IPS made this change but to be honest, asking clients to seek custom app/plugin development is going to be a lot more expensive than finding an app on a marketplace that many customers will be able to purchase. I guess it will make me a lot more hesitant to spend my money on third party apps.

As an addendum, I would say that a core part of any community strategy is to convert guests into members. Members have more tools including notifications to make your site more 'sticky'.
Allowing guests too much scope will reduce the number of sign-ups you ultimately get. There is a balance of course, I dislike things like restricting viewing attachments (often photos) to members only and restricting the number of topics they read, but finding ways to encourage registration is a good long term strategy.

These UI changes are looking really nice, fantastic work as always Ehren. Having you join the IPS design team is undoubtedly one of the most exciting things to happen and your work here is just proving that every day. Looking forward to seeing even more!
I'm also now interested in seeing some of the improvements to the UX that complement the UI changes - in particular the mobile topic/posting experience, which in V4 is currently quite miserable now when you compare the ease of posting on social media apps. Just this morning I tried to post a topic about a news story I read earlier, and it was a constant battle of scrolling up/down just to reach post editor toolbar icons that had been moved off-screen as my post got longer (some elements, like the GIF implementation and URL insertion, are pretty clunky as well).
Not knocking the V4 experience as I know it's a decade old at this point and originally designed to serve a desktop experience over mobile - but at the same time, I can see why many in my community prefer to post status updates when it's currently so difficult to quickly and easily post a topic or a post on the forum via their phones. 😅

These UI changes are looking really nice, fantastic work as always Ehren. Having you join the IPS design team is undoubtedly one of the most exciting things to happen and your work here is just proving that every day. Looking forward to seeing even more!
I'm also now interested in seeing some of the improvements to the UX that complement the UI changes - in particular the mobile topic/posting experience, which in V4 is currently quite miserable now when you compare the ease of posting on social media apps. Just this morning I tried to post a topic about a news story I read earlier, and it was a constant battle of scrolling up/down just to reach post editor toolbar icons that had been moved off-screen as my post got longer (some elements, like the GIF implementation and URL insertion, are pretty clunky as well).
Not knocking the V4 experience as I know it's a decade old at this point and originally designed to serve a desktop experience over mobile - but at the same time, I can see why many in my community prefer to post status updates when it's currently so difficult to quickly and easily post a topic or a post on the forum via their phones. 😅

These UI changes are looking really nice, fantastic work as always Ehren. Having you join the IPS design team is undoubtedly one of the most exciting things to happen and your work here is just proving that every day. Looking forward to seeing even more!
I'm also now interested in seeing some of the improvements to the UX that complement the UI changes - in particular the mobile topic/posting experience, which in V4 is currently quite miserable now when you compare the ease of posting on social media apps. Just this morning I tried to post a topic about a news story I read earlier, and it was a constant battle of scrolling up/down just to reach post editor toolbar icons that had been moved off-screen as my post got longer (some elements, like the GIF implementation and URL insertion, are pretty clunky as well).
Not knocking the V4 experience as I know it's a decade old at this point and originally designed to serve a desktop experience over mobile - but at the same time, I can see why many in my community prefer to post status updates when it's currently so difficult to quickly and easily post a topic or a post on the forum via their phones. 😅

Oh I see, thanks. So I guess the solution with that issue is to have a setting that allows the Admin to choose whether a topic or the page keeps the "canonical" tag and supersedes the other. That'd be nice to see. Might have a positive impact on how your community's content is displayed in Google search results too (although I'm obviously not holding my breath 😄)

These UI changes are looking really nice, fantastic work as always Ehren. Having you join the IPS design team is undoubtedly one of the most exciting things to happen and your work here is just proving that every day. Looking forward to seeing even more!
I'm also now interested in seeing some of the improvements to the UX that complement the UI changes - in particular the mobile topic/posting experience, which in V4 is currently quite miserable now when you compare the ease of posting on social media apps. Just this morning I tried to post a topic about a news story I read earlier, and it was a constant battle of scrolling up/down just to reach post editor toolbar icons that had been moved off-screen as my post got longer (some elements, like the GIF implementation and URL insertion, are pretty clunky as well).
Not knocking the V4 experience as I know it's a decade old at this point and originally designed to serve a desktop experience over mobile - but at the same time, I can see why many in my community prefer to post status updates when it's currently so difficult to quickly and easily post a topic or a post on the forum via their phones. 😅

Currently, when a record is created, you have the option of posting that record as a thread within a specified forum. If you utilize that option, both creations come with a canonical tag that gives the 'thread' preference. It would be nice if there was an option to give the 'Record' prominence over the 'Thread.'

Having Google being directed to not rank the database page in tis manner kind of defeats the whole underlying purpose of a CMS system.

TYIA

Google claims to not penalize duplicate content on a site but regardless, it can still hurt your SEO practices. The problem lies in the fact that IPS places a <link rel="canonical" ...../"  /> tag (which directs a search engine that this is the master copy) on both the page and the topic. You can easily see this by viewing the page source of both the page and topic. It should be line 171. You shouldn't have a canonical tag on both pages claiming to be the master.

I have reported this previously but never followed up on it by placing the topic in the Feedback sub.

As showcased in our past blogs, Invision Community 5 introduces a brand new, modern interface which brings improvements to performance, aesthetics and mobile usability.
An optional side navigation panel, new view modes, light/dark modes, customizable header layouts, a search modal and a mobile navigation bar are some of the things we've showcased previously. Today, lets take a closer look at some other miscellaneous changes that we've been working on while developing Version 5, including some of the code reductions and performance improvements that we've been able to achieve in the process.
For those of you who are developers, we'll also give some simple explanations of how (and why) we've implemented these changes.
 
Widgets
Sidebar widgets are perfect for displaying content feeds, featured members, announcements, advertisements and more on your page. In version 4 however, the widget column would often become an empty space once the widgets had been scrolled past:
  widgets-v4.mp4  
In version 5, widgets now stick to the screen once the last widget has been reached, ensuring your readers have more convenient  access to your widgets rather than a void space:
  sticky-widgets-v5.mp4  
 
Messenger
The Messenger is a great way to reach out to members when a private chat is more appropriate than a topic. Inspired by modern email clients, the messenger in Version 5 has been revamped with a full-height, sticky inbox, a longer message snippet, mini profiles and a more polished UI - all with a 25% reduction in CSS and a 100% reduction in Javascript.
messenger-v5.mp4
 
Sticky elements
We've mentioned sticky elements a couple of times now, so lets take a look behind the scenes at how they're created, and some of the performance improvements with Version 5. Traditionally, sticky elements were created using Javascript which would calculate the position of the element on the page and adjust it's stickiness every time the page was scrolled. Scroll events can be quite taxing for browsers, and when it comes to Javascript, the less, the better (especially when aiming for great page speed scores)!
With that in mind, all sticky elements are now handled using sticky positioning via CSS, which is a native and much more performant way of controlling these elements. We've been able to replace an entire 400 line Javascript component with just 3 lines of CSS.
 
Grids and Masonry
Grids have previously been handled in a similar fashion. Javascript would scan all elements within a grid to determine how many could fit on a single line, and would then shuffle these elements into position after the page was loaded or resized. CSS has since introduced its own grid properties, which has allowed us to replace more than 350 lines of Javascript with just a few lines of CSS, resulting in more performant page rendering and nicer looking grids (especially on small-medium displays such as mobiles and tablets).
 

 
Fun fact: We first introduced a similar performance improvement to "masonry grids" in our Gallery update from January this year, by replacing more than 400 lines of Javascript with, you guessed it, just a few lines of CSS.
 

 
 
 
Click targets
We wanted to make Version 5 as simple as possible to navigate, and one way of doing that has been by implementing larger click targets. Clicking anywhere inside an entry in a table or grid will now take you to that entry (you can still click on other links like normal within the click target, such as subforums or profile links). Click targets are optional and can be disabled via your theme settings if necessary.
 
click-targets.mp4
 
Data Lists (tables)
Speaking of tables, they too have been revamped. Tables automatically adapt to the space they've been assigned to (for those curious, this is done using CSS container-queries), so they're always neat regardless of the screen size, with no overflow or squashed layouts. Behind the scenes, the two columns below are created with identical code, yet they're quite different visually due to the size which they've been allocated. Even with these improvements, tables have received a 25% reduction in CSS.
 

 
Profiles
Profiles have been polished for Version 5 and include some nice improvements such as sticky widgets and tabs. 
profile-desktop.mp4
 
On mobiles, the side column collapses into a carousel, and the sticky tabs allow you to easily flick between content types without scrolling to the top of the page.
profile-mobile.mp4
 

Tabs
You may have noticed in the above clip that tabs on mobiles are now scrollable, compared to a dropdown menu from version 4. We made this change to ensure that tabs are given more equal exposure on small devices, and have managed to reduce the CSS by a whopping 80%.
 
Carousels
Last and certainly not least, are carousels. Carousels are great for displaying large amounts of data in a confined space and they've been rewritten from scratch for version 5. Previously, a Javascript library was used to create the "scroll effect", however this has never been the smoothest experience on laptop trackpads and touch devices.
In version 5, carousels are powered by native smooth-scrolling and scroll-snapping, which results in a much nicer user experience, especially on touchscreens. We've been able to remove a staggering 95% of the Javascript, substituting it with just a few lines of CSS.
 
carousel.mp4
 
To be honest, we've only just scratched the surface here! In addition to these changes, we've modernized (and reduced code) in almost every component throughout the suite including avatars, cover photos, dropdown menus, forms, inputs, buttons, lists, off-canvas menus, side menus, columns and more!
Combined, these changes result in not only a significant reduction in code, but also a polished UI that performs smoothly on desktop and touch devices. We're excited to continue modernizing Invision Community well into the future as new technologies and techniques become available to us, and are looking forward to getting it in your hands in 2024.

View full blog entry

Hi @Dreadknux
Funnily enough, this is something we discussed internally a few weeks ago. We're working hard on revamping Pages at the moment, so we'll be able to provide more information in the future about widget customizations 🙂 

Hey @Ehren sorry for the topic bump but I was rewatching this and something came to me when seeing these newly-designed widgets:

Considering how great these particular 'scrollable column' widgets look both on desktop and mobile, is there scope to include these widget designs for custom content blocks in the V5 Block Manager (or as a built-in template to leverage in the AdminCP Block Editor)? I can just see myself using this particular widget design to list the latest records in a 'News' Pages CMS database, for example.

I just checked the rogue online event and saw that it was set for a repeat the following year, I unchecked it and it removed itself from the Online Events widget. So I guess that was that. Thanks for that Jim, guess you guys already know about that then! 🙂