Create Task
Maniphest T13260

Unify AboutPage behaviour
Open, Needs TriagePublic
Actions

Description

While we have a kool and consistent component for creating About Pages in Kirigami the way we use them is not consistent.

Some apps, e.g. Discover and Calindori replace the entire pagestack with the about page. The user is then able to navigate away from it via the apps usual navigation mechanisms.

Other apps, e.g. KTrip and Itinerary, push it onto the current page stack. They often don't provide any way to navigate back, or sometimes they provide a close action in the AboutPage

on mobile both lead to a somewhat similar result since only one page is visible at a time, but with a wide desktop window pushing it on the stack makes the aboutpage not fill all of the window

nicolasfella updated the task description. (Show Details)Jun 10 2020, 2:09 PM
nicolasfella added a comment.Jul 4 2020, 12:27 PM

I think this is solved nicely by using pageStack.layers. It then covers all regular pages and has a builtin closing mechanism. There was a minor issue with the license page ending up in the wrong place, but that was addressed with https://invent.kde.org/frameworks/kirigami/-/merge_requests/40. The only thing that needs to be watched out for is not pushing the page multiple times.

if (window.pageStack.layers.depth < 2) {
    window.pageStack.layers.push(aboutPage)
}

I therefore propose we formalize:

  • Each application should have an aboutpage
  • It gets pushed on pageStack.layers
  • It can only be pushed once
  • There is an action in the global drawer/sidebar/hamburger menu that opens the AboutPage

Things I'm not sure about:

  • text of the action: I tend to prefer "About" over "About AppName", but the KXmlGui/Widgets counterpart uses "About AppName"
  • icon of the action: We tend to use help-about or help-about-symbolic in Kirigami apps, but the KXmlGui/Widgets counterpart uses the app's icon
ndavis added a subscriber: ndavis.EditedJul 4 2020, 1:06 PM

Sounds like a good idea.

Text: I prefer "About AppName", unless you're merging "About AppName" and "About KDE" into one dialog. If that's the case, I'm not sure, but I guess "About" would be fine.
Icon: Use help-about. KXmlGui should also use it and "What's This?" should be changed to use help-whatsthis.

nicolasfella added a comment.Jul 4 2020, 1:53 PM

There is an issue with the help-about icon. It changes between monochrome/colorful depending on the size, which results in a different style depending on screen DPI. I see a few possible resolutions:

  1. Make help-about always colorful and use help-about-symbolic when we want monochrome
  2. Make help-about always monochrome. Where do we use it colorfully?
  3. Use the icon scaling thing to keep it monochrome on highdpi while keeping it colourful on certain sizes
nihalani added subscribers: sredman, nihalani.Jul 4 2020, 3:13 PM

I had a couple of comments about this type of implementation and posted it in a PR discussion but will re post it here so we can discuss it.

The about page actually take up the entire application displacing several key supposedly static elements of the GUI leaving the user feeling displaced. Most of the other KDE apps solve this by opening up another window with the about window which I suppose is also an option but presents a problem with touch devices that I think @sredman should weigh in on
This also increase the number of clicks the user has to do before the user gets something useful. If the user wants to get to a new conversation they have to click back and then the icon of the new conversation rather than just click the icon of the new conversation. This also presents a problem for mobile users as they have to stretch their finger to the top to go back.
The back button ends up being weird, traditionally the back button is always the left most interaction, in other applications they take care of this either by moving the menu to the right or moving the menu to its own row. I was planning to fix this in another PR but wanted to incorporate a fix for the menu not showing up in kde plasma global menu applet.

nicolasfella added a comment.Jul 4 2020, 7:41 PM
In T13260#234664, @nihalani wrote:

The about page actually take up the entire application displacing several key supposedly static elements of the GUI leaving the user feeling displaced. Most of the other KDE apps solve this by opening up another window with the about window which I suppose is also an option but presents a problem with touch devices that I think @sredman should weigh in on

I don't see a reason why one would need to see the content of the about page and other elements at the same time

This also increase the number of clicks the user has to do before the user gets something useful. If the user wants to get to a new conversation they have to click back and then the icon of the new conversation rather than just click the icon of the new conversation. This also presents a problem for mobile users as they have to stretch their finger to the top to go back.

Checking the aboutpage is only done rarely, so optimizing that for the number of clicks isn't really an important objective

The back button ends up being weird, traditionally the back button is always the left most interaction, in other applications they take care of this either by moving the menu to the right or moving the menu to its own row. I was planning to fix this in another PR but wanted to incorporate a fix for the menu not showing up in kde plasma global menu applet.

It's no different to every other page in Kirigami where the back button is to the right of the menu button/drawer handle

nihalani added a comment.Jul 4 2020, 8:15 PM

Breadcrumbs are kept in place so that user doesn't feel jared. That throughout the entire application the look and feel is the same. In Dolphin, Konsole, and most of the KDE applications the about info is in a new dialog for this very reason. However if that's not an option then at least keep the breadcrumbs.

Sure the user doesn't use the about menu but it doesn't mean you shouldn't design with the user in mind. Clicks matter. A key metric of how usable a software is how many clicks it takes to get to an action. In the KDE HIG states the complex operations should be accessable in a few clicks.

Dolphins, Firefox, Konsole, etc all have their menu bars on the right. They may not be using Kirigami but are users more likely to have those apps than other Kirigami apps. We should just strive to look like those apps so that the user intuitively know where everything is placed. They also have their forward and back button always present regardless of whether or not the are currently used in the current context. It ties into breadcrumbs where the user expects certain icons/elements to always be there regardless of whether there are currently applicable.

I guess the final question is why not? At the end of the day the end user whether it be us or somebody else should be the ultimate stakeholder. Why not spend the extra ten to fifteen min to explore another solution, write a couple of lines of extra code, or brainstorm a little more that provides a more pleasing/usable experience.

nicolasfella added a comment.Jul 5 2020, 2:15 PM
In T13260#234711, @nihalani wrote:

Breadcrumbs are kept in place so that user doesn't feel jared. That throughout the entire application the look and feel is the same. In Dolphin, Konsole, and most of the KDE applications the about info is in a new dialog for this very reason. However if that's not an option then at least keep the breadcrumbs.

The page structure is preserved when pushing something on the layers stack, it basically is like a dialog that spans the full size of the window

Sure the user doesn't use the about menu but it doesn't mean you shouldn't design with the user in mind. Clicks matter. A key metric of how usable a software is how many clicks it takes to get to an action. In the KDE HIG states the complex operations should be accessable in a few clicks.

What is actually taking longer? Depending on your menu you have one or two clicks to open the about page, and one to close it again. It doesn't get any faster if you don't make assumptions about the apps content, which we can't really do given that our guidelines are broadly applicable

Dolphins, Firefox, Konsole, etc all have their menu bars on the right. They may not be using Kirigami but are users more likely to have those apps than other Kirigami apps. We should just strive to look like those apps so that the user intuitively know where everything is placed. They also have their forward and back button always present regardless of whether or not the are currently used in the current context. It ties into breadcrumbs where the user expects certain icons/elements to always be there regardless of whether there are currently applicable.

Where do those apps have menu bars on the right? The about dialogs of these apps don't have any of the controls from the main window, so I don't see why the AboutPage in Kirigami should inherit anything from the pages below

I guess the final question is why not? At the end of the day the end user whether it be us or somebody else should be the ultimate stakeholder. Why not spend the extra ten to fifteen min to explore another solution, write a couple of lines of extra code, or brainstorm a little more that provides a more pleasing/usable experience.

Do you have a suggestion to discuss?