What happened to pup?

[Mike Hearn]

On Sun, 22 May 2005 17:31:35 +0200, Kyrre Ness Sjobak wrote:
> Lets say Adobe wanted to make a really, really simple-to-use installer
> for their reader.

You're starting out on the same line of thinking that led me to write
autopackage.

For what it's worth here's what we're thinking of for The Next Level
in usability:

  http://autopackage.org/ui-vision.html

All a long way off yet. Essentially, the idea is:

 * Add an extension to .desktop files which points to an autopackage or
   luau XML file (this is the part where you can hook native packages like
   RPMs and DEBs in as well)

 * Define a new XML namespace and element such that you can embed .desktop
   files into web pages, and the browser will render them as it would be
   rendered inside Nautilus, see the mockups if I'm not clear enough.

   For XHTML based web pages it can be embedded directly. For legacy pages,
   you could use an IFRAME that points to a piece of XHTML/XML.

   Gecko already supports this sort of thing: http://www.croczilla.com/xtf
  
   Why XTF and not a traditional Netscape style plugin? Well, you really
   want to be able to control the rendering precisely and defer certain
   things to Gecko - like rendering SVG icons which are blended on top of
   web page content.

 * Allow the user to click and/or drag-drop these embedded launcher icon
   things. So you can drag them into the panel for instance, or onto your
   desktop, or into an email, or just over the applications menu.

   These .desktop files resemble "advertised shortcuts" in MSI. They
   contain enough information to launch them and if the app is missing,
   install them. The desktop/shell can use this information to trigger
   automatic installation.

 * Because GNOME/KDE wish to remain package manager agnostic (which is
   right and good), you need some kind of abstraction so they can stay
   portable whilst still integrating deeply with the base OS. For hardware
   integration the HAL is being built and it seems to be working nicely.
   Nobody seems to have any hangups about using it and it adds value.

   For packaging, there could be an equivalent, one design of which is
   described here:

      http://live.gnome.org/PackagingAbstractionLayer

None of this desktop integration need be autopackage specific. However, I
think it may actually be better if it was from a holistic usability
perspective because autopackage is distribution independent (to a large
extent).

The problem with doing this in the way people are talking about here, with
adding repositories and stuff, is that it's got bad usability.
Generally speaking, it doesn't matter how slick or streamlined your GUI
is if it fails fundamental usability principles like:

- Machine model should match users mental model
- System should be safe, and allow exploration
- System should be predictable and reliable

It's the last one that concerns me here. If you go about relying on
repositories or Fedora Extras you can get these situations:

Bob goes to neat-app.org on his desktop computer and clicks the icon.
After confirming, it automatically installs and runs. He is happy.
Bob switches on his laptop, and does the same thing. He clicks the icon
and gets an error message he doesn't understand. What happened? His laptop
was running Fedora Core 3 and his desktop was running Fedora Core 4. There
are no RPMs that work on Fedora Core 3, so it failed despite both desktop
and laptop *appearing* to be pretty much the same.

Alice finds out about GWhizz, goes to the website, clicks to install and
it runs. She is happy. Because she thinks it's so cool she gets onto her
instant messaging network and tells Sarah about this amazing new GWhizz
and sends her the URL. Sarah clicks the icon and nothing happens. She is
not happy. Neither her nor Alice can figure out why it works in one place
but not the other. What happened? Alice was using Fedora, but Sarah was
using Ubuntu. The desktop and theme are the same though so they, at first
glance, appear to be identical.

In both cases the systems are unusable not because they failed (no system
is perfect) but because they are *unpredictable*. Eventually users will
learn that this system (and computers in general) cannot be trusted and
will flake out just when you need them most. Bad news.

Now imagine only universal packages work with this UI. Maybe they're LSB
RPMs, maybe they're autopackages, the important thing is they work on any
reasonably sane Linux distribution. FreeBSD and other non-Linux systems
aren't really an issue here because the type of people that need very
simple, straightforward UI are not the type who will be using an OS
outside of {Linux, MacOS, Windows}. Now it works whenever you click the
icon, or at least gets a lot further. The system is more predictable, more
reliable, and therefore more usable.

People may raise security as an issue but this is orthogonal to usability:
making things "secure" by being hard to use is just security through
obscurity, which doesn't work very well. Better solutions would be things
like sandboxed installs, whitelisting networks and so on. It's discussed
in the FAQ section of the autopackage website.

thanks -mike