-
Notifications
You must be signed in to change notification settings - Fork 4
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
improve user experience TFGrid #1466
Comments
Most are indeed tracked in the 3.13 project https://github.com/orgs/threefoldtech/projects/199 |
I set the priority to major, since @despiegk set a deadline of 2 weeks to improve UI. The following is some summary of the gdocs (and some more info) so we can have it here on Github and see where to go next. Ideally, we get things done within 2 weeks, so if some things need more time, we can set aside (e.g. not sure mycelium will be ready in 2 weeks). ThreeFold UI ImprovementsIssues
Improvements - UI Flow
Community FeedbackHere is a forum post to get the feedback of the community around UI. Might not take everything shared into account since we have 2 weeks to proceed, but it will give us a good idea of what people think of how to improve the UI. Basic InspirationAs stated, we want a smooth experience as with https://vast.ai UI Details
DeadlineIdeally, we can improve drastically the UI within the next 2 weeks. Teamwork@AhmedHanafy725, Kristof asked me to assist you as much as I can here. Not necessarily in coding per se, but for the overall flow of the UI. That being said, I can help with coding if possible/needed. I know the deadline is short, so don't hesitate to contact me at anytime to discuss this project. |
Different ParametersHere are some parameters that would improve the user experience.
New FlowIn brief, as of now, the Playground loads available nodes automatically. We would like that the playground loads only when the user has finished setting up the parameters they are looking for. The new flow would be:
NotesSome of those parameters might already be in current issues. We will track if this is the case. |
Important note: choosing the node is a "side" thing, the user should work against farms or locations, choice if the node is less important, specially with the farmerbot, the user shouldn't count on a specific node, Also let's avoid repeating the functionality of the explorer in the playground. major label is removed: major = to be solved in 1 or 2 days max. |
"let's avoid repeating the functionality of the explorer in the playground" I understand your position. But at the same time, the goal of this issue is to make it as easy as possible for users to deploy with the playground (improve UI). Does it make sense to ask users to go on the Explorer before using the Playground? Ideally, a user could find every valuable information within the Playground, for a smooth UX. I also understand that the node is a side thing, but as of now the users of the Playground do use a lot the node ID directly when deploying workloads. Noted for major label. |
Couple things to clear out
Please make sure to check https://new.playground.dev.grid.tf for the already existing experience on 3.13 project and we work from there |
Selecting a specific node is clearly an important use case for the kinds of users we have on the grid today and the way that the grid works. Specifically:
|
What others do is they tag their servers to do a better planning e.g nodes more suitable for compute or storage which is I believe why some need the node ID. And that's why I re-added it to our UI again Aside from that, to your points Scott:
|
Here's a basic example with how the playground works today:
You might say that the issue is that the interface doesn't show me info on the farm, but the fact remains that the node id is the most direct proxy for the environment where a workload is deployed. Let's see that with a second example:
It's true, but we know that even in the best case this can take time. Maybe in the future health checks can help to automatically avoid nodes that get into a bad state (due to hardware failures, Zos issues, or whatever), but for now having the ability to jump over a problematic node might be the difference between a whole farm being usable or not. I guess in general my argument here is that while certainly a lot of the reasons why someone would enter a node id manually could be reduced or eliminated through system improvements including UI, we are better off providing more flexibility for unforeseen circumstances and unanticipated use cases. |
So I happened to revisit the old playground, and the experience there is actually much closer to what we're imagining: Discussed with @Mik-TF today, and this is what we like about the old playground:
What can be improved:
I'd propose to return generally to the approach of the old playground with these changes:
|
To complement what Scott is saying here, this is the Playground flow that we propose: Playground Revisited FlowWe propose the following flow:
Note: To be as clear as possible, we explicitly write in parenthesis that the filters are optional (as shown above). This way, the user instantly understands that it is possible to click directly the Search Nodes button. This will allow for a very smooth flow. |
Another note these optional filters
they should affect each other
also, at this point the user shouldn't care about the nodes to choose? I think they should, given some of the nodes can report they have enough storage to fit the deployment while they don't have enough ssd pools? |
for the confusion of the capacity filter dropdown, there is a new design (radio buttons) that was done by @ehab-hassan. what do you think? |
I think this looks amazing! And will be appreciated by the different kinds of user.
|
New Playground Flow v2Here is a proposed workflow that makes use of the radio buttons, with more details on the possible filter combinations. Automated Method: Filters
Node Selection
Automated Node Selection
Filter Combinations
|
Summary of the 3 issues to improve UI:
EDIT: This was updated. |
Most of the tasks demanded here are now done on the Playground devnet. Thanks everyone. One thing left is this:
Is this possible with the new configurations? E.g. when you click on a solution, there's already a node proposed. And when you change the filters, a new node based on the new filter parameters get proposed? This would be a very quick UX. @AhmedHanafy725 I can create an issue on this if it's possible to implement it. Thanks. |
@Mik-TF we have updated the behavior to select a node once the user opens any solution. but if the user changes something in the filters, the user has to click on |
@AhmedHanafy725 On my part, all the tasks asked have been completed. Thanks again. |
a major update for the node selection threefoldtech/tfgrid-sdk-ts#1884 |
Verified, Devnet 7b55dd4.
A new test suite https://app.testlodge.com/a/26076/projects/40893/suites/234374 is created for the new dashboard with all the new cases are being covered their. |
Verified:
|
some requirements
follow specs on
purpose
The text was updated successfully, but these errors were encountered: