For packaging formats that have separate download/install phases, the typical process of updating results in entries on the Updates page exhibiting the following behavior: - First the progress bars for every item fill up halfway - Then once all of them have filled up halfway, they all start to complete one at a time This results in a somewhat uncertain experience for a user, because most progress bars don't behave this way, and it may be unclear what's going on. The user may be left thinking, "What's happening here? It is stuck? Should I close the app and start over?" I'd like to propose a more user-friendly behavior: - Once the update process begins, each item's progress bar displays the word "Downloading" and fills up to 100% - Once an item has been downloaded, its text changes to "Downloaded" and its progress bar resets to 0% - When an item moves to the installation phase, its tech changes to "Installing" and the progress bar fills up to 100% again as it's installed - Once each item is successfully installed, it *immediately* disappears from the list Combined with the sorting proposed in Bug 390911, I believe the result will be a substantially improved user interface that makes it much more clear what's happening, and as a consequence generates increased confidence in Discover as a GUI updater.
Implementation-wise this is easier. I think that in practice it's not very nice because you never know how many full progress bars you'll end up getting, but it's easily doable.
(In reply to Aleix Pol from comment #1) > Implementation-wise this is easier. I think that in practice it's not very > nice because you never know how many full progress bars you'll end up > getting, but it's easily doable. The idea is to help the user understand what the current status is: - for the overall update task - for each individual package Even though it might seem weird, I think this would improve clarity overall.
So only for the update items? What about global progress?
For the global progress bar, we could take one of two approaches: - Repeat the same visible separation betweend ownloading and installing, and have the progress bar go up 100% twice (once for when downloading is complete, and a second time once installation is complete) - Try to tweak the current progress bar such that it reaches 50% at the exact moment when everything is downloaded, and 100% once everything is installed. I think I might slightly prefer the second option. There's no real need for so much specificity in the global update progress bar the way there is for the dedicated update view, where if you're looking at it, it's probably because you're interested in what's happening. I don't have a real strong preference though.
I applaud this proposal. There is really no problem with many progress bars when we see pacman or apt output in terminal - they nicely show what is being done. We could always go with spinning circle... but that's not a thing that would satisfy a Linux user if there is a way to show it better. There is something hypnotizing and satisfying in seeing an update info and that is being done right. Currently Discover's update behavior is everything opposite: unsatisfying and confusing. Clicking on "Update" does not show any graphical, immediate response, like: changing UI for update info: preparing, initializing, checking, downloading, etc. It invokes feeling of being stuck, frozen, like something bad had happened so this proposal is important and can lead to only better result. - Having bar cleared out and filled up again on next update phase feels quite ok - many programs or systems follow that step by step progress bar pattern. - Having multiple progress bars that are filled to the end after each phase is completed feels also ok, although a bit busy and this could take more space. - Having a single progress bar for all operation is not great IMO. Each phase can take different time, it's hard to have accurate % info (maybe I'm wrong), such progress bar moves much slower (less satisfying), has more opportunities to stuck on certain level (again: not good). Linux users tend to want more info what is happening, even on GUI programs. Single progress bar is ok for single program/package installation but for the system update this feels like too simplistic approach which don't take into account user's intelligence and need to know what is happening. There is a reason why most people end up using Synaptics, Muon, terminals or other less graphically pleasing but more accurate and informative programs. It would be cool if Discover was ahead of normal software centers and presented seemingly simple, nice for newbie and yet, had more "juice" in it. Clear info on package source (and other options timed to it) is a move toward this direction. Improving update experience would be another step. Sure, it won't be ideal at first but once the step will be done, it can be improved. So in the end Discover would be "simple by default, powerful when needed" ;). Another thing is: how package managers questions re handled by Discover? Is it already implemented when we need to delete/replace some packages or there might be info on unresolved dependencies (which can point to manual solution on what to do to fix the update)? So far GUI programs are not always showing enough info so on rolling systems terminal is the advised method of updates. Or maybe allowing users to use terminal for update can be a thing? Octopi does that nicely, I always shows an option to use terminal and I always agree as it's right thing to do on Arch based system. This is ideal, because I either confirm update in GUI program or click to open terminal. There is no additional prompt that would annoy users. Just a bunch of thoughts. Thanks for making PLasma better and better every day? :D
*** Bug 400131 has been marked as a duplicate of this bug. ***
Git commit 4ef91fa6f7335385c359add0a1f22f37fd8808ee by Aleix Pol. Committed on 17/03/2019 at 16:28. Pushed by apol into branch 'master'. Switch to 2 progress bars on the UpdatesPage delegate We show them consecutively, we show "Installing" while installing. M +2 -0 discover/DiscoverDeclarativePlugin.cpp M +1 -1 discover/qml/UpdatesPage.qml M +0 -1 libdiscover/UpdateModel/UpdateItem.cpp M +6 -1 libdiscover/UpdateModel/UpdateItem.h M +6 -2 libdiscover/UpdateModel/UpdateModel.cpp M +4 -2 libdiscover/UpdateModel/UpdateModel.h M +6 -1 libdiscover/backends/DummyBackend/DummyTransaction.cpp M +24 -6 libdiscover/backends/PackageKitBackend/PackageKitUpdater.cpp M +4 -1 libdiscover/resources/AbstractBackendUpdater.h M +3 -3 libdiscover/resources/ResourcesUpdatesModel.h M +21 -2 libdiscover/resources/StandardBackendUpdater.cpp M +1 -1 libdiscover/resources/StandardBackendUpdater.h https://commits.kde.org/discover/4ef91fa6f7335385c359add0a1f22f37fd8808ee
Git commit 95c39a6f7f2bf7ddf69d8aef558012fe2dff305d by Nate Graham. Committed on 17/03/2019 at 17:00. Pushed by ngraham into branch 'master'. Improve update states' UI Summary: - Add a busy indicator when something is refreshing or checking - Update strings to be a bit more user-friendly - Don't change the Update page's title; status is adequately indicated by the footer text already Related: bug 402897 FIXED-IN: 5.16.0 Test Plan: For example: {F6698086, size=full} Reviewers: apol, #vdg, #discover_software_store Reviewed By: apol, #discover_software_store Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D19825 M +1 -1 discover/qml/DiscoverWindow.qml M +19 -12 discover/qml/UpdatesPage.qml https://commits.kde.org/discover/95c39a6f7f2bf7ddf69d8aef558012fe2dff305d