/Overview, support 10 - 100 processes

[mcdonnelldean]

Hey @thefoxis so we need to support a high level list of processes, 10 - 100. Let's do the design on the overview screen using our list of processes. We are going to do the collapsed detail a little later with data coming down the line.

The current list is a good starting point for data right now, each process needs to show:

• Tag (arbitrary - 30ish cars long) (we don't have this in the live data yet)
• Pid
• Host (ip address) (we don't have this in the live data yet)
• Current Event Loop data
• Current Heap / Mem data

Everything else can be dropped.

We also need a bigger indicator like a big square. It's states are

• Green - Healthy
• Amber - Under Stress
• Red - Terminal
• Black - Dead

Dead process tend to stick around until the data they emitted has gone out of view.

In terms of grouping we need to be able to group the list into collapsible sections by host, tag, both, or none. We also need the same context for the search bar (except none).

Generally the more items on screen the better. We are looking for maximum glanceability. (I've always wanted to say that) :)

If you post the list of css classes I need to change the various states I can update the logic in the morning to power it all.

note: can we do this work on a branch so we can have a bit of freedom to get it working, this means you can add static bits to the screen if needed.

P.S To add more services under monitor open new terminal windows and run node -r toolbag test.rig.js Note you need to globally install toolbag to do this npm install -g

@mcollina Anything you would add?

[thefoxis]

I'm unsure about this bit @mcdonnelldean:

In terms of grouping we need to be able to group the list into collapsible sections by host, tag, both, or none. We also need the same context for the search bar (except none).

how would you collapse it? if the information was still in card format and had rows and columns, tag and host would be single column and row so collapsing it wouldn't really gain any space. maybe you can do a sketch or something to visualise it as I don't understand what we're aiming for.

I think if the need is to list a lot of information with many properties we have to go with a table. Unfortunately even with that layout there are too many columns to display to make it plausible which is why I came up with a solution. Here's what I'm proposing:

• use a table, as currently pictured
• for heap usage and event loop merge three cells into one with descriptive, smart language like so: 73/100mb (103mb RSS) or 73mb used out of 100mb (103mb RSS) and 4s delay (30s allowed). if the limits are exceeded we'd either add a class for the cell to change text colour accordingly or have the status change on the left hand side (if it's correlated, but I think changing cell text colour makes it easy to spot what's wrong)
• dim the text on dead processes (done by attaching a class on row)
• currently the table is scrollable on mobile, we could use this solution by Zurb to make the first column fixed for context

let me know what you meant with collapsing / sorting for the data and search scenario so I can amend. does the proposed solution sound / look alright? I really believe that'd be the best way of displaying a lot of data.

[mcdonnelldean]

@thefoxis Ok so my fault I should have explained the grouping.

So every process we track is a single node process. It's super common to have multiple instances of the same process running. To group these together we give them a text tag, like a nickname. If you take your example above, you may have 4 processes if they are all tagged the same they are considered instances of the same service.

On top of that each process may live on a different host, so even though all of the processes above are tagged the same the could all live on different boxes, you see this when you're doing geo redundancy for instance.

With that in mind every process will have two group fields, it's tag, and host. All we want to do is give people the option to group by them in collapsable sections.

We will always receive the data data as a flat list of processes with two keys, I manage the grouping on screen.

The collapsed sections will just have the counts of healthy, stressed, terminal, and dead services on it. These can be color coded. This is about as much info as you know at a group level

In terms of the table. I think a combination of combination data you did above plus the original overview with everything below the uptime section nuked would work well. The problem with the table is I can't add to it after a certain point. With a list I can trade vertical space for more info. Making the whole list section smaller, like the table would work wonders for fitting more on screen.

I really want to avoid tables as we are destined to need more data, I'd rather cards with tabular data in grouped list format.

On the list in terms of grouping it's only every

• Don't group
• Group all processes by tag
• Group all processes by system
• Group all processes by system and tag

The system by tag is still a flat group, we just combine both fields together.

Don't nuke this table design from the styles though, I have an idea for this table on another screen :D

[thefoxis]

I kept the styles for the table and its markup for now. Process cards are now smaller and include system and process uptime. You can mark each cell as being under stress or terminal with a class, along with changing the main status next to the pid. the process container panels should be collapsed and expanded through the icon in the heading where the grouping information is shown. dead processes are dimmed. if that's not compact enough we can have all information in one row.

[mcdonnelldean]

@thefoxis Looks awesome on screen, I've rebased the branch with baster so you might need to pull the branch fresh. I'll continue working on this branch to get it functional. Epic stuff!