Jump to content

Rikki

Invision Community Team
  • Posts

    24,349
  • Joined

  • Days Won

    81

Reputation Activity

  1. Like
    Rikki got a reaction from Mandalala for an entry, 4.5: Improvements for theme designers   
    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.
  2. Like
    Rikki got a reaction from Firdavs Khaydarov for an entry, 4.5: Improvements for theme designers   
    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.
  3. Like
    Rikki got a reaction from crmarks for an entry, 4.5: Improvements for theme designers   
    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.
  4. Like
    Rikki got a reaction from Bluto for an entry, 4.5: Improvements for theme designers   
    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.
  5. Thanks
    Rikki got a reaction from Spanner for an entry, 4.5: Improvements for theme designers   
    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.
  6. Like
    Rikki got a reaction from Teascu Dorin for an entry, 4.5: Improvements for theme designers   
    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.
  7. Like
    Rikki got a reaction from Foolboy for an entry, 4.5: Improvements for theme designers   
    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.
  8. Like
    Rikki got a reaction from shahed for an entry, 4.5: Improvements for theme designers   
    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.
  9. Like
    Rikki got a reaction from Rafael Oliveira for an entry, 4.5: Improvements for theme designers   
    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.
  10. Like
    Rikki got a reaction from Emanoel for an entry, 4.5: Improvements for theme designers   
    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.
  11. Like
    Rikki got a reaction from Rhett for an entry, 4.5: Improvements for theme designers   
    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.
  12. Like
    Rikki got a reaction from SC36DC for an entry, 4.5: Improvements for theme designers   
    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.
  13. Like
    Rikki got a reaction from -RAW- for an entry, 4.5: Improvements for theme designers   
    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.
  14. Like
    Rikki got a reaction from SoloInter for an entry, 4.5: Improvements for theme designers   
    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.
  15. Like
    Rikki got a reaction from Sonya* for an entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases   
    Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
    In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
    As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
    Setting up blocks
    The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

    Creating one of the blocks we'll need
     
    Adding the field
    Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
    Here, though, I've just created the Number field, and named it Forum ID.

    Setting up the database field
     
    Using the field formatter to show the correct block
    Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
    {{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

    End result, with the correct block pulled in based on the ID we provided to the record
     
    Going further
    So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
    Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
    {block="content_for_{$record->author()->member_id}"}  
    I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!
  16. Like
    Rikki got a reaction from Meddysong for an entry, 4.0 - Extending JS controllers using Mixins   
    Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

    Reviewing controllers

    Some time ago, I blogged about the javascript framework we've built for IPS4. In it, I covered the most important component: controllers. To recap, a controller is a special object within the framework, and is applied on specific elements. That element is the controller's scope, and the controller works on it to provide its functionality. For example, a simple controller might look like this:

    ips.controller.register('core.global.core.example', { initialize: function () { this.on( 'click', this.showAlert ); }, showAlert: function (e) { alert( "This button's text is: " + this.scope.html() ); } });
    It would be used on an element like so:

    <button data-controller='core.global.core.example'>Click me</button>
    Here we're registering core.global.core.example as a controller. This represents the controller path - it's in the format app.module.group.controllerName. Though it seems longwinded, this allows IPS4 to dynamically load controllers on-demand, rather than loading them all when the page is loaded. In the initialize method (called automatically), we set up an event handler for a click. When the element is clicked, you'd see an alert saying "This button's text is: Click me".

    So, that's how controllers work. Almost all page behavior in IPS4 is handled through controllers. But how would you change a method in an existing controller, say if you were writing an addon, or if you had two controllers that were fairly similar, and wanted to provide a base controller they both shared?

    Mixins

    To enable that, we have mixins. Mixins allow you to specify functions which are inherited by objects - in this case, our controller objects. This means, using mixins we can add new functions to a controller without needing to edit the controller itself.

    A mixin is defined like so:

    ips.controller.mixin('addAnotherMethod', 'core.global.core.example', true, function () { this.anotherMethod = function () { alert('Inside anotherMethod'); }; });
    The ips.controller.mixin method takes up to 4 parameters:

    ips.controller.mixin( name, controller, automaticallyExtend, fnDefinition )
    name: Name to identify this mixin
    controller: The controller this mixin extends
    automaticallyExtend: [optional, default false] Does this mixin automatically extend the controller (more on that below)
    fnDetinition: The function definition applied to the controller

    In this example, our mixin adds a method named anotherMethod to our core.global.core.example controller shown earlier.

    Let's talk more about the automaticallyExtend parameter. Mixins can be applied to controllers in one of two ways - either automatically on a global basis, or manually on a case-by-case basis. Mixins are manually specified like so:

    <button data-controller='core.global.core.example( addAnotherMethod )'>Click me</button>
    This means the mixin is used on this element - but another element using core.global.core.example wouldn't get it. This is useful when you're building your own apps or addons; you can write simple controllers that implement base functionality, then extend them with functionality for specific cases by specifying the mixin name in your HTML. We use this ourselves - for example, we have a base table controller that handles sorting, filtering and so forth. We then have a mixin for AdminCP tables, and a mixin for front-end tables, which add functionality specific to those areas, reducing code duplication.

    If you're extending an IPS controller in an IPS app, though, modifying the HTML isn't typically an option. Instead, you can specify the mixin as global, and it will be applied to all elements where that controller is used. This means you can write your own mixins that work with our default controllers without having to touch our controller code (and that's a good thing).

    Advice

    So that shows how to add new methods to a controller. But what if you want to work with the methods that already exist in the controller? In the above example you'd only be able to overwrite an existing method - certainly not ideal, because 1) you would break any other mixins using the default method, 2) if we made an update to a method in a later release, your mixin would break it.

    To facilitate working with existing controller methods, we're using a model called advice. This adds three special methods to a mixin: before, after and around. These let you 'hook into' existing methods and provide additional code for them. Let's rewrite our example mixin from above to take advantage of it:

    ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.before('showAlert', function () { this.scope.css({ background: 'red' }); }; });
    Here, I'm using the before method. I'm hooking into showAlert method (from the controller), and changing the background color of the scope element. So what happens when the link is clicked? First the background changes to red, and then an alert box is shown. We've added the background changing functionality without needing to edit the controller at all. Here's two other ways of doing the same thing, using the other two special methods:

    ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.after('showAlert', function () { this.scope.css({ background: 'red' }); }; this.around('showAlert', function (origFn) { this.scope.css({ background: 'red' }); origFn(); }; });
    The after method is fairly self-evident. With the around method, the original function is passed in as an argument, allowing you to determine when it is executed by your mixin.

    All three of these methods will stack, so multiple mixins can hook into the same method, and they'll be executed in order, each receiving the previous.

    Conclusion

    I hope this introduction to mixins proves useful to developers; it shows how our core app controllers can be extended in a non-destructive way, but also how your own apps can use the mixin functionality to create an inheritance model to make your life easier.

    Javascript in IPS4 makes extensive use of custom events, so the preferred way of adding new functionality is to listen for appropriate events and act on them - but the mixin support described above provides a mechanism by which you can adapt existing event handlers.
  17. Like
    Rikki reacted to Matt for an entry, What are the benefits of a support community?   
    When your customers buy or use your products, they will have many questions. They may have issues using the product, or they may have requests for future versions based on their needs.
    Managing and responding to those questions and requests quickly increases conversion, satisfaction and the likelihood or purchasing again.
    The statistics back this up.

    There is no doubt that unless you have a support community for your brand,  you are not delivering the best experience for your customers and risk losing them to competitors that do.
    Building a support community around your product or service will positively drive your business across all departments from product development through sales and into customer support.
    Let's break it down and look at the key benefits for each department.
    Customer Service
    Encouraging your customers to visit your support community is the simplest way to reduce the cost of supporting your product or service. Creating a self-help culture allows other more experienced customers to offer assistance and troubleshoot any problems they have.
    73% of customers fall in love with a brand because of friendly customer service representatives.**
    Quite often, new customers encounter the same issues that would flood customer support if they were all channelled to your support desk. For example, consider a company that produces an internet-enabled smart device. Less technically savvy customers will likely contact support to troubleshoot initial connectivity issues which can quickly be resolved by peers in the support community.
    These questions and answers form a crowdsourced knowledge base that will allow customers to help themselves without any intervention from your team. Furthermore, these questions will feature in external search results, driving more traffic to your site.

    Sales
    The primary purpose of your community may have initially been to help support your customers, but it quickly becomes a valuable resource to help drive sales.
    Your support community will be a relaxed place where customers talk to each other honestly and openly. They will be less inhibited than they would if they were talking to your sales agents.
    Customers might be discussing a need for more functionality that you have in another product or service. Your sales team can move these conversations from the community to your CRM to curate new sales leads.
    72% of customers will tell 6 people or more if they have a satisfying experience. - Esteban Kolsky
    Customers that have had positive interactions with their peers and members of your support team will become advocates for your brand. They will help sell your product over social media and among their friend circles. Given than 90% of customers are influenced by a positive review when buying a product*, having brand advocates is critical to your growth.

    Marketing
    There are several costly routes to learning about your customers and their wants and needs. You can conduct external surveys, or pay for research groups to look at your products and offer feedback.
    56% of customers don't mind sharing their personal information in exchange for better service.**
    The most effective method is to look at your community.
    Your customers will be posting their thoughts daily. They'll tell you exactly how they use your products, offering you valuable insight into the problems they are solving with your product. This information should be used as the basis of new marketing campaigns.

    Project Development
    Your support community is a direct line to your customers. You no longer need to use external tools and services to determine which features you should add next. You'll be told directly!
    55% of customers are willing to spend more money with a company that guarantees them a satisfying experience.**
    You'll find that some feature requests bubble up regularly. These are the ones you will want to move to your product roadmap.
    Invision Community allows you to segment your community into private areas for beta testing. Your developers can interact with this group to work directly with your customers to shape new functionality.
    Harnessing analytical data will inform development decisions. Invision Community can track keywords in user-generated content. If you have released a new feature, you can track how often it is mentioned in conversations to monitor its uptake.
    52% of customers believe that companies need to take action on their feedback.*

    Setting up your Invision Community
    Now we've looked at the compelling reasons you should create a support community around your products, let's take a look at how to set up your Invision Community.
    Support Desk
    Invision Community has a fully-featured built in support desk functionality. Commerce has all the features you need, including multiple support desk categories, reply by email, pre-written reply templates and private notes.

     
    However, if you already use another support desk such as Zendesk then our API tools mean that Invision Community can integrate with your existing support flow seamlessly.
    Keyword Tracking
    Invision Community allows you to track how often specific words or phrases. This is useful to monitor which of your products are trending or monitoring uptake on new features.
    To set this up, visit the Statistics section of the Admin CP.
    Question and Answers
    To formalize a support or ideation area within your support community, Invision Community offers a Question and Answer forum type.
    Question and Answer forum types allow your members to post questions and enable other members to upvote the questions and replies. Your support team can also flag specific responses as the "best answer" which turns historical questions into a crowdsourced knowledge base.
    Showcasing Great Content
    Invision Community has several tools to highlight great customer-created content. You can pin topics, and feature specific replies within those topics.
    You can also convert posts into new articles within a formal knowledge base or blog to further help your customers find the right answers to their questions.
    Extensibility
    Invision Community has OAuth and a REST API out of the box. This means it's trivial to extend Invision Community to work within your existing flows. Integrate Invision Community to your SalesForce CRM and Zendesk support systems seamlessly.
    Create a federated search to integrate your external knowledge base with client-generated knowledge.
    The options are limitless, and we can take care of any custom integrations for you.
    If you have any questions, please let me know below, or contact us to see how we can help you harness the power of community for your business.
    * https://www.customerthermometer.com/customer-service/customer-service-and-satisfaction-statistics-for-2019/
    ** https://www.qminder.com/customer-service-statistics/
  18. Like
    Rikki got a reaction from OptimusBain for an entry, Theme Tip: Replacing forum icons with images   
    In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
    It's easy to use some custom CSS to replace all of the icons - lets see how.
    First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
     
    The basics
    Here's the basic CSS to replace the icon for all forums with your custom image:
    body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
    The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
     
    Using a different 'read' icon
    By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
    body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
     
    Using different icons for redirect or Q&A forums
    If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
    body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.
  19. Sad
    Rikki got a reaction from Christopher Nolan-Downs for an entry, New: Reactions   
    This entry is about our IPS Community Suite 4.2 release.
    IPS Community Suite has long had a reputation system; first we had a simple up/down system, later updated to introduce a Likes system as an alternative. Whichever system you chose to use, it tied in with our reputation system.
    We're pleased to introduce the latest updates to the reputation system, and it's something that has been requested for quite some time: Reactions.
    Quite simply, reactions allow users to offer more fine-grained sentiments towards content than a simple up/down or 'like'. They are now in common usage on social networks, and so users expect to be able to be more nuanced in their response to something they see.
    Let's see how they work in a post, and then cover the options you'll have available.

    What you see above is the default setup for a site that has used the Like system in version 4.1. We include 5 reactions by default:
    Like Thanks Confused Sad Haha If you currently use the older style up/down reputation system, don't fret - you'll still get the new reactions on upgrade, but they'll be disabled by default and instead the new reaction UI will show up/down reactions. This gives you the flexibility to decide which of the new reactions, if any, you want to allow.
    So, those are the basics - but what configuration options can you expect to see? First, you can of course add your own reactions! We expect that beyond the default reactions you'd expect to find, some sites will want reaction types specific to their use-case. On an intranet, you might want to have 'agree' and 'disagree' reactions for staff to use when responding to discussions. On a gaming community, you might replace the icons to be some graphic from a video game that means something to your particular userbase. There's a wealth of possibilities.
    Each reaction you set up can be configured to adjust the original author's reputation count - a reaction can be positive (i.e. award a reputation point), negative (i.e. subtract a reputation point), or neutral (i.e. leave the reputation count unchanged). Our default set won't include any negative reactions, but you are free to configure these and new reactions to suit your own use-case. A user's total reputation count is still shown alongside their content and in their profile, of course.
    If you don't want to use the new reactions for whatever reason, you can disable all of them except Like, and it'll behave just the like 4.1-and-earlier system:

     
    Sites that currently use the up/down system don't show a list of names of users, and instead show an overall reputation score for the content. With the new reaction system, you can enable this even if you don't use up/down reactions. This is great if you plan to use reactions as, for example, an agree/disagree system, or where the content score is more important to your site than the individual reaction types.

    How the reaction UI looks with the 'count only' setting enabled
    As you'd expect, you can click individual reaction counts (or the overall reputation score, if you enable that setting) to view who reacted to the content. This remains a permission setting that you can apply per-group.

    On touch devices, on-hover functionality is not suitable, and so for these devices the reactions UI looks like this:

    Reactions play well with all areas of the suite, including Recommended Replies:

    ...and activity streams...

    ...and a couple of places we aren't quite ready to reveal yet  
     
    We hope you're looking forward to this new feature as much as we are. It's already been a hit on our internal testing site, and we're looking forward to seeing how clients customize it for use on their own community.
    Developer note: Reactions are one of two new features (the other currently unannounced) so far that make use of PHP Traits.
  20. Like
    Rikki got a reaction from MySimS3k® for an entry, Theme Tip: Using custom template bits   
    We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
    Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
    With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
    We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

    Example custom template bits in a custom theme
    Using them is simple:
    {template="_customHeader" group="global" app="core"}  
    I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
  21. Like
    Rikki reacted to Guest Writer for an entry, Case Study: Building Safe Spaces for The Trevor Project   
    Every day, LGBTQ young people from all walks of life log into TrevorSpace, the world’s largest moderated safe space for LGBTQ youth online.
    Here, young people can support each other, share their stories, and find refuge from what might be a less than accepting environment offline.
    Launched in 2008, TrevorSpace is housed under The Trevor Project, the foremost suicide prevention and crisis intervention organization for LGBTQ youth in the world. Having an affirming digital community has been an indispensable resource for the youth The Trevor Project aims to protect, but guiding it to the success it enjoys today has had its challenges.
    Shortly after its launch, TrevorSpace rapidly grew to serve tens of thousands of users in just a few years. While the platform initially started on commercial community software, some unique requirements led the organization to go custom, building a community platform from the ground up.

    Faced with increasing hosting and development costs and declining user activity, senior leadership faced a tough decision: either dramatically transform the program, or discontinue it altogether. That’s when Invision Community stepped in.
    “We were already planning a digital transformation, replacing everything from our physical computers to our crisis services software infrastructure, the platforms that young people use to reach out to us, like TrevorLifeline, TrevorChat, and TrevorText,” John Callery, director of technology at The Trevor Project said of the challenges facing the organization at the time. “We had to be very careful with our resources and where we allocated our time.”
    Continuing the TrevorSpace program would mean The Trevor Project needed to move to a solution that could be implemented and managed with very limited resources while still providing the quality of care that the community had come to expect. It also meant meeting the specific needs of the organization’s mission, particularly around safety.
    After looking into the Invision Community platform per the suggestion of a team member, it became clear that they had all of the fundamentals TrevorSpace was looking for, like messages boards, social networking, and private messaging.
    Here was a chance to save the platform.
    Customers rarely have the opportunity to meet the people behind the technology they use. This wasn’t the case for The Trevor Project and the Invision Community team, who made it clear they believed in our mission to support LGBTQ youth in crisis and were willing to partner with us to realize our specific needs and figure out new solutions.
    Through utilizing the Invision Community team’s applications and plugins, we were able to meet all of our community’s custom needs, adding functionality unique to TrevorSpace to protect our users, many of whom are especially vulnerable when it comes to their privacy. None of this would have been possible without the incredible support of the Invision Community team.
    For just one example of how crucial TrevorSpace is to young LGBTQ people around the world, listen to Mani Cavalieri, the community’s product manager: “When the most prevalent forms of social media are so enmeshed with our in-person relationships, LGBTQ youth often lose a safe place to explore their identities. TrevorSpace is one of those special communities that balances anonymity (often a necessity for safety) with real, personal connections.” Since joining the team, Mani has already seen multiple instances of users finding lifelong friends - and even partners - over the years on TrevorSpace - and on the Invision Community platform, it is able to reach more users than ever before.
    In January 2018, TrevorSpace received double the number of registrations than any other month in the program’s 10-year history. We continue to see more than a thousand new registered members each week.
    As we begin international promotion of the program, we expect to break many more records in the coming year. As we continue to grow TrevorSpace, we also continue to rely on Invision Community’s extensibility.
    Our mission is to improve support networks and mental resilience for our users. This requires us to understand our users’ behavior and needs from a different perspective than other online communities, and it will continue to require more custom solutions.
    The marketplace of plugins, as well as the enthusiastic support of the Invision Community team, enable us to be bold in our ambitions, to build out a community that is truly unique in its class, and to improve the lives of those that need a supportive community the most.
    As one user puts in, in their welcome message to each newcomer: “That's our little secret - there's some one here, going through what you're going through. Whether that be mental health, body issues, parents, friends, and whatever else life as someone who's LGBTQ+ can throw at you. Reach out, and someone will be there for you.”
    - This entry was written by The Trevor Project team

    https://www.trevorspace.org
    https://www.thetrevorproject.org/
  22. Like
    Rikki reacted to Joel R for an entry, 10 Tips For Converting from vBulletin to Invision Community   
    Are you a vBulletin admin looking to stay on the leading edge of online communities? 
    As an IPS client who frequents the Invision Community support forums on a daily basis, I often run across existing or former vBulletin admins looking to migrate to IPS.  In fact, based on my not-so-scientific survey, vBulletin is one of the most popular platforms from where admins migrate. Many of the vBulletin users are professional administrators looking for a stable company, rapid development, and a trusted platform to power their communities into the future. 
    I interviewed 6 former vBulletin admins who are now Invision Community clients.  Most of these vBulletin admins have 10+ years of experience running successful forums, so their input was especially insightful.   
    “I love the design of the admin and moderation back-end, a real treat after living with the antiquated and confusing vBulletin back-end.” -- @cfish
    “I like the well-thought concept, the details, and abundance of features and functions.” --@Ramsesx
    I’ve compiled the top 10 questions and answers from their interviews and the forums specifically for vBulletin admins for an insider’s perspective on how to convert from vBulletin to Invision Community.  You can also read their full interviews in my Community Guide attached at the bottom.
    10. What is the typical lifecycle of Invision Community and what new features come out?
    Invision Community is currently on 4.4.  It’s a great time to be migrating as both the software and converter are very mature.  You’ll be able to take advantage of all the new features from Invision Community 4.x such as Social Clubs, Subscriptions, SEO updates, and GDPR updates. 
    In general, IPS publishes one major update like 4.4 once a year, with several bug fixes, security updates, and enhancements throughout the year.  The best place to read about Product Updates is the official IPS Blog in Product Updates.
    9. What are the pricing options and how do they compare to vBulletin?
    IPS is comparable in pricing when compared to vBulletin depending on your choice of apps.  The self-hosted option is cheaper when considering support and upgrades.    
    The pricing for an active license is simple, easy, and comprehensive.  A new license includes professional ticket support, forum support, access to new upgrades, and managed spam service for 6 months.  Renew again in six months to continue those benefits.  If you choose not to renew, your software will continue to work.
    8.  Is the software mobile ready like vBulletin?
    Yes, the software is responsive by design.  This means the community naturally fits and beautifully displays in any device size, giving you a consistent look-and-feel across all devices.  Try it now by resizing your window! 
    It also means you don’t need to pay for any extra “mobile bundles.”  This approach to mobile design was one of the reasons why @cfish chose IPS: “I didn’t like vBulletin’s approach to mobile. The IPS approach to responsive web design was inline with my own thinking.”
    7.  What are the official Invision Community apps and how do they compare to vBulletin? 
    @Steve Bullman converted to IPS because “IPS seemed to offer a better all-round package for what I needed.”  One of the biggest reasons for considering IPS is a broader approach to community.  Whereas vBulletin focuses only on Forums and Blogs, IPS empowers you to build a suite of applications customized to your needs.  Mix and match apps like Gallery, Blogs, Downloads, Pages, and Commerce to build a modern community with resource directories, databases, paid subscriptions, albums and more that go beyond forums.   
    You can read more about the apps in Features. Calendar and Clubs are included for free! 
    6.  What will be migrated from vBulletin? 
    The free converter app will migrate all of your member and content items from vBulletin 3.8.x, 4.x, and 5.x.  This includes members, private messages, member groups, ranks, forums, topics, posts, and attachments.  You can view the full list on Migrate and choose your vBulletin version from the list of choices.
    Obviously, you will not be able to migrate any custom themes or custom modifications.  @ChristForums adds, “I wish I had known that the converter was so easy to use and migrate from Vbulletin 5.”
    5.  What are the channels for support? 
    Every active license comes with professional ticket support, which should always be your first source of contact.  @Markus Jung highlights “fast support” as the item he appreciates the most about his license.  You can also obtain help from the community forums, help guides, release notes, and other public resources. 
    If you’re not an IPS client yet, you can post in Pre-Sales forum or email sales@invisionpower.com. 
    4.  How do I prepare my community?
    The six admins that I interviewed offered several tips for new Invision Community owners.  Prior to the conversion, you should read through the converter package to see what will convert and redirect.  You should purchase other Invision Community apps in advance to fully convert vBulletin items as needed; not delete any old content since Invision Community includes an archive function; and not make drastic changes to allow members a chance to become accustomed to the new forum. 
    3.  What will happen to my traffic and URL redirects? 
    The free converter app will redirect your existing URLs.  This includes forums, topics, posts, member profiles, print view pages, archived content, attachments, and tags.  You need to leave your converter installed after migration to ensure the redirects will work.   
    AlexWebsites wrote, “the converter came with built-in redirects and I was able to redirect most of my traffic. Traffic recovered within a few months.”
    2. What are the server configuration and database requirements?    
    If you choose cloud, then Invision Community will manage the hosting. 
    If you choose on-premise, you can use the free ‘Get Ready’ compatibility file to check your server.  The latest version of Invision Community 4.4 requires:
    PHP 7.1.0 or higher (7.3.x is supported) MySQL 5.5.3 or higher (5.6.2 recommended).  1. How stable is the company? 
    Other companies lost their development talent. Other companies were bought and sold by multi-media conglomerates. Other companies have a history of lawsuits.
    Through it all, Charles, Lindy and Matt have been here since the beginning providing steady leadership to Invision Communities everywhere.  If you’re looking for stability, it’s nice to know you can rely on the same people who started the company.  For serious and professional vBulletin admins looking to transition, you know you’re not just buying into the software, but investing in the development team, staff, and platform for years to come. Ramsesx shared his personal story: “I always prefer the best for my community from where I earn my income.  An important aspect was the longtime outlook.  Invision Community gave me the feeling of being trustworthy, they are more than 17 years in the forum software market.” 
    It’s no wonder that so many successful vBulletin admins feel the same after moving to Invision Community.  You get stability, years of experience, a deep understanding of online communities, and a dedication to development that continues to innovate.  It’s time to bring your vBulletin community over to Invision Community! 
    Bookmark this page for future reference and download the Community Guide for experiences from real clients who converted from vBulletin.  Much appreciation to @AlexWebsites @cfish @Christforums @Markus Jung @Ramsesx @Steve Bullman for participating in the interviews.  
    - Joel R
    Community Guide vBulletin Migration to Invision Community.pdf
  23. Like
    Rikki reacted to HelenG for an entry, How I started my community   
    I'm only one month in to starting a new community and I've already learned a huge amount. I was a little apprehensive at first but I'm taking things one step at a time and I'm happy with how things are going so far.
    The points I'm going to raise are working for me but I'm a beginner and running a website of any description is new. Nothing here is guaranteed and I hope to receive comments from established community admins so I can continue to improve.

    The first thing I realised is that I wasn't actually starting a community but instead I'm going to be bringing new tools and ideas to an already existing one. My chosen subject is broad (Dogs) so there is already a well established real life community globally. My aim therefore is not to replicate already available content but to reach this community with unique content and encourage them to contribute their own. More on that later but before I could do that I needed something they could visit.

    The new community site
    Get Started
    You can spend days and weeks planning and writing business plans and these are all good things to do alongside everything else but they shouldn't stop you getting started. The only thing that really mattered to me was starting on the actual idea and to do that all I needed was a platform. You've probably already guessed but Invision Community was chosen for this as it offered multiple apps that would allow me to have both long form articles and forum content. There's also the monetisation options that appealed to me but I am not yet using. It's good to know they are there when I'm ready though. 
    I also considered Wordpress but it lacked the community tools I was already sold on.
    Rope in friends and family and use their skill sets
    I'm not scared to admit where I need help and as I have hit problems or things I don't know I have called in favours. I don't have a large budget for stock photography subscriptions so a friend is providing photos in exchange for attribution. My fiance is more technically minded so he has helped with some of the set up and help with Invision Community features is only a support ticket away.
    There is plenty of general information a quick web search away too but some topics are complex and I thought that if I could free up at least some of my time I can keep focussed on the direction. 
    Help can be as simple as nudging friends into posting new topics or comments to get some initial activity and momentum. It's also a good test to make sure you have everything set up with your registration process and identify some potential problems.
    These helpers are also now active members of the site of course so it's a two for one. I'm sure they'll be calling in return favours at some point but that's fine, they've earned it.
    Encourage all contributions even if you don't agree with them
    Coming from a primary school teaching background I see kids come up with lots of crazy and novel ideas all the time, they might sound silly but you never know, they may grow into something bigger. My aim is to foster a sense of community and belonging and people of all ages who have their ideas valued tend to stick around. If an idea doesn't work that's fine but you never know what will work so I'm trying lots of things and encouraging innovation. The forums are a great tool for this as everything doesn't need to be rigidly structured.
    Be passionate and confident about your subject matter
    Perhaps my top tip…If you don't value your own thoughts and actions then how can you expect others to? Show your enthusiasm and knock away negative thoughts and doubts. 
    Use all of your tools
    Once you've encouraged your initial core group of members, you need to keep them coming back. So far I've had success using the bulk mail feature for a monthly newsletter to rekindle the interest of early members who may no longer be as active. I was warned about bad email practices so I have our notification defaults set very loosely as I want to build trust by not spamming. Everything I send is opt-in and using the newsletter signup block I've been able to make this prominent but not obtrusive. I'm worried I might be missing out by not being aggressive enough with email but it's a risk I'm taking to hopefully get better long term members.
    Get involved with your member activities and conversations
    Join in with conversations on your community where it makes sense and be as active as possible. You're running a website but to do so you don't always need to be in front of a computer. Speak to your members face to face as well as through the keyboard. I've been going on local dog walks with clubs and other community groups which is a great chance to network and give your members and potential members the chance to see the people behind the website. If there are events or shows in your field get involved and spread the word verbally. I'm talking to dog owners face to face about behavioural issues and always in the back of my mind is the fact this could be discussed on the website to help others and build activity. Over time these "real world" relationships should also be represented on the website too.
    Don't get distracted
    I've got into the habit of using a reminders app to keep track of future things I want to do. It is tempting to start lots of things every time you have a new idea but that can take your mind off what is actually important right now. Don't forget about these ideas though, make a note and come back to them later.
    Approvals and applications for things can also take time. I found myself sometimes sitting around waiting for adsense accounts to be approved or Facebook apps to be verified for sign in. Don't let this downtime be unproductive.
    Keep writing new content
    What we have started as new community admins isn't easy, it's going to be a long haul so you need to be consistent and regular with updates. On that note I have a breed profile about Chow Chows to write.
    Thanks for listening to my ramblings and if you have any more tips please let me know in the comments.
    Helen is a year 3 international primary school teacher currently living in Slovakia. She loves dogs (of course), books, and reading whenever possible. She has travelled extensively for work, particularly in South East Asia and has experienced many amazing cultures. She is a qualified Zumba dance fitness instructor and is now building what she hopes to be an invaluable resource for dog owners.
    https://doglymail.com/
  24. Like
    Rikki reacted to Matt for an entry, Team Talk: Your favourite 4.4 feature?   
    Release parties at Invision Community are a fairly tame affair. You'd think after months of planning, coding and testing we'd want to cut loose and dance the night away.
    The reality is we send each other a few amusing GIFs in Slack and then wait for support tickets to start appearing while our developers crack their knuckles and prepare for bug reports to be filed.

    It's a nightmare trying to get a photo of our team, so here's a stock image. Just pretend it's us. That's me looking at a report of how much code Mark Wade has refused during reviews
    I did manage to find five minutes to ask the team what their favourite feature of 4.4 was.

    Here's what they said.
    Marc S
    Support, Guides and Keen Cyclist @Marc Stridgen
    I'm going to go with 'Post before registering', because it allows for more effective onboarding of new members on your site. People are much more likely to register after just having written a topic, then they are if they have to register before getting started. It also gives you the opportunity to see how many people are not actually registering, and maybe address that on the site.

    Ryan
    Developer, T3 support and reluctant AWS wrangler @Ryan Ashbrook
    My favorite 4.4 feature is the progressive web app settings. I now have our site pinned to my phones home screen for quick access, and use our site on mobile even more now that I can just hit the icon to pull up our site.

    Mark H
    Support, Beta Tester and remembers this when it was fields @Mark H
    While this isn’t “a” favorite feature, I most like the steady small improvements to Gallery in the 4.x series. Photography-centric sites should especially like the additions to extended EXIF data in 4.4 so that authors can provide the most detail about their submitted photos…. where it was taken, what camera, which lens, shutter speed and aperture, etc.

    Daniel
    Developer, T2 support and airport security fan @Daniel F
    As IPS4 consumer, I'm going to say that Lazy Loading and mobile create menu are my favorite enhancement.
    As community owner, I'm most excited about post before register and email advertisements.. That's going to bring the $$$

    Brandon
    Developer, Enterprise Support and proud of his thorough code reviews @bfarber
    My favorite change in 4.4 (besides the overall performance improvements, as I'm a geek for that sort of thing) is the overhauled Conversion experience (which we haven't even blogged about). We took converters and flipped them on their head for 4.4, so you now choose what software you want to convert from, what applications from that software you want to convert, fill in any required details, and the conversion process just launches and runs from beginning to end right then and there. You no longer need to convert each application and each type of data within each application individually, making for an easier and overall smoother experience.

    Stuart
    Developer, Conversion Specialist and PC enthusiast @Stuart Silvester
    This is actually hard to answer than it seems, there are so many great changes and features in 4.4. The combined performance improvements including HTTP/2 Push, More aggressive caching, SVG letter photos, lazy loading are definitely some of my favourites. After all, time is money. (A smaller favourite is the browser notification prompt change, especially with visiting as many customer sites as I do in Tier 2).

    Jim
    Support, Beta Tester and suspiciously quiet in staff chat @Jim M
    The communities I run are about cars and very heavily image based. Whether it's "I have an issue" or simple sharing of car builds, topics get image heavy very quickly and doing anything to improve moving throughout that topic more quickly is going to go far. I feel a lot of communities can relate and why lazy load of images is my favorite 4.4 feature.

    Jennifer
    Designer, Enterprise Theme Specialist, owner of several super powers @Jennifer M
    There are so many changes with 4.4 it's actually really hard to choose just one change that is my absolutely favorite. I would probably say a lot of the more micro features are my favorites. Colored usernames everywhere, lazy load for images, improved notifications experience, text or URLs for announcements, reordering of club tabs, ability to hide widgets/blocks from mobile etc. They are all quality of life improvements that I love and appreciate on so many levels.

    We're Steve Ballmer levels of excited about 4.4.

    It looks like Rikki's lazy loading is a clear winner. I'm not surprised, it's a real boost for page speed and reduces hosting costs. Personally I'm a fan of the progressive web app settings which, like Ryan, enables me to have our community on my phone's home page.

    Let us know what your favourites are below! 
  25. Like
    Rikki reacted to Matt for an entry, The incredible power of anonymity when growing your community   
    We attach a significant amount of personally identifiable data to our social media profiles daily.
    I regularly use social media to share photos of my kids and holidays. I post my personal thoughts on products I've used and TV shows I've watched. I'm even tagged in location-based check-ins.
    It's all there in my news feed for anyone to see.
    I'm not alone. More and more of us live our lives through the prism of social media. We share things we love, things we loathe and things that make us laugh.
    With just a few clicks, you can discover a lot of information about a person. More often than not, you can see where they work, where they live and what school they went to.
    Scrolling through their timeline often reveals their stance on hot topics such as gun control, the current President and other recent headline news items.
    This information follows you when you join a Facebook Group. Your past Tweets are always available to trawl through.

     
    Indeed, there may be some groups that you decide you cannot post in as people would be able to identify you. 
    This is particularly true for stigmatised conditions, such as financial help, illness and mental health.
    After all, if you were seeking help with a large amount of debt or managing an embarrassing medical condition, you wouldn't feel comfortable knowing that work colleagues, friends and family could read your posts.
    The benefit of anonymity for stigmatised topics
    "Forums can all offer some initial anonymity, a community, and information that geographically proximate others may not have. What stigma-related forums uniquely offer is that the anonymity protects those who are not ready to be publicly associated with sensitive topics; the community helps to neutralise the “spoilage” of identity that accompanies stigma." (1)
    Unlike social media where reams of personal data is willingly added, and which can identify you to other online users, forums allow you to add as much information as you are comfortable with.
    Support communities for mental health and illness flourish using forums for this reason. An individual may feel devalued in society and unwilling to share their condition over social media.

     
    "Nowadays people can both avoid and proactively cope with this devaluation by turning to online forums populated by others who share the same devalued group membership." (1)
    Forums offer a safe space for these individuals to seek and receive support from others without disclosing large amounts of identifiable data.
    Allowing a level of anonymity encourages more people to register and over time, they will develop ties with other users.
    For an individual with a stigmatized condition, a forum may be a real life-line in coping with the condition as face-to-face support is often limited.
    Adrial Dale, who owns Herpes Opportunity agrees.
    "In order for us to truly be able to work through the shame that stigma can trigger, it's absolutely vital for us to feel safe to open up and tell all. Through opening up, we not only get to share with an understanding and compassionate community (which normalizes our shared experiences), but we're also able to begin to release what has felt like our own solitary burden to bear. 
    Then a magical thing can happen ... an alchemical process that transforms shame into an opportunity for connection. An opportunity for us to be accepted for who we are *behind* the thick wall of shame. And ultimately, an opportunity to accept ourselves.
    Especially in these days of the internet not feeling so private (even in places where it absolutely should be), having true privacy and anonymity is paramount for communities like Herpes Opportunity. Anything other than that is grounds for paranoia and holding back from sharing ourselves. (In fact, just the other day someone messaged me asking "Are private messages really private?") Fear can lead to closing ourselves off, which can lead to isolation and paranoia, which can lead to a downward spiral of self-loathing and depression. On the other hand, safety, connection and compassion creates an an okayness with the nitty-grittiness of what it means to be human."
    The benefit of expressing a new identity
    "People may strategically express identities when they think they will not be punished, and/or connect them to an audience that is valued." (1)
    It is arguably true that not so many years ago, tech-related communities were very much male-dominated, with female contributions valued less.
    Forums allow a way to create a new identity that is either gender-neutral thus allowing the male users to assume a gender, or overtly male to ensure their contributions are evaluated on merit, and not with any gender bias.

     
    Christopher Marks who owns Nano-Reef has seen this first hand.
    "During a discussion with a women’s group in our generally male dominant hobby, a number of women had expressed the benefit of having an anonymous username and profile when asking for help and advice on forums, they receive equal help without the unfortunate gender bias or belittling that can sometimes happen in real life when seeking the same help in person."
    Invision Community's Jennifer has also experience of this on her own community; RPG Initiative.
    "RPG Initiative is a community for all roleplayers. We focus on all text-based roleplaying forms that are hosted on the internet. We encourage roleplayers to find each other, discuss roleplay and grow as collaborative writers here at the Initiative in a safe environment."
    Jennifer relies on, and encourages anonymity. She knows that because her site is predominately female, some female users identify as male to increase the chances of getting others to collaborate with them.
    "Male players are rare, in fact, I recently ran a poll on my site and of those that responded to it less than 15% of them are male (or identify as such). So this gets them more attention and in turn, more people that want to write with them."
    Jennifer explains how anonymity is critical to her site's growth.
    "Anonymity is a difficult thing to accomplish in a small niche like mine, but it's sort of like a small town where everyone knows everyone, and they likely know all of your secrets. So enforcing rules to preserve anonymity is really important to my community and me. This includes prohibiting the "naming of names" or the "site" that the drama is coming from when seeking for advice or help. This doesn't negate that people may know the existing situation or people involved because they are also involved or know some of the people involved, but it helps cut down on the drama and the spread of negativity and false information about people."
    With a forum community, you can truly be who you want to be.
    This is not so with social media where others can create bias based on your gender, looks or topical preferences.
    Together, together
    "In her early work, Turkle argued that the internet provided myriad positive opportunities for self-transformation, but more recently, she argues that the explosion in social media options has led us to develop superficial, emotionally lazy but instantly available virtual relationships." (1)
    It's hard to argue against this statement when you consider the content that predominates social media. And often an endless stream of self-focused content.
    "Indeed, we provide clear evidence that online forums afford users a way of being genuinely “together, together”, as opposed to what Turkle calls “alone together.”(1)
    The bottom line is that it has been proven that allowing a degree on anonymity increases engagement across all niches, but especially those that are built to support those with stigmatised conditions. These forums have a greater sense of community and depth than those built on social media.
    When you allow your members to take back control of their privacy, you are empowering them to make decisions about what to share.
    Given how eroded our privacy is in our modern always-connected world, this is a precious gift.
    If you are looking to create a new community then consider this before choosing your community platform.
    References:
    1: https://www.sciencedirect.com/science/article/pii/S074756321500268X
    2: https://www.tandfonline.com/doi/full/10.1080/10410236.2017.1339370
×
×
  • Create New...