Kver wrote:With the recent discussion on system monitors over at user prompt I've started throwing ideas together; As the prompt wraps up I'll refine this if wanted.

Looks good to me, some points:

• the graphs are too curvy, IMHO. I'd prefer something like the current plasma CPU widget is using at most.
• the graphs are also taking too much space on the overview. IMHO, just show them in their individual tabs and leave the overview for processes only. Or make them much smaller.
• I'm missing a disk I/O column on the overview
• I'd expect to see an up/down in Ki|MiB/s in the Network column instead of MB it.. downloaded? uploaded? both? not clear from the current design
• The process icons should not be smaller than the warning icons
• I don't think "using large amounts of x" is really necessary, the red/orange text says it all imho. Removing that would fix the uneven table row height and save some space overall

What will the different tabs show, precisely? My guess is something like

• CPU Tab
  • per core usage graph with % display
  • CPU info (name, current frequency, ...)
• Memory Tab
  • RAM usage graph with Ki/Mi/GiB total usage
  • RAM info (number of DIMMs, their size, current frequency,...)
• Storage Tab
  • per physical (or logical?) volume usage graph with Ki|Mi|GiB/s read and write display
  • I/O display in %
  • HDD name (as listed in hdparam/smartctl)
• Network Tab
  • per adapter network usage graph with Ki|Mi|GiB/s up and down display
  • each adapter name (as listed in lspci)

Or at least that's what I'd like to see.

edit: added I/O display in % for the storage tab. It's sometimes more descriptive than I/O in MiB/s, think small file access on an HDD.

Kver wrote:With the recent discussion on system monitors over at user prompt I've started throwing ideas together; As the prompt wraps up I'll refine this if wanted.

First, I congratulate you. It looks like very good but I think "End Current Process" button could be more stylish. It looks rough. Icons are so big.

Design should be generally more serious not such as toys. For example some laptops have lots of CPU core, this application should be handle it. I'm following

User comments from the survey [1] were summarized [2] and transformed into the requirements:

* Show an overview about the current status in order to inspect system health and find misbehaving processes.
* Monitor system activities to understand and predict the development of process activity.
* Show information per process including all depending properties to get a comprehensive summary of activities.
* Provide extended access to single process to maintain operability of the system.
* Follow the vision of being ‘simple by default and powerful on demand’ for a perfect UX.

You find the full blog post at http://user-prompt.com/ksysguard-the-green-paper/ with some mockups [3] to initiate the discussion here.

[1] Survey about requirements http://user-prompt.com/ksysguard-what-a ... m-monitor/
[2] Working paper; Etherpad at User Prompt https://etherpad.user-prompt.com:8082/p ... KSysGuard#
[3] Balsamiq Mockup prototypes at KDE share https://share.kde.org/index.php/apps/fi ... -KSysGuard

Heiko Tietze wrote:User comments from the survey [1] were summarized [2] and transformed into the requirements:

* Show an overview about the current status in order to inspect system health and find misbehaving processes.
* Monitor system activities to understand and predict the development of process activity.
* Show information per process including all depending properties to get a comprehensive summary of activities.
* Provide extended access to single process to maintain operability of the system.
* Follow the vision of being ‘simple by default and powerful on demand’ for a perfect UX.

You find the full blog post at http://user-prompt.com/ksysguard-the-green-paper/ with some mockups [3] to initiate the discussion here.

[1] Survey about requirements http://user-prompt.com/ksysguard-what-a ... m-monitor/
[2] Working paper; Etherpad at User Prompt https://etherpad.user-prompt.com:8082/p ... KSysGuard#
[3] Balsamiq Mockup prototypes at KDE share https://share.kde.org/index.php/apps/fi ... -KSysGuard

I'm glad I waited until the end of the study until producing/pushing more designs, overall it's a much better direction than I was moving. I think as a system monitor there's much more meat on your designs. I'll have mockups fourthcoming now that I have a better for the aim of this thing, but for now here's my interpretation of the results view-by-view;

System Health
The overview, being the first thing users would see when they launch this application, should be the most simple and user-friendly view with easily digestible information; the 'simple by default' end of the scale with the expectation that general users should easily understand it. I would break system health into 3 sections; realtime usage, storage, and alerts.

Realtime usage would default to Processor, RAM, and network charts. They would be amalgamated graphs, so if a user has 6 CPU cores or 2 physical CPUs it would still show only one emblem with the overall usage. The user could add more graphs but those are the 'big 3' which every monitor defaults to. I wouldn't default to having any additional sensors, as (unless there's an issue) things like fan speed and CPU temperature don't impact performance or stability - unless at a point where it should be an alert. As was mentioned in my designs, we should consider abandoning the graphical icons, unless we use doughnut charts or gauges and want to fill the white-space. I would put the extra sensor options as a checklist in the menu.
Storage would show the storage drives and their space. For each storage drive we could include an I/O blinkers and throughput meter to show their live usage, eliminating the need for storage graphs.
Alerts would show important issues. Mainly, alerts would flag misbehaving processes, but for issues such as certain components are especially hot we could show those as alerts too, partially eliminating the need for temperature monitors by default. Other events of concern could be posted, such as hard drive failures, RAM faults, or too many fridge magnets stuck to the tower.

I would strip out the per-process pie-chart from the main UI, it takes up a huge amount of space and seems to be mostly filler data. Instead, I would simply have it be an advanced tooltip; hover over the real-time widgets and show just the graph and capacity information. It also requires the sensors be implemented as buttons with tab-like behaviour when they don't have that layout, which isn't immediately obvious; it took me my third pass to realise that was going on. This will save UI space, clean up the interface, and avoids needing to justify used space with otherwise needless information.


Heat List Monitor Processes
I would combine the heat map and the monitor graph into one tool, much like my previous mockup. The requirements for both 'Philip' and 'Matt' are still satisfied by a combined view. I would add the ability to pause data collection, scrub the data, and select a process in the heatmap to highlight its usage in the graphs. By combining the two related tools we get one much more functional utility.

Pause/resume/record: 'Philip' especially would enjoy this feature, especially if the problem at hand is something that only happens in a short time-span. Additionally, he may need time to interpret the graph properly. For example, if Philip is inspecting the graph because Firefox is acting strangely, he may want to pause it while he interprets the issue. There could be a 'record' option which will assist in capturing arbitrary time-frames.
Timeline Scrubber; if we're collecting statistics for the past timespan, both Philip and Matt may want to look at what happened in a specific moment. Not only could data collection be paused, but that collected information could be scrubbed to view what was happening. For example, if there was a CPU jump 4 seconds ago, the users could pause the collection, and scrub to the jump to see what was happening that exact moment. The process list would also be updated to reflect the moment so the users could use the heat-map, locating what caused the spikes in more detail than a tooltip.

By letting users select specific points in time to examine, combined with highlighting an app to see just that applications' usage graphs immediately gives users the ability to pinpoint chokes and specific usages.


Processes Inspector pop-up
I hate to say, but I'm not entirely convinced with the current design...

I would make the per-process inspector launch in a separate window, possibly launched by the process browser, and have it in sync with the main window; if you paused the main window to closely debug what you've seen, the process inspector would pause. If you scrubbed to somewhere in the timeline, they would stay in sync, etc... This way, you could simultaneously debug multiple processes.

I would change the style of the graph to one closer to the Glave/Vulkan debugger uses, where there's many compressed graphs. Perhaps clicking on an individual row may 'decompress it'. Overall, I'd just try to organise the information a bit more thoroughly... I'll do up a mockup at some point to show some alt layouts.


Separate 'Kill Process' app
One thing I will put on the table would be keeping an extremely streamlined/simple 'Kill Application' utility for general purpose application takedown, one separate from the monitor - similar to what we have now, but a little more purpose-driven. I know some people in the threads bemoaned the idea of keeping two applications which might show processes, but we have two very different goals for each application and we could further streamline a general 'Kill frozen applications' tool. General users looking to kill a frozen application just want to get in, get out, and work again - no matter how you slice it, this new monitor design would be overkill for just application killing.

TheBlackCat commented the blog post and wrote:Overview:

I think two rows of information per item would be better
1. For CPU, it should show the overall percentage in the first row, and percentage per CPU in the second
2. For a RAM summary, it should show the amount used in the first row, and the percentage used in the second row
3. For network, it should show down in the first row, and up in the second.
4. For harddisk, it should show percentage used in the first row, and rate in the second row
5. For power, it should show percentage left in the first row, and amount in the second row

I was afraid to have too many information on the start page but you add even more . Seriously, I'm not sure if Berna looks for more than just the colors.
Please take the configuration into account (sidebar overlay on click at the hamburger menu, illustrated by the panel right hand).

TheBlackCat wrote:Monitor:

1. I think that a logarithmic time axis would be more useful in most situations, so I think it would be better as a default, but at the very least should be an option.
2. Would this show one line for each CPU (in this example), or one line for each of the top N processes, or what?
3. It should probably have layouts like the heatmap.

Logarithmic sounds interesting for techies. And the famous Weber-Fechner law states such a relation between stimulus and perception. But that's not true for time, IMHO, or at least it's a delicate topic. Plus, you lose the opportunity to aggregate data what I suggested. For instance, you get a value every second but the sensor provides 100Hz or more. By averaging you smooth extreme values like high CPU or I/O on program start which isn't relevant.
The lines represent "sensors". That could be an overall CPU load or load per single CPU. And you can add as many you want. Perhaps it's a good idea to have the "layout" storage from the other section here as well .

TheBlackCat wrote:Heatmap:

1. Might it be better to have one scrollbar per section?
2. There should probably be an ungrouped view, or perhaps a checkbox on whether to group.
3. Giving the numbers units might make it easier to quickly scan across columns without having to look up at the column names all the time.
4. I think having the graphical meters in the cells is useful, I wouldn’t take that away. But as I said before, I think having an additional vertical moving line like in music player spectrum meters would be helpful

Please do not clutter the GUI with scrollbars; a configuration switch could work.
But I believe this type of organization is very challenging anyway since we have a highly structured tree right now (akonadi_control>akonadiserver>mysql). What do we show under what section?

TheBlackCat wrote:Processes:

1. History should probably be searchable and some filters
2. It should probably have window manager information, when appropriate, such as what desktop it is on, what activity it is in, whether it is minimized, maximized, shaded, etc.
3. I would put a quick list of current usage (CPU, RAM, network, IO), or average usage over the last 1 or 2 seconds, to the right of “information”.

I wanted to create a separate section for info that doesn't belong to other. Something like output of external programs. And of course it's possible to split that information into different sections and add more stuff.

Kver wrote:System Health
The overview, being the first thing users would see when they launch this application, should be the most simple and user-friendly view with easily digestible information...

Signed! But do you mean three fix sections? Why not show as many tiles as the user want. And that means you cannot predefine sections. What if the system has two network connections, or the user needs to observe hard disk activity?
I wouldn't show many charts. The tiles shouldn't be over-informative, no blinking, no gauges, and definitely not this 'doughnut thing' - just the color. But one chart to see the top processes in relation to the selected sensor capability makes sense. Even when it clutters the overview a little bit.
Please keep an eye on the configuration. Every specific alert such as RAM faults would require hard-coded thresholds. If it's a sensor it can be shown along with thresholds (min/max value with lower/upper warning and alarm thresholds that are user-defined; in case of faults 0,1000:1,-,2,-).

Kver wrote:Heat List Monitor Processes
I would combine the heat map and the monitor graph into one tool, much like my previous mockup.

Sounds reasonable. However, the monitor shows sensors and the heatmap processes.
The pause feature is a really good addition to the requirements.

Kver wrote:Processes Inspector pop-up
I hate to say, but I'm not entirely convinced with the current design...

As replied the TheBlackCat this section intends primarily the need for information from external programs. Sure it can be done better.
Your wording is truly better. But I would call this one just Inspector without the 'pop-up'.

Kver wrote:Separate 'Kill Process' app
General users looking to kill a frozen application just want to get in, get out, and work again....

There is a terminate button (I intentionally call it different than the advanced stuff at the heatmap section but it should be SIGKILL) at the overview for a selection of processes that misbehave.

Feedback Nitpicking on the Green Paper.

Overview section
Icons in boxes in a grid is hard to scan (my pet peeve). A plain list with little icon, label and value would be more efficient and less busy layout choice.

Heatmap section
Hopefully a placeholder name to be replaced with something descriptive like 'Processes' .
Is there there any point in dividing processes into user, system and kernel processes? All it does is make it harder to see what is consuming resources.
A table column for sorting would provide all the benefits of grouping without none of the complexity of this one.

I'm assuming that the rightmost box is what the hamburger menu shows.
You have placed column selection into the hamburger menu when its logical place is in the context menu of the table header. At least I've been under the impression that every kde app has it there (a feature I love). It is a little less discoverable, but not so much that this part of this app deserves to be a special snow flake .

Please, do not put a dropdown in a table data cell, unless it's for editing data in that cell. Having a drop down for actions is justifiable only as the last cell of the row. In this case, a context menu for the entire row would be in order.

Processes section
This section looks informative, but the ui is clunky. Presumably, double click in the heatmap brings you here with the right process selected, but then you can't easily compare processes. Changing the viewed process with the dropdown at the top will certainly be unusable (several dozen items with cryptic names or and possibly duplicates).
[idea=]
I'd rather have this process detail information presented in tabs, ie, double click in the heatmap opens a tab here for the clicked process. That would allow keeping an eye on more than one process without going back and forth between this page and the heatmap.
[/idea]

alamaki wrote:Is there there any point in dividing processes into user, system and kernel processes?

Grouping is done to break down the long list into digestible chunks, to get rid of the tree, and to mimic both Microsoft and legacy (aka current) KSysGuard. Actually, Matt wants to see Akondi as the umbrella item for akonadiserver, akonadi_control, akonadi_* with a association to mysql (it's a subordinate item today). And Berna does not even know about Akonadi but Kontact. So how do we want to structure the data, despite from the question how to code?

Sorting is available out-of-the-box when you add the respective column.

alamaki wrote:Please, do not put a dropdown in a table data cell, unless it's for editing data in that cell. Having a drop down for actions is justifiable only as the last cell of the row. In this case, a context menu for the entire row would be in order.

Limiting creativity because of devs laziness?
The idea was to offer a way for sending signals to the process or to open the debug section. And preferably only on activation to avoid clutter like in Kver's suggestion above. A context menu would be sufficient but maybe to obvious enough.

alamaki wrote:I'd rather have this process detail information presented in tabs...

Tabs are evil, outdated, and ugly. And it is the wrong solution for a potentially unlimited number pages.

General remark
Sorry for being in a defense position of my proposal. Of course it's all up to the users and devs. And therefore it's better to challenge requirements. For example: Do we really want to have a full-featured KSysGuard enriched with information from KInfoCenter and purpose of many use cases? Grouping belongs to this discussion but not whether tabs are used or not.

Addendum
At the blog post Adriano added the need for interaction with touch screens. I'm not sure about that.

Heiko Tietze wrote:Signed! But do you mean three fix sections? Why not show as many tiles as the user want. And that means you cannot predefine sections. What if the system has two network connections, or the user needs to observe hard disk activity?
I wouldn't show many charts. The tiles shouldn't be over-informative, no blinking, no gauges, and definitely not this 'doughnut thing' - just the color. But one chart to see the top processes in relation to the selected sensor capability makes sense. Even when it clutters the overview a little bit.
Please keep an eye on the configuration. Every specific alert such as RAM faults would require hard-coded thresholds. If it's a sensor it can be shown along with thresholds (min/max value with lower/upper warning and alarm thresholds that are user-defined; in case of faults 0,1000:1,-,2,-).

No, I like the way you have them configurable; I'm just thinking those 3 ought to be default since they are the most important resources. If someone doesn't care about networking, CPU, or RAM, then they should be removable, and if they want more it should be easily added. I don't think it should be 'locked' to 3 slots either, users should be able to have several monitors available at once.

For the thresholds, I'll step back from that - my duty here is limited to pretty pictures, but I think the system should be able to calculate sensible maths formulas. I did some 'Gauge' style sensors in this design just to see how they would turn out. Mostly because I started this before your reply.

Heiko Tietze wrote:As replied the TheBlackCat this section intends primarily the need for information from external programs. Sure it can be done better.
Your wording is truly better. But I would call this one just Inspector without the 'pop-up'.

I was just saying popup because I would open the inspectors in new windows. I'll hold off before mocking those up, and I'll take your advice on whether or not they should be a section; there are arguments for both.

Heiko Tietze wrote:There is a terminate button (I intentionally call it different than the advanced stuff at the heatmap section but it should be SIGKILL) at the overview for a selection of processes that misbehave.

I drew two variations of the buttons; as much as I aesthetically like the "close" style buttons, I think the proper "X Kill" buttons better convey their functionality.

And the process inspector. It's a bit cramped, so I feel some tweaking is in order, but the basic idea...



The black lines is the time scrubber; if you're scrubbing the time the list on the bottom would also reflect the moment selected.

Loves!

This looks good, but as you said, the processes tab is too cramped. Especially the process listing.
I think it might need a vertical horizontal splitter, allowing the user to completely hide the graphs to maximize space for the process list. Else navigating those will be a pain.

Great idea with the time scrubbers! Is the pause button there to stop the graphs/data flow?

Lovely Mockups!

I'd suggest to split up the Process "tab" into Resourecs and Processes.

Resources tab shows (configurable, like in the current version maybe?) the graphs for CPU/mem/swap/networking etc.
Process tab shows the process list. Maybe in-line some features like "jump to process", "set priortiy" or "kill process" directly into the ListView instead of having them as right-click option?.

Overview

Kver wrote:I'm just thinking those 3 ought to be default since they are the most important resources.

According the requirements those three are not sufficient for most users. For instance, a single CPU indicator is not enough for 8 CPU cores (each CPU adds 12.5%). What information has to be shown depends heavily on your setup. Power consumption is quite interesting for mobile devices and I/O for servers. Three slots might be not enough.

The 'gauge' style sensors are not a good decision, IMHO. It's more or less a bar chart with a confusing circular orientation. And for the overview that's too much details, if we talk about system health in one glance.
Colors are probably not finished - green (or turquoise) stands for good but zombie processes aren't.
The overlay is a good idea, however only available for systems with mouse input. BTW: We could also think about a stacked pie chart, something like filelight.

Processes

Kver wrote:And the process inspector. It's a bit cramped, so I feel some tweaking is in order, but the basic idea...

Font color are not the same as highlighting the cell background. Altogether there are too many colored information without a special attractor. Plus, numeric data should be right aligned. PS: Using different units makes the content unnecessary hard to read. I'd either use one unit prefix (e.g. MB) or show just the percentage to the total.
Again my concerns are the limited number of charts. And I would expect a history per process here. However your proposal is closer to the current organization of processes.
What I also miss is the interaction with processes. Could be available via context menu, okay.

Do you refuse the requirement of starting a plasmoids from KSysGuard? And what's about the in-detail information such as debugging or running a performance analysis. Should that all be available per external programs only?

Soukyuu wrote:I think it might need a vertical splitter

Good idea.

Saabhero wrote:I'd suggest to split up the Process "tab" into Resourecs and Processes.

In this case the graph is not associated with a particular process.

What about having something like this as the overview screen but with some tweaks:


The Process table does look a little cramped to me too.

By default just show the 3 graphs (CPU, RAM & Network) and leave the Process table off completely - IMO the style of the graphs is perfect.

You open the System monitor & see only the 3 graphs, you notice something strange on the CPU graph so you click on the graph itself and it changes the window to one with only the CPU graph at the top and the Process table below. The Process table can now be a decent size so that it doesn't feel cramped any more and the suggested functionality of 'click on a process and you'll see on the graph how much resources that particular process is using' will remain intact.

There's the benefit of no wasted space in a sidebar with only 2 items in it (the whole window is quite small anyway - why waste space?) & no tabs or tab-like items either! And you'd be able to quickly glance at all 3 graphs as soon as the front screen is displayed and decide what to look at in more detail.

Oh, and the Overview screen:


might look a bit sparse if there's no 'problem applications' to display in the list on the lower half of that window.