A short summary:
We will be:
- building an entirely new OAuth2-compatible API
- moving away from Vue.js in favour of React
- discontinuing support for selecting different board languages
- introducing support for adding and removing columns
- improving support for liking user cards
- changing the way we encrypt boards to simplify the user experience
- removing boards created before February 25, 2018
- requiring users to be registered and logged in to create new boards
The full details:
Later this summer (for those of us in the Northern Hemisphere), we will be releasing a major back-end overhaul that will result in a number of changes that we’d like to make our users aware of.
The good news is that our work today will address technical constraints on our side that’s preventing us from delivering some important features our users have been asking us for.
Firstly, we are building an entirely new OAuth2-compatible API that will allow third parties (and you!) to provide meaningful integrations into our platform. This will allow us to support a wider range of third party services that we might not otherwise intend to support ourselves.
We plan to start rolling out third party access to our API early next year. In the meantime, we’d love to hear from you about what kind of third party services you use that you’d like our platform to be supported by.
We’ve had a number of conversations with a few companies that augment what we do well and we will continue to have those conversations as we progress forward with our development track.
Secondly, we are migrating away from Vue.js in favour of React. We greatly prefer JSX over HTML templating and we will be exploring React Native in the future. There are also more software engineers experienced with React which is obviously important to us from a hiring perspective, especially when there is a constant shortage of software engineers in England.
In a recent JetBrains Developer Ecosystem Survey , only 33% of respondents said they use Vue.js regularly, compared with 60% for React (this increases to 85% if you include React Native in the mix). This also drives our technical decision.
We have been receiving a lot of feedback from users about being able to add and delete columns on their boards. There are several important reasons why we don’t currently support this.
When you create a board, our platform checks whether you’ve created any similar boards before and made any customisations to the default title/apperance of the columns. If you have, we re-use those customisations when you create another board belonging to the same type; so you can spend less time setting up your board and more time leading your teams’ retrospective.
The problem here is if we allow people to add and remove columns when we have fixed board types, we can end up carrying over customisations that no longer reflect the type of board you are creating. Obviously, we can address this in one way or another, but we want to avoid adding unnecessarily complexity to support the different reasons people might want to customise the default columns.
For example, some teams might not even use the Starfish Retrospective model for their retros, but they may choose to create a board using this format so they have five columns to work with. Clearly, this is stupid and not very scalable.
We’ll be addressing this by removing the different board types and instead allow you to choose how many columns you need when creating your board.
As you may know, we allow users to create boards in either Arabic, English, French, German or Spanish. We are finding not many users are choosing to create boards in other languages, so we will be discontinuing this feature later this summer. You will still be able to conduct retrospectives in your own language, of course – you’ll just need to modify the column titles first!
Subscribers are able to take advantage of advanced features such as board encryption. Right now, using this feature requires you to supply a decryption key which then needs to be passed onto your team to gain access. From the feedback we have received, users don’t like having to needlessly store passwords for each board. We need to simplify the way this works.
We will be removing the need for users to supply their own decryption password and we will instead encrypt and decrypt these boards with our own platform key. Data will be encrypted with OpenSSL using the AES-256-CBC cipher. This way, boards can be automatically decrypted when they’re accessed by team members. Of course, subscribers will be able to take advantage of user access control to limit who can access these boards.
Unfortunately, we will need to break compatibility with existing boards that are encrypted using the current method when we make these changes live later this summer, but we will provide an utility for board administrators to automatically convert their boards to the new encryption method. Alternatively, board administrators can ask us for a copy of their encrypted data so they can decrypt them locally.
We will also be introducing better support for ‘liking’ cards by allowing participants to see who liked each item, and prevent users from liking cards multiple times. Of course, we will continue to allow guests to like cards on boards that don’t require participants to be logged in, and they will be recorded as anonymous votes.
Finally, we will be removing boards created before February 25, 2018 as these boards were created before we had a user registration system in place. The changes we are making to our API (and to facilitate our plan to provide third party access in the future) requires all boards to belong to a user account.
We are proud to have a wide range of companies using our platform – from small startups to large organisations within the FTSE 100. Over the next year, we will be reviewing our subscription strategy to identify whether we can continue to offer a free tier for our users. We may choose to transition to a paid-only subscription model in the future, or place new restrictions on non-subscribers to encourage heavy users to upgrade.
Rest assured, we will provide advance notice if this becomes necessary. What we will not do, however, is undermine the user experience as an undignified tactic to frustrate users into upgrading.
We hope you enjoy using Sprint Boards as much as we love building it!