Written by xfuser4 the 29 Jun 09 at 11:24.
Related project: Update manager.
Status: New
Rationale
While the automatic update of Ubuntu is great, it seems to be confusing to some users.
The problem is, that often there is a list of packages which are totally unknown to the user (like openssl, libwebkit or HAL).
A user that just don't know, what these packages mean, could be confused by the large set of information (esp. after a fresh install of Ubuntu). At least it will be useless for the user and if something went wrong, the user could not really tell what kind of update happened before the system failed, because the list was too long.
@Darwin Survivor: Damn you! Stealing my fame and glory :D
Regarding categorizing, I think that it would be good to try to stick to very beginner-friendly names. Preferably consistent with naming scheme in menus. But Exact menu categories; Accessories, Games, Graphics, etc. might be rationalising a bit too much, and would probably require two levels in the tree-view i.e. category>application>packages:
For example I think that we'd have to stay away from names like "Gnome" and "Baobab" (either use a more descriptive name or shove those updates under a "system" category)
Showing users exactly what is being updated is one of Ubuntu's better features. I'd much rather have it show that outright then have to click on a link or expand something to see what is going on. I say, keep the updater as is.
andruk(Idea reviewer)
wrote on the 4 Jul 09 at 09:15
The advanced mode should expand all trees.
I really like the tree idea, as it seems to represent the real relationships between packages.
Besides increased understandability for users who do not understand packages, I think some form of categorizing would be beneficial for the majority of users.
As it is now the updates are just one long alphabetically ordered list, and unless you intend to read through all updates in alphabetical order it is not very useful.
With the tree view we could hopefully keep all the information which is available currently but arrange it in a nice and useful structure.
It seems to me like it would take extra time for the computer to calculate the dependencies, and then it might not even determine the correct application that's being updated.
What I had in mind (and I think others too) would not involve calculating any dependencies. Instead, all packages would have a simple "category" (or "whole application" if you will) assigned to them, meaning that everytime the update manager runs it checks all packages that are to be upgraded for their assigned category, and then displays those categories as the top level of the tree, with the packages themselves below that, just as they are displayed currently.
A starting point for this would be to simply use the "sections" which are already assigned to all debian packages, as these imagined "categories".
However, for this to mean a simplification for new users and make a good structure I think the sections may have to be significantly redesigned in being turned into categories in U-M. For example, I would rather see all of OpenOffice.org under one "OpenOffice" or even "Office" category rather than spread out over "editors", "text", "gnome", "translations", etc. as is the case if you look at the current sections assigned to the packages.
Translating the "sections" into appropriate "categories" might mean some considerable work, in going through all packages.
But I still think that just stealing the sections straight off would mean an improvement compared to current alphabetical list.
It would maybe be a good idea to expand all categories automatically if the total number of packages being updated are below a certain number, say 5-10 something.
And possibly an option to "(always) expand all categories" would be useful to.
(Rather uncertain on that one though, might be good to just push that back into gconf in the form of "expand categories threshold" i.e. when *number of upgradable packages* are below this threshold all categories are expanded automatically, hence if set to 1 it would have the "always expand" effect).
Personally I dislike the idea of hiding information. I much prefer it be presented and not looked at by those who don't care/understand it.
That said, I do understand not wanting to frighten or scare off those who do not need or want to know the details. Unfortunately, after time, that approach often leads to the information not being provided "since most users don't want it". And that path leads to mostly hiding information like Windows does to its users.
Lastly I wanted to say that the tree approach sounds good but may be difficult to implement since some updates affect more than one package.
Summary: I voted against just hiding anything, for optional choices, but not for the tree method even though it might be the most attractive method of presentation.