Bug 1783676

Created attachment 1645206 [details]
earlier cockpit front page at 1024x768

Created attachment 1645207 [details]
cockpit 209 front page at 1024x768

Also note the fairly large amount of horizontal space (80 pixels or so, it looks like?) lost to displaying just two buttons of unclear purpose and a bunch of blank dark grey space.

So from looking at the screenshots side by side I'm guessing the mystery meat menu gives you the other power options? To me that's clearly a backwards move. The previous design clearly connects the down caret to the restart button, making it obvious the two are related. The new design just has the burger button floating in space with no clear indication it has anything to do with the Restart button - by simple proximity it's as likely to be related to the hostname as to the Restart button.

> The Cockpit front page prior to version 209 ... provides lots of useful information and links...
> CPU, memory, disk and network traffic usage

These information are going to be presented as well. But not as graphs. Graphs take a lot of space, distract users from more important items on the page (like health), are not accessible and also it is questionable if users need to see this information always on the front page. It is gonna be presented in same way as is memory now. For future design see https://garrett.github.io/cockpit-mockweb/navigation2/

> and links to view SSH key fingerprints, realm join, system time

One of the main reasons why we did this change was to promote the more important things. One of those is health, another is usage (which is not yet completely implemented, but hopefully in the next release) and things like joining realm or ssh keys can be a bit lower since you don't need to see these information immediately and every time you log into Cockpit. So the fact that these information are not the first things you see helps with Cockpit usability and its effectiveness. Also things are grouped into cards to help users to find more important things faster - as opposed to just listing everything in one long table as it was before. This of course takes more space.

> system power, and even a system alert at the bottom.

System power is still available on the top of the page. Not sure what you meant by `system alert`.

> Cockpit 209, by contrast, provides you with rolling acres of whitespace, a mystery meat burger menu, the hostname in a gigantic font, two lines of system information and...that's about it. See second screenshot.

As mentioned above, it is due to grouping related items together, promoting Health and usage. Also your screen resolution seems very specific. You can see all information at once since 1280x800 (see [2] for screenshot at this resolution). Also exactly the same amount of information you see at 1024x768 you would see on normal phones like Iphone 6 or Nexus 5 (just random phones that I can emulate). The 1024 seems to be unlucky width, since it is not wide enough to have two columns of cards (as it happens when the width is around 1200), but still wide enough to take a lot of white space (as said, standard phone vertically shows the same amount of info, but since it is much less wide it does not take so much whitespace).

> I can see some of the intent here, I guess - not sure what the UI intent of hiding the graphs behind a button is, but it'd actually be helpful to openQA as I can use the wait_still_screen function again! 

See above, I explained why we don't want graphs on the overview page.

> but the burger menu is soooo obnoxiously 2016 (just from looking at the screenshot I actually have no idea what it does), the whitespace is just way too much, and there's barely anything of actual use there.

The choice of burger menu was done by our designers. They of course tried also dropdown, but decided for this. For why, they would have to explain. (I guess accessibility and also burger menu is standard way of showing additional actions?). But the fact that you did not realize it shows additional options suggests that it needs to be looked at, as it is not obvious.


[2] https://cockpit-project.org/blog/cockpit-209.html

> The 1024 seems to be unlucky width

Let's keep that bug for fixing that. Most everything else (like spacing etc.) is prescribed by PatternFly 4, but we should optimize for small screen widths a bit.

1024x768 is what you get if you use virt-manager to create a virtual machine. I'd wager this is a fairly common thing for people who use Cockpit to do. :)

Also, as a general thought on Matej's response: lots of the notes were "OK, I know it looks weird now, but we're doing X so we can do Y in future". I'd say where possible in that kind of situation it'd be better to only ship X once you're done with Y. Users don't like being exposed to that kind of "inside baseball". They just use the app: the knowledge that you're doing lots of hard clever re-engineering behind the scenes is useless to them. If the new UI isn't better than the old one *right now*, users will be unhappy if you ship it, even if the path to the beautiful future vision is clear to *you*.

oh, one more thing - by 'cards' do you mean the 'host' and 'dashboard' buttons on the left? Because if so I found those a bit confusing too. It'd be relatively easy to figure out by experimenting, of course, but just looking at them, the relationship between those and the previously-existing 'overview', 'logs', 'storage' etc. buttons is not too clear to me. Are the 'host' and 'dashboard' buttons "under" the selected 'overview' button? i.e. if I click 'dashboard' I'm switching to a second "page" of 'overview', and if I click 'logs' then 'host' and 'dashboard' potentially go away and are replaced by different choices? That's my best guess, but it doesn't seem *clear*. It'd be nice if the UI somehow gave you a stronger hint as to the relationship here.

> Also, as a general thought on Matej's response: lots of the notes were "OK, I know it looks weird now, but we're doing X so we can do Y in future". I'd say where possible in that kind of situation it'd be better to only ship X once you're done with Y. Users don't like being exposed to that kind of "inside baseball". They just use the app: the knowledge that you're doing lots of hard clever re-engineering behind the scenes is useless to them. If the new UI isn't better than the old one *right now*, users will be unhappy if you ship it, even if the path to the beautiful future vision is clear to *you*.

Then we would slip into once a year release, since there is always something which can be better :) "Release early, release often". And we think that this version IS much better that the previous one. If you look at screenshot in different resolution than yours (like in our blog post), then it obviously IS better. Also, if we would not release this version, we would not find out that it is not optimal at this kind of resolution. And also, the only thing that was not yet shipped is showing of storage and CPU load in the 'Usage' card.

> 1024x768 is what you get if you use virt-manager to create a virtual machine. I'd wager this is a fairly common thing for people who use Cockpit to do. :)

How do you mean? You create VM with UI and then use Cockpit from inside of the VM to manage it/other machines? That is opposite of what Cockpit is for. Create VM without UI, and then just connect to it from your local machine.

> oh, one more thing - by 'cards' do you mean the 'host' and 'dashboard' buttons on the left?

No. By cards I mean `Health`, `Usage`, `System Information` and `Configuration`. `Host` and `Dashboard` is something different (which exists in Cockpit for very long time) but only appears when you install cockpit-dashboard or other applications which require submenu. It is second level menu. (or well, it is the first level and the menu you were used to becomes second level). But also we are going to change menu, so these items will disappear anyway soon-ish.

"`Host` and `Dashboard` is something different (which exists in Cockpit for very long time) but only appears when you install cockpit-dashboard or other applications which require submenu."

Huh. That's odd, then, because they only started showing up in the openQA test with 209. Perhaps an app that requires the submenu is now included by default when it wasn't before? Anyway, seems irrelevant per your response.

I proposed solution in https://github.com/cockpit-project/cockpit/pull/13315
It uses a magic constant, but it seems to work in all cases.

https://github.com/cockpit-project/cockpit/pull/13315 tweaks the CSS to fix this. Check out the screenshots there at 1024x768, and Matej also validated this on (literally) every smaller width. Thanks!

Looks great to me. Thanks! I filed https://github.com/cockpit-project/cockpit/issues/13316 for the power menu UI issue.

This is an incorrect fix and breaks the layout for most desktop sizes, especially in longer worded languages.

See https://github.com/cockpit-project/cockpit/issues/13326 for the most glaring example of the problem.

The original intention of setting the card size that narrow is for very tiny mobile phones, notably iPhone SE and similar sizes. It should not be used for desktops.


FWIW, regarding the new layout:

1. items were grouped and reordered to be findable & consistent (before, they were just inconsistent links added in random locations)

2. we've updated the page to use PF4 widgets and patterns (such as cards, kebab menu, etc.)

2. there's no "burger menu". There's a kebab menu, which is for additional actions and a standard PF4 component (this said, we're probably going to be moving it back to a split button)

3. graphs were moved from this page as they are often misinterpreted, unnecessary, and are a drain on system and browser resources

4. usage bars replace the graphs for a current, basic idea of system stats (but there's only one implemented at the moment; others should have been implemented and will *hopefully* arrive very soon)


I'll look into a proper fix that reverts the card width to what it was before. And, most relevant for this actual issue, also tweak everything to work better at a 1024x760 layout, with VMs in mind.

https://github.com/cockpit-project/cockpit/pull/13409

FEDORA-2020-e70cf11146 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e70cf11146

cockpit-211-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e70cf11146

cockpit-211-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d5974928d6

cockpit-211-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

cockpit-211.1-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-13dea2829c

cockpit-212-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f951136bb9

cockpit-212-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.