The UI/UX for the sprints section is currently really lacking. The current layout of the sprints page was a temporary layout, where we planned to implement a better UI/UX when all functionality was implemented. Now that the functionality for this module is set, we are happily discussing ways to improve it.
One way to improve the sprint functionality, is to implement the ability to edit the sprint. Very similar to how we currently have the kanban board editor setup, it will be on a separate page and only for those with specific permissions. This edit functionality will allow a user to update the title of the sprint, the start and end date. Existing functionality like starting and finishing the sprint will still reside on the sprint information page.
The layout of the information page will be drastically changed, and we are going to remove the bootstrap card that currently holds the information of the sprint. We are in the mist of designing this new UI/UX.
At the moment, users will not be able to delete any objects. For example if a user accidentally makes a duplicate task, that task can not be removed from the system. The user will need to flag the fact that it is a duplicate and then close that task. This is the perfect example where deletion will benefit the user.
We will only implement the delete functionality for users who have a permission level of 4, which is the highest permission level. We are currently planning on where to place the buttons and the procedures around how to delete an object.
Currently only kanban cards have priorty. However this useful little bit of information is actually required in the following objects;
Objects that are parents of sub objects will not have priority built into them. For example "requirement" and "Kan ban board". Requirement will not need priority as it is a helicopter view of the user's requirements. Where the individual requirement item will have the priority.
The NearBeach Flow is an understanding of how NearBeach works as a project management system. It describes at a helicopter level how each module of NearBeach connects and flows into the other modules.
These ideas will need to be written down in our documentation.
To open NearBeach up to other applications so they may also utilise NearBeach's functionality, we will need to implement an API. We could potentially then look at implementing plugins or extended functionality for NearBeach utilising this API.
The main blockers for this particular task at the moment, is the OAUTH/permissions. For example a dashboard will not be able to log into NearBeach, however if we have a simple token authentication (like used in OAuth), we could bypass the login screen.
We'll also need to research how a user will send form data to our backend. For example it's shape and what we are expecting.
Card202 - Implement 2FA for login
Card301 - Implement 2FA with 1Password
Like many project management systems out there, we will need to implement a way a project/task can be estimated. For example a user might use story points. We are investigating how this feature will be re-implemented back into NearBeach and what new functionality it could handle. i.e implementing an estimation feature where multiple users could supply estimations.
Card342 - Implementation of Story Points - for Job Quotation
We do not want to restrict NearBeach to English speaking users. We would like to offer NearBeach to anyone, no matter their language. Translating NearBeach into multiple different languages will open up NearBeach as a useful tool for everyone.
Currently we need to research the most effective way we can implement this, and going forward open up the doors for anyone to submit a translation into NearBeach. Following the translation of NearBeach we will also need to translate the documentation.
Card216 - Translate the application