The ACSS team made a strong push to fix all existing bugs in Linear before the end of the year. While this doesn’t mean ACSS is completely bug-free (no software is), it does mean that we’ve successfully squashed every single reported issue as of the publishing of this post.
For a product that’s 3+ years old, that supports multiple platforms, that continuously innovates, and that was completely rebuilt for v3.0 just months ago, that’s unheard of.
It’s what our users deserve, though. We’ll talk about this more in a moment. First, let’s talk about the last few months.
Rebuilding a complex plugin from the ground up to accomplish what no other framework has even attempted, across dozens of different development environments from builders to browsers and everything in between, definitely came with plenty of challenges.
It was more than worth it, though. ACSS is easier to navigate, easier to search, and easier to adjust and use.
We – [all of us] – now have a framework that is accessed from where we’re already working and it’s a tool that shows immediate feedback in real time. The “magic area” dragon that plagues so many front-end development tools has finally been slayed once and for all.
While the battle may have been a little messy, the important part is that we won. Our goal of having a stable, immediately responsive, real-time dashboard has been achieved.
So what happens now?
With all the really challenging work completed, it’s time for a new focus. Where 2024 was all about innovation, refactoring, and being bold in our vision, 2025 is going to be completely different.
Our three words for 2025 are “stability,” “simplicity,” and “support.”
- Stability – ACSS must set the example for software reliability.
- Simplicity – ACSS must feel simple, easy to implement, and easy to adjust.
- Support – We must double down on our efforts to support, educate, and empower users.
Here’s our plan for hyper-focusing on these three areas:
Stability
ACSS is a complex tool that’s very hard to automatically test-cover because it exists across multiple builder environments and can be used in an unlimited number of ways by users in different development environments and scenarios, with different browsers, and with various front-end implications.
While it’s impossible to completely test-cover ACSS the way some software might be fully test-covered with automation, we’re still going to take every possible step to ensure automated stability that goes far beyond manual testing.
- Auto-test-cover all critical features. This will mainly be for back-end and dashboard functionality, rather than the framework itself. It’s a ton of additional work, but will increase stability far beyond the current manual testing methods.
- Manual-upgrade releases. If for some reason we are unsure about the stability of a given release, we’ll release it as a manual upgrade. This means users will not receive an auto-update notice – you’ll log into your account and download the file manually. This will prevent thousands of users from auto-updating into a version with an issue.
- Fix-first development policy. Bugs are prioritized over features, even to the point of freezing feature development when new bugs are reported. The threshold for this is a single bug.
- Experimental features. Even if we’re completely sold on the idea/concept of a new feature, we’re going to first add it as an experimental feature behind a toggle. This allows users who have the time and patience for potential issues to play with new features before they’re made official. It also gives us time and feedback to account for all potential scenarios and options. We did this with textures and overlays, the card framework, the icon framework, etc. with great success.
- Automated visual regression testing. We’re going to invest a lot of time and money into setting up and running visual regression tests on each update. This will supplement manual testing and alert the team to any visual regressions prior to release.
- Bug-bounty program. We are exploring the possibility of creating a bug bounty program where users are paid a cash bounty for adequately reported, confirmed bugs. While this isn’t a necessary thing, it further demonstrates our full-blown dedication to stability. We’ll post more about this next year once the details are worked out.
Simplicity
Great software translates “feature-rich” into “simple and easy.”
- Dashboard UX Improvements. How much easier and faster can the dashboard be to use?
- Framework Simplifications. How much easier and faster can using the framework get?
- Workflow Improvements. How much easier and faster can building websites get?
These are the primary questions we’re going to ask ourselves over and over again throughout 2025. We’re going to put less focus on new features and more focus on UX, simplification, and your workflow as a user.
Support & Education
We already lead the industry in support and education, but we’re doubling down in 2025. Here’s how:
- No-Tolerance Policy for Zero Comments. Threads in the support community are not allowed to have zero comments for longer than 3 hours (weekdays during U.S. business hours). This ensures that users (1) can get help with an unprecedented response time (2) are confident in turning to the support community because they know they can get quick help.
- No Release Without Documentation Rule. Any fix/feature that makes it into a release must be documented before that release is public. This ensures that documentation exists and is kept up to date.
- 180-day Document Expiry Rule. All documentation articles will be put on a 180-day timer. If any doc hasn’t been updated in 180 days, it will trigger a manual review of that doc. It’s quite possible that nothing needs to change, but if nobody checks it, we can’t know for sure that a doc is still up to date. A manual review will either update or re-certify a doc’s accuracy.
- 60-second feature “shorts.” Not every user has time to watch full videos on a feature or to understand what’s available in ACSS. We will produce a series of 60-second “shorts” highlighting specific features so you can see it, understand it, and know how to use it in just 60 seconds.
We’re the industry-leading framework for WordPress by a wide margin and we plan to keep it that way.
No other framework for Wordpress comes close to ACSS in features, innovation, education, or user experience. The gap is wide and that’s well-reflected in the size of the user base and the number of active sites built with ACSS.
We’re very proud of this, but we also feel a growing sense of responsibility to (1) make sure there isn’t a single user that feels left behind by changes, updates, and innovations, and (2) make sure we’re actually helping you as a user, without setback.
Your main focus as a web developer is getting work done. This is how you keep customers happy and keep money coming in the door.
You use ACSS because it adds tremendous speed, consistency, and convenience to your workflow while dramatically reducing the number of decisions you have to make.
If the tool innovates and iterates too quickly, causing you to feel left behind, then we’re not helping you the way we should be. We’re mindful of this.
If the tool breaks something when you update and you have to take time to address it, then we’re not helping you the way we should be. We’re mindful of this.
Innovation, iteration, stability, and education all must be, and will be, delicately balanced. This is the standard we seek in the products we use, so it makes sense that it’s also the standard we set for the products we create.
Thanks for an amazing 2024 and here’s to an insanely productive 2025!
Want to comment on this post? Visit the official discussion thread in the ACSS community.