Loading Look and Feel
Open, Needs TriagePublic

Description

Currently, loading is basically presented however the application developers of a given application decided to slap the loading bar in.
Some examples:

  • Dolphin blanks the view while loading a directory
  • Kate also remains blank, but sets the cursor to a loading animation
  • Kirigami applications use a spinning view-refresh icon in their list views when loading
  • KMail uses plain loading bars wherever it feels like it
  • Systemsettings5 freezes the view and sets the cursor to a loading animation
  • KDE Help uses freezes the view and shows a message in the bottom left corner, the icon selection dialog used in places such as editing application entries freezes the view, shows a loading bar, and sets the cursor to loading.

I feel like loading could be unified into two types: short form and long form loading.

Short form
This should be used for loading that can occur frequently - i.e. clicking through directories in Dolphin in quick succession.

  1. Preserve view for a moment - if the next view loads within the timeframe before blanking, go straight to it
  2. If the next view doesn't load within a moment, blank the view and display an indicator that it's loading where a user is likely to see it

Long form
This should be used for loading that won't occur frequently - i.e. syncing KMail for the first time or launching Discover and it needs to refresh metadata.
A long form loader should be split into three parts:

  1. Large decorative component representative of what's being loaded (i.e. Discover could use a large shopping bag icon here)
  2. Loading bar to represent loading progress
  3. Text describing what's being done currently (i.e. Discover could list what repo it's currently refreshing)

Long form loaders should make sense as the only component on the screen, otherwise a short form loader would probably do better.

Related Objects

cblack created this task.Jul 15 2019, 11:25 PM
lydia added a subscriber: lydia.Jul 16 2019, 6:16 PM

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.

cblack edited projects, added VDG; removed Goal Setting 2019.Jul 16 2019, 6:18 PM
lydia added a comment.Jul 16 2019, 6:27 PM

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.

cblack added a comment.EditedJul 17 2019, 5:07 PM

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

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).

cblack added a comment.EditedJul 18 2019, 7:56 PM

-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.

-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.

niccolove moved this task from Reported to VDG Discussion on the Consistency board.