Linux and application installing

Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about?

Mo illustrated a few days ago about how confusing the updater is and I agree with her; and it’s mostly my fault for not pushing applications harder. Lists of unlocalized generic packages are so 1990’s, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs.

So, a solution. I’ve been working on app-install with some people from other distros for the last few months, and last week it had it’s first public release. Schema version 2 is already being worked on, and now optionally integrates with PackageKit and also provides some other features like sorting applications by rating and application screenshots. I’ve already generated distro metadata for the entire fedora repository (this takes about four hours on my laptop) and packages are available. It’s really easy to generate metadata for the other repos too, but I digress. Read the README file for all the guts about how it works.

I’ve got two demo applications that use the app-install data. One is an installer and one is an updater. These are work in progress, and show dramatically the lack of my UI design skills.

The installer will be an additional tool (much like the ubuntu-application-installer compliments synaptic) which is focused on ordinary desktop users. If you know what an epoch is, it’s probably not for you. The old tool will remain, so panic not. This tool will just install applications, that-is anything that ships a desktop file with an icon. Anything else just isn’t shown. Sorry! We will hopefully show groups too, perhaps even the same entries as the “Applications” menu.

The updater will be an improved version of the old package updater, and anything that’s not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called “System infrastructure“. If you update an application that depends on a package from the “System infrastructure” group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the “System infrastructure” metagroup. Of course, you can descend and pick updates in that group individually like before, if you know what you are doing, but I think most people will just install the metagroup as one lump.

Also, bear in mind that neither app-install or the application data packages are in distros just yet. This stuff isn’t well tested. The packages may steal all your magazines from your bathroom.

Now, I mentioned my ineptitude at designing GUIs. This is where you come in. I would love you add mockups of what you think an application installer or application updater should look like to this page. I’m going to ask Máirín (mizmo on IRC) to help with the design work, so please upload mockups I can share with her and the other design people. Thanks!

15 responses to “Linux and application installing”

  1. jeff

    The 2nd mockup seems good enough to me at first glance, but I’ll give you some text feedback on the first one (because I’m le tired):
    – Do not use progress bars for ratings, they look bloated and they don’t indicate progress. Maybe a rank of 5 stars (with half stars precision)? Just rip rhythmbox’s code for that I guess :)
    – Shouldn’t the “Find” button should be on the right? Actually, why do we have a find button? If performance allows, let’s replace it by a “Search: ” text label, and have the thing autosearch when you type more than 3 characters in the search entry and when you pause for more than 1 second.
    – The “Installed” column… I’m not sure its meaning is clear (ie: is it a status indicator or an action?). Maybe “Add/remove” would be clearer.
    – There should be [ Quit ] [ Apply changes ] buttons on the bottom right.
    – The ubuntu software centre “categories” seem to make sense to me.

  2. zekopeko

    Why all this duplication of work when there is already excellent alternatives such as the above mentioned Software Center? Why not work on it with Ubuntu devs so you can plug PK into it and get all the fancy UI for free?

    There is also a spec for the Software Updater here: https://wiki.ubuntu.com/SoftwareUpdates?action=show&redirect=SoftwareUpdateHandling

  3. Johannes

    Wow, that’s good news. Nice that someone picked up the ideas and pushed them!

    The cool thing of the Linux Desktop is that you can update everything from a central place and a cleaner UI will make that much more transparent for the end-user!

    Thanks!

  4. Jaliste

    That’s nice that this is getting to Fedora and other RPMs distros. One thing (not related) I keep asking myself is Why we can’t auto-update the systems with only security-fixes. I think most users will just choose to stay in a stable repo + security fixes and these should be installed automatically (if the user has chosen it when installing the system) without user intervention. Since now Ksplice is getting to Fedora, this probably could be made in a way that you don’t even need to reboot your system. Another thing I would like to see is to have some kind of “time machine” for the status of your system, where this means that each time you update some packages, there is a record with enough information so the user could choose to revert one or some of the package’s updates.

  5. Michael Vogt

    A quick note from me on the ubuntu software-center packagekit backend. It should not be hard to do that, as was pointed out by Frédéric Péters. The demands on the packaging layer are pretty small, most information comes from the app-install layer. The backend should be easy to switch to PK.

  6. henshaw

    Fedora updates often comprise of related packages pushed out together (e.g. update FEDORA-2010-5392). Additionally a package (and its subpackages) may contain multiple applications.

    So an application-wise view of updates may be not be much more user-friendly than a package-wise view of updates. For example, an ordinary desktop user may be presented by a long list of applications to update, which belong to a much smaller list of packages. Or they may be presented with a list of applications which can only be updated together (e.g. firefox and chatzilla, or any other xulrunner-based app).Or they may be presented with a KDE SC 4.x.y update, which comprises of a bewilderingly long list of items (whether viewed as applications or packages) but only makes sense to update all together.

    If you’re going to redesign the update UI for “ordinary desktop users”, shouldn’t it also better reflect the way updates are structured? That is, one entry for all firefox + xulrunner updates (or packagekit updates, or kde/openoffice/kernel/etc. updates) with the options to view a detailed list of packages (or applications?).

    See also my comment at http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/#comment-7207

  7. howick

    app-install will be nice for an Ubuntu Software Center alternative, but for the update manager, I propose to use

    no interface at all

    and update automatically in the background.

Bad Behavior has blocked 2769 access attempts in the last 7 days.