Thanks for the proposal!
While this seems very relevant it currently seems too narrow for a goal a large part of the KDE Community can get rallied behind. Is there a meaningful expansion?

It just inherited the goal setting tag from its parent task. Guess I should probably change it to something more appropriate.

Ah ok. Thanks :)

One probably needs to consider that progress indicators may be determinate or indeterminate.

A determinate progress (e.g. progress bar) operator can/should be used if progress can be detected, while an indeterminate progress indicator (e.g. busy mouse cursor) should be used, if the app can not detect any progress.

@cblack maybe as a next step, create a patch ( https://hig.kde.org/resources/contribute.htm ) for the HIG https://hig.kde.org/components/assistance/progress.html ?

l

GNOME does something pretty nice: they draw a blank/white background with a monochrome desaturated version of the app's icon in the middle. It looks really classy IMO. We could do the same, maybe also with a monochrome desaturated indeterminate progress bar below the icon.

In T11227#192157, @ngraham wrote:

GNOME does something pretty nice: they draw a blank/white background with a monochrome desaturated version of the app's icon in the middle. It looks really classy IMO. We could do the same, maybe also with a monochrome desaturated indeterminate progress bar below the icon.

That's pretty much the long form loading that I described - mostly because that's what I drew most of my inspiration from.

The example I gave of what Discover could be is literally just a description of GNOME Software's start loading screen

In T11227#192173, @cblack wrote:

In T11227#192157, @ngraham wrote:

GNOME does something pretty nice: they draw a blank/white background with a monochrome desaturated version of the app's icon in the middle. It looks really classy IMO. We could do the same, maybe also with a monochrome desaturated indeterminate progress bar below the icon.

That's pretty much the long form loading that I described - mostly because that's what I drew most of my inspiration from.

The example I gave of what Discover could be is literally just a description of GNOME Software's start loading screen

To be honest, I think we should probably do something like that, except keep it akin to Plasma's Breeze Splash screen so we have the spinning loading indicator from that splash screen and an opaque shopping bag symbolic icon above the loading animation, all of course in the ColorScheme-Text colour. That way we retain consistency with the rest of Plasma and potentially also all across KDE in regards to how splash screens look.

That means instead of the loading bar we should then just have the spinning indicator. While it may remove some detail in terms of how much a program has left to load, we can either move that into their window list item's progress bar ala Spectacle's timer or we could just take into account the fact that once it starts progressing it'll most likely be finished doing whatever it does on most of these applications anyway in a few seconds (therefore making having a progress bar redundant anyway).

In T11227#192240, @The-Feren-OS-Dev wrote:

-snip-
That means instead of the loading bar we should then just have the spinning indicator. While it may remove some detail in terms of how much a program has left to load, we can either move that into their window list item's progress bar ala Spectacle's timer or we could just take into account the fact that once it starts progressing it'll most likely be finished doing whatever it does on most of these applications anyway in a few seconds (therefore making having a progress bar redundant anyway).

The point of a longform loading screen is to be for things that may not complete in a few seconds like refreshing repositories on Discover's start (add distro repositories + repos for universal packages and there's probably a lot to do). Nothing kills user experience more than a dreaded nonstop loading screen with an indeterminate indicator. If loading must take a while, there should be effort to let users know how much time is left or how much is done versus how much there is to do.

In T11227#192242, @cblack wrote:

In T11227#192240, @The-Feren-OS-Dev wrote:

-snip-
That means instead of the loading bar we should then just have the spinning indicator. While it may remove some detail in terms of how much a program has left to load, we can either move that into their window list item's progress bar ala Spectacle's timer or we could just take into account the fact that once it starts progressing it'll most likely be finished doing whatever it does on most of these applications anyway in a few seconds (therefore making having a progress bar redundant anyway).

The point of a longform loading screen is to be for things that may not complete in a few seconds like refreshing repositories on Discover's start (add distro repositories + repos for universal packages and there's probably a lot to do). Nothing kills user experience more than a dreaded nonstop loading screen with an indeterminate indicator. If loading must take a while, there should be effort to let users know how much time is left or how much is done versus how much there is to do.

Fair enough.

It's really great to see this thread, I was thinking about starting one like this.

In T11227#192021, @fabianr wrote:

One probably needs to consider that progress indicators may be determinate or indeterminate.

A determinate progress (e.g. progress bar) operator can/should be used if progress can be detected, while an indeterminate progress indicator (e.g. busy mouse cursor) should be used, if the app can not detect any progress.

@cblack maybe as a next step, create a patch ( https://hig.kde.org/resources/contribute.htm ) for the HIG https://hig.kde.org/components/assistance/progress.html ?

l

Agree with this separation, indeterminate and determinate, but I see two levels, one within the application only and second integrated with the system. I would like to add that, there are currently duplicated progress indicators:

determinate:

Within applications, spinner feels hard to maintain as even it's size can be easly inconsistent between windows, it is something to consider. As for separation between progress bar and spinner: http://babich.biz/progress-indicators/. - author of this article says spinner should be saved for fast operations, which take 3-10 seconds max.

In T11227#192157, @ngraham wrote:

GNOME does something pretty nice: they draw a blank/white background with a monochrome desaturated version of the app's icon in the middle. It looks really classy IMO. We could do the same, maybe also with a monochrome desaturated indeterminate progress bar below the icon.

I like this one and this is something I would call system level progress (if it would be possible to let Plasma handle it, like Unity 8), together with busy mouse cursor.

Here is my proposal for this topic.

Indeterminate Spinner


Used when the progress is always unknown.
I'll make a MR for the cog loading icon.
This is a QML code example:

ColumnLayout {
    opacity: 0.5
    anchors.centerIn: parent
    Kirigami.Icon {
        Layout.alignment: Qt.AlignCenter
        Layout.preferredWidth: Kirigami.Units.gridUnit * 8
        Layout.preferredHeight: Kirigami.Units.gridUnit * 8
        source: "plasmadiscover"
        layer.enabled: true
        Desaturate {
            anchors.fill: parent
            source: parent
            desaturation: 1.0
        }
    }
    QQC2.BusyIndicator {
        Layout.preferredWidth: Kirigami.Units.gridUnit * 3
        Layout.preferredHeight: Kirigami.Units.gridUnit * 3
        Layout.alignment: Qt.AlignCenter
    }
    Kirigami.Heading {
        Layout.alignment: Qt.AlignCenter
        text: i18n("Loading Application List…")
    }
}

Indeterminate Progress Bar

Used when the progress is unknown at first, but can be determined after some time. Could also be used when the spinner style doesn't fit (for example in notifications).
This is the behavior used in the Plasma theme and will need to be ported to the QWidgets/QQC2 style. The outlined progress bar look we have now should of course be kept.

Determinate Progress Bar

Used when the progress is known.

In T11227#261191, @GB_2 wrote:

Indeterminate Progress Bar
Used when the progress is unknown at first, but can be determined after some time.

I think having this distinction for loading presentation makes a lot of sense.

Indeterminate Spinner

Is this meant to only be used as launch feedback? Aside from launch feedback I think spinning loading feedback in the task manager might be a bad idea:

If the indeterminate loading is fairly brief I think feedback in the application window itself is enough.

If the indeterminate loading is taking so much time that users might want to minimise the window, we need a slightly less noticeable indicator or this fast spinning might grind users' gears.

In T11227#261226, @felixernst wrote:

Is this meant to only be used as launch feedback?

Yes, I just replaced the current spinner icon we have in the task manager now. It shows up when the window didn't appear yet.