About future views

[arnaudmm]

Hi!

I have a proposal about views and layout... Tell me what you think

First page would be a "dashboard" view with 4 elements

1. total host number (when you click on this number, you get a list of hosts, when you click on one host, you get into a page with a table listing all process on this particular host)

2. total "type" of processes (given by process.group). Same logic, if you click on this number, you get a list of process type and if you click on a type...

3. total processes. If you click on this number, you get a big table with all process (whatever host, type..)

4. maybe other informations like total stopped/running...

NB : every table view could be sorted

[sagikazarmark]

I am not sure I can follow, but it seems to be a bit complicated. I think the less the clicks are the easier the application is to use.

However my initial plan was to allow layouts as well.

The main dashboard should display at least the list of hosts. Additionally, in grid view some processes could also be displayed. I say some, because in case of long process lists the main page could end up being too long. There could be some pagination as well.

The other type of layout is list view, where the servers are listed optionally with some basic information about it. From here you can go to the list of processes.

About process groups: my plan was to sort the process list by groups and indicate somehow that given processes belong to the same group.

total host number (when you click on this number, you get a list of hosts, when you click on one host, you get into a page with a table listing all process on this particular host)

How do you imagine this? Display only a number on the main page initially? My other concern is that displaying many data in one, complex structure can be confusing.

Thanks for your ideas, let me know what you think.

[arnaudmm]

From my point of view, main page should not display processes... because I have too much and there is no reason to display some. But it's only my point of view, I'm here to propose!

I did a google draw to illustrate: (maybe you can give me your gaccount if you have to edit it)

https://docs.google.com/drawings/d/1q2XYzQlgsAHzEhHqMiXfDEHgdN-TwcYGcvPWp66k4NM/edit?usp=sharing

[sagikazarmark]

Ah, I think I see now, but I still have questions.

Should the process groups be cross-server (meaning grouped by name from all servers) or not?

Basically this layout is the same as the list layout I described.

About long process list: this is exactly why there was a limit in the grid layout (which you removed IIRC in a PR). So there is a list view where only the servers are listed (and/or process groups?) and there is a grid view where the servers are displayed in a grid and some processes are displayed as well, but not all (because of the long list possibility). This is where a pagination could make sense.

But essentially the way you propose is almost the same as I imagine list view (which should currently work by appending ?layout=list (or something like that, I can't recall) to the URL).

[sagikazarmark]

Thanks for the drawing 👍

[arnaudmm]

Should the process groups be cross-server (meaning grouped by name from all servers) or not?

Yes!

About long process list: this is exactly why there was a limit in the grid layout (which you removed IIRC in a PR). So there is a list view where only the servers are listed (and/or process groups?) and there is a grid view where the servers are displayed in a grid and some processes are displayed as well, but not all (because of the long list possibility). This is where a pagination could make sense.

Yes I found the list layout, It could be a good start!

What do you about layout pages taking parameters like host or group? to be able to filter results

[sagikazarmark]

I am not against multiple layouts (simple, advanced, etc). Actually, it is client side configuration. I am even thinking about that this part should completely be rewritten so that you don't have to reload the page to choose another layout. Every data is passed to the client side and it formats it the way the user chooses. The reason that keeps me back is that we would have to create a REST API for that to work which would expose the API to the world. By passing everything directly to the twig template, it is not true.

About process group loading: we have to think about it. I can't see the benefit and the hard things that might occur, but I don't reject it either.

I think any filtering/sorting should be done client side so that applying an additional filter does not require the site to be reloaded which means less requests to the API.

[arnaudmm]

Agreed but unfortunatly, i'm not a JS guy. Passing a big data structure to the twig template could be a workaround to start playing... but ok not the best solution

[sagikazarmark]

I am familiar with JS, but using it here might be an overkill. Also, this tries to be a simple monitoring app. The only thing that drives me there is the fact that every page reload is an XML-RPC request to one or more servers which takes time. I haven't tried, but page loading for 5-10 servers might even take a minute.

[arnaudmm]

hey it's really fast, I have 45 servers here and it takes 500 ms to load (all my server are on the same private local network)

[sagikazarmark]

OMG!

But it makes sense on a private network. Imagine case where servers are on the internet.

However this is an admin tool, so probably it doesn't make sense to use it for internet servers. But we still have to test it's performance.