Jump to content

Rikki

Members
  • Posts

    24,413
  • Joined

  • Last visited

  • Days Won

    84

Reputation Activity

  1. Like
    Rikki reacted to Ehren for a blog entry, Invision Community 5: Live Topic Improvements   
    Live Topics in Invision Community 5
    Introduced last year, Live Topics are an innovative way to host live chat and question-and-answer sessions, complete with the option for live video integration. Live Topics effortlessly transform these events into permanent forum topics once the event concludes, allowing your members to not only interact in real-time with the rest of your community, but also continue the conversation far beyond the events conclusion.
    As part of Invision Community 5, Live Topics will ship with a brand new design, rich-text editors and dynamic reactions. Let’s take a look at all three improvements, starting with the new design.
     

    Full-screen, 3 column layout
    When viewing a live topic, you’ll be taken to a new, minimal, full-screen, 3 column layout which provides plenty of space to simultaneously view your video, question-and-answer list, and live chat columns all at once. The width of the video can easily be adjusted using a simple drag and drop handle, allowing your members to shift their focus between the video or the question-and-answer list depending on the moment.
    Resize.mp4
     
    The second column holds a list of dynamic question-and-answer discussions, while the third column boasts a redesigned chat area that more closely resemble an app-like experience.
      Questions-and-chat.mp4  
    For smaller devices such as tablets and mobiles, the video is always visible at the top of the page. The question-and-answer list and live chat collapse into their own tabbed area to conserve space.
    Mobile.mp4
     
     

    Rich-text editors
    Text fields in Live Topics have been upgraded to CKEditor, allowing for greater flexibility when it comes to formatting text or posting emoji’s.
     
    Richtext.mp4
     
     
    Reactions
    Reactions have been added to live topics for both the question feed and the live chat. Reactions update dynamically in real-time, offering valuable insights into the content your community deems significant in the moment.
    Reactions.mp4
     
    A lot of thought has gone into transforming Live Topics into a much more user friendly experience. The refreshed, modern design combined with new real-time features make Live Topics a fantastic solution for hosting real-time community events, and we're looking forward to shipping these updates alongside Invision Community 5 later this year.
     
     
  2. Like
    Rikki got a reaction from SeNioR- for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  3. 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.
  4. Thanks
    Rikki got a reaction from PrettyPixels for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  5. Like
    Rikki reacted to Matt for a blog entry, Live Topics: A first look   
    We're excited to bring you a first look at our new and innovative Invision Community feature: Live Topics.
    Live Topics is a hosted live chat and question-and-answer event that is converted into a forum topic upon completion. It combines the fun and togetherness of a live event with the permanence of a forum topic allowing you to continue the conversation long after the event has ended.
    Your event doesn't have to just be text based! Live Topics allows you to feature a live video for your attendees. You can present to your attendees while fellow hosts select messages from the attendee chat to raise as questions for answers via the video or message replies from other attendees. 
    Once the live event has ended, the questions and answers are converted into a permanent forum topic. Additional replies to the forum topic can reply to a specific question raised in the live event.

    If you choose to answer on the live video, you can mark the timestamp of the answer, allowing members to jump to that segment of the video from the forum topic.

    We're thrilled to finally share details of this new and exciting Invision Community feature. Although this is just a first look at Live Topics, we will follow this blog up with others drilling into the details, and multiple use cases Live Topics offers.
    Live Topics is unique to Invision Community and will soon be available to selected cloud plans.
  6. Like
    Rikki reacted to Daniel F for a blog entry, Introducing GraphQL for Invision Community   
    We are excited to announce that the Invision Community GraphQL API is now available.
    This blog takes you through what GraphQL is and what makes it better than existing APIs present in Invision Community. It does get a bit technical, but you don't need to be a developer to appreciate how GraphQL will make life easier for those that do develop.
    What is GraphQL?
    GraphQL describes itself as a query language for APIs that gives clients the power to ask for precisely what is needed and nothing more.
    GraphQL was created by Facebook in 2012 and is now an open-source project governed by the GraphQL Foundation, which operates independently of Facebook.
    What makes GraphQL better than existing REST APIs?
    GraphQL has several advantages over the existing REST API present in Invision Community, and these include:
    Flexibility: GraphQL allows clients to request only the data they need, reducing over-fetching or under-fetching data. Getting data from a REST API often means receiving many fields and values you don't need to complete the operation you're creating.
    Versatility: GraphQL can query multiple databases or APIs, making it a more versatile solution than REST, which often requires multiple endpoints for multiple data types.
    Strong Typing: GraphQL has a robust type system, making it easier to understand the capabilities of an API and catch errors early in the development process.
    Better Performance: By allowing the client to request only the data it needs, GraphQL can improve the performance of an application compared to REST, which often returns more data than necessary.
    Easier to evolve: The schema-based nature of GraphQL allows for more straightforward and less-breaking changes to the API compared to REST.
    Let's look at an example
    You're building a dashboard that uses Invision Community data for your Node.js application that shows the latest topics, latest registered members and calendar events. With the REST API, you need to make three requests to get all the data you need. With GraphQL, you can fetch the exact data you need with a single request.

    Modern Web Development
    GraphQL is now the standard for modern web development, including building mobile apps. A modern web app has a "front-end" and a "back-end".
    The front-end refers to the user-facing part of the web application. The front-end is typically written in client-side languages such as HTML, CSS, and JavaScript and is responsible for rendering the user interface and handling user interactions. It communicates with the back-end to retrieve and display data.
    The back-end refers to the server-side part of the web application. The back-end is typically written in server-side languages such as PHP, and is responsible for performing business logic, managing data, and serving API responses to the front-end.
    Using GraphQL as the interface between the front-end and back-end, the development and deployment of each component can be done independently, improving the overall efficiency and scalability of the application.
    At Invision Community, we know that some clients use REST to pull data from Invision Community for use in bespoke web and mobile apps. So we hope you're even more excited about the possibilities with GraphQL.
    A list with all currently available queries, mutators and data types can be found in our developer documentation section.

    Extending Invision Community Functionality
    Of course, you also have full access to the GraphQL API in the Invision Community framework, so you can use GraphQL inside your controllers to run your queries, which has the advantage that you won't need to worry about future changes to the API. 
    In addition, we have also created a GraphQL template plugin, which can be utilized inside templates to fetch any data.
    This is a more technology-heavy blog than usual. The main takeaway is that we continue to invest in ways to allow your Invision Community data to be used by your own applications. GraphQL makes that job a lot easier and much more efficient.
    Let me know if you have any questions!
  7. 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!
  8. Like
    Rikki reacted to Matt for a blog entry, SEO: Improving crawling efficiency   
    No matter how good your content is, how accurate your keywords are or how precise your microdata is, inefficient crawling reduces the number of pages Google will read and store from your site.
    Search engines need to look at and store as many pages that exist on the internet as possible. There are currently an estimated 4.5 billion web pages active today. That's a lot of work for Google.
    It cannot look and store every page, so it needs to decide what to keep and how long it will spend on your site indexing pages.
    Right now, Invision Community is not very good at helping Google understand what is important and how to get there quickly. This blog article runs through the changes we've made to improve crawling efficiency dramatically, starting with Invision Community 4.6.8, our November release.

    The short version
    This entry will get a little technical. The short version is that we remove a lot of pages from Google's view, including user profiles and filters that create faceted pages and remove a lot of redirect links to reduce the crawl depth and reduce the volume of thin content of little value. Instead, we want Google to focus wholly on topics, posts and other key user-generated content.
    Let's now take a deep dive into what crawl budget is, the current problem, the solution and finally look at a before and after analysis. Note, I use the terms "Google" and "search engines" interchangeably. I know that there are many wonderful search engines available but most understand what Google is and does.
    Crawl depth and budget
    In terms of crawl efficiency, there are two metrics to think about: crawl depth and crawl budget. The crawl budget is the number of links Google (and other search engines) will spider per day. The time spent on your site and the number of links examined depend on multiple factors, including site age, site freshness and more. For example, Google may choose to look at fewer than 100 links per day from your site, whereas Twitter may see hundreds of thousands of links indexed per day.
    Crawl depth is essentially how many links Google has to follow to index the page. The fewer links to get to a page, is better. Generally speaking, Google will reduce indexing links more than 5 to 6 clicks deep.
    The current problem #1: Crawl depth
    A community generates a lot of linked content. Many of these links, such as permalinks to specific posts and redirects to scroll to new posts in a topic, are very useful for logged in members but less so to spiders. These links are easy to spot; just look for "&do=getNewComment" or "&do=getLastComment" in the URL. Indeed, even guests would struggle to use these convenience links given the lack of unread tracking until logged in.  Although they offer no clear advantage to guests and search engines, they are prolific, and following the links results in a redirect which increases the crawl depth for content such as topics.
    The current problem #2: Crawl budget and faceted content
    A single user profile page can have around 150 redirect links to existing content. User profiles are linked from many pages. A single page of a topic will have around 25 links to user profiles. That's potentially 3,750 links Google has to crawl before deciding if any of it should be stored. Even sites with a healthy crawl budget will see a lot of their budget eaten up by links that add nothing new to the search index. These links are also very deep into the site, adding to the overall average crawl depth, which can signal search engines to reduce your crawl budget.
    Filters are a valuable tool to sort lists of data in particular ways. For example, when viewing a list of topics, you can filter by the number of replies or when the topic was created. Unfortunately, these filters are a problem for search engines as they create faceted navigation, which creates duplicate pages.

    The solution
    There is a straightforward solution to solve all of the problems outlined above.  We can ask that Google avoids indexing certain pages. We can help by using a mix of hints and directives to ensure pages without valuable content are ignored and by reducing the number of links to get to the content. We have used "noindex" in the past, but this still eats up the crawl budget as Google has to crawl the page to learn we do not want it stored in the index.
    Fortunately, Google has a hint directive called "nofollow", which you can apply in the <a href> code that wraps a link. This sends a strong hint that this link should not be read at all. However, Google may wish to follow it anyway, which means that we need to use a special file that contains firm instructions for Google on what to follow and index.
    This file is called robots.txt. We can use this file to write rules to ensure search engines don't waste their valuable time looking at links that do not have valuable content; that create faceted navigational issues and links that lead to a redirect.
    Invision Community will now create a dynamic robots.txt file with rules optimised for your community, or you can create custom rules if you prefer.

    The new robots.txt generator in Invision Community
    Analysis: Before and after
    I took a benchmark crawl using a popular SEO site audit tool of my test community with 50 members and around 20,000 posts, most of which were populated from RSS feeds, so they have actual content, including links, etc. There are approximately 5,000 topics visible to guests.
    Once I had implemented the "nofollow" changes, removed a lot of the redirect links for guests and added an optimised robots.txt file, I completed another crawl.
    Let's compare the data from the before and after.
    First up, the raw numbers show a stark difference.

    Before our changes, the audit tool crawled 176,175 links, of which nearly 23% were redirect links. After, just 6,389 links were crawled, with only 0.4% being redirection links. This is a dramatic reduction in both crawl budget and crawl depth. Simply by guiding Google away from thin content like profiles, leaderboards, online lists and redirect links, we can ask it to focus on content such as topics and posts.

    Note: You may notice a large drop in "Blocked by Robots.txt" in the 'after' crawl despite using a robots.txt for the first time. The calculation here also includes sharer images and other external links which are blocked by those sites robots.txt files. I added nofollow to the external links for the 'after' crawl so they were not fetched and then blocked externally.

    As we can see in this before, the crawl depth has a low peak between 5 and 7 levels deep, with a strong peak at 10+.

    After, the peak crawl depth is just 3. This will send a strong signal to Google that your site is optimised and worth crawling more often.
    Let's look at a crawl visualisation before we made these changes. It's easy to see how most content was found via table filters, which led to a redirect (the red dots), dramatically increasing crawl depth and reducing crawl efficiency.

    Compare that with the after, which shows a much more ordered crawl, with all content discoverable as expected without any red dots indicating redirects.

    Conclusion
    SEO is a multi-faceted discipline. In the past, we have focused on ensuring we send the correct headers, use the correct microdata such as JSON-LD and optimise meta tags. These are all vital parts of ensuring your site is optimised for crawling. However, as we can see in this blog that without focusing on the crawl budget and crawl efficiency, even the most accurately presented content is wasted if it is not discovered and added into the search index.
    These simple changes will offer considerable advantages to how Google and other search engines spider your site.
    The features and changes outlined in this blog will be available in our November release, which will be Invision Community 4.6.8.
  9. Like
    Rikki got a reaction from Maxxius for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  10. Like
    Rikki got a reaction from OptimusBain for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  11. 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!
  12. 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!
  13. 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!
  14. 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!
  15. 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!
  16. 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!
  17. 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!
  18. 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!
  19. 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!
  20. 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)
     
  21. 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!
  22. 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!
  23. 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!
  24. 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!
  25. 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!
  26. 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!
  27. 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!
  28. 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!
  29. 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!
  30. 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!
  31. 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!
  32. 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!
  33. 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!
  34. 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!
  35. 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!
  36. 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!
  37. 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!
  38. 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!
  39. 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!
  40. 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!
  41. 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!
  42. 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!
  43. 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!
  44. 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!
  45. 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!
  46. 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!
  47. 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!
  48. 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!
  49. 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!
  50. 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!
  51. 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!
  52. 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!
  53. 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!
  54. 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!
  55. 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!
  56. 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.
  57. 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)
     
  58. 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)
     
  59. 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)
     
  60. 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)
     
  61. 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)
     
  62. 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)
     
  63. 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)
     
  64. 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)
     
  65. 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)
     
  66. 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)
     
  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 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)
     
  73. 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)
     
  74. 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)
     
  75. 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)
     
  76. 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)
     
  77. 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)
     
  78. 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)
     
  79. 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)
     
  80. 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)
     
  81. 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)
     
  82. 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)
     
  83. 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)
     
  84. 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)
     
  85. 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)
     
  86. 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)
     
  87. 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)
     
  88. 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)
     
  89. 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)
     
  90. 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)
     
  91. 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)
     
  92. 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)
     
  93. 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)
     
  94. 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)
     
  95. 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)
     
  96. 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)
     
  97. 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)
     
  98. 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)
     
  99. 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)
     
  100. 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)
     
  101. 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)
     
  102. 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)
     
  103. 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)
     
  104. 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)
     
  105. 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.
  106. 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.
  107. 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.
  108. Like
    Rikki got a reaction from The Old Man for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  109. Like
    Rikki got a reaction from princeton for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  110. Like
    Rikki got a reaction from princeton for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  111. Thanks
    Rikki got a reaction from RMweb for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  112. Like
    Rikki got a reaction from shahed for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  113. Like
    Rikki got a reaction from Darrien for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  114. 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.
  115. Like
    Rikki got a reaction from Ohio Guns for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  116. Like
    Rikki got a reaction from Marcelo Cappelletti for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  117. Like
    Rikki got a reaction from IPCommerceFan for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  118. Like
    Rikki got a reaction from Alessandro Caramia for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  119. Like
    Rikki got a reaction from cocoliso for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  120. Like
    Rikki got a reaction from xtech for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  121. Like
    Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  122. Like
    Rikki got a reaction from IveLeft... for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  123. Like
    Rikki got a reaction from sobrenome for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  124. Like
    Rikki got a reaction from Teascu Dorin for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  125. Like
    Rikki got a reaction from SeNioR- for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  126. Like
    Rikki got a reaction from BN_IT_Support for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  127. Like
    Rikki got a reaction from jaeitee for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  128. Like
    Rikki got a reaction from -FP for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  129. 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.
  130. 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.
  131. 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.
  132. 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.
  133. 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.
  134. 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.
  135. 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.
  136. 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.
  137. 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.
  138. 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.
  139. Like
    Rikki got a reaction from AKrasnov for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  140. Like
    Rikki got a reaction from Ryan Boyd for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  141. Like
    Rikki got a reaction from *José Antonio for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  142. Like
    Rikki got a reaction from Dundurs for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  143. Like
    Rikki got a reaction from Marc Stridgen for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  144. Like
    Rikki got a reaction from IBResource ltd. for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  145. Like
    Rikki got a reaction from xtech for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  146. Like
    Rikki got a reaction from modman for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  147. Like
    Rikki got a reaction from Bluto for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  148. Like
    Rikki got a reaction from Shariq Ansari for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  149. Like
    Rikki got a reaction from media for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  150. Like
    Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  151. Like
    Rikki got a reaction from marklcfc for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  152. Like
    Rikki got a reaction from sobrenome for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  153. Like
    Rikki got a reaction from Ioannis D for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  154. Like
    Rikki got a reaction from Robiss767 for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  155. Like
    Rikki got a reaction from EmpireKicking for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
  156. Like
    Rikki got a reaction from -FP for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
×
×
  • Create New...