Rikki

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
Goals
Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
 
Brighter UI
The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

Brighter default colors
 

Simplifying the UI by removing block backgrounds
 
Improving typography
We've felt our typography has been somewhat muddled for some time - with a mixture of sizes, weights and colors used depending on the particular context.
The first step to improving it was to create a typography scale that we could refer to and implement, to ensure we remained consistent throughout the product.

Our typography scale
(The keen-eyed amongst you may also notice we've switched our default font to Inter. Inter is a fantastic open source font that is ideal for text on the web, and was recently added to the Google Web Fonts project making it super simple for us to incorporate it into our default theme.)
We've been much more deliberate about applying type styles, especially for titles, ensuring that they are always visually distinct from surrounding text. We've done this through both color and weight. As a result, pages should instinctively feel more organized and logical than before.

An example of improved typography, from the Downloads app
 
Improved spacing (especially on mobile)
We identified that spacing (padding and margins) needed some improvement. A lot of spacing values were arbitrary and inconsistent, leading to poor visual harmony across any given page.
Most troubling of all, on mobile sizes we simply halved desktop padding values. While this was a reasonable approach in the days of phones with small screens, it has felt decidedly dated for some time. Phone screens are now typically larger and able to accommodate roomier UIs without appearing comical.
In 4.5, we have done away with that approach, and the impact was immediate. Mobile sizes now get a much more pleasant interface, with elements having room to breathe. In addition, we've also made most cards full-width to provide additional breathing space for content.

Posts can finally breathe on mobile
 
There are numerous other tweaks across the product too: default spacing has been increased a little, data tables (e.g. topic listing) get extra vertical spacing, and spacing between elements has become more consistent.
 
Improved grouping of related elements
Prior to 4.5, most content areas existed inside cards. However, one notable exception to this was page headers and as a result, they could feel particularly disorganized, especially for users who had many controls in this part of the page (such as staff).
To solve this problem, we've developed a new, standardized design for content item page headers, giving them their own cards and consistent button placement.

Topic view header
 
Some areas don't necessarily fit into the same design pattern above. In those areas, we've tweaked styling to suit the context, while still adhering to our overall aesthetic.

Calendar header

Messenger conversation header
 
Reducing underutilized links/buttons
Finally, another area we identified as needing improvement is the abundance of tools, made up of links and buttons, across pages. Many of these are only used occasionally and so would be better moved out of the main view to simplify the page.
Two particular areas we focused on were share links and postbits (both forum posts and comments in other apps).
Research shows social share links are used by a vanishingly small percentage of users, so even though they were at the bottom of the page, it was unnecessary to make them so prominent (given their eye-catching colors). To solve this, we've added a share link to the page header, with the social network links themselves in a popup menu. The result is ideal: sharing functionality is unobtrusive but obvious.

Share links in content items
Comment areas have also suffered from 'button creep' over the years. A typical comment will contain a report link, a share link, a quote link and multiquote button, reactions, plus IP address, checkbox, edit and options links for certain users. That is a lot of visual noise around the important part: the content.
We've therefore simplified comment boxes as much as is reasonable. Reporting and sharing comments/posts is now available in the post options menu, as are any tools for the author/staff. Quoting and reacting are two primary interactions for users, so they of course retain their position in the control bar.

Simpler postbits, even for staff
 
Improving post states
Posts/comments in Invision Community can have many states - sometimes more than one. Posts can be hidden/unapproved, popular, recommended, solved (new in 4.5!) or highlighted because of the author's group. It's always been a challenge to indicate these statuses well.
In previous versions, we added a border but the most prominent indicator was a flag in the top-right corner of the post. This had three problems:
Due to the lack of space (thanks to report/share links), showing more than one flag was difficult. Showing any flags on mobile was messy because of the space constraints. The meaning of the flags was not obvious, especially to new users. Group-highlighted posts had no flag, just a border, which made them even more difficult to understand. With the top-right corner of posts now tidied up and free from fluff, we were able to much more effectively use this space to indicate post statuses.
In 4.5, posts and comments will show badges when they have a particular status, as well as a more attractive semi-transparent border. For group-highlighted posts, we show the group name instead (the colors of this highlight are still controllable via theme settings).

A post with two states: group highlighted and popular
This works much better on mobile too, where the status badges get the prominence they deserve:

Mobile post statuses
 
Modernizing the underlying code
I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
 
Wrapping up
As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
 
Screenshots
  
Desktop forum views (click to expand)
 
    
Mobile forum views (click to expand)
 
 
Activity streams & messenger (click to expand)
 

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.