ubuntu-manual team mailing list archive

[Vishnoo <vish@xxxxxxxxxx>]

On Wed, 2010-07-07 at 12:47 +0100, Phil Bull wrote:
[...]
> This is certainly something we can help with. I think it would be useful
> to develop some guidelines for user-friendly package descriptions before
> we start fixing bugs; consistency is particularly desirable in this
> situation, and decent guidelines will allow developers to fix their own
> package descriptions properly, if they like.
> 
Brilliant ! This would certainly help a lot!
Having a unified pattern for all the descriptions would certainly bring
consistency.

> Do you have any information on what users are typically looking for in a
> package description? We could guess at their requirements, but I'd
> prefer to rely on actual feedback if possible.

Charline Poirer is working on making them available , we should probably
have it by the end of the week.

>  My guesses would be:
> 
>       * Broadly, what you can do with the application (simple
>         description, first para)
>       * Notable features
>       * Supported specialist features (necessarily more technical)
>       * Links to further information and documentation
SC presents a link to homepage as "Website". So we probably dont need it
in the description.
Interesting idea to link the documentation, maybe MPT could work it into
his mockup? :
https://wiki.ubuntu.com/SoftwareCenter#Software%20item%20screen


>       * Where the application can be started from once installed (might
>         cause problems between GNOME/KDE/Xfce/etc.)

https://wiki.ubuntu.com/SoftwareCenter#%E2%80%9CWhere%20Is%20It?%E2%80%
9D%20button
Should cover that.

>       * Equivalence to applications on other operating systems
> 

The first two para should be sufficient for most of the applications. We
should probably set a guideline which applications need the rest. 

MPT , your thoughts on setting a standard format for descriptions?

> In reference to comments in some of the bugs: including technical
> information is not necessarily a bad thing. There are use cases where
> the user specifically wants technical information, such as which file
> formats can be handled by an application, or whether certain specialist
> hardware is supported.

Application extension handling is essential , it's not planned to remove
that information. Users do often search for applications based on the
filetype they want to open.

> For the GIMP, that would lead to a description something like this:
[...]
Thanks , mentioned it on the bug report.

-- 
Cheers,
Vish