KSysGuard: The Green Paper

This green paper summarizes user comments regarding needs and wishes for a new KSysGuard and presents a couple of mockups to initiate the discussion at the KDE forums.

tl;dr; This blog post summarizes requirements for KDE system monitor and presents a couple of mockups to initiate the discussion at the KDE forums.

Introduction

Recently, we asked about your requirements for the KDE system monitor and task manager KSysGuard. And – thanks a lot! – we got a vast number of responses that need to be classified now. It was planned to do the next steps, discuss the requirements and create mockups, in the KDE forums. But it turns out that such a posting would be too long for the context. So we decided to write this blog post (also somewhat lengthy) with the essence of user comments and first ideas how the application could look like and subsequently ask you to join the discussion in the forums.

Requirements

  1. Show an overview about the current status in order to inspect system health and find misbehaving processes.
    Berna wants to start with a plain overview that shows the system health at a glance. If one or more processes are not responding (e.g. flagged as zombie) or misbehaving (e.g. high CPU load) they should be shown with the option to terminate. The overview has to contain of a couple of ‘highly relevant data’ (e.g. CPU load, RAM usage, network load, I/O activity) along with a chart that shows the usage of this data per process (e.g. as pie chart). Additionally, data from other sensors (CPU & system temp, fan speed, GPU freq/temp) and less relevant information (e.g. total number of processes) would be nice to estimate system health.
  2. Monitor system activities to understand and predict the development of process activity.
    Philip wants to monitor system activity in order to track down problems he experienced lately. Primarily he wants to see how the highly relevant data (such as CPU, RAM, network, power consumption etc.) performed within the last couple of seconds, minutes, and hours. The chart has to be interactive in terms of providing information at the cursor and giving options to change the refresh rate (remark: rather than scrolling, zooming etc.). And Philip wants to be able to get plasmoids for selected information, at best at the system tray.
  3. Show information per process including all depending properties to get a comprehensive summary of activities.
    Matt wants to browse through processes, sort by sensors, filter and search for items. Sensors should be as flexible as possible in order to observe both default parameters like average CPU load, RAM usage, power consumption etc. as well as extended information such as hardware and network access. Furthermore he wants to read rather static information like open file or used libraries. Matt expects conspicuous processes to be highlighted so the full table represents a heatmap.
  4. Provide extended access to single process to maintain operability of the system.
    Philip wants to get detailed information on a particular process with data from multiple source, including the system journal, for instance. He wants to be able to interact with the process, which means sending signals to a process, the opportunity to debug it, to run a performance analysis, and so on.
  5. Follow the vision of being ‘simple by default and powerful on demand’ for a perfect UX.
    Berna, Philip, and Matt want KSysGuard to fit into the system. It should be easy to handle by default with all freedom on demand. Special attention should be paid to sort, filter, and search.

The classification of all comments that led to these requirements can be found in the working paper. The background of the KDE personas Berna, Matt, and Philip is available here.

Mockups

With only a few globally applicable commands, KSysGuard has a simple command structure, and the respective pattern using a context panel is applied. To organize the different views onto the content, a left sidebar gives access to the sections overview, monitor, heatmap, and process that serve the use cases according the requirements. The flat icons used in the mocks are ‘designed by Freepik’ using “free license (with attribution)”. Draft have been created using Balasmiq Mockups, and are available at KDE share (VDG Share > public > software > app-system-KSysGuard).

Overview section

20150518_KSysGuard_1

Figure 1: KSysGuard: Overview section.

  • Tiles, highlighted according to the status to get a quick impression about system health
  • List of suspicious processes below with the license to kill them
  • System information on the selected tile is shown right hand along with the most relevant processes, if applicable (pie charts should always show 100% so free memory is usually the largest slice)
  • Option offers access to the user-defined definition of thresholds
  • ‘Hidden feature’ allow direct propagation as a Plasmoid

Monitoring section

Figure 2: KSysGuard: Monitoring section.

Figure 2: KSysGuard: Monitoring section.

  • ‘Advanced’ chart where users can assign sensors to axes
  • Sections are cross-linked via processes

Heatmap section

Figure 3: KSysGuard: Heatmap section

Figure 3: KSysGuard: Heatmap section.

  • Heatmap for primary sensors according to defined thresholds
  • Natural grouping with collapse/expand feature and the option to sort data
  • User can add/remove columns from a large selection of all sensors
  • Simple interaction with processes per menu button and links to the single process section
  • Rather static data is shown in tooltip
  • Set of sensors can be stored to and loaded from a layout

Single process section

Figure 4: KSysGuard: Process section.

Figure 4: KSysGuard: Process section.

  • Report style with a scrollarea that contains all information
  • Integration of data from external tools
  • Export function to share results

Discussion

Of course, all mockups are matter of discussion and rather intended to start the discussion that should run at the KDE forums: https://forum.kde.org/viewtopic.php?f=285&t=125930.

Please take the requirements into account when you suggest a different type of view. This proposal does not cover the access to remote computers since it adds another ‘navigation layer’ that is rarely needed. A simple command line parameter could be used instead to provide this option. On the other hand, it might be reasonable to focus on the key features. For instance, the overview page could be even more clean (though geekish Linux/KDE users usually wants to get more information).

Once we have a good proposal, perhaps with pixel-perfect pictures, we will present the white paper to the community. And in case we come up with more than one proposal it could be worth to let the users vote. So stay tuned even if you don’t want to join the discussion.