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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
