Re: Debian Usability Research
Disclaimer: All is me ranting at 4:30am. Never mind.
> > 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
Reply to: