Hello list,
I wasn't much involved in Mandrake development until
now (except translation), but I hope that that will
change. First I must say that, as a long time Mandrake
user, I very much appreciate the fine work done by
Mandrake developers, especially from a technical point
of view. However, I was slightly disappointed to find
that "the great modifications" in RpmDrake in 9.2 RCs
were mostly under-the-hub stuff. I'm sure that
technical improvements were significant, but the
interface is very much the same.
Personally, I expected something more radical. I
expected that the very concept of "packages" would
finally be abandoned. In this long(ish) mail I'll try
to explain what I mean. I hope that someone
(preferably RpmDrake developers ;) will actually read
this mail and perhaps even make some comments,
suggestions and - who knows, one can only hope :) -
maybe they will accept some of my ideas and implement
them in the next version!
On numerous occasions I've heard users complaining how
Linux comes on 3 CDs while Windows XP is only one.
This shows that they don't realize that these 3 CDs
carry hundreds of exciting software titles.
The reason for this oversight is, obviously, that
program installation tools in present Linux
distributions are intimidating and un-friendly. I
believe that program installation is the central - and
simultaneously, the least user-friendly part of every
Linux distribution. When talking to many newbie
(Mandrake) Linux users, here are the most frequent
complaints they have:
- Packages have cryptic names
And I don't complain about names such as Konqueror or
XMMS - those are fine names for programs. The problem
is that a typical package manager will show something
like
kde-konqueror-3.1.3-1mdk.i586.rpm
That's just scary. A typical Windows user would never
install anything having a name like that.
- Descriptions are too technical
You don't have to look too far to find examples of
this. Take ami-1.0.11-5mdk. When you replace all the
words that a typical user without previous Linux
experience wouldn't understand with dots, you get
"Korean ... using ..., support ... mode and ... mode.
... mode ... is available from the separate packages."
wtf???
Writing better descriptions is not too hard, I for one
volunteer to do that, but even with the finest worded
descriptions users can still be at a loss about what
exactly does each package do. That's why most
beginner-oriented shareware CDs feature screenshots of
programs they carry.
- When I install some package, nothing happens
The problem here is that, when installing a certain
package, user can perceive absolutely no change in her
system, so she is left with a scary feeling that
"something has happened". No desktop icons. No menu
entries. No new directories. Nothing. Especially, the
thing user expects is some new entries in her "start"
menu. Some reasons why this doesn't happen include:
* the K menu sometimes doesn't update immediately
* some programs don't have menu entries (a packaging
bug!)
* some programs are for console only
* some packages actually aren't programs but
libraries or system components
Other possible reasons for the feeling of confusion
are:
* Linux file system will throw files around, with no
distinct package directory
* services aren't shown in the systray, or anywhere
else, apart for some obscure program (such as
DrakServices)
- Dependencies
Not much to be said here :)
- Program installation pops-up during OS install
Most users aren't used to install programs together
with the system itself. Presenting them with a long
list of cryptic package names is one of the scariest
parts of a Linux install. A typical user expects to
install a plain OS, and then to download and
(un)install programs endlessly until she finds
something interesting and suitable. I should know
that, I've fixed dozens of Windows computers
completely broken by senseless installing of
everything found on the Internet.
But the most important issue is:
- "I don't want to install packages, I want to
install programs"
The very word "package" means nothing to the
unexperienced user coming from a different OS.
Therefore, they feel "package managers" as something
alien, an inappropriate tool for what they need.
How do distros deal with these issues?
Dependency hell is solved nicely in Mandrake. However,
other issues remain.
A typical solution, accepted by Mandrake, RedHat, SuSE
and many other distributions are "package groups". The
concept of package groups is used at OS installation
and later the package installer is based around it. I
find this solution to be a lousy one and merely adding
to the problem. Here are some of the reasons why:
- It presumes that users are too stupid to understand
the concept of a "software program"
Never mind the fact that the No. 1 rule of usability
is "never treat users like idiots"; there are indeed
some users that don't care about programs but rather
about tasks to achieve.
*Well, those users have no business installing an
OS!!!*
They should be presented with a preinstalled and
preconfigured desktop, preferably with a task-oriented
start menu. However there are certain people that do
install OSes and programs - what's more, they also do
it for their friends and relatives. They are perfectly
capable of comprehending that a task can be achieved
with several (often weirdly named) programs, and that
some programs can have overlapping functionalities.
How else do you explain the enormous popularity of
sites such as Download.com or Tucows?
- It presumes that a user knows in advance what kind
of tasks will the computer perform
Apart from servers, that's simply not the fact. I
personally use my computer for everything and
anything.
- It installs groups of programs for doing similar
tasks
Well, no offense, but that's plain stupid. Why would I
want both KOffice and OpenOffice.org on my computer?
What I want is: install KOffice, see how it goes,
uninstall it, install OOo... and so on, until I find
something to my liking. That's why having a friendly
program installer rather then installing everything
with the system is crucial to a wider adoption of
Linux.
- It hides some programs away
Which kind of defeats it's very purpose. No wander
that most users don't know about software titles on
their 3 CDs when "Mandrake Choices" (the default mode
of RpmDrake) will show only about a third of them.
My proposition
Based on the above observations, I believe that the
following should be done:
- There should be a new application named "Add/Remove
Programs"
In no way am I suggesting that RpmDrake is to be
replaced. It should be kept as a tool for
professionals and sysadmins that want to have a
complete control of their system. However, newbie
users should be directed to this new Add/Remove
Programs tool.
- This application should feature _programs_, not
_packages_
This is not just about terminology. What I mean is:
list only packages that are programs and hide
everything else. A definition of a program is "a
package that has one or more menu entries". E.g. if
it's not in the menus, it's not a program and
therefore shouldn't be listed.
"So what do we do with those other packages", you ask?
- libraries - should be (un)installed
automatically, as required, transparent to the user.
The installer should also be smart enough to remove a
library when it's not used anymore.
- system components - should be dealt with by
corresponding system configuration tools (i.e. X
servers should be (un)installed with XFDrake, CUPS and
PDQ with PrinterDrake, SANE with ScannerDrake etc.)
- plug-ins and add-ons - they should be installed
through a pop-up window that appears when installing
the corresponding program. For example: presently we
have packages named licq, licq-kde, licq-console and
licq-rms. Add/Remove Programs should list just Licq.
However, clicking on Licq should pop-up a dialog with
checkboxes labeled "KDE support", "Console support"
and "Remote management service". Dependencies for
these packages (such as "at least one of..." and "only
one of...") should be embedded in the GUI, using
tricks such as disabled checkboxes, one checkbox
activating when the other one is (un)checked, radio
buttons etc.
- console applications - this is a tough one :) I
think the best solution here is: there should be a
category named "Console Applications" containing _all_
of them (so no sneaking lynx in the Browsers
category!), with some console applications behaving
like libraries (i.e. if user installs K3b, cdrecord
should be installed automatically) or using mentioned
pop-ups (i.e. Kooka now support both gocr and ocrad,
so a pop-up should appear with two appropriately named
checkboxes)
- development libraries and source code - similar
solution
- other packages - should be dealt with by special
purpose programs (i.e. fonts should be installed with
FontDrake etc.)
- Programs should be listed under their real names
Short version: just use the Summary tag instead of
name+version
Long version: in most cases, this will not do. Summary
contains a short (one sentence) description - what we
need is a name with proper capitalization and spacing.
Therefore: a new RPM meta-information tag
- These programs should be categorized
Something along the lines of "All packages, by Group"
in RpmDrake. However, those categories are horrible.
Why don't we just use the same categorization as used
in menus? That would be very intuitive for the user. I
would also volunteer to develop a new categorization.
To get a clue, look at sites such as Download.com,
Tucows and other. (Apps.kde.com has so many
cross-references that it's barely usable. The point of
categories IMO is that everything is in one and just
one category.) The two "special" categories should be
Console Applications and Servers&Tools.
- Much, much more meta-information
Given the above observations, these are the least that
should be added to present RPM meta-info:
* a nice name
* a category under "the new categorization"
* an icon/logo
* a screenshot
* list of plug-ins and add-ons for use in the pop-up
(may be achieved with what-requires?)
Apart from that, there are some observations with
present RpmDrake that I will humbly present here :=)
- Skip the package selection during OS installation
The rationale is given above. Mandrake should install
a plain minimal desktop. Only a menu should be given
to choose between desktops (KDE, GNOME, Others, No
GUI). This can be discussed further but may I suggest
a new thread :) This change should vastly simplify the
installation! The first time wizard (or Galaxy?) could
offer to run Add/Remove Programs, pointing out to
users that their CDs contain many programs that are
just a few clicks away.
- Combine the Install/Remove/Update tools
The problem is that these three are presented as
separate programs (although we know that they are just
RpmDrake with different params), but have very similar
appearance with the same categories, buttons, etc.
Also, in Package Removal checking a package will
uninstall it, but in Package Installation you need to
UNcheck a package to uninstall it!? Confusing. I think
that there should be a single application with tabs
named "Add programs", "Remove programs" and "Update
programs". Or it could be a single list with
checkboxes, like the SuSE Yast. "Update system" could
be a separate icon.
- "Sources" and "Media" mess
The term "source" was simply horrible. The first time
I saw it, I thought it had something to do with
.src.rpm files. "Medium" is much better, but it has
issues. Mostly because people associate the word
"media" to CDs, DVDs, tapes etc. but not to Internet
repositories. The main power of urpmi IMO lies exactly
in its Internet capabilities. Therefore I present you
my proposal for a new (ugh! not again ;) name for
this: "channels".
- Add more sources/media/channels automatically
I know that Mandrake will never implement this, but
what the hell :) one can dream.
The biggest problem with RpmDrake is that sources are
still too complicated to configure. Therefore I
propose that it connects to a site containing all the
official and unofficial sources and mirrors and then
offer to user to activate some of them. This should
happen the first time RpmDrake is started with the
Internet connection active.
- There should be a clearer distinction between
packages coming from different sources. I.e. I should
be able to see a package coming from Cooker and the
one from CDs and choose one of them as I please.
The Sample Implementation
Finally, to put my money/time where my mouth is, I've
put together a GUI proposal in Qt Designer. (This is
kind of like an application that doesn't do anything.)
Here are some screenshots:
http://members.smartnet.ba/vedran/mdkarp/screen1.png -
The main window, showing new categories, nice name and
meta-info in action, with a clear separation of the
new "channels".
I can further this design and make some sketches for
channel configuration (it's all in my head), Update
Programs screen, the pop-up window etc. If anyone is
interested I can send the .ui files.
Thank you for reading this enormous mail :) I'm not
very good at English so sometimes it takes me more
words to articulate my point. Anyway I hope there are
some useful ideas here.
Regards,
Vedran
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
