Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graphical upgrade #90

Open
kinow opened this issue Nov 21, 2023 · 43 comments
Open

Graphical upgrade #90

kinow opened this issue Nov 21, 2023 · 43 comments
Labels
working on Someone is working on it

Comments

@kinow
Copy link
Member

kinow commented Nov 21, 2023

In GitLab by @ltenorio on Nov 21, 2023, 16:41

After the great presentation of @bdepaula showing the Cylc GUI, I noticed some desire from the team to have a more friendly and aesthetic GUI.

So, I took a little time to mock up a better Home page style to start the discussion about the importance of making an upgrade to the GUI soon.

Home

@mcastril what do you think about this? I know that this is not a priority nowadays, but might be relevant sooner or later.

@kinow
Copy link
Member Author

kinow commented Nov 22, 2023

In GitLab by @ltenorio on Nov 22, 2023, 10:46

Additional things to consider for the graphical upgrade:

  • Upgrade from normal CSS to SASS for better stylesheet organization.
  • Changes in the UI library. We can stay using Bootstrap 4.6.0 or upgrade it to a newer version like 5.3. Also, we can change to a highly customizable UI library like Tailwind CSS.
  • Consider changing graphical libraries like the one used for the graph view vis-network to a more customizable one like React Flow.

@kinow
Copy link
Member Author

kinow commented Nov 22, 2023

In GitLab by @bdepaula on Nov 22, 2023, 11:03

Upgrade from normal CSS to SASS for better stylesheet organization.

+1 💯

Changes in the UI library. We can stay using Bootstrap 4.6.0 or upgrade it to a newer version like 5.3. Also, we can change to a highly customizable UI library like Tailwind CSS.

👍 we adopted a Material library in Cylc, but in hindsight that was not the best choice, because when we had to upgrade Vue2 to Vue3 that library blocked for >1 year the upgrade. I don't think that applies to React libraries (faster development).

Said that, the library still helped a lot to speed up our development, instead of relying on Bootstrap or pure CSS.

Consider changing graphical libraries like the one used for the graph view vis-network to a more customizable one like React Flow.

React Flow looks amazing. We just need to make sure its features cover everything that we have (or that we want to have). But the look and feel and docs look really good.

@kinow
Copy link
Member Author

kinow commented Nov 22, 2023

In GitLab by @ltenorio on Nov 22, 2023, 11:29

👍 we adopted a Material library in Cylc, but in hindsight that was not the best choice, because when we had to upgrade Vue2 to Vue3 that library blocked for >1 year the upgrade. I don't think that applies to React libraries (faster development).

That's good to know! I don't think there will be a block if we avoid using UI React component libraries.

In this case, Bootstrap and Tailwind can be used with just HTML, CSS, and Javascript.

Bootstrap does include some style classes and functions to implement common components, but sometimes they are difficult to customize.

On the other hand, Tailwind has many customizable styling class options without dealing too much with CSS. Also, it gives plenty of "recipes" to deal with common things with a lot of flexibility, but some of them need to add dependencies for the functional side.

IMO if we want general faster development, Bootstrap is the way. But if we need high out-of-the-box customization, Tailwind will do better.

@kinow
Copy link
Member Author

kinow commented Nov 23, 2023

In GitLab by @bdepaula on Nov 23, 2023, 10:38

IMO if we want general faster development, Bootstrap is the way. But if we need high out-of-the-box customization, Tailwind will do better.

👍 agreed, and I trust to make the best choice here! :medal:

@kinow
Copy link
Member Author

kinow commented Dec 7, 2023

In GitLab by @ltenorio on Dec 7, 2023, 14:59

added 2 designs

@kinow
Copy link
Member Author

kinow commented Dec 13, 2023

In GitLab by @ltenorio on Dec 13, 2023, 14:51

removed 2 designs

@kinow
Copy link
Member Author

kinow commented Dec 13, 2023

In GitLab by @ltenorio on Dec 13, 2023, 14:56

added 4 designs

@kinow
Copy link
Member Author

kinow commented Dec 14, 2023

In GitLab by @ltenorio on Dec 14, 2023, 09:29

As discussed, one way to validate these mockups is by sending a poll to a group of users. I'm thinking of adding these questions to focus on usability and feedback:

  • What are your initial thoughts or feelings about the design?
  • Is the navigation intuitive? Can you easily find what you're looking for? Are there any elements that are confusing or difficult to understand?
  • What specific changes would you recommend to enhance the user experience?
  • Are there any additional features or functionalities you'd like to see?

As suggested by @mcastril, we could contact Eric and Gilbert to build this group of users, or send this poll to a mailing list.

@kinow
Copy link
Member Author

kinow commented Dec 29, 2023

In GitLab by @ltenorio on Dec 29, 2023, 11:25

As part of the Graphical Upgrade taking into account issue #92 and the new API route distribution, I have listed the tasks to do:

  • Node version updated to lts/iron
  • Dependencies updated to their latest version using npm-check-updates
  • Migration from CSS to Sass
  • Migrate CDN dependencies (bootstrap, fancytree, vis-network, fontawesome) to their bundled ones
  • Include Redux Toolkit for better state management
  • Include RTK Query for better API calling (with cache and polling) and support v3 and v4 API
  • Update authentication handler
  • Migrate Home View
  • Migrate Summary Modal -> Table View
  • Migrate Quick View
  • Migrate Tree View
  • Migrate Monitor Tree
  • Migrate select historical run in Tree View
  • Migrate Job Selection (?)
  • Migrate Graph Standard View
  • Migrate Selection helpers (status, wrappers) in Graph View
  • Migrate Graph extra views (?)
  • Migrate Monitor Graph
  • Migrate Run Log View
  • Migrate Configuration View
  • Migrate Statistics View
  • Migrate Performance View

@kinow
Copy link
Member Author

kinow commented Dec 29, 2023

In GitLab by @ltenorio on Dec 29, 2023, 14:09

mentioned in commit 274a9b6

@kinow
Copy link
Member Author

kinow commented Jan 2, 2024

In GitLab by @ltenorio on Jan 2, 2024, 16:44

added 1 design

@kinow
Copy link
Member Author

kinow commented Jan 2, 2024

In GitLab by @ltenorio on Jan 2, 2024, 16:45

updated 1 design

@kinow
Copy link
Member Author

kinow commented Jan 2, 2024

In GitLab by @mcastril on Jan 2, 2024, 18:58

These are good questions Luiggi.

We have a couple of persons with expertise in UX/UI in BSC-ES. We could ask them about their opinion concerning these questions.

Yes, contact Eric and Gilbert as soon as possible. I understand that you don't need a full upgrade (the list of tasks below) before the session, just a few pages. Otherwise, in case the users asked for major changes you would have saved time.

@kinow
Copy link
Member Author

kinow commented Jan 3, 2024

In GitLab by @ltenorio on Jan 3, 2024, 16:06

added 1 design

@kinow
Copy link
Member Author

kinow commented Jan 3, 2024

In GitLab by @ltenorio on Jan 3, 2024, 17:24

mentioned in commit 2e152ea

@kinow
Copy link
Member Author

kinow commented Jan 4, 2024

In GitLab by @ltenorio on Jan 4, 2024, 16:11

added 1 design

@kinow
Copy link
Member Author

kinow commented Jan 12, 2024

In GitLab by @ltenorio on Jan 12, 2024, 10:59

@mcastril After talking with Eric and Gilbert about relevant users of the Autosubmit GUI we got the following possible users to validate the designs:

In AC:

  • Montse Costa
  • Luka Ilic

In CES:

  • Gilbert Montané
  • Eric Ferrer
  • Miriam Olid
  • Alejandro Garcia

In CVC:

  • Valentina Sicardi
  • Aude Carreric

Also, it will be good to include some people from Destination Earth:

  • Aina Gaya
  • Francesc Roura
  • Leo Arriola

Now I have some inquiries on how to handle this validation. Instead of having a session with everyone, I think it will be better to start with a form sent to everyone asking for feedback (with the questions set above). Then, with this initial feedback, make an interactive mockup in Figma (or complete the implementation (?) ). Afterwards, it would be better to have small sessions (15-30min) with small groups (2-3), so the users can have more freedom to share their opinions.

@bdepaula what do you think? Maybe we can add some things done in Cylc 👀

@kinow
Copy link
Member Author

kinow commented Jan 12, 2024

In GitLab by @bdepaula on Jan 12, 2024, 12:27

Sounds good, @ltenorio ! Maybe we can add a few small improvements adapting features from Cylc or ecFlow's UI. But I think you will probably have a lot to address just with the new layout :slight_smile: Let's see how much work that will require, and maybe add a few other improvements (some may not require user feedback, e.g. use a websocket instead of polling every N seconds).

@kinow
Copy link
Member Author

kinow commented Jan 12, 2024

In GitLab by @mcastril on Jan 12, 2024, 16:41

Thanks @ltenorio, for sharing the list. From AC, you could also involve Rubén Sousse, who is always running different experiments.

Send a form beforehand if you consider it a useful source of information. I thing it would be.

About Figma and completing the implementation, maybe there is a compromise solution that does not represent an overhead and allows us to re-use most of the work. For example, leaving a few sections uncomplete. The most important ones for the users are the search view and tree view, and later the quick view and the graph view.

If you want to do it in small groups, I agree but I wouldn't split them so much. Maybe one session with AC and CVC and another one with CES (including DE).

Finally, I would leave the suggestions for new features noted so that we can evaluate them together and create issues. In any case, it would be work for later. After the graphical upgrade, we should go first for the deployment in Climate DT and the write-mode endpints.

Thanks for this work

@kinow
Copy link
Member Author

kinow commented Jan 16, 2024

In GitLab by @ltenorio on Jan 16, 2024, 10:49

updated 1 design

@kinow
Copy link
Member Author

kinow commented Jan 16, 2024

In GitLab by @ltenorio on Jan 16, 2024, 10:54

updated 6 designs

@kinow
Copy link
Member Author

kinow commented Jan 16, 2024

In GitLab by @ltenorio on Jan 16, 2024, 11:03

updated 1 design

@kinow
Copy link
Member Author

kinow commented Jan 18, 2024

In GitLab by @bdepaula on Jan 18, 2024, 10:34

Feedback from AS meeting today:

@dbeltran: maybe make the boxes smaller, use two different ways to display it (list/table)
@bdepaula: I like big fonts, it doesn't render well on my viewport/browser

@kinow
Copy link
Member Author

kinow commented Jan 22, 2024

In GitLab by @ltenorio on Jan 22, 2024, 10:11

Here is a summary of the form that was submitted last week (5 out of 12 responses):

  • Users liked the "modern" style of the new design
  • Users find it intuitive and easy to use
  • They feel it preserves the "old" setup, so they don't feel they have to learn something new
  • The new design has too many dark colors. Contrast adjustments are highly suggested by the users.
  • "Select previous runs" button was missing and seems to be an important feature
  • Apart from the new design they asked for improvements to visualize big experiments
  • Also, they asked about "setstatus" buttons which are aligned with our work for EDITO
  • Improve visualization of wrappers (and their status) and retries
  • A button to watch just your experiments on the homepage
  • Also: https://earth.bsc.es/gitlab/es/autosubmitreact/-/issues/69

CSV: Autosubmit_GUI_Update.csv

@kinow
Copy link
Member Author

kinow commented Jan 22, 2024

In GitLab by @bdepaula on Jan 22, 2024, 10:37

Great feedback, thanks for summarizing it, @ltenorio. And kudos for keeping the old setup. I think that will really help existing users.

I think most of the items can be fixed in this issue. #69 is for the performance metrics, the setstatus I think depends on https://earth.bsc.es/gitlab/es/autosubmit_api/-/issues/55.

Do we have issues already for “Improve visualization of wrappers (and their status) and retries”, ”A button to watch just your experiments on the homepage”, and for “Apart from the new design they asked for improvements to visualize big experiments”?

@kinow
Copy link
Member Author

kinow commented Jan 22, 2024

In GitLab by @ltenorio on Jan 22, 2024, 11:38

About the missing issues:

  • Improve visualization of wrappers (and their status) and retries: Graph Visualization Improvement #41 GUI handling of horizontal wrappers in graph view #68 are more or less related
  • A button to watch just your experiments on the homepage: No issue related but can be done easily with the new endpoints but we have to improve the synchronization with the DDBBs
  • Improvements to visualize big experiments: The suggestion here was to limit the number of items in the tree view but the current job filter should work fine IMO because the jobs are already grouped. Not sure if this could be an issue. We might want to have more feedback about this in the further small sessions.

@kinow
Copy link
Member Author

kinow commented Jan 31, 2024

In GitLab by @mcastril on Jan 31, 2024, 18:06

I remember Cristian recommended a move to Tailwind before leaving. But it's worth to consider staying in Bootstrap and upgrade.

React Flow looks amazing. We just need to make sure its features cover everything that we have (or that we want to have). But the look and feel and docs look really good.

I agree with Bruno. Maybe you have already seen that, the Graph display is a delicate one. In the first versions of the GUI, the elements were not positioned as we liked (following the chunk order, in rows and spatiated as we used to). At some point, I think that Wilmer had to take the coordinates of the nodes generated by Graphviz in Autosubmit to provide them to the graph library used in the GUI.

The other issue was the rendering of bigger graphs, which were taking much time. For that reason, he created a worker (populate_graph.py) to generate and extract these coordinates offline.

I don't know if this workflow is compatible with React Flow and if that's more performant. Just things to take into account.

@kinow
Copy link
Member Author

kinow commented Jan 31, 2024

In GitLab by @mcastril on Jan 31, 2024, 18:17

Thanks a lot, Luiggi, for taking the initiative, for holding the session, and for providing the answers summarized here!

Sorry for my delay catching up with this. Last week we had a deadline for submitting a National Project (prepared by CES).

I wonder what they really meant with the setstatus helper. There is a "helper" already (CHANGE STATUS), that prints (and copies in the clipboard) a setstatus command that the user can directly type in the command-line. I don't know if the user was aware of this feature. But if you were there, maybe you are more certain that they really wanted to have the action button.

Regarding the size of the boxes, that was also my opinion. The current setup could work well in a tablet or phone thoug, but on bigger screens, we should show more experiments.

Concerning the loading time, it's true for bigger workloads. The filter only works after everything is loaded.

About improving the visualization for big experiments, we started to work on that with the group buttons in the Graph. In the tree, they are already grouped and there is a filter as you are saying.

@kinow
Copy link
Member Author

kinow commented Feb 1, 2024

In GitLab by @ltenorio on Feb 1, 2024, 10:48

I remember Cristian recommended a move to Tailwind before leaving. But it's worth to consider staying in Bootstrap and upgrade.

Yes, to do the upgrade faster I did have to stay with Bootstrap (and extend it a little more with Sass). Still, Bootstrap is way more limited in customization than using Tailwind with a compatible component library like Radix. So, we might consider migrating it in the future.

@kinow
Copy link
Member Author

kinow commented Feb 1, 2024

In GitLab by @ltenorio on Feb 1, 2024, 11:45

After this upgrade, I considered creating a new repo for this new GUI. This is mainly, to keep the old issue list of the old GUI here because they will mostly not apply to the new one. Also, we can take the opportunity to rename it from autosubmitreact.

@mcastril WDYT?

@kinow
Copy link
Member Author

kinow commented Feb 1, 2024

In GitLab by @bdepaula on Feb 1, 2024, 12:13

Wouldn't it be easier to keep using this repo, so that we can link issues/commits, and - more importantly - the Git history? +1 to renaming it though 💯 !

@kinow
Copy link
Member Author

kinow commented Feb 1, 2024

In GitLab by @ltenorio on Feb 1, 2024, 12:48

Agree! For me is better to keep this repo. The only fallbacks that I think I'll have is to manage the issues list between the old and new GUI, and if there were another additional reason why this repo is private (sensitive data maybe? but I remember this was not the case).

@kinow
Copy link
Member Author

kinow commented Feb 1, 2024

In GitLab by @bdepaula on Feb 1, 2024, 13:23

If there are things that are not valid anymore, we can close it as won't fix, or add a label that it needs discussion/etc.

As for being private, I think it was only until we made it portable, and had reviewed it to make sure there were no security issues. I don't believe we have any passwords or sensitive information here (we always kept destine/edito/etc. info on issues in those projects' repositories).

@kinow
Copy link
Member Author

kinow commented Feb 2, 2024

In GitLab by @mcastril on Feb 2, 2024, 17:48

I am also in favor of keeping this repository. As Bruno said, you can close issues that are not valid anymore (commenting that they were fixed in the new release) and keep the other ones.

If we were going to maintain both versions I would say that you can create labels for v3 and v4, but I don't think this is going to be the case.

Regarding the project path, it can be renamed when we decide.

And regarding the public repo, it's as Bruno said.

@kinow
Copy link
Member Author

kinow commented Feb 5, 2024

In GitLab by @ltenorio on Feb 5, 2024, 09:36

mentioned in issue digital-twins/de_340/project_management#534

@kinow
Copy link
Member Author

kinow commented Feb 20, 2024

In GitLab by @ltenorio on Feb 20, 2024, 09:54

I'm preparing the first hands-on session to validate the new GUI using the already developed and deployed in our development environment (https://bscesautosubmitdev01.bsc.es/autosubmitGUI). This will be a 30-minute (or maybe more?) session with the people of MWT and DE:

  • Aina Gaya
  • Francesc Roura
  • Leo Arriola
  • Gilbert Montané
  • Eric Ferrer
  • Miriam Olid
  • Alejandro Garcia

Then, the following questions will be set for this session:

  • What are your initial thoughts? Do you like it? It is easy to use?
  • How do you feel about the color palette? Do you want a dark mode?
  • Do you need other "order by" options on the home page?
  • Do you need the other views in the experiment graph? Any suggestion to improve visualization?
  • Do you need the job "change status" command generator? Do you need to select multiple jobs in it? Do you need another command to be generated?
  • Any additional suggestions?

After this session, the next step will be to focus on the suggestions of the DE people aiming to be the ones that will first use it.

Consequently, in ES, we can also deploy the new GUI in parallel like it is the development environment. But to do that we have to request the BSC CAS maintainers add the service names to the CAS whitelist. In this case, add https://earth.bsc.es/autosubmitGUI and https://bscesautosubmitdev01.bsc.es/autosubmitGUI. Is that possible @mcastril?

@kinow
Copy link
Member Author

kinow commented Mar 19, 2024

In GitLab by @mcastril on Mar 19, 2024, 16:24

@ltenorio, thanks for deploying the new GUI, it looks very nice.

When do you plan to have this session?

Regarding the questions:

Do you need the job "change status" command generator? Do you need to select multiple jobs in it? Do you need another command to be generated?

The first one shouldn't be an option. Different users from the scientific groups said that this one was very helpful. Even if we allowed the status to be changed directly with the GUI, it would still be a nice help for the CLI.

As said through Slack, I think that the experiment's detailed view should either have a button or be accessed by clicking on any part of the card. Using only the header is not intuitive, in my opinion. Title bars are normally used for dragging.

@kinow
Copy link
Member Author

kinow commented Mar 19, 2024

In GitLab by @ltenorio on Mar 19, 2024, 16:46

When do you plan to have this session?

I wanted to do it after deploying it publicly to the CES members so they have enough time to try it before the session. But now, it seems quicker to send a form like the last time than to look for a free spot from everyone. Maybe the form can be shared in the next MWT meeting to get the attention of everyone. WDYT?

The first one shouldn't be an option. Different users from the scientific groups said that this one was very helpful. Even if we allowed the status to be changed directly with the GUI, it would still be a nice help for the CLI.

Yes, I got that feedback from some Climate DT people already. I was thinking of implementing it as a shopping cart like in UniProt (people from life sciences will love it) so it can be easily extended to have multiple features.

As said through Slack, I think that the experiment's detailed view should either have a button or be accessed by clicking on any part of the card. Using only the header is not intuitive, in my opinion. Title bars are normally used for dragging.

Yes, that is on the to do list for the next version. The only fallback I see is that the user will not be able to select and copy text inside the card easily but this seems meaningless.

@kinow
Copy link
Member Author

kinow commented Mar 19, 2024

In GitLab by @mcastril on Mar 19, 2024, 17:16

I wanted to do it after deploying it publicly to the CES members so they have enough time to try it before the session. But now, it seems quicker to send a form like the last time than to look for a free spot from everyone. Maybe the form can be shared in the next MWT meeting to get the attention of everyone. WDYT?

Actually, I think this is a very good idea. Why not use one of the next MWT meetings (the non-reporting ones) to showcase the GUI and ask people for feedback? You could complement it with the sharing of the form, before or after.

There are some presentations/sessions in the backlog, but I don't think that they have any objection to letting you a spot in the next weeks: https://trello.com/c/991ldOUj/164-models-workflows-team

Yes, I got that feedback from some Climate DT people already. I was thinking of implementing it as a shopping cart like in UniProt (people from life sciences will love it) so it can be easily extended to have multiple features.

So, do you mean adding the tasks to be changed in an overlay instead of just selecting them?

Yes, that is on the to do list for the next version. The only fallback I see is that the user will not be able to select and copy text inside the card easily but this seems meaningless.

I see. Well, maybe you can leave a part of the card as non-clickable (the part of the text) using another colour and some kind of border. You'd have to test it to see if it's fine

@kinow
Copy link
Member Author

kinow commented Mar 19, 2024

In GitLab by @ltenorio on Mar 19, 2024, 17:30

Actually, I think this is a very good idea. Why not use one of the next MWT meetings (the non-reporting ones) to showcase the GUI and ask people for feedback? You could complement it with the sharing of the form, before or after.

It will be fun to do it that way. As a disclaimer, it might not be a presentation, instead, it will be an interactive session where we will ask people to do some tasks with the GUI and ask for feedback immediately. I'll add it to the backlog.

So, do you mean adding the tasks to be changed in an overlay instead of just selecting them?

Yes, it is not so different from how the "ACTIVATE SELECTION MODE" button works in the old GUI.

@kinow
Copy link
Member Author

kinow commented Mar 19, 2024

In GitLab by @mcastril on Mar 19, 2024, 17:34

It will be fun to do it that way. As a disclaimer, it might not be a presentation, instead, it will be an interactive session where we will ask people to do some tasks with the GUI and ask for feedback immediately. I'll add it to the backlog.

I like the idea. You can use the format that you think it'll work best, but this one sounds like a nice team activity.

@kinow
Copy link
Member Author

kinow commented Mar 28, 2024

In GitLab by @ltenorio on Mar 28, 2024, 14:34

A quick debrief of the user testing session of today:

  • Add a warning to the Home search suggesting to disable the "Only active" option
  • Rename "Created (asc/desc)" with something more descriptive like Newest/Latest
  • Add order by total jobs or # of chunks
  • Filter by AS version
  • Retrieve storage usage of the experiment (If it is possible)
  • Add an "Advanced search" with AND/OR operators
  • Test GUI with big screens
  • Modify page size in experiment search
  • Add project/branch information
  • Checking the last run was not intuitive. Might add some documentation on how to do it.
  • Selecting multiple jobs was not intuitive in the tree/graph view. Add some helping text.
  • Job detail panel collides with the job basket in smaller screens. Reduce the initial size of the job detail panel. Could be expandable.
  • Job basket selected jobs should be highlighted in the tree
  • Go back to the default tree view after expanding or collapsing all
  • In Graph, add a button to change the status of multiple selected nodes (like the old GUI). The job basket could be used here but should be synced with what is currently selected and highlighted.
  • Add a job history button (like the old GUI)
  • Show a legend in the graph view (select by status works like a legend)
  • Add a status filter. It could iterate through the results by continuously clicking it.
  • Add a message on the top of the configuration view when there is a difference and explain what the tooltip means.
  • Add a filter to just show the differences in the configuration view
  • It might be good to have an "Experiment overview" section. Might iterate again with the users to see what could be inside.
  • Generalize performance metrics to be calculated not only for SIM jobs and could be used for other job sections.

Thanks @mcastril for the notes 🙌

@kinow
Copy link
Member Author

kinow commented Apr 16, 2024

In GitLab by @ltenorio on Apr 16, 2024, 12:14

Most of the requirements gathered in the testing session are resolved by now.

So, I gathered the remaining ones and assigned an effort/priority estimation here:

(@mcastril what do you think about the priority estimations?)

Requirement Observations Effort Priority
Have a public documentation (Read The Docs) Done! ✅ Mid High
Migrate status and date-member graph views Mid Mid
Add order by total jobs Require API changes to DDBB High Mid
Add order by # of chunks Require API changes to DDBB High Mid
Generalize performance metrics to other job sections Deep API refactor High Low
Retrieve storage usage per experiment Require API changes Mid Low
Filter only differences in configuration view Improve current logic in API Mid Low
Add advanced search Require API changes and will add maintenance cost High Low
Add an “experiment overview” page Must be defined first ? ?

The strategy that I suggest is to complete the documentation requirement (first one) and release the official v4.0.0 release for public use. The other requirements will be moved for future releases depending on the needs of our users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
working on Someone is working on it
Projects
None yet
Development

No branches or pull requests

1 participant