Open olivierlambert opened 7 years ago
Models links : https://bl.ocks.org/mbostock/4063550 http://bl.ocks.org/NPashaP/cd80ab54c52f80c4d84cad0ba9da72c2 https://bl.ocks.org/mbostock/4062045 https://bl.ocks.org/mbostock/4339083 https://thepowerrank.com/ncaa-tournament-predictions/ http://bl.ocks.org/syntagmatic/4092944
Branch : https://github.com/vatesfr/xo-web/tree/cbs-innovativeTreeView
I like this one that separate correctly all the potential pools: https://bl.ocks.org/mbostock/95aa92e2f4e8345aaa55a4a94d41ce37
I do not want to tilt my head to read a tree. What is wrong with a table layout with rows in alphabetical or any order under each host. It is the basic tree view xenserver gui has always provided. Please bring a basic tree view that lists vms under their hosts back. Very frustrating without it, I find myself opening up xencenter to easily see tree view when I'm paying all this money for xoa without a tree view.
@dpcinc The table or tree layout is not compatible with a big infra.
Why not? Maybe You can pick which hosts you want to populate on the top list before listing vms under it. I'm sure its very handy to many many customers. Don't use it if it doesn't work for you. Still should be an option.
Even a sort by 'host' to give us a sorted huge list of VMs like it is now would help.
What if you have a few hundreds hosts? XO is used with small and big infras, we need to make sure each views is usable for each of those cases.
The tree view in XO 4 was difficult to used even with a few hundreds of VMs, we might reimplement one, but we'll need to make it better than the previous one.
You already have the host filter tags, so with a few hundred you'd populate that , filter your hosts down. Wouldn't necessarily have to have ALL hosts by default on a new tree view - force the filter possibly to avoid huge lists.
Another simple idea is add the option to have a 'heading row' to the current vm list that would label the host + option sort vm list by hostname would give a faux tree view . You could maintain your current pagination, however would prefer if # of items per page was user configurable as each user has a difference pain tolerance level for how many vms they want to see listed on one screen.
My three cents :
A large table view is very hard to manage with large infras. You need to somehow organize data in groups - most conveniently by the servers - in a collapsible manner (tree view....).
Pagination is a killer when managing large infras because in many cases you need to sift through the list to see issues or to check various things so filters are not so relevant because you don't always know what you are looking for (we sometimes find VMs that should be off just by scanning the tree).
A tree view has context menus. You can quickly apply actions to a VM that are harder to represent on a table view. If you need to quickly start or shutdown a VM, you don't want to click it to enter a new page and then run the action but you rather want a context menu. Time is money and time is sparse, so every redundant page load is a killer when handling tens or hundreds of VMs.
A web-based tree view may be too heavy so you might want to indeed divide it into different pools. Most often you don't go over two or more pools at the same time so it's decent to display only one pool, though I admit it's quite convenient having one big tree with all pools.
Dragging and dropping is a must-have in tree views - especially with migration. When you see things laid out in a tree, you see for each host how many VMs it has on it so it's easy to make a decision as to where migration should take place - because you identify a lightly used host easily compared to overloaded hosts with a single glimpse. Much more difficult to present in a list view.
In a tree you can do multiple tasks in one view. In a list, especially paginated - it's a pain in the hind.
Problems with web UI refreshing may be quite horrible. Any implementation must provide high levels of certainty in the data or else bad things may take place if the status of a certain VM is not communicated properly. This is true for any web UI but it's very important for hosts where tasks are carried out and if reflected incorrectly - can damage a customer environment.
Hierarchy is a MUST when managing large infras. I personally find it very hard to see things not laid out in a hierarchy with indentation such as in a tree view - because one big list is hard to read visually. I love clean, simple and communicative layouts vs. large lists with too much data...
The key is the effort needed to perform actions. When doing many IT / management tasks at the same time, you don't have a second to waste or to spare. Every page load - even 1-second long - creates a delay and it is quite annoying because you do a lot of tasks at the same time which you cannot do that easy in a long list or paginated list (filtering is an issue because you don't always know what you should be looking for). A tree view presents all data in one screen, hierarchically laid out - which is very important when managing a lot of elements.
@NithidaK we should work on "draft papers" to get a selection of various ways to tackle this issue. Can you prepare some ideas (more than "principles") and let's dig some details tomorrow!
Here are a few that we’ve inspected in the past when we built some web apps.
And with context menus:
https://dhtmlx.com/docs/products/dhtmlxTree/samples/03_context_menu/01_pro_context_menu.html
The problem with most HTML tree views is the clickable areas (e.g the expand/collapse button). Most HTML tree views are a bit unresponsive when you click and a bit annoying.
The most important requirement is fast response. Sorry for using XenCenter as a comparison but personally I find it very fast, responsive and convenient (in fact, XC is much more convenient than VMWare the client).
You are assuming that making a copy is the only solution (ie: making a tree view). It's one of the solutions ;) We investigate to find alternatives too!
@NithidaK you can check these tree demo to get inspiration:
My input on the below.
The most important thing that always goes overlooked in various UI controls for the web is their scalability to content that grows large. Many lists and tree views are nice but become horrible when they grow – especially those with animation – up to a point where expanding the tree shows a 3-4 second slow-mo tree expanding and the browser hits 100% CPU….
https://fritz-c.github.io/react-sortable-tree/ https://fritz-c.github.io/react-sortable-tree/ Nice and quite fast and responsive (VERY important, especially with many items in the tree). The layout is too space consuming (I guess it can be tweaked).
http://alexcurtis.github.io/react-treebeard/ http://alexcurtis.github.io/react-treebeard/ Horribly slow in response (clicks follow my mouse with a delay of about 0.5 second!) although quite clean layout.
https://cdn.rawgit.com/chenglou/react-treeview/aa72ed8b9e0b31fabc09e2f8bd4084947d48bb09/demos/index.html https://cdn.rawgit.com/chenglou/react-treeview/aa72ed8b9e0b31fabc09e2f8bd4084947d48bb09/demos/index.html Simplistic… not much to test here so can’t say much.
http://jonmiles.github.io/react-bootstrap-treeview/ http://jonmiles.github.io/react-bootstrap-treeview/ VERY FAST and responsive, good layout.
Best Regards,
Avi Bluestein, General Manager
interconnect
From: Olivier Lambert [mailto:notifications@github.com] Sent: Monday, December 11, 2017 3:22 PM To: vatesfr/xo-web xo-web@noreply.github.com Cc: aviblue avib@interconnect.co.il; Comment comment@noreply.github.com Subject: Re: [vatesfr/xo-web] Innovative tree view (#2029)
@NithidaK https://github.com/nithidak you can check these tree demo to get inspiration:
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vatesfr/xo-web/issues/2029#issuecomment-350722440 , or mute the thread https://github.com/notifications/unsubscribe-auth/Ag1SlFGfEzrlpz0hddv2ZdvIdTFTnA2Cks5s_Sx2gaJpZM4MjNBt .
We started to experiment on react-sortable-tree
up to a point where expanding the tree shows a 3-4 second slow-mo tree expanding and the browser hits 100% CPU….
I often ran into issues when web pages are animated and you are (because of reasons) connected over RDP... you just wait 5 ore more seconds to get the next frame and all is slow and unresponsive. I also have this issue with remote service tools (like TeamViewer). Most annoying case is Internet Explorer which loads an animated newspage as default!!
So it would be a good idea to make animations optional (an option to turn them off completely).
I personaly like the tree view in XenCenter a lot. And I saw this picture: (https://blog.paessler.com/prtg9-features-tree-view-filtering)
So I created a visual mockup:
Just the image:
Image with some sort of Browser:
How many pools do you display? What if you have 20 pools?
edit: thanks for the idea by the way :)
@olivierlambert what if I have 2000 Pools? ( I would be rich ;-) )
I think there is not THE solution to this... do you have some images of your experiments in the tree field? Maybe XO should have more than one tree-/graph-/table-/displaying mode.
Do you know Check MK? They have multiple views, so you can show more or less details depending of the a mount of pieces you want to see.
some host/services: (https://www.sico-systems.de/wp-content/uploads/13.png)
many host/services: (https://www.vdsar.net/wordpress/wp-content/uploads/2015/01/Check_MK_vdSarICT-4.jpg)
By the way: I hope you and @stormi are pleased with the test pool names ;-)
haha didn't spotted the names ;) Sam isn't working on XO btw :p
As you said, the difficulty is to provide something that adaptable from 1 to n pool (we got customer with hundreds of pools).
Sam isn't working on XO btw :p
I know :-)
Stormipool :+1:
Just like to add that not having a tree view is the only reason that I sometimes use XCP-ng center, so I can easily see where all the VM's are located.
I've just counted: default tree view of Xencenter on landscape FulllHD let me see a host in a pool and up to 36 VMs on that host.
There is 2 different needs:
Where?
Collective tree view
In fact, the only needed thing in the tree view is to visualize easily the number of running VMs on each host in a pool.
This could be achieved with our first idea of the "molecule view" (https://bl.ocks.org/mbostock/4062045 "-ish")
Limiting this per pool would be easier to deal with it at the end, and it opens a lot of opportunities with dot size and color.
Adding this too: https://bl.ocks.org/mbostock/9a8124ccde3a4e9625bc413b48f14b30