Aptitude, ARs

[Enrico Zini]

--cNdxnHkX5QqsyA0e
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[I'm Cc-ing deb-usability-list so that people interested in usability
can know what's been discussed in -devel about it.  I invite others to
do the same]

On Fri, Mar 28, 2003 at 12:06:45AM -0800, Osamu Aoki wrote:

> > I'm interested in helping in the menu issue, too; I've offered help some
> > months ago, but I didn't get many answers.  There are some different
> > problems there though, like coping with the existing Gnome and KDE menu=
s.
>=20
> As for your question on the later thread, I was thinking to "extract"
> data from gnome menu to assign some short key words to each packages.

Extracting tag data from Gnome and KDE menus is a good idea (and it's
the same algorithm I use to merge XBEL bookmark files with tagbk).

However, this would mean providing another, different menu tree.

One problem about these menu trees is that the support people wants them
to be standard, that is to be able to tell how to find an application to
those who seek help.

This means that if we go with a different menu system, we should take
care to make sure that both the paths already available in the Gnome and
KDE menus can be followed to reach an application, so that support
people (which is not limited to just Sun or IBM hotlines) can keep
giving the right directions also in Debian systems.

Even better could be to work with Gnome and KDE people: working at the
same thing, at minimum we want to know what the others are doing, and
hopefully we want to work together and share the most.

I just wrote to the Gnome usability list asking about what's going on in
that field; I have no contacts with the KDE guys, but I hope to have
some soon.


> > How do you plan to tune the thresholds, since this weighting is likely
> > to be strongly subjective?
> Popocon type data gathering is one way I can think of.  This time if any
> of us initiate similar efforts, we need to gather short report on each
> installed package in a standardized format.

Problem is, popcon results are biased: they are limited to machines with
an internet connection and an SMTP server available.  It's unlikely to
be installed in computer labs, kiosks or other systems focused to
providing service to people.  It's also unlikely to be installed on
production servers, were you don't want anything you don't really need.

It also treats all boxes as equal, regardless of the services they
should provide and of the kind of public that uses them.

I don't mean that it shouldn't be taken into account, only that extra
care should be used with the data it provides, and that it shouldn't be
the only source of data used to rate packages if a rating system is to
be put in place.


Bye,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

--cNdxnHkX5QqsyA0e
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+lW7x9LSwzHl+v6sRAppaAJ0T/Y03949Q8xm75samOSWFrNu5sACfSMdm
xSPQ1eHNRedEoLmN1E01zhQ=
=YRZN
-----END PGP SIGNATURE-----

--cNdxnHkX5QqsyA0e--