Chris Anderson

I would love to test v5.

@Jordan MillerHere's an article about the Bionic Font you might find interesting: Does Bionic Reading actually work? Test for yourself! (readwise.io)

All jokes aside, not everyone visually processes things the same way when it is in a small, medium, or large format. A one size fits all approach will leave some folks at a disadvantage. If someone has less than "normal" vision, it can be quite challenging to comfortably read everything that is presented to us as we visit one site after another. It would be nice if sites running this software suite could be the exception to the rule. There may be value in offering a variety of different fonts instead of being locked into one. Doing so would likely increase the amount of content actually read and reacted to, increasing overall engagement. If one font appealed to one and all there wouldn't be thousands of free or purchasable fonts out there. A vast majority of these fonts are created to be aesthetically pleasing, not for increased readability. There are some fonts that might work far better for some portion of your members, as it stands today, we can't readily offer them an option. If your site is geared more towards educating, then things get more complicated. People learn in a variety of different ways. Some like to read content, some like to hear it, and some want to visualize the material being presented, and many want a combination of all three at their fingertips. Having an all-text site leaves many people out in the cold. Having a built-in ability to hear text would be great for those that want to give their eyes a break or are severely sight impaired. So, I'm not sure if @Jordan Millerwas being lighthearted in offering up the Bionic font for discussion or was trying to strike up an earnest conversation around fonts and how they can be better utilized to serve our communities.

I imagine for some folks it would be NSFW so its best we don't delve too deeply into this subject.

This Bionic font might be appealing to a segment of one's audience but likely not all. It would be interesting to see if you could provide a toggle to change the display font and size.

Okay, cloud customers may not have their very own server, but they do have a centralized place to manage various settings and install and manage custom and third-party apps. Some additional functionality to assist in troubleshooting and fixing minor issues with custom or third-party apps would go a long way towards helping convert a subset of self-hosted customers to become cloud customers or those individuals thinking about becoming a hosting customer.

I can appreciate why locking down a cloud server would be appropriate for a VERY large portion of IPS's clientele but by doing so they lock out a segment of their client base that would consider choosing to purchase a cloud server subscription if they were afforded the ability to manage and troubleshoot "some" aspects of their cloud server environment such as marketplace and custom apps. Maybe IPS could open up a section of the ACP that would provide a little more access to "that" server instance, but it would require agreeing not to hold IPS accountable for any missteps. If something were to go amiss IPS would simply offer to restore the site to a prior state. I'm thinking that the additional access to be able to manage "some" aspect of one's own server would only be granted to those individuals that have shown they have a team in place that knows what they are doing, as evidenced by the client's support tickets (or lack thereof) over a course of time for new and existing customers. This might be done via the installation of a plugin. If a client manages their cloud server well the plugin remains installed, the moment they show they aren't up to the task of minimally self-managing their server a customer support person would simply uninstall the plugin.

@Jordan MillerCould you please be a little more specific in regard to these lists. The above list seems to indicate a list of identified issues that the developers have acknowledged as being a verifiable issue warranting a fix. What is up for debate is when one could expect each of the above fixes to appear in a release. Is it the next beta, 4.7, or in some future 4.7.x release yet to be determined? Knowing "approximate" release times helps an admin better manage issues such as workarounds or managing customer expectations. An issue that will be fixed next week requires an entirely different management approach than that of an issue that could take several months before being resolved. This would also assist in the beta testing process, knowing when a reported problem is supposedly resolved the beta testers could test the fix one more time to ensure that it is fixed under a variety of different testbeds. This would really be helpful now that we have a near monthly release schedule.

IT's hard to know the overall value of any particular thread. Just because it has lots of comments and some posts have some likes it's hard to gauge its overall value. Having a visual que that a topic has an overall positive value would be helpful (like a Rotten Tomatoes score for movies), this might be thought of as a sentiment score. Does each new contribution increase the sentiment score or not? This might be attained by helping to keep the conversation on point and bringing useful insights and knowledge into play Instead of "liking" a post you might instead acknowledge the value that post brings to the conversation and community as a whole. Maybe this type of "liking" wouldn't' be publicly viewable but is tracked to determine an overall sentiment score. Is it worth my time to read through the comments and participate further or should I ignore it and skip onto the next forum topic? It's really hard to know for sure. Sometimes a topic for discussion will have multiple instances being commented upon at the same time. Which one do you participate in, well if one has a higher sentiment score that might be the better one to participate in. Tracking member likes has value, but there might be even more value in tracking their contributions to topic sentiment scores. The more they contribute and get acknowledged for their contributions the higher their score becomes. The score could reset on a yearly basis. This would encourage people to keep returning on a continuous basis so that they can continuedly be seen as a valuable contributor to the site.

I'm not advocating that you keep us apprised of features like: "A friendly reminder before posting" that you announced yesterday ahead of time. This feature is entirely opt-in. Those sites that want to take advantage of the new feature are free to do so on their schedule. If an upcoming feature will require a fair amount of social engineering and configuration to use it to its fullest, more of a heads up would be helpful. A feature that would fit this scenario well would be “Member Achievements”. The various languages and third-party integrations you utilize are constantly being updated to stay compliant with new standards or to markedly improve their utility. At various points in time, you may have to rewrite portions of the suite to extend the product's lifespan. Some things might remain unchanged, and some things might require a complete reset such as subscription renewals. (Just using this for illustrative purposes). That could be “consequential” for sites with little to no cash reserves to tide them over until all the subscription renewals could be reenabled for all the effected members get around to restarting their subscription. I am advocating that you keep your customer base apprised of such occurrences with as much head's up time as you can. If for example you must fundamentally rearchitect themes, we will be forced to use your provided default theme until such time as the theme creators revamp their offerings. If the changes are too radical and time consuming many if not all the existing providers might exit the marketplace. It could take time to recruit replacements and a variety of compliant themes get released due to a high learning curve. Some sites could readily adapt to the default theme, and some might not as their members are extremely attached to the look and feel of the site and various community value adds that are integrated into the theme. You may have a multitude of different projects on your radar. I’m in no way advocating you to keep us apprised of all of them just, the “consequential” ones we will have to address in the next rolling six to twelve months.

@Jordan MillerI'm not advocating for radical change in clarity but incremental improvements here and there that one day will lead to something substantially more useful to the community as a whole.

@MattI will give your team kudus for talking about some of the substantial features in advance. But often times less substantial features don't get mentioned when they are to be added or changed ahead of time. When they are mentioned the details are often lacking to make an informed decision as to whether or not to implement it or the likelihood that it will undergo additional development based on customer input. I strongly advocated for a comprehensive release notes and I applaud your efforts to track adds, changes and deprecations. You track a lot but there are some that don't get addressed or could benefit from a "little" more information here and there. This would be especially helpful to those individuals that don't yet have a great understanding of the platform or particular feature usage. When is a feature complete (for all intents and purposes) and when are you open to further development? Further development might bring the feature to a point that it would be useful on one's site, or it could make it unsuitable. There are dozens of features that make up the software suite. They all are intertwined together. When meshed together in just the right way you have the makings of a real "community". A feature that is in continual development with no clarity of when said development is "feature complete" one can't reliably know when it makes sense to implement it (or if it will ever work for your unique environment). An example of this would be Member Achievements. Member Achievements is a feature you can toggle on or off but that isn't the case for all features. Some features you are forced to use whether or not they are really fully developed (for your purposes) and bug free. A feature could work for your site with just "one" change or addition to it. Are you the only one that wants it or is there actually significant pent-up demand for its inclusion? When is it prudent to hold off updating your board, one month, two months or six months? Without better clarity from your team its next to impossible to make an informed decision. Also, you have to live with all of the unpatched bugs or security vulnerabilities that are discovered and corrected in the interim. Skipping too many monthly releases in a row increases the likelihood of encountering unrecoverable upgrade issues. You aren't actually pushed to upgrade but not doing so could come at a price. Features that include a lot of different configuration choices are likely the ones that could benefit the most from additional clarity. Changing just one of those choices "could" materially change a feature's behavior, especially if toggled on or off by default. That behavior could be beneficial or not. Being made aware of such would be useful to know prior to deciding to upgrade and give customers an opportunity to say, "Hey wait a minute", let's rethink this feature prior to release.

I mentioned that myself in my initial post but deleted it figuring it would be akin to preaching to the choir.