Re: Usability: Technical details in package descriptions?
Benjamin Mesing wrote:
However I have to say that I disagree with you in some points. You are
correct, that the package description should be as non technical as
possbile, without underminining the usefullness of it.
Yes, I agree. Instead of the "absolutes" I proposed, perhaps it still
makes alot of sense to have generally have rules of thumb that:
1) Package descriptions should tend towards readers like grandma by
default (ie. are as general as possible by default), and
2) Debtags tend toward geekly, highly-accurate searchability by default
(ie. are specific by default)
This would still help reduce redundancy and economize the efforts of
volunteers who edit the Package Descriptions and add Debtags.
I think the following formula should hold true: What you don't
understand that should be of no use to you. E.g. I don't have any use
for programs evaluating DICOM images (I only know what it is from a
recent discussion in debtags-devel).
I strongly agree here.
Additionally I do strongly disagree with debtags describing only the
internals! Debtags is designed to allow an effective search without the
fuzziness you get, when doing a full-text search. And it fullfills this
task very good (have a look at the use:: and works-with:: facet). Or
should your grandma read the >15.000 package descriptions to find a
program to archive her receipies?
My point is that Grandma should be able to merely use the simple search
dialog in Synaptic without having to mess around with selecting/surfing
through debtags. Moreover, her search terms are going to be very
general, eg. "money" (instead of accounting) or "recipes" (instead of
cooking). Therefore, let her general query turn up the best results,
and hopefully having a general description (ideally with example use
mentioned) in Package Descriptions helps in this regard. A Package
Description provides the opportunity to squeeze in a few synonyms, or
related words for even better searchability beyond the rather standard
values in Debtags.
If the debtags also get searched when she does a simple search, then
great. This will depend on how seamlessly debtags get integrated into
package managers (like Synaptic's) search facilities (for example, a
simple search by default, then an "Advanced" button to expand the search
dialog, and there are all the debtags to select or exclude, with logical
operators).
Finally I disagree with debtags being highly technical. It is only one
step further from hierachies, and in my opinion even more intuitive.
That's a good point. Since this is CC'ed to debtags-devel, perhaps
there could be a quality measuring facet called "Maturity::", with
Sourceforge-like values such as: "Conceptual" -> "Planning" ->
"Pre-Alpha" -> "Alpha" -> "Beta" -> "Stable" -> "Mature"
I have CCed debtags-devel and attached your original message for the
benefit of those reading only debtags-devel.
Best regards
Ben
Wouldn't it make sense that debtags and Package Descriptions not do
redundant work of each other?
And on a related tangent, wouldn't it also make sense that all the
volunteers who are going to examine all the package descriptions one at
a time also create the appropriate debtags while they are at it? This
could further help eliminate redundancy in what debtags and package
descriptions explain.
At the very least, wouldn't it make sense for there to be more
coordination between the debtags effort, and the Packages Descriptions
review campaign? Maybe the gui tool "debtags-editor" should/could be
extended to *also* allow editing of package descriptions?
Cheers,
--
Dustin Harriman
http://annexia.ca
--
Dustin Harriman
http://annexia.ca
Reply to: