Replies: 6 comments
-
@karmatarap @nbenn @christophsax @DivadNojnarg these are my thoughts for the roadmap, feel free to let me know what you think and what timelines you reckon is feasible. |
Beta Was this translation helpful? Give feedback.
-
Thanks, @JohnCoene. We discussed with @karmatarap and internally and the division in short and medium-long term / backlog makes a lot of sense. We should focus on the short-term issues during May and try to finalize them as much as possible. Your short-term agenda, enriched with @nbenn's details, now looks like this: Ideally, we can link all the tickets we work during May on to one of these. It also means other tasks / features should go into the backlog. Short term (End of May)Save/restore
Stability issues/core fixes
Here is the corresponding project board: https://github.com/orgs/blockr-org/projects/4. This roadmap is also available on the project board, if you click this button: |
Beta Was this translation helpful? Give feedback.
-
Blockr Summer 2024Planning for our next monthly sprints: Juni
Juli
August
We can discuss tomorrow. |
Beta Was this translation helpful? Give feedback.
-
High-Level GoalsEnd User Features
|
Beta Was this translation helpful? Give feedback.
-
Medium-long term
|
Beta Was this translation helpful? Give feedback.
-
As discussed with Karma: markdownize a Stack is another user need. |
Beta Was this translation helpful? Give feedback.
-
Roadmap for weeks and months ahead.
Feel free to give feedback.
Short term
Pressing tangible features and issues that need to be addressed.
Infinite reactive loop
This is partly caused by the validation, though I believe @nbenn thought there were also other causes. Refactoring of the validation is, as far as I can tell, required to fully fix the infinite reactive loop issue.
Stability
I hope this is not too problematic to solve. We need to avoid app crashes at all costs. This mainly concerns block evaluation (
tryCatch
) but there may be other areas that need to be addressed.Medium to long-term
We've received feedback that users would like to selectively expose inputs when a dashboard is locked: hiding all inputs is often not useful as users want to build interactive dashboards. Ideally users would be able to selectively choose which field remain visible when the dashboard is locked. Initial PR is #337 which is currently on draft. Feedback welcome.
Improved error messages: blockr may be more stable but will likely still occasionally throw errors; we can't control what users will write as blocks and these may errors. However, these errors are currently difficult for dashboard users to understand.
Support table creation. We've focused on plot outputs and we display a simple table by default, e.g.: on data block. But we are going to need to support table generation, primarily for life sciences where programmers are used to build tables by appending rows together.
Library of stacks. Oftentimes users create very similar stacks over and over for different projects, e.g.: demos that we have given already often repeat the creation of similar stacks. We'd need the possibility to create a library of stacks that dashboard builders could import. This is likely outside of blockr itself.
Beta Was this translation helpful? Give feedback.
All reactions