The user interface vision

This document attempts to explain my personal goals for what package management and software installation on Linux should look like in future. This isn't really an Autopackage thing as there's no reason that any of it needs to be Autopackage-specific, rather see this as a description of what I'll be working towards once I feel Autopackage is mature enough to have achieved its goal.

To recap, the goal of the Autopackage project is to create a system that allows you to build packages that can install on any Linux distribution, and that are easy to use, build and interact with.

This goal is one subcomponent of a larger goal - that of making software installation and management on Linux the easiest in the world.

We already have a great deal more power than the competition in the area where it most counts in the short term - the corporate desktop. While systems like apt+rpm or Red Carpet can be as much a curse as a blessing for individual end users and present an ultimately undesirable UI, they are an invaluable tool for IT administrators who know exactly what the configuration of their end machines is, and need to duplicate that effortlessly.

So, given that we already have power for those who most need it, the next place to push forward is in ease of use. This document explains what I think the future should look like, and how we can get there.

Installation

Autopackage itself does not provide a best-of-breed user interface. On its own, an Autopackage is capable of using several front ends but they are all semantically similar: they are geared towards an InstallShield/Win32 style user interface. This is straightforward to implement and doesn't place much demand on other parts of the desktop, but we can do much better.

A fundamental assumption of this article is that the concept of installers have flawed usability. Firstly, their usefulness is limited: you typically download them or get them on CD, use them, then throw them away. If you don't throw them away you now have two representations of the application on your system: the installer icon, and the launcher for the app itself. It is a user error to click the installer icon at this point, but that's perhaps not obvious to somebody who doesn't really understand what's going on behind the scenes.

Usability could be improved if the underbelly of the system was never revealed and there was only ever one representation of an application no matter what state the users system was in. The icon of an application can be used to launch the program but it currently only works if the software has already been installed. In fact, it won't even appear until this is the case.

Many people like the UI that MacOS X, NeXTStep and the ROX Desktop use (or attempt to use), namely that of appfolders. In the appfolders model, the application directory is the launcher icon, and you can install the software by moving the directory to wherever you keep your launchers.

The UI therefore is one of dragging and dropping software onto your system in order to be able to launch it. This UI works quite nicely, and it'd be good to adopt it. In the FAQ we argue against an appfolders implementation for Linux, but this is an argument agains the implementation as used on MacOS X and ROX, not the user interface itself. There are a few fundamental UI inconsistencies with current implementations of appfolders:

You can drag the appfolder from removable media to your system and vice-versa, but you cannot drag the appfolder into an email or IM conversation due to the way the system is implemented.
In order to integrate with the web, MacOS X has some pretty awful hacks: self mounting disk images spring to mind. A DMG file is basically like a disk image that can be mounted as a loopback device: the web browser is responsible for downloading this, mounting it, extracting the appfolders if any are present then unmounting the disk image again. The end result is that clicking a link in a web page can silently place software on your desktop, sometimes with no notification that this has occurred.

A better approach would be allowing the application icons to be dragged straight from the web page into the dock or Applications folder on the system.
Many applications make assumptions about being able to write to their appfolder. This means you sometimes have to move the appfolder to the hard disk before it will run - but this is not always intuitive nor obvious.
Little attempt is made to manage multi-user setups. With a large library of software, the "menu" (normally the file manager is used) can become cluttered with programs irrelevant to the user. If all users can install/uninstall software, you have to manually track what people are using so you don't accidentally remove something another user wants to keep.

Most of these problems are related to the way in which it is implemented. I haven't discussed the various other issues the bundles approach has which make it unsuitable for implementing this UI in the Linux/free software community, that is partly discussed in the Autopackage FAQ. We focus here on the UI only.

So, what would our ideal software installation UI look like? Something similar to the appfolders approach, but with an implementation that lets us take it further would be good. For instance, we should be able to launch software directly from an icon embedded in a web page, decide we like the program and drag it to a panel and send it to a friend by dropping it into an email or IM conversation. This should all transfer the minimum amount of data required, deal with dependencies, and the icon name and appearance should be themable and localised into the users language.

Of course, clicking an icon in a web page to launch software has a few issues we'd have to deal with. The first is that it may take a long time to download and install. The user needs to be aware of this, and should be able to monitor the operation - ah, perhaps our GUI front-ends are not so useless after all :)

So let's say we have some kind of UI for progress feedback. When you click an icon (and this is true no matter what context the icon is in, whether a web page or from disk), the software is located, downloaded and installed in the background with some simple animations to give you an idea of progress. The icon starts gray scale and then becomes coloured as it is installed. An animated clock appears over the icon to indicate that the system is working. Clicking it again reveals the standard progress GUI you can see in the gallery.

Once the software has been downloaded and installed successfully, it is run automatically. After all, the user already requested it be run by clicking the icon. The next time they visit that web page, the icon is already fully coloured and clicking on it launches the Gimp instantly.

The panel is a convenient place to bookmark software for fast access. You can drag icons to it if you like the program and want to run it again without needing to visit the web page. The icon doesn't have to be in a web page. It could be in an IM conversation, email, on a CD, a flash card - anywhere you could store a file, you can store an application icon.

So what is this icon thing? From the perspective of the user it's all really very simple: the icon is the application. From our perspective (that of developers) things are rather more complicated. An icon is in fact a .desktop file with extra meta-data in it describing how the system can locate and install the software. This will probably take the form of a URL to a luau XML description of the package. The desktop environment is responsible for parsing the desktop entry, using the TryExec field to determine if the software is installed or not and rendering it correctly if not. The icon field could point to directory that conforms to the icon theme spec, providing SVG icons for large sizes and hand tuned PNGs for small sizes. Alternatively a new icon file format could be created that allows you to ship around app icons in various formats (probably just a magic ZIP would do fine).

It's the responsibility of an as-yet-unwritten packaging layer to parse the desktop file, select the best package from the ones advertised and begin the installation process while notifying the icon container of progress. The packaging layer then delegates in turn to the actual package manager frontend, whether that be Autopackage, apt, yum, up2date, emerge or whatever. This then retrieves the packages for the right architecture from the best mirrors, resolving dependencies and language packs for maximum efficiency.

Uninstallation

Because the launchers on the users desktop (and in their menu) now contains the package name you can trigger an uninstall by dragging the app to the trash can. One alternative is to garbage collect desktop packages: this would be an opt in system whereby any packages that were marked as collectable were tracked for reachability in a similar manner to how objects are garbage collected in a managed runtime such as Java. When no more desktop entries are reachable from any users account, the software is safe to delete.

This can help solve the problem of many users, who may not communicate with each other over what software is wanted and what isn't. This is the most dubious proposition in this article though and would require careful thought and testing before being proposed formally.

Software updates

Assuming that the software and all its dependencies are available in a package repository current update techniques work fairly well. In the most extreme case it's possible to continuously upgrade a distro without reinstalling for years at a time. However, the UI for this is typically non-existant: the best I've seen is Red Hats up2date service, which while pretty still leaves a lot to be desired.

In a package managed system with Autopackage installed, there are several sources of possible updates:

The native distro update repositories
Updates published by 3rd party packagers using Autopackage (so luau XML files)
Random extra 3rd party software that uses a custom installer. For instance the icculus game ports, CrossOver etc all use custom installers.

To support all of these, a standardised layer is needed that can use plugins dropped into a set of directories to query for updates, then represent that data to the user somehow. An update scan would be performed say once a week, and the results aggregated. Package upgrades can be broadly categorised into two categories:

Updates that apply to system components that the user does not interact with directly. This includes things like the kernel, desktop environment, toolchain and so on. It could also include servers and command line only apps. For these, systems like yum/apt/raw Autopackage work well.
Updates that affect user visible desktop applications.

Both kinds of package updates should be visible in a global package updates UI. This is already implemented on some distros, for instance Fedora has the rhn-applet which pulses a red exclamation mark when there are updates available. This infrastructure needs to be pulled upstream, tidied up (the code is a bit of a mess) and a package update abstraction used so we can get consistency across distributions and desktops for software updates. Security updates are critical enough that we cannot risk user confusion being a cause of not applying them.

For updates with a corresponding desktop icon, an emblem can be placed on it indicating that an update is available. When the user clicks the icon rather than launching the app, the desktop is responsible for asking the user if they wish to upgrade the software before running it, or ask again next week etc.

Security and other implications

You may be thinking that being able to install and run software direct from a web page is rather bad security, but really it's little different to the user downloading and running a .package, RPM or Windows installer normally. Once the user has chosen to give some software access to their system, we should be making it as easy as possible for them to act upon their decisions. Security therefore becomes a matter of how to aid the user in making the correct decisions rather than making their lives inconvenient.

A discussion of desktop security is outside the scope of this article, however a future article will be dedicated to how we can protect the users of tomorrow from viruses, worms, trojans and spyware/adware.

Desktop notifications

As time goes on more and more software will become soft linked, meaning that it can operate in the absence of a dependency but has enhanced functionality when that dependency is present. An example of this would be the Gnome 2.6 clock applet which can interface with your Evolution calendar. This is a handy ability. Unfortunately, it's currently not even soft linked, using libebook is a compile time option. Let us assume that this is fixed - for instance, the relaytool program can be used to make soft linking much easier and will hopefully cause it to be more popular. However, if you now install Evolution in order to make the clock applet recognise its presence you must restart the clock: there is no way to do this in the UI so the only GUI-only way is to log out and back in again.

This is not ideal. One solution is to have a standard for notification of new software becoming available (whether installed by a package manager or install from source by the user): DBUS could be used here. The clock applet would listen for software installation events being broadcast on the bus, and if evolution-data-server was installed it could dynamically link to libebook and initialize its support for watching the Evolution calendar.

Other uses for notification of software installation would be on terminal servers where multiple users may be interested in the availability of new programs. For home terminal server setups this is an especially interesting possibility.