[Debtags-devel] Re: Usability: Technical details in package descriptions?

Benjamin Mesing ben-ml at gmx.net
Wed Aug 3 07:16:23 UTC 2005


Hello,


I agree with you, that the documentation review team should have the
debtags approach in mind. Also debtags-edit being able to edit
descriptions would be desirable - however someone would need to
implement this, and Enrico is very busy ;-). Being able to edit the
package information in one program does have a lot of charm :-) 
Note that it took Thaddeus Black years(!) to categorize all the packages
in sarge (for debram). Being done by a team makes a lot of sense - but
even more to be cared for by the package maintainers themselves.

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. Especially
details like "written in C++" should be left to the debtags system as
there is no use for the end user. However not every description should
be tuned for your grandma, they should be written towards the target
audience. No use to describe an IDE, the debhelper packages and other to
your grandma. Science applications are also canditates were it might
make sense, that many of us may not understand their purpose without
doing us any harm. 
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).
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?
Finally I disagree with debtags being highly technical. It is only one
step further from hierachies, and in my opinion even more intuitive.
Take a look at the "packagesearch" program to see a really simple user
interface. It does allow only an && combination of tags, but for most
end-users this is sufficient.

I have CCed debtags-devel and attached your original message for the
benefit of those reading only debtags-devel.

Best regards 

Ben

> Hi all,
> 
> Debtags shows great promise in covering the technical aspect of 
> describing Debian packages.  Debtags do a better job than Package 
> Descriptions when it comes to precisely describing a package in a 
> highly-technical, highly-searchable format (that is fully geek compliant).
> 
> Wouldn't it make sense that debtags and Package Descriptions not do 
> redundant work of each other?
> 
> I propose that by a simple split in the use of the Package Description 
> and debtags between the "internal world" (ie. relative to the computer) 
> and "external world" (ie. relative to the end user's real life apart 
> from their computer), respectively, I think we can make the best use of 
> volunteer effort as they review the Package Descriptions and create debtags.
> 
> I think that the Package Description should be (re)written using 
> language intended at your grandma.  This way she can intuitively find 
> packages also without needing to learn about the debtags system. 
> Learning how to use the search button in Synaptic is work enough for 
> her, let alone learn and play with debtags to do wild and crazy 
> searching (with logical operators no less).
> 
> As debtags cater to the geek, I think the Package Description should 
> cater to grandma.  I think the package desription should state the 
> purpose of the software as it relates to the real world, whenever 
> possible: eg. "helps you easily keep lists of contact information on 
> people along with details like their birthdays".  A description like 
> this is useful to grandma.  Anything more technical and you lose her to 
> the likes of Ubuntu or Linspire.  Come on, throw grandma a (less than 80 
> character) bone!  Grandma can give back some day by helping to file a 
> bug report or something.
> 
> I therefore propose that ***the package description should explain how a 
> package could be used for real-world usefulness for the end user***, 
> giving an example or two for those with dimmer imaginations than hard 
> core geeks.  In my example above, mentioning tracking birthdays helps 
> users start imagining the potential usefulness of the software.  Note 
> how mozilla.org has a screenshot of the craiglist website on the front 
> page to help users *imagine* visiting a website like craigslist using 
> the browser (albeit visually, not textually).  Same idea.  Imagining how 
> some piece of software could be useful is hard work for most people, and 
> you can help them tremendously by providing a simple and obvious-to-you 
> example in the package description.
> 
> Debtags will much better handle all the fine-grained, geeky details, 
> like the language it was written in, and to which suite it belongs. 
> Therefore ***I think debtags should aim to exclusively describe a 
> package's relationship to the internal system it lives in, ie. relative 
> to Debian.***
> 
> 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
> 
> 
-- 
Please do not sent any email to the ben-ml at gmx.net - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.




More information about the Debtags-devel mailing list