improve user experience TFGrid

[despiegk]

some requirements

• single login widget (being worked on)
• more consistent UI experience and more easy for users to use
• more often values can be saved automatically (e.g. if someone copies SSH key in, or at least warn that it needs to be doen)
• now it says the deployment is invalid on the top, but hard to see and also doesn't show what
• integrate monitor stats from https://github.com/threefoldtech/home/issues/1453 on the overview grid

follow specs on

• see this gdoc
• we need more community input
• scott/mik will driver the experience, review, ... and will accept the changes

purpose

• have a UI which is usable and good enough for people to use us as jukebox for VM's

[despiegk]

can't click on left "full virtual machine again", have to click on other element before I can go back, this is not logical because maybe I just want to create a new machine now

[despiegk]

when I start its checking my config but haven't filled anything in,

this is not logical

would prob still be better to check once someone clicks on DEPLOY

[despiegk]

needs to go to 16 GB of mem

[despiegk]

deploy button is very small compared to the rest and difficult to find

[xmonader]

Most are indeed tracked in the 3.13 project https://github.com/orgs/threefoldtech/projects/199

[Mik-TF]

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 Improvements

Issues

• The current widget approach is too slow and too unreliable
• All the checks make it so slow
• Then often it fails anyhow at the end
• It's also way too difficult to figure out where to deploy

Improvements - UI Flow

• The start of widget ok, let people put requirements in
  • Mem,CPU
  • Network
  • Name
  • …
  • NO CHECKS AT THIS STAGE TO NETWORK & ZOS
• Better defaults
  • Network std Mycelium see https://github.com/threefoldtech/home/issues/1480
  • Make sure there is also machine 8 and 16 GB with bigger ssd disks
• Once all requirements put in, let user click on a FIND NODES button
  • Now show a grid of nodes (see vast.ai) which shows size, utilization, location, …
  • See https://github.com/threefoldtech/home/issues/1453 for info which will be available
• Now the user selects one
• After selecting there are more checks if needed, if it wouldn’t work out show grid again and apologize
• GO OVER ALL ERROR MSG;s and make sure they make sense, now so often it just says something which people will not understand.

Community Feedback

Here 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 Inspiration

As stated, we want a smooth experience as with https://vast.ai

UI Details

• All fonts need to be more same size, in middle fonts now too big
• Fonts are too big no matter what

Deadline

Ideally, 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.

[Mik-TF]

Different Parameters

Here are some parameters that would improve the user experience.

• to be able to simply select

  • farm (without needing to select the country)
  • nodeID (without needing to select the country or the farm, i.e. all nodes show)

• to be able to write a farm name and find it (without needing to select the country)

• to be able to write a nodeID and find it (without needing to choose a farm before)

• to be able to find farms/nodes by regions and/or by countries

  • regions
  • All Regions
  • north america
  • south america
  • europe
  • asia
  • africa
  • oceania
  • Countries
  • All Countries
  • specific country A
  • specific country B
  • ...

• to load nodes by node certification types

• to load farms by farm certification types

• to load nodes by gpu

• to load nodes by gpu types

• to load nodes by uptime (e.g. > 98% during the last 2-3 months)

  • might not be feasible soon

• to load nodes by Inet up

  • might not be feasible soon

• to load nodes by Inet down

  • might not be feasible soon

New Flow

In 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:

• Users open the playground deployment window
• Users choose their parameters
• Users click on "Search"
  • then the playground searches for the nodes, not before
• Users select the node they want
• Users click on "Deploy"

Notes

Some of those parameters might already be in current issues. We will track if this is the case.

[xmonader]

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.

[Mik-TF]

"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.

[xmonader]

Couple things to clear out

• As a user, the only nodes I'm only concerned with are the nodes that I rented (as dedicated to use for my workloads)
• As a user of other cloud providers I don't specify which physical server my virtual machine runs in ( I understand some just put nodeID, but that was a clear requirement from Kristof, I added that back on community request, maybe it's the right thing, but still as a user I shouldn't count on a specific node for my deployment, I shouldn't be aware of any actually, all should be managed by the farmerbot and it does the capacity planning, again as the requirement from before from Kristof.
• I definitely agree that I don't want the user to jump around, I'd even go one step further and enable reserving a node directly while deploying a solution from the UI :)

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

[scottyeager]

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:

• Users today are commonly also farmers or working directly with farmers, so they know and care about nodes
• We are not another cloud provider offering a homogeneous product to users. Nodes can be vastly different, including being partially faulty
• Farmerbot is currently optional. Maybe in the future it's mandatory and all deployments are done in coordination with it, but this is now

[xmonader]

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:

• it appears that many farmers who have more than one node or a reasonably larger farmer use the farmerbot already for power saving, so I can't really count on having a specific node while deploying given the power management. Is there any specific reason other than nodes capabilities? I know RobertL needs to do it that way

• having a node ID doesn't make much difference for single-node farmers which are supposedly the majority of the farmers. Choosing their single node farm while deploying should be enough

• from an enduser perspective, who has no relation with any farmer, the only significant nodes are the ones I rented, other than that all are the same unless there is some sort of capabilities exposed (which isn't) around the nodes that I take into consideration

• I agree they could be partially faulty, but that's on the farmer, and they need to fix their setup not the user jumping around to find a working node (we will be providing node test results for nodes health anyway)

[scottyeager]

Here's a basic example with how the playground works today:

1. I have a VM. It's been reliable and I want another one just like it, but I don't remember which farm or node it's deployed on
2. So I open up the workload details and get the node id. Farm id or name isn't visible
3. I have to go to the explorer to check the farm info, then come back to the playground and drill through the menus
4. I'd rather just enter the node id. If I can't deploy on this node again (cause it's full for example), that's fine, the playground can helpfully suggest me another node from the same farm at this point

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:

1. I have a VM, and I want a second VM that has at least LAN speed networking with the first one
2. Knowing the farm of the first VM doesn't necessarily help that much, because farms can span multiple physical locations
3. If I can get another VM on the same node, great!
4. If not, maybe in some future system the playground (+ farmerbot) could be able to suggest me a node in the same LAN, but we can't reliably know that without knowing the node id for the first VM

I agree they could be partially faulty, but that's on the farmer, and they need to fix their setup

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.

[scottyeager]

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:

• Farm and country selection are optional and independent
• It's possible to select manual mode and skip straight to entering the node id
• We enter preferences first and then hit a button to query matching nodes. There's not a lot of waiting to load and validate data between steps

What can be improved:

• Mandatory and potentially confusing option for the user: "Manual" vs "Capacity Filter"
• Have to wait to load the full list of farms every time we choose Capacity Filter
• Some options like certified are missing

I'd propose to return generally to the approach of the old playground with these changes:

• Rather than a drop down with "Manual" vs "Capacity Filter", there's just a toggle labeled "Manual". By default it is disabled and the filter menu is shown
• Add regions selector. Simplest would be continents. This can be used by itself or as a way to narrow the country selection. Country selection can also be used independently
• Load and cache some data about farms (and maybe also nodes) in the background as soon as the page loads. If possible, hang onto it when user navigates to a different solution so there isn't so much loading of duplicate data and waiting on that
• After the search, it's okay for now to just present the user with a list of node ids. But as soon as there's more information to show regarding performance, uptime, etc, these should be included in a list than can be sorted, rather than a drop down menu

[Mik-TF]

To complement what Scott is saying here, this is the Playground flow that we propose:

Playground Revisited Flow

We propose the following flow:

• The user selects a weblet on the Playground menu
• The weblet page is composed of two sections, Deployment Configuration, and Node Filters
  • (1) Deployment Configuration (this is the same as the current Playground, example below as with a VM)
  • Name
  • CPU
  • Memory
  • etc.
  • (2) Node Filters
  • There is a toggle button named Manual Selection (disabled by default)
    • Enabled: When enabled, the user is presented with the Node ID section.
    • The user can write directly the node ID and click the button Deploy
    • Disabled: When the toggle button is disabled, the user is presented with the Capacity Filter section
    • The user can decide to use optional filters
    • The user then clicks the button Search Nodes
    • Once the nodes are fetched, the user clicks the button Deploy
    • Notes on the filters
    • The filters are all optional (i.e. the user can click the Search Nodes button directly or choose some filter options before triggering the search).
    • The filters are independent (i.e. the user can use them all, none, or some of them)
      • Filters:
      • Farm name (Optional)
      • Region (Optional)
      • Country (Optional)

---

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.

[xmonader]

Another note these optional filters

The filters are independent (i.e. the user can use them all, none, or some of them)
Filters:
Farm name (Optional)
Region (Optional)
Country (Optional)

they should affect each other e.g

• if i choose a country, the upcoming list of farms should be farms within that country
• if i choose a region, the allowed list of countries and farms should be with in that region

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?

[AhmedHanafy725]

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?

[Mik-TF]

@AhmedHanafy725 @ehab-hassan

I think this looks amazing! And will be appreciated by the different kinds of user.

• Some notes/propositions for the texts:

  • "Choose a node selection method"
  • "Enter a node ID"

  ---

  @xmonader

  I agree with you. I wasn't clear in my communication. I will try to reformulate it.

[Mik-TF]

New Playground Flow v2

Here is a proposed workflow that makes use of the radio buttons, with more details on the possible filter combinations.

Automated Method: Filters

• Region (optional)
  • All regions
  • Region 1
  • Region 2
  • ...
• Country (optional)
  • All countries
  • Country 1
  • Country 2
  • ...
• Farm (optional)
  • All farms
  • Farm 1
  • Farm 2
  • ...
• Node ID
  • Automatically fetched node ID, with a drop-down menu to present all possible nodes.

---

Node Selection

• We use the radio buttons for Automated and Manual node selection. Automated is set by default.

Automated Node Selection

• All regions, All countries, All farms, are set by default
• Node ID
  • For every possible combinations of filters, a given node ID is always proposed by default
  • The user can always use the node ID drop-down menu and select a node within the available node list

Filter Combinations

• The user has many possibilities when it comes to using the filters. Let's try to cover the general patterns:
  • All regions, all countries, all farms
  • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.
  • All regions, all countries
  • The user selects a farm
    • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.
  • All regions
  • The user selects a country
    • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.
    • The user selects a farm (from that country)
    • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.
  • The user selects a region
  • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.
  • The user selects a country (from that region)
    • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.
    • The user selects a farm (from that country)
    • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.
  • The user selects a farm (from that region)
    • The user uses the node proposed by default or uses the node ID drop-down menu. Clicks deploy.

[Mik-TF]

Summary of the 3 issues to improve UI:

• automated/manual radio buttons for node selection
  • https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1094
• regions added as a filter
  • https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1449
• All Regions, All Countries, All Farms added as a choice for the filters.
  • https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1453

EDIT: This was updated.

[Mik-TF]

Most of the tasks demanded here are now done on the Playground devnet. Thanks everyone.

One thing left is this:

• For every possible combinations of filters, a given node ID is always proposed by default

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 @A-Harby @xmonader @scottyeager @ramezsaeed @MohamedElmdary

I can create an issue on this if it's possible to implement it. Thanks.

[AhmedHanafy725]

@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 loadNode button to get some nodes that satisfy the new filters. This has already been deployed on devnet.

[Mik-TF]

@AhmedHanafy725 It looks amazing. Very user-friendly.

On my part, all the tasks asked have been completed. Thanks again.

[xmonader]

Extra issues after a review from @despiegk

• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1861
• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1878
• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1863
• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1862
• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1869
• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1866
• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1867

[xmonader]

a major update for the node selection https://github.com/threefoldtech/tfgrid-sdk-ts/pull/1884

[A-Harby]

Verified, Devnet 7b55dd4.

• single login widget
• more often, values can be saved automatically
• more consistent UI experience
• Better Nodes UI/UX, filters, and loading.
• breadcrumb for the navigations.
• Reorder Sidebar
• New filter has been added as regions and UX have improved.
• Also with every new load node or application, a random node is proposed every time.
• https://github.com/threefoldtech/tfgrid-sdk-ts/issues/2080 and https://github.com/threefoldtech/tfgrid-sdk-ts/issues/2079

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.

• Profile Manager section.
• TC2156 - all fields have clear hints
• TC2461 - Node details in Load Nodes List
• TC2488 - BreadCrumb Navigation
• TC2186 - Select instance capacity
• TC2197 - Verify Sidebar
• TC2444 - Filter Nodes by Region
• TC2307 - Error message for filter failure

[ramezsaeed]

Verified:

• Devnet
• 99e15a0