Jump to content

Rikki

Members
  • Posts

    24,413
  • Joined

  • Last visited

  • Days Won

    84

Reputation Activity

  1. Like
    Rikki got a reaction from SeNioR- for a blog 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.
  2. Like
    Rikki got a reaction from Kacperrr_ for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  3. Like
    Rikki got a reaction from dhpunkt for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  4. Like
    Rikki got a reaction from A Zayed for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  5. Thanks
    Rikki got a reaction from SoloInter for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  6. Like
    Rikki got a reaction from S. Rose for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  7. Like
    Rikki got a reaction from Mateusz Manikowski for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  8. Like
    Rikki got a reaction from GazzaGarratt for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  9. Like
    Rikki got a reaction from Zdeněk Tůma for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  10. Thanks
    Rikki got a reaction from sofos for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  11. Like
    Rikki got a reaction from Nigel Moore for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

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

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  13. Like
    Rikki got a reaction from Interferon for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  14. Like
    Rikki got a reaction from OptimusBain for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  15. Like
    Rikki got a reaction from LiquidFractal for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  16. Like
    Rikki got a reaction from kmk for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  17. Thanks
    Rikki got a reaction from Silnei L Andrade for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  18. Like
    Rikki got a reaction from Miss_B for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  19. Like
    Rikki got a reaction from uA_Y_C_A for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  20. Like
    Rikki got a reaction from Marc Stridgen for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  21. Like
    Rikki got a reaction from SeNioR- for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  22. Thanks
    Rikki got a reaction from Ilya Hoilik for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  23. Like
    Rikki got a reaction from bEARS for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  24. Thanks
    Rikki got a reaction from Ibai for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  25. Like
    Rikki got a reaction from Apfelstrudel for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  26. Like
    Rikki got a reaction from Maxxius for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  27. Like
    Rikki got a reaction from shahed for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  28. Like
    Rikki got a reaction from Thomas. for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  29. Thanks
    Rikki got a reaction from IPCommerceFan for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  30. Like
    Rikki got a reaction from SUBRTX for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  31. Like
    Rikki got a reaction from Chris Anderson for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  32. Like
    Rikki got a reaction from sobrenome for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  33. Thanks
    Rikki got a reaction from crmarks for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  34. Like
    Rikki got a reaction from AlexWebsites for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  35. Like
    Rikki got a reaction from ASTRAPI for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  36. Like
    Rikki got a reaction from Ramsesx for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  37. Like
    Rikki got a reaction from Sonya* for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  38. Like
    Rikki got a reaction from shiobi for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  39. Like
    Rikki got a reaction from Noble~ for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  40. Like
    Rikki got a reaction from BariatricPal for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  41. Thanks
    Rikki got a reaction from SammyS for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  42. Like
    Rikki got a reaction from Yamamura for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  43. Like
    Rikki got a reaction from marklcfc for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  44. Like
    Rikki got a reaction from opentype for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  45. Like
    Rikki got a reaction from Real Hal9000 for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  46. Like
    Rikki got a reaction from Jordan Miller for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

     
    We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  47. Like
    Rikki got a reaction from Ryan Ashbrook for a blog entry, Web push notifications, native sharing & offline support   
    As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device.
    Web push notifications
    For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices.
    In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep.
    We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications.

    Choosing push notifications
    For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types.

    Push notifications enabled
    Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade.
    Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum.

    Grouped push notifications
    And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out.
    We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone.
    On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance.
    Splash Screen Images
    When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app.
     

    Sharing using native share options
    Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note.

    Offline support
    With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community.

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

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  51. Like
    Rikki got a reaction from B_U_R_I for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  52. Like
    Rikki got a reaction from Pescao6 for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  53. Like
    Rikki reacted to Andy Millne for a blog entry, 4.5: Sign in with Apple   
    Since the feature was announced at last year’s World Wide Developer Conference (WWDC) we have received lots of requests to implement Sign in with Apple in Invision Community. We’re pleased to announce that as of 4.5 this is now available.
    You will need a paid Apple developer account to use it but once enabled users will be able to sign in using their Apple ID and all the convenience that brings. Touch ID and Face ID is supported natively where available and works across all your devices.

    Choose to share or hide your email address
    Isn’t it just another login button?
    Sign in with Apple is built on similar technologies as other login buttons such as those already available in Invision Community from Facebook, Google and Microsoft. The difference is Apple’s unique focus on privacy. On certain community types users can be reluctant to sign up when they fear they need to disclose lots of personal details. Every community is different so allowing your users to share as little or as much info as they like could be important to your success. Apple have stated that no user tracking will take place in contrast to other services where this forms a part of their business model.
    When signing in with their Apple ID the user can choose whether or not to share their real email address with your community. If the user chooses to hide their email address then your community will receive a relay email address that will forward to their real address. The email address used is unique to your community so the user can retain control.
    Can users link their existing Invision Community accounts?
    Yes! If a user signs in using the Apple button and shares their real email address, then providing they already have an account on your community they will be prompted to link their account in the same way as other social login buttons. They can also link an existing account from their account settings. If linking from account settings then the email addresses used do not need to match.
    Sign in with Apple is already enabled here on our community and is available in the 4.5 beta available to download now.
  54. Like
    Rikki got a reaction from mydickisbig for a blog 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.
  55. Like
    Rikki got a reaction from Mandalala for a blog 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.
  56. Thanks
    Rikki got a reaction from media for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  57. Like
    Rikki got a reaction from Firdavs Khaydarov for a blog 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.
  58. Like
    Rikki got a reaction from Silnei L Andrade for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  59. Like
    Rikki got a reaction from PANL for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  60. Thanks
    Rikki got a reaction from andavis for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  61. Like
    Rikki got a reaction from crmarks for a blog 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.
  62. Like
    Rikki got a reaction from elk7 for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  63. Like
    Rikki got a reaction from Bluto for a blog 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.
  64. Like
    Rikki got a reaction from AlexWright for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  65. Like
    Rikki got a reaction from Alzar for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  66. Thanks
    Rikki got a reaction from Spanner for a blog 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.
  67. Thanks
    Rikki got a reaction from Spanner for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  68. Thanks
    Rikki got a reaction from Abies for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  69. Like
    Rikki got a reaction from -RAW- for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  70. Thanks
    Rikki got a reaction from Andrey S for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  71. Like
    Rikki got a reaction from Teascu Dorin for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  72. Like
    Rikki got a reaction from Teascu Dorin for a blog 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.
  73. Like
    Rikki got a reaction from The Old Man for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  74. Like
    Rikki got a reaction from Kjell Iver Johansen for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  75. Like
    Rikki got a reaction from Foolboy for a blog 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.
  76. Like
    Rikki got a reaction from shahed for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  77. Like
    Rikki got a reaction from shahed for a blog 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.
  78. Like
    Rikki got a reaction from kmk for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  79. Like
    Rikki got a reaction from levsha for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  80. Like
    Rikki got a reaction from sobrenome for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  81. Like
    Rikki got a reaction from Bernardo Rezende for a blog 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.
  82. Like
    Rikki got a reaction from Emanoel for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  83. Like
    Rikki got a reaction from Emanoel for a blog 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.
  84. Like
    Rikki got a reaction from Brian A. for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  85. Like
    Rikki got a reaction from Sheffielder for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  86. Like
    Rikki got a reaction from Adlago for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  87. Like
    Rikki got a reaction from PrettyPixels for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  88. Like
    Rikki got a reaction from BariatricPal for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  89. Like
    Rikki got a reaction from McAtze for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  90. Like
    Rikki got a reaction from StormyWays13 for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  91. Thanks
    Rikki got a reaction from SammyS for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  92. Like
    Rikki got a reaction from aXenDev for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  93. Like
    Rikki got a reaction from Meddysong for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  94. Like
    Rikki got a reaction from rnorth6920 for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  95. Confused
    Rikki got a reaction from Yamamura for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  96. Like
    Rikki got a reaction from Bluto for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  97. Like
    Rikki got a reaction from Adriano Faria for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  98. Like
    Rikki got a reaction from Jim M for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  99. Like
    Rikki got a reaction from modified for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  100. Like
    Rikki got a reaction from ASTRAPI for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  101. Like
    Rikki got a reaction from Hatsu for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  102. Like
    Rikki got a reaction from SoloInter for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  103. Like
    Rikki got a reaction from DawPi for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  104. Like
    Rikki got a reaction from Miss_B for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  105. Like
    Rikki got a reaction from MMXII for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  106. Like
    Rikki got a reaction from Real Hal9000 for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  107. Like
    Rikki got a reaction from Sonya* for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  108. Thanks
    Rikki got a reaction from Derek M. for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  109. Thanks
    Rikki got a reaction from Matt for a blog entry, 4.5: Introducing our updated default theme   
    If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
    With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version.
    In this entry, I want to talk a little about some of the design decisions that went into building the new theme.
    Goals
    Redesigning for the sake of it is never a good idea, so we first laid out what we wanted to achieve:
    A brighter UI with more saturation & contrast and simpler overall color scheme Improved typography Better, more consistent, spacing around and between elements, especially on mobile Better logical grouping of sections of each page Reducing underutilized links/buttons on the page and finding alternative ways of making them available Improving how post states are displayed Modernizing and enhancing the underlying code that powers the default theme Let's talk a little about each of these.
     
    Brighter UI
    The most obvious change will be that our default colors are brighter and more saturated than before. Before making any changes, we first created a color scale for both neutrals and the brand color (blue, of course). This gave us a flexible but consistent palette of colors to choose from, with appropriate contrast built in. Neutrals have a touch of blue too to avoid seeming washed out.
    We've simplified the style, in particular reducing reliance on background colors to differentiate sections within cards (a card essentially being an ipsBox, for those who are familiar with our framework). Instead, we use spacing, borders and appropriate typography to achieve visual separation.

    Brighter default colors
     

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

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

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

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

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

    Calendar header

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

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

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

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

    Mobile post statuses
     
    Modernizing the underlying code
    I wrote about the technical improvements behind the theme in a previous entry. If you're a theme designer or edit the theme for your own community, go and check it out now!
     
    Wrapping up
    As well as these large-scale concepts, you'll notice many other smaller enhancements as you start using the new theme.
    I've shown some snippets of pages in the screenshots above, but I've included some full-page views below so you can see the overall aesthetic and how these pieces fit together.
    Modernizing and refreshing our default theme has been needed for some time, but we view this as just a stepping stone to future work that will be reserved for a major version bump, and we're excited to figure out where we go next.
     
    Screenshots
      
    Desktop forum views (click to expand)
     
        
    Mobile forum views (click to expand)
     
     
    Activity streams & messenger (click to expand)
     
  110. Like
    Rikki got a reaction from Rhett for a blog 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.
  111. Like
    Rikki got a reaction from SC36DC for a blog 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.
  112. Like
    Rikki got a reaction from -RAW- for a blog 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.
  113. Like
    Rikki got a reaction from SoloInter for a blog 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.
  114. Like
    Rikki got a reaction from ASTRAPI for a blog 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.
  115. Thanks
    Rikki got a reaction from levsha for a blog 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.
  116. Thanks
    Rikki got a reaction from TAMAN for a blog 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.
  117. Like
    Rikki got a reaction from The Old Man for a blog 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.
  118. Like
    Rikki got a reaction from Pete T for a blog 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.
  119. Like
    Rikki got a reaction from sobrenome for a blog 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.
  120. Like
    Rikki got a reaction from PrettyPixels for a blog 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.
  121. Like
    Rikki got a reaction from Lisownik for a blog 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.
  122. Like
    Rikki got a reaction from Miss_B for a blog 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.
  123. Like
    Rikki got a reaction from stoo2000 for a blog 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.
  124. Like
    Rikki got a reaction from Davyc for a blog 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.
  125. Thanks
    Rikki got a reaction from Abies for a blog 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.
  126. Like
    Rikki got a reaction from McAtze for a blog 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.
  127. Like
    Rikki got a reaction from DejaVu24 for a blog 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.
  128. Like
    Rikki got a reaction from Yamamura for a blog 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.
  129. Like
    Rikki got a reaction from uA_Y_C_A for a blog 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.
  130. Like
    Rikki got a reaction from DawPi for a blog 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.
  131. Like
    Rikki got a reaction from Meddysong for a blog 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.
  132. Like
    Rikki got a reaction from aXenDev for a blog 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.
  133. Like
    Rikki got a reaction from Maxxius for a blog 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.
  134. Like
    Rikki got a reaction from Sonya* for a blog 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.
  135. Thanks
    Rikki got a reaction from LaCollision for a blog 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.
  136. Like
    Rikki got a reaction from rnorth6920 for a blog 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.
  137. Like
    Rikki got a reaction from Ilya Hoilik for a blog 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.
  138. Like
    Rikki got a reaction from GTServices for a blog 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.
  139. Like
    Rikki got a reaction from Matt for a blog 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.
  140. Like
    Rikki got a reaction from We7dy for a blog 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.
  141. Like
    Rikki got a reaction from Merojaan for a blog 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.
  142. Like
    Rikki got a reaction from elonegenio for a blog 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.
  143. Like
    Rikki got a reaction from Heverus for a blog 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.
  144. Confused
    Rikki got a reaction from Fxlx for a blog 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.
  145. Like
    Rikki got a reaction from BomAle for a blog 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.
  146. Like
    Rikki got a reaction from Messebau for a blog 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.
  147. Haha
    Rikki got a reaction from Ramsesx for a blog 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.
  148. Sad
    Rikki got a reaction from LemonZ for a blog 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.
  149. Like
    Rikki got a reaction from Alexis Compain for a blog 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.
  150. Like
    Rikki got a reaction from MeMaBlue for a blog 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.
  151. Like
    Rikki got a reaction from Emanoel for a blog 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.
  152. Like
    Rikki got a reaction from Darrien for a blog 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.
  153. Like
    Rikki got a reaction from Canindia for a blog 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.
  154. Like
    Rikki got a reaction from Cyboman for a blog 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.
  155. Like
    Rikki got a reaction from gavpedz for a blog 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.
  156. Like
    Rikki got a reaction from Tomasz Nowak_59903 for a blog 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.
  157. Like
    Rikki got a reaction from Whiskey Bizness for a blog 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.
  158. Like
    Rikki got a reaction from espacemusculation for a blog 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.
  159. Like
    Rikki got a reaction from Hisashi for a blog 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.
  160. Like
    Rikki got a reaction from AlexJ for a blog 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.
  161. Like
    Rikki got a reaction from Mitchell Higgins for a blog 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.
  162. Like
    Rikki got a reaction from T-MIKE for a blog 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.
  163. Like
    Rikki got a reaction from McArtemon for a blog 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.
  164. Like
    Rikki got a reaction from Jujuwar for a blog 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.
  165. Like
    Rikki got a reaction from A Zayed for a blog 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.
  166. Like
    Rikki got a reaction from SJ77 for a blog 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.
  167. Like
    Rikki got a reaction from xtech for a blog 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.
  168. Like
    Rikki got a reaction from Iwooo for a blog 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.
  169. Like
    Rikki got a reaction from Maxxius for a blog 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.
  170. Like
    Rikki got a reaction from NoGi for a blog 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.
  171. Like
    Rikki got a reaction from Ioannis D for a blog 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.
  172. Like
    Rikki got a reaction from simonle for a blog 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.
  173. Like
    Rikki got a reaction from klierik for a blog 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.
  174. Like
    Rikki got a reaction from raza ali for a blog 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.
  175. Like
    Rikki got a reaction from scaz for a blog 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.
  176. Like
    Rikki got a reaction from IPB3 for a blog 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.
  177. Like
    Rikki got a reaction from Farook for a blog 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.
  178. Like
    Rikki got a reaction from motomac for a blog 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.
  179. Like
    Rikki got a reaction from Teascu Dorin for a blog 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.
  180. Like
    Rikki got a reaction from TSP for a blog 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.
  181. Like
    Rikki got a reaction from Foolboy for a blog 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.
  182. Like
    Rikki got a reaction from BariatricPal for a blog 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.
  183. Like
    Rikki got a reaction from Daddy for a blog 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.
  184. Like
    Rikki got a reaction from The Old Man for a blog 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.
  185. Like
    Rikki got a reaction from SeNioR- for a blog 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.
  186. Like
    Rikki got a reaction from uA_Y_C_A for a blog 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.
  187. Like
    Rikki got a reaction from Markus Jung for a blog 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.
  188. Like
    Rikki got a reaction from Thomas. for a blog 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.
  189. Like
    Rikki got a reaction from mark007 for a blog 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.
  190. Like
    Rikki got a reaction from sudo for a blog 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.
  191. Like
    Rikki got a reaction from LiquidFractal for a blog 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.
  192. Like
    Rikki got a reaction from kysil for a blog 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.
  193. Like
    Rikki got a reaction from Tom_K for a blog 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.
  194. Like
    Rikki got a reaction from Setsumi for a blog 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.
  195. Like
    Rikki got a reaction from PrettyPixels for a blog 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.
  196. Like
    Rikki got a reaction from hmikko for a blog 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.
  197. Like
    Rikki got a reaction from Chris Anderson for a blog 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.
  198. Like
    Rikki got a reaction from sobrenome for a blog 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.
  199. Like
    Rikki got a reaction from Orlando Delcid for a blog 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.
  200. Like
    Rikki got a reaction from Octavian Dima for a blog 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.
  201. Like
    Rikki got a reaction from Robiss767 for a blog 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.
  202. Like
    Rikki got a reaction from Chris59 for a blog 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.
  203. Like
    Rikki got a reaction from BomAle for a blog 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.
  204. Like
    Rikki got a reaction from Wonster for a blog 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.
  205. Like
    Rikki got a reaction from Square Wheels for a blog 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.
  206. Like
    Rikki got a reaction from nodle for a blog 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.
  207. Like
    Rikki got a reaction from Meddysong for a blog 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.
  208. Like
    Rikki got a reaction from RObiN-HoOD for a blog 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.
  209. Like
    Rikki got a reaction from KentT for a blog 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.
  210. Like
    Rikki got a reaction from naXe90 for a blog 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.
  211. Like
    Rikki got a reaction from onlyME for a blog 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.
  212. Like
    Guest
    Rikki got a reaction from Guest for a blog 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.
  213. Like
    Rikki got a reaction from pidje for a blog 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.
  214. Like
    Rikki got a reaction from openfire for a blog 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.
  215. Like
    Rikki got a reaction from TAMAN for a blog 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.
  216. Like
    Rikki got a reaction from Simon Woods for a blog 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.
  217. Like
    Rikki got a reaction from media for a blog 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.
  218. Like
    Rikki got a reaction from shahed for a blog 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.
  219. Like
    Rikki got a reaction from Real Hal9000 for a blog 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.
  220. Like
    Rikki got a reaction from O9C4 for a blog 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.
  221. Like
    Rikki got a reaction from Spanner for a blog 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.
  222. Like
    Rikki got a reaction from BN_IT_Support for a blog 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.
  223. Like
    Rikki got a reaction from ric4rdo for a blog 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.
  224. Like
    Rikki got a reaction from Jim M for a blog 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.
  225. Like
    Rikki got a reaction from Apfelstrudel for a blog 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.
  226. Like
    Rikki got a reaction from Dennis_87 for a blog 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.
  227. Like
    Rikki got a reaction from LaCollision for a blog 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.
  228. Like
    Rikki got a reaction from Michael R for a blog 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.
  229. Like
    Rikki got a reaction from Charles for a blog 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.
  230. Like
    Rikki got a reaction from GriefCode for a blog 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.
  231. Like
    Rikki got a reaction from Adriano Faria for a blog 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.
  232. Like
    Rikki got a reaction from Ilya Hoilik for a blog 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.
  233. Like
    Rikki got a reaction from Ryan Ashbrook for a blog 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.
  234. Like
    Rikki got a reaction from Rhett for a blog 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.
  235. Like
    Rikki got a reaction from Daniel F for a blog 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.
  236. Like
    Rikki got a reaction from Subdreamer for a blog 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.
  237. Like
    Rikki got a reaction from Frontpage for a blog 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.
  238. Like
    Rikki got a reaction from The Old Man for a blog 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.
  239. Like
    Rikki got a reaction from sobrenome for a blog 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.
  240. Like
    Rikki got a reaction from Ilya Hoilik for a blog 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.
  241. Like
    Rikki got a reaction from MADMAN32395 for a blog 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.
  242. Like
    Rikki got a reaction from .Matt. for a blog 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.
  243. Like
    Rikki got a reaction from j4ss for a blog 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.
  244. Like
    Rikki got a reaction from grande_ecks for a blog 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.
  245. Like
    Rikki got a reaction from IveLeft... for a blog 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.
  246. Like
    Rikki got a reaction from Patreon Lukazuki for a blog 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.
×
×
  • Create New...