Debian Usability Research
Enrico Zini
after the entusiasm gathered at the Linux Conference Australia 2003, I'm
honored to announce the birth of a new Debian effort.
The Debian Usability Research
* Where it is
Web site: http://deb-usability.alioth.debian.org
Mailing list: http://lists.alioth.debian.org/mailman/listinfo/deb-usability-list
* What it is
The Debian Usability Research is a volunteer research effort focused on
identifying and addressing Debian-specific usability issues.
* What it is not
The Debian Usability Research does not intend to address general human computer
interaction, nor any other usability issue that is not specific to Debian, like
Gnome, KDE or OpenOffice usability problems. For that purpose, other
infrastructure and communities have already been available for a long time.
* Brief history
At the Linux Conference Australia 2003 there was a BOF about debian usability
issues. At the end of the BOF we gathered e-mail addresses and decided to
continue working on these issues once we got back home. The continuation of
that BOF is what is now called "Debian Usability Research".
The initial main areas of interest were:
- status of package metadata: what is ok, what is still missing, how could it
be added;
- package searching and browsing techniques, to cope with the large and
increasing number of packages;
- how "debian flavours" (debian package subsets targeted at specific needs)
could help produce distributions that better address the needs of different
communities and how they could be more easily created;
- how to handle usability bug reports.
Recently, there have been many interesting discussions in debian-devel
on topics like these, and it seems that there is a strong and growing
interest in them. I especially welcome all the people who followed
those threads to join and participate to the list: the Debian Usability
Research intends to be the place where this kind of issues can be
seriously studied and taken care of.
Debian is steadily growing, and the growth introduces new and
interesting usability problems.
I hope you will decide to join in, and share the fun.
Yours truly,
Enrico
P.S.:
I would really like to thank the staff of www.bononia.it for kindly
volunteering to host the project. We had already started setting up
things there, but Alioth came in and it was the right place to be.
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enr...@debian.org>
Andreas Tille
> I hope you will decide to join in, and share the fun.
I might suggest to read
http://people.debian.org/~tille/debian-med/talks/200303_chem_int/index_en.html
There is also a link to the Debian Subproject HOWTO which might be very
interesting to you.
Moreover this again brings up the question whether somebody would volunteer to
care for web pages common to Debian internal projects. I would like to offer
help here. The talks is available and I plan to publish a paper about this
topic in Linux Magazin.
> P.S.:
> I would really like to thank the staff of www.bononia.it for kindly
> volunteering to host the project. We had already started setting up
> things there, but Alioth came in and it was the right place to be.
In my opinion the official Debian web sites near debian-jr, debian-med and
debian-desktop are the best place to host this project.
Kind regards
Andreas.
--
Mankind must put an end to war before war puts an end to mankind.
John F. Kennedy
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Enrico Zini
> In my opinion the official Debian web sites near debian-jr, debian-med
> and debian-desktop are the best place to host this project.
I considered making an official subproject, but since it is just the
continuation of the works of a BOF, I thought we'd best spend some time
to better organize ideas. For that reason, Alioth seemed good.
However, I realize this is a good occasion to start a discussion in
debian-devel to verify the need of such a subproject.
Good! Let's do it.
What would a Debian Usability project do?
Why not Debian QA?
Who's interested?
If I should give a definition of Debian Usability, I'd go with:
Identify problems in how Debian, or a part of it, addresses a
particular, practical need. Then study them, and find solutions.
About Debian QA, I'd like to hear the Debian QA people on this: AFAIR
they have always been focused on more practical issues, but this doesn't
mean that they are not interested.
Who's interested? Me, for sure!
Enrico
Andreas Tille
> What would a Debian Usability project do?
I see a really strong relation to Debian-Desktop. If you can't see any
different goals just work together.
> Identify problems in how Debian, or a part of it, addresses a
> particular, practical need. Then study them, and find solutions.
In this general sense it is plain QA and we need no extra project.
> Who's interested? Me, for sure!
I guess we need more information about your plan.
Kind regards
Andreas.
--
Mankind must put an end to war before war puts an end to mankind.
John F. Kennedy
Luca - De Whiskey's - De Vitis
> However, I realize this is a good occasion to start a discussion in
> debian-devel to verify the need of such a subproject.
>
> Good! Let's do it.
>
>
> What would a Debian Usability project do?
Your areas of interest are a good starting point: i think we really need some
new research on those issues. More things may come later in the project. Just
start with the one you've listed.
> Why not Debian QA?
Because i think QA should be (and is) a team for the control and assurance of
the technical quality and compliance to Debian Policy.
> Who's interested?
Well I'm too busy to contribute, but I think there should be a cooperation
between Usability and Policy (more than QA).
I'd like to see something like you solving a usability issue, then working with
the Policy to let your solution be consistent with the other rules; at the
end, QA would ensure (as far as possible) that everything comply.
ciao,
--
Luca - De Whiskey's - De Vitis | Elegant or ugly code as well
aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$ | as fine or rude sentences have
Infinite loop: see `Loop, infinite'. | something in common: they
Loop, infinite: see `Infinite loop'. | don't depend on the language.
Colin Walters
> On Thu, 3 Apr 2003, Enrico Zini wrote:
>
> > What would a Debian Usability project do?
> I see a really strong relation to Debian-Desktop. If you can't see any
> different goals just work together.
I do too, honestly. -desktop has a slightly larger goal (e.g. making a
good default GUI environment), but usability is at least 75% of the
project.
J.Brown (Ender/Amigo)
> > In my opinion the official Debian web sites near debian-jr, debian-med
> > and debian-desktop are the best place to host this project.
>
> I considered making an official subproject, but since it is just the
> continuation of the works of a BOF, I thought we'd best spend some time
> to better organize ideas. For that reason, Alioth seemed good.
The main problem that I felt when discussing this with Enrico and other
people at LCA/DebMiniConf/Usability BOF is that setting up a subproject is
rther premature without really defining what the goal is. 'Debian
Usability' is a pretty broad subject. And a few people didn't quite get
it, so dragging the topic into an official project is rather sily until we
judge how many people can the idea or come up with enough to justify it's
creation and whether it will go anywhere. Alioth is good for this purpose
I think. And it makes it easier for me as I can easily be very involed
without feeling 'I need to get around to applying as a DD, but I have a
phobia of it".
> If I should give a definition of Debian Usability, I'd go with:
>
> Identify problems in how Debian, or a part of it, addresses a
> particular, practical need. Then study them, and find solutions.
The emphisis being on the word Debian. Debian-Desktop and other projects
on their own have been focusing on desktop-specific usability for some
time. Most big projects hae usabiity discussions on their own software.
So the point is not to look at problems with 'usability on Debian', but
'usability with Debian'.
Practical example that came up in the BOF and the Mini-conf (and points
that Andreas seems to have kind of alluded to in the LinuxTag talk):
Debian has task packages and other meta-packages to install a specific
subset of software, or specific functionality. However from a usability
point of view, Debian has far too much software. So there is a usability
problem with both package management software and policy/process.
User A wants to install a graphical mail client for KDE, but this is a
minimal system to installing a 'desktop' task package isn't exactly the
best option. How would the user find out what mail clients are available
in Debian? Apt tools are great if you know what you want to install, but
with the large amount of software in the repository what about a user that
is just getting started?
You could say, "Well, look at packages in Section mail.. or it might be
in section net.. or section X11... Well hopefully in all of them." - so
are a bunch of MTAs and other useless (in this situation) clients.
Or, "apt-cache search mail" (useless, "apt-cache search kde mail" is
better but still very bad). Look at packages that Provides: mail-reader?
Time consuming, and not possible for something more obscure. Face it, in
this case the tools (and perhaps the metadata itself) isn't quite up to
spec and anything would be nothing more than an educated guess.
However, User B has a problem in that she has to use large font sizes
because of a vision problem. Yet, the truetype libraries were not compile
with --enable-bad-example. This is, among other things, a usability
problem. Yes, it could be considered a problem with Debian and thus a
Deban Usability probem. However this is a problem possibly not shared by
other distros. I don't believe that this type of problem is a problem to
be delt with as a 'Debian Usablity issue'. It has to do with a specific
QA'sh problem - but it doesn't fit in when you Debian as anything more
than an indexed group of Packages and software... at best it would be a
Debian-Desktop problem. :)
- Ender
http://www.scummvm.org/ | Classic Adventures on Modern Systems
http://www.quakesrc.org/ | Making old engines bloatier
http://www.enderboi.com/ | Spam, Junk and generic garbage
Christian Surchi
> > What would a Debian Usability project do?
> I see a really strong relation to Debian-Desktop. If you can't see any
> different goals just work together.
What about discussing about server-side usability? :)
Should servers be *unusable*? :)
--
Christian Surchi, csu...@debian.org, chri...@firenze.linux.it | ICQ
www.debian.org - www.softwarelibero.it - www.firenze.linux.it | 38374818
"I don't have to take this abuse from you -- I've got hundreds of
people waiting to abuse me." -- Bill Murray, "Ghostbusters"
Christian Surchi
> I do too, honestly. -desktop has a slightly larger goal (e.g. making a
> good default GUI environment), but usability is at least 75% of the
> project.
I don't think usability is simply a subset of -desktop.
Usability is a general concept, not only related to desktop users, IMHO.
--
Christian Surchi, csu...@debian.org, chri...@firenze.linux.it | ICQ
www.debian.org - www.softwarelibero.it - www.firenze.linux.it | 38374818
If you're going to tell people the truth, be funny or they'll kill you.
-- Billy Wilder
Enrico Zini
> > > What would a Debian Usability project do?
> > I see a really strong relation to Debian-Desktop. If you can't see any
> > different goals just work together.
> I do too, honestly. -desktop has a slightly larger goal (e.g. making a
> good default GUI environment), but usability is at least 75% of the
> project.
Well, I see Debian Usability as something not necessarily tied to the
desktop. I see instead the risk of think about usability as something
that only regards the desktop, and miss all the rest.
I quite agree that usability is a really big part in addressing desktop
environments, and it's no surprise that all major desktop projects have
thriving usability working groups. However, while these people's task
is to address desktop usability, ours (as Debian, not as Debian Desktop)
is to address the distribution as a whole.
This doesn't mean just a desktop: it could mean a handeld environment,
an installation on a live-cd acting as a kiosk with a TV output, an
embedded router or (and this is what's special about such a big
distribution) any other use we can't predict.
Many topics have been raised at the LCA BOF, some of which have been
summarized in my original announcement.
Some of them are most useful to the desktop area, such as how to put
mime support info in package metadata to allow features such as
installing an appropriate reader on demand.
Some of them, however, cover a broader scope, like introducing multiple
package sections, providing different metadata sets for different debian
flavours/subprojects or finding a smarter way to answer usability bug
reports. This stuff can definitely help in a desktop environment, but
it's not limited to it: it improves the whole structure of the distro.
There is already a lot of work going on in usability for the desktop
area, but very little has been made (afaik) to address the specific
problems that a whole, huge distribution like Debian can have.
This is where I want to go.
Enrico
David B Harris
> > I do too, honestly. -desktop has a slightly larger goal (e.g. making a
> > good default GUI environment), but usability is at least 75% of the
> > project.
>
> I don't think usability is simply a subset of -desktop.
> Usability is a general concept, not only related to desktop users, IMHO.
Usability means different things to different groups. The Debian Desktop
subproject is decidedly targetting non-sophisticated users (or, rather,
those users who aren't sophisticated as far as Debian is concerned).
Good "usability" for someone like myself (a systems administrator) means
a plethora of command-line utilities and an unpleasant number of options
to control them. Very steep learning curve, something you wouldn't want
to inflict upon, say, a user the Debian Desktop is targetting - but
something that would make my job much, much, much harder if it didn't
exist.
Andreas Tille
> User A wants to install a graphical mail client for KDE, but this is a
> minimal system to installing a 'desktop' task package isn't exactly the
> best option. How would the user find out what mail clients are available
> in Debian? Apt tools are great if you know what you want to install, but
> with the large amount of software in the repository what about a user that
> is just getting started?
So I guess the first thing we urgently need is an evaluation document which
describes commons and differences between packages solving certain tasks.
This might perhaps decrease the sort of flame wars emacs vis vi,
mutt vis pine, postgresql vis mysql or whatever. Just search the archive
for this type of flame wars, remove the rubish and find a reasonable way
to publish.
Kind regards
Andreas.
--
Mankind must put an end to war before war puts an end to mankind.
John F. Kennedy
Eduard Bloch
* J.Brown (Ender/Amigo) [Thu, Apr 03 2003, 02:30:30PM]:
> User A wants to install a graphical mail client for KDE, but this is a
> minimal system to installing a 'desktop' task package isn't exactly the
> best option. How would the user find out what mail clients are available
> in Debian? Apt tools are great if you know what you want to install, but
> with the large amount of software in the repository what about a user that
> is just getting started?
>
> You could say, "Well, look at packages in Section mail.. or it might be
> in section net.. or section X11... Well hopefully in all of them." - so
> are a bunch of MTAs and other useless (in this situation) clients.
I and others did already suggest all we need to make this work.
Conditional dependencies, controllable sequence of debconf setups and
full-non-interactive debconf setups based either on answers of previous
debconf answers (see controllable sequence) (or maybe some flavor
keywords in some conffile, but I do not like this solution much).
For example, the user chooses the packages env-i18n, env-french,
network-client, x11, web, kde, mail, news, popular-software.
env-french depends on utf8-preconfigure and has lower
debconf-sequence-priority so utf8-yes-or-not is asked first.
x11 has higher debconf-sequence-priority than kde.
mail and news have lower debconf-sequence-priority than client.
kde has "Cond-Depends: env-french -> kde-i18n-fr".
env-french asks on installation about different french specific things
(do not ask me what) and writes them where needed.
popular-software has "Cond-Depends: kde -> kmail".
web has "Cond-Depends: kde -> konqueror, x11 -> mozilla-browser, (x11 && non-US) -> mozilla-psm".
Etc.
Currently, we do not have any such mechanism in Debian to make things
smooth, and they are not even "on the radar of the things to be done".
So, sorry, if you wish to change some things in Debian to make them work
smooth for the end user, redesign the packagement system first.
And I already see some others critisizing me about claiming some things
without evidence, but that is (as always) the beginning of another
flamewar toggling the ignorance switch and ending in _nothing_.
MfG,
Eduard.
Michael Banck
> User A wants to install a graphical mail client for KDE, but this is a
> minimal system to installing a 'desktop' task package isn't exactly the
> best option. How would the user find out what mail clients are available
> in Debian? Apt tools are great if you know what you want to install, but
> with the large amount of software in the repository what about a user that
> is just getting started?
>
> You could say, "Well, look at packages in Section mail.. or it might be
> in section net.. or section X11... Well hopefully in all of them." - so
> are a bunch of MTAs and other useless (in this situation) clients.
Easy task using aptitude's category browser. See
http://debian.vitavonni.de/packagebrowser for the available categories.
Michael
Petter Reinholdtsen
[Enrico Zini]
> What would a Debian Usability project do?
What about looking at the new installer, and give suggestions to how
it can be made easier to understand and user for new users?
Enrico Zini
> > What would a Debian Usability project do?
> What about looking at the new installer, and give suggestions to how
> it can be made easier to understand and user for new users?
Good one. As you can probably see, I'm pretty busy with many other
things; however I hope someone picks this one up and starts working on
it.
Before giving suggestions on how it can be made easier for new users,
however, it is of primary importance to understand who is actually going
to use it, and how.
For example, a *really* new and occasional user is likely to try the
distro from a CD found in some computer review. For that kind of
target, the installer is maybe the worst tool to use, as it would be
preferable to ship a Knoppix or Morphix style live CD with a good
on-disk installer that produces a clean debian system and there you go:
it couldn't be made easier, no matter how you try!
When those live-cd debians will start to produce good and clean debian
systems once on disk, no newbie and desktop oriented people will ever
need the installer. This would mean that the people working at it
won't need to focus on new and inexperienced users, but should instead
concentrate on a more complex but complete and flexible system.
Some other experienced people would maybe boot a Knoppix and create an
on-disk Debian with debootstrap, chroot into it, dpkg --set-selection
from somewhere and that's all.
Many install methods have popped up from time to time, and maybe the
role of an installer is not anymore what it used to be.
Is there someone who could conduct some study on this?
Yours truly,
Enrico