GNOME Bugzilla – Bug 531097
Efficient use of screen is very poor when small
Last modified: 2018-05-22 12:06:15 UTC
This report has been filed here: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/221594 "I have my screen resolution set at 1680x1050. The smallest I can make this app is that it still occupies about 1/6 of the screen area. This is really bad use of space - an app like this should be able to operate even when its window is taken down to the size of a postage stamp. Not only that, but when operating at its smallest size, - it shows 3 graphs, the height of the graphs is in total less than 20% of the window height, the rest is just wasted space. The important things in the voids between the graphs, such as the key and the scales, should plip out of existance when the graph gets below a certain size. When the graph is bigger, these problems are mitigated somewhat." "This makes "Resources" almost useless for me. About 10% of the window is used for data. As described above, the rest is 10 numbers, huge icons, a couple of chartoons (for memory use) and a lot wasted space. Attached is an example." http://launchpadlibrarian.net/13881028/Screenshot-2.png Thanks,
So whats happening here ? Its not like there is any ifs and buts about this? The design issues highlighted are obvious for all to see! This was filed 2 years ago. Surely something can be done about this in that time?
[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on https://bugzilla.gnome.org/userprefs.cgi?tab=email when the assignee is changed to an individual.]
A couple of things that may improve the situation are * Removing the graph for Memory/Swap. It is almost always just showing flat lines corresponding to the current status. * Move the legends on the side of the associated graph.
(In reply to comment #3) > A couple of things that may improve the situation are > > * Removing the graph for Memory/Swap. It is almost always just showing flat > lines corresponding to the current status. I would rather make it cinfigurable, which charts to show. > > * Move the legends on the side of the associated graph. Which side did you think of? What about 24 or more core systems?
*** Bug 674406 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > (In reply to comment #3) > > * Move the legends on the side of the associated graph. > Which side did you think of? What about 24 or more core systems? Mmm... touché :) I was thinking of the right side, but for the many-core-system case it would break badly indeed.
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > > > * Move the legends on the side of the associated graph. > > Which side did you think of? What about 24 or more core systems? > > Mmm... touché :) > > I was thinking of the right side, but for the many-core-system case it would > break badly indeed. No problem, the current one also breaks :) That's another thing I like ubergraph for, as with ubergraph the color selector are only displayed when the chart is clicked, and hidden when clicked again, so you have screen space, but still can access the color selectors easily (not that people use changing the chart color that often, so probably it would also work in preferences)
I mean really, 3 years on and you are still arguing about the number of cores? Its obvious, dont display the legand at all with a large number of cores, nobody actually cares if red is for core 5 or core 8!! And if they do put it in a seperate pop up. This is a classic example of how to discourage someone from posting bugs , hell if it was difficult to see or understand, controversial or anything like that it probably would have been closed ages ago now, or due to senility setting in in the person who first reported the bug. This is not a difficult one. Its a straightforward, obvious design problem, this version is way worse than the previous version which if we carry on talking much longer no-one will even remember. I appreciate that the designer may not have the time or inclination to fix this and am sympathetic to that, but this is a problem that most users of the utility will run up against and be annoyed by.
(In reply to comment #8) > I mean really, 3 years on and you are still arguing about the number of cores? Actually we've just started working on this, however the requirements and computers and everything has changed since (remember this is an open-source project, with volunteers working WHEN and IF they have time) so it doesn't hurt to discuss the plan first. > Its obvious, dont display the legand at all with a large number of cores, > nobody actually cares if red is for core 5 or core 8!! And if they do put it in > a seperate pop up. Yes, that is one of the options I have suggested and was asking for feedback or other ideas on that, so I'll count your response as a +1 for moving the color chooser to the preferences. > > This is a classic example of how to discourage someone from posting bugs , hell > if it was difficult to see or understand, controversial or anything like that > it probably would have been closed ages ago now, or due to senility setting in > in the person who first reported the bug. > > This is not a difficult one. Its a straightforward, obvious design problem, > this version is way worse than the previous version which if we carry on > talking much longer no-one will even remember. I appreciate that the designer > may not have the time or inclination to fix this and am sympathetic to that, > but this is a problem that most users of the utility will run up against and be > annoyed by. I'm just one of those guys who doesn't remember the previous versions, and I see no point in arguing about the past, let's look ahead and find and fix issues like these. Thanks for the feedback.
I have added options in the head version to show/hide graphs on the resources tab, so to have more vertical space for a chart (e.g. CPU monitoring) people can turn off the others, e.g Memory and Network, Memory generally being a horizontal line.
Created attachment 250206 [details] Expandable/collapsible rows Showing only one graph at a time looks like good solution, but the checkboxes in Preferences may not be not the best way to achieve this. First, it depends on user intervention for small windows to become useful, expecting them to know beforehand that this functionality is available in Preferences; it would be better for the application to automatically adapt to small sizes, while still letting the users choose which graphic they want to see. Moveover, going to Preferences everytime just to change which graph to show can be a tiresome; I'd try to place controls directly in the main window. Finally, it's currently possible to have an empty Resources page by disabling all graphs. My idea would be to use disclosure arrows to expand/collapse graphs, as in the attached mockup. When the window is bellow a sensible size, only one graph would be shown at a time; expanding one graph would collapse the other. At larger window sizes, the user would be free to expand 1, 2 or all 3 graphs. The mockup also features another idea for reclaiming more vertical space: merging the legends and the header into a single row. This also has the advantage of keeping summary stats visible while the respective graph is collapsed. (I take the chance to cheer Robert and Stefano for the great work on bug-fixing and modernization of gnome-system-monitor's code base and user interface.)
Thanks for the idea, I like the expander idea, and merging the section title with the color pickers is also a good one. I was aware that with the checkboxes in place we could get to an empty page, but your idea also solves that, if you collapse all views, you don't get an empty page, but a quick overview of the current status which is still meaningful and useful. Thanks again for your contribution.
I too like the mock-up, but I'd like to see it go a bit further. At small screen sizes only one would be shown, and clicking on it would do a round-robin of some type on the available displays, but only showing one of them at a time. This way a really small graph could be shown still utilising a big percentage of the available space, and I think thats the aim.
Expanders have been implemented by Robert in commit 7951df19b242c8bda2beeedc6d471f6cccc85900 Still, it would be nice to allow for arbitrary shrinkage of the window, maybe adjusting the size of the legends accordingly.
Robert, I'm glad you liked the ideas and already enjoying the implementation. I noticed you started working on a wip/newdesign branch, so I've expanded the mock-up to make it more comprehensive and detailed. If you want to discuss any ideas, feel free to email or ping me (antoniof on irc.gnome.org).
Created attachment 251278 [details] Resourses mockup v2 Sorry, I forgot to attach with the previous comment.
(In reply to comment #16) > Created an attachment (id=251278) [details] > Resourses mockup v2 > > Sorry, I forgot to attach with the previous comment. Looks nice, but the white label might look ugly on some bright colors (on your mockup the white on yellow is less readable than the others, even if the yellow is an orangish yellow ), so what do you think about adding a black/gray outline to the text on the colorpicker?
(In reply to comment #17) Good point. I tried the branch. The grey outline doesn't look very nice, it looks as if the numbers are fuzzy. I'd go for black outline or try shadows instead, and use bold font.
(In reply to comment #18) > (In reply to comment #17) > Good point. > > I tried the branch. The grey outline doesn't look very nice, it looks as if the > numbers are fuzzy. I'd go for black outline or try shadows instead, and use > bold font. I have first tried with black, didn't like that, that's why I have tried a gray, which looks a bit better, in my opinion. Shadows don't look nice on GUI interface texts in my opinion, but I guess I'll also try something like that, we'll see how it goes.
Created attachment 251652 [details] Current screenshot of WIP improvements Attaching a screenshot for review with system monitor resized to the minimum possible. I would appreciate comments especially on the look of the text on the color pickers, what do you think, how can that be improved, ideas, suggestions are welcome.
Created attachment 251654 [details] another screenshot
(In reply to comment #20) (Sorry, I was AFK earlier on IRC) I'm still not convinced by the outline. Isn't it possible to have a text shadow like the one seen on the pressed "Resources" button? (That's done through gtk+ CSS magic?) I also notice that the text is not centered. Can we drop the "CPU1", "CPU2", "CPU3", "CPU4" labels? We already have "CPU" on the expander header, and it should be obvious enough that the 1st color is the 1st CPU, the 2nd color is 2nd CPU, and so on. The Memory and Swap details still show two lines while collapsed. The percentage is the most interesting information, so the absolute values should be collapsed together with the graph. I suggest replacing the "and" with a "&" on "Memory and Swap". The "&" character is already employed, for instance, on gnome-control-center panels names. The three previous points will also allow for a lower minimum window width (bug 684347). Finally, it would be really nice if everything was aligned in a grid as in the mock-ups, such that, for instance, the download speed button aligns with the CPU2 button.
Created attachment 251694 [details] screenshot with CSS text styling
(In reply to comment #22) > (In reply to comment #20) > (Sorry, I was AFK earlier on IRC) > > The Memory and Swap details still show two lines while collapsed. The > percentage is the most interesting information, so the absolute values should > be collapsed together with the graph. > What do you think of replacing the pie chart for Memory/Swap with a levelbar styled like the CPU/network color pickers? The pie chart looks a bit out of place now.
(In reply to comment #24) > (In reply to comment #22) > > (In reply to comment #20) > > (Sorry, I was AFK earlier on IRC) > > > > The Memory and Swap details still show two lines while collapsed. The > > percentage is the most interesting information, so the absolute values should > > be collapsed together with the graph. > > > > What do you think of replacing the pie chart for Memory/Swap with a levelbar > styled like the CPU/network color pickers? The pie chart looks a bit out of > place now. Replacing the pie chart with a styled levelbar could work, but have to think about the details: if swap usage is 0, the pie chart shows the middle of the pie with the selected color, how would that work on a styled levelbar? if the level represents the usage, and only that part is clickable, 0 usage will not be clickable.
(In reply to comment #22) > (In reply to comment #20) > (Sorry, I was AFK earlier on IRC) > > I'm still not convinced by the outline. Isn't it possible to have a text shadow > like the one seen on the pressed "Resources" button? (That's done through gtk+ > CSS magic?) > I also notice that the text is not centered. stfacc fixed that > > Can we drop the "CPU1", "CPU2", "CPU3", "CPU4" labels? We already have "CPU" on > the expander header, and it should be obvious enough that the 1st color is the > 1st CPU, the 2nd color is 2nd CPU, and so on. > stfacc fixed that too :) > The Memory and Swap details still show two lines while collapsed. The > percentage is the most interesting information, so the absolute values should > be collapsed together with the graph. what about using something else (like levelbars) instead of the piechart? > > I suggest replacing the "and" with a "&" on "Memory and Swap". The "&" > character is already employed, for instance, on gnome-control-center panels > names. > > The three previous points will also allow for a lower minimum window width (bug > 684347). > in progress > Finally, it would be really nice if everything was aligned in a grid as in the > mock-ups, such that, for instance, the download speed button aligns with the > CPU2 button. what about systems with 1 or 2 cores? the mockup looks great with 4 cores, and core2 and core4 are aligned with the receiving and sending picker, but how would that work on less-core systems? align the last pickers only?
Created attachment 251725 [details] pie inside button (In reply to comment #26) > what about using something else (like levelbars) instead of the piechart? I'm attaching an idea. If we already use words such as "CPU" and "Swap", why not replace "Memory" with "RAM" and turn "Memory & Swap" into simply "Memory"? > what about systems with 1 or 2 cores? the mockup looks great with 4 cores, and > core2 and core4 are aligned with the receiving and sending picker, but how > would that work on less-core systems? align the last pickers only? I'm attaching attach an idea to the next comment.
Created attachment 251728 [details] CPU # cases This tries to keep the same 4 columns layout. I'm not sure that "Highest" is the proper word here. The idea is to display the the busiest core, which can be at 100% while even if the CPU average is low. Maybe "Maximum"?
(In reply to comment #28) > Created an attachment (id=251728) [details] > CPU # cases > > This tries to keep the same 4 columns layout. > > I'm not sure that "Highest" is the proper word here. The idea is to display the > the busiest core, which can be at 100% while even if the CPU average is low. > Maybe "Maximum"? Yet another question: Maximum/highest shows the highest core usage at the moment, but is also a color picker for a line on the chart ... what should that line show? Should that also be the history of maximum core load? Is this what you have been thinking in the4+ cores case?
(In reply to comment #29) > Yet another question: Maximum/highest shows the highest core usage at the > moment, but is also a color picker for a line on the chart ... what should that > line show? Should that also be the history of maximum core load? Is this what > you have been thinking in the4+ cores case? Sorry, I completely forgot about this. :S Yes, I think it makes sense to have a line for the history of maximum core load. This way, the lines graph would have only 2 lines: "Average" and "Maximum". However, if the "stacked" option is enabled, it doesn't make as much sense to show the history of maximum core load. But we don't need to, because we can still display individual cores, alternating light and dark shades of the "Average" color (say light blue, dark blue, light blue, dark blue, etc.). Now that I think about it, "Average" is too confusing on this context. "Global" or "All Cores" is more clear. Perhaps even "All 16 Cores".
Ignore the "All Cores" and "All 16 Cores" ideas. It will break the layout for some locales because of long translated strings. "Total", "Global" or "Overall" may be less problematic here. Also, I fear that "Maximum" is still confusing. "Highest" (or even "Busiest") seems to have a more clear meaning, but I am not a native speaker.
Created attachment 251818 [details] quick mockup Antoniof asked me to post a mockup with some visual fixes in it. * Solid lines instead of dotted makes it nicer to the eye and is more coherent with other things in GNOME. * By placing the percentages outside the color box instead of inside, we can make sure it's readable, as it follows the systems theme color and size (for a11y) and we don't need the shadow on the labels.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-system-monitor/issues/23.