Ehren

Yeah, that’s a good example of the "scroll spy" (or timeline scroll) element I was referring to.. being able to drag a slider to quickly navigate within a topic. It kind of works okay, but I feel like there are some downfalls which are tough to overcome. The main issue I see with that, is I can’t scroll to the top or bottom of the page (on mobile) since new content is constantly loaded. The desktop version doesn't suffer from this issue, only because it has a fixed header and sidebar. As soon as they're gone, you're stuck in scrolling limbo again. This could be alleviated with a “load more replies” button, but then we’re almost back in pagination territory. The scroll spy also needs to be sticky in the sidebar, which means there unfortunately wouldn't be any room for other sidebar widgets within topics.

When viewing a “mega topic” (let’s say one which would typically span 20+ pages), how would infinite scrolling work? Infinite scrolling would be nice for smaller topics, but my brain can’t think of a nice way to handle long topics. If I viewed that “mega topic” for the first time, I’d be taken to post #1. Imagine needing to scroll 20+ pages of content just to read the most recent reply. Infinite scrolling is tough to implement in large topics unless it’s paired with a “scroll spy” sort of element (which lets you drag a slider to speed through the topic). Paginated content makes it easy to skip through large amounts of content, or return to earlier parts of a topic, using a very common and reliable UI. It even gives you a general idea on the size of the topic (a lot of pages = a lot of content), which isn’t obvious on an infinite scrolling page - you’d just keep scrolling with no hints on how close you are to the end (unless the UI was redesigned to convey this information). Even Google is reverting back to paginated content following their attempt at infinite scrolling, but that’s likely due to other reasons than the ones we’ve discussed. 🤷‍♂️

With the amount of code and user generated content transferred on each page load, the removal of the image HTML (a few bytes at most) would be infinitely negligible in terms of performance gains. You wouldn’t see a single point improvement in any page speed test by doing that. You even mentioned yourself that less than a kb is not a problem at all. I’m very, very particular about performance and excessive code, but would happily apply the CSS solution on all of my own sites if I needed to remove the thumbnails for some reason.

The fallback image is now customizable in v5 and the entire image cell can be removed with CSS if no user-uploaded image exists.

Yes. You can do this in v4 already, and the same feature exists in v5.

Yes, but that use-case was already addressed in my earlier post 😅 Version 5 outputs that information as data-ips-member and data-ips-member-group attributes. If the visitor is a guest, data-ips-guest is used instead. With all of that said, you should really be using the Advertisements feature to show ads conditionally to user groups. Manually hard-coding them into themes isn't very future-proof, and you don't get easy access to conditional settings such as "Show in certain locations" or "Show to certain user groups" or "Hide after certain date", etc.

This is on my todo list, and has been for a while. Consider it fixed for version 5.

Thanks aia, View transitions are actually used in the "drag header elements" feature in the v5 Theme Editor (they create the subtle reordering animation). In terms of cross page navigation, I'd need to find areas where this would actually make sense and benefit the user, instead of adding it just for the sake of an animation. Depending on the goal of the animation, we'd potentially need to scatter the page with view-transition-name properties which isn't super ideal. They're great for dynamic DOM updates where elements are repositioned, but that doesn't happen too often with our software. So I guess my question is, what areas did you want transitioned exactly?

Out of curiosity, what requirements are you trying to fill by adding classes to the body element? Hiding elements on mobiles is very easily achieved by CSS and doesn't require template modifications. You could potentially shuffle the page header elements with CSS (grid or flexbox), but v5 will aim to have more consistent component designs across the suite, so this will hopefully no longer be an issue for you.

Attributes for "logged in" and "member group ID" are already available by default in v5 on the <html> element: data-ips-member='1234' data-ips-member-group='4' Editing templates just to change "padding" to "padding-half" is a poor decision in terms of maintenance. Using CSS to overwrite those areas is much more future-proof. Version 5 has more helpful selectors in the code, so you'll be able to target elements much easier compared to v4.

Your presumption is correct! 🤝 Topic feeds will display the "share/embed" image if one exists. For the moment, a placeholder is shown for topics which don't have an image in the first post, but we can revisit that in the future if needed 🙂 Two example screenshots below using Grid and Wallpaper:

Widget Designs are still being rolled out and will be available for many widgets once I’m done. They are not finished in Alpha 2.

Introducing new Page Builder tools in Invision Community 5 Widgets are an incredibly powerful tool for displaying curated content of your choice on any page of your community - and despite the extensive array of settings for customizing their data, they've often been limited in terms of their design options. But this changes thanks to the new Page Builder tools in Invision Community 5! Widget Designs Previously in version 4, widgets would often have 2 designs: one for the main content area and a more minimal version for the sidebar. This worked well, but it meant your page was very limited in terms of design as you'd typically need to use the same table-like layout for most widgets. Anything beyond that would typically require a custom block to be coded, often with additional HTML or CSS. Version 5 offers much more customization by allowing you to change the design of each widget with the click of your mouse - no coding necessary! When dragging a widget onto your page, a new toolbar at the bottom of the page appears, holding all of the widget design options. Lets take a look at some below! Grid A familiar a very layout used elsewhere in the suite, the Grid design neatly aligns entries in a grid with a large cover photo sitting up top. A great combination of visual imagery alongside meta data such as entry descriptions. Featured A spacious list and a great way to feature content, pardon the pun. Wallpaper Perfect for content which includes uploaded cover photos or thumbnails! The Wallpaper design stretches each image to make it occupy the entire background, overlaid by a minimal amount of content. A subtle gradient sits behind the text to ensure it's easy to read, even on detailed images. Rows (table) The Rows design is a very familiar one, used very often throughout other areas of the suite. Content is displayed in a neat table, that collapses into a more compact design on small screens. Minimal Great for displaying a lot of content in a compact area! Minimal only shows primary information and hides meta data such as entry descriptions and stats. Great for sidebars, or areas with limited width. Minimal Grid The Minimal Grid design removes large meta information and displays content in a nice, compact grid. A nice option for displaying a lot of content while being cautious of vertical space. Carousel The Carousel option is quite unique because it can be applied in tandem with other widget designs, and is a perfect way to make the existing layouts even more compact. For example, by default, the Wallpaper design is aligned as a grid, but with the Carousel option enabled, the layout is converted into a carousel instead: Carousel-widget.mp4 Here's another example, using the Featured and Carousel options: Blog - featured carousel.mp4 Fun fact for developers: All of these designs use the exact same HTML structure; the only thing that differs is the class name on the parent element. This makes it incredibly easy to adjust the design of your own widgets without needing to manually code multiple layouts. Widget Areas Version 4 was often quite limiting when it came to aligning widgets in pages. Widgets could be dragged into a stacked, vertical list but that was typically as far as you could go in terms of design. Version 5 introduces a new concept called Widget Areas, which allow you to align multiple widgets in a variety of ways. Lets take a look! To create an area, you simply need to drag one widget on top of another. Blog - areas.mp4 By default, they'll align themselves into a grid, but can be realigned with ease by using the toolbar at the bottom of the page. The toolbar also holds controls for adjusting the width of widgets, and the gap between them: Blog - alignments.mp4 Widget Designs and Widget Areas in Version 5 make it incredibly easy to create a completely custom page in a matter of seconds. We're really excited for you to get your hands on these new tools in Invision Community 5, and are looking forward to seeing all of these new page designs in the wild, in the very near future! View full blog entry

Attaching images using your phone camera has been around for some time, and is available in both v4 and v5. The "Add Files" button will appear if your device supports that feature.