Seems we’re frozen from any further upgrades these months.
— Response —
Consideration 1: We are now at version 1.6.0. Between stages 1.2 and 1.4 there were many new elements we needed to consider and a few old things we need to re-prioritize. For example, we had a future release planned where were would open up team collaboration for those working with editors or co-writers. This update was planned for many months from now but increased demand for this feature caused us to shift its priority in our feature queue, which brought team collaboration to fruition sooner (it’s already been completed), but delayed updates 1.2 – 1.4.
Consideration 2: Similarly, Scribble is new and we’re still figuring out what features our users want and what priority they want those features in. In this respect, our milestone page should be seen a rough outline of our goals for the future rather than a document that’s set in stone. For example, this month we had a great user suggestion to help with first draft story structure (as a form of controlled brainstorming). During the process of working on our draft system we decided that this new feature would really compliment our new drafting system and help users with a big pain point (i.e. first draft story structure mapping / planning / visualization). Therefore, we decided to squeeze this feature into the front of the feature release queue, which added an entirely new (unplanned feature), but as a consequence pushed back some other older feature requests. We believe it’s more important to make the software as good as it can be by being open to new good ideas rather than locking ourselves into the dates on our milestone page as if they were written in stone. For us those features are important milestones and in some cases we might get to them early (like the team collaboration feature) and in some cases, if we prioritize a new feature rather than pushing it to the end of the list, this will inevitably result in all currently planned features to be pushed into the future (like what happened with the draft system update).
Consideration 3: Some non feature related obstacles come up on a month to month basis. Most of these are easy to solve issues. However, just before version 1.4 we introduced 2 major inefficiencies into our system. One of these inefficiencies was introduced because we bettered the software and the other was introduced based on a technical change which was out of our control. In the first example, after we added A.I. capabilities into our system we had a major boost in storage usage since we’re allowing users to generate and save 4K images on our servers. Again, we’re happy we added this feature and many users are using it, but it’s massively increased our storage requirements which increases our storage costs and therefore our old “storage economics” didn’t work anymore due to this new feature. Secondly, our backend infrastructure relies on many “workflows”. This is the code that runs every time users do anything within our application. For example, every time a user loads a page, creates a book, adds a character, gives a character a description, or checks their book’s wordcount, they’re running multiple workflows. Each users runs thousands to tens of thousands of these workflows every month. Early this year the cost of running these workflows dramatically increased. Due to the fact that we have our chapter / book word-counting workflow automated to update every few seconds during the time a user is logged in. Last year our processing power was computed using a different calculation. Since the beginning of this year, the calculation has changed and our automated workflows need to be re-imagined and re-designed to improve the efficiency of this part of the software. These aren’t necessarily hard things to deal with. They are just enormously time consuming. When issues like this come up they need to be dealt with immediately so that the software continues to operate as efficiently as possible. This can slow our feature development process down as well since these issues are usually “all-hands-on-deck” sort of issues. In order to make room for these surprise issues, we’ve changed our milestone page’s dates to give us a bit more wiggle room when these issues come up.
Conclusion: Again, it’s best to look at our milestone dates as being written in sand rather than written in stone. In some cases we might be one or two month’s ahead of schedule, and in some cases we might be 1 or 2 months behind schedule. However, keep in mind that we’ll always get to every single release. We never stop working on the software… ever. It’s worked on and improved daily. Similarly, because we take user suggestions seriously, this means that what we need to give the software space to accept new unplanned for features each month or two. It’s an organic process and prioritizing the benefits that come from this organic process is important to us. New feature ideas that comes from that organic process are more important to us than hitting arbitrary deadlines. The deadlines of course motivate us and we always try to reach them, but they are not as important to us as the injection of good new ideas into the software. Also, remember that users don’t necessarily see of the changes we’re making. Some of these changes are improvements in speed, image storage, the way we deploy a book template as well as more granular server side changes to name only a handful of examples.
Hopefully the changes in dates on our milestone page improve our ability to hit those timeline targets (early or on time rather than late) while taking into consideration both new feature changes we want to add to the front of the queue as well as unplanned technical issues that come up.
Thank you for bringing this to our attention and we hope that our changes in milestone scheduling help us avoid this issue in the future!
All the best!
The Scribble Team