[HIG] REVIEW: Desktop Integration

[Calum Benson <calum benson sun com>]

Again, mostly proof-reading comments on this chapter...

Desktop Integration
-------------------

- "There are two elements... GNOME Desktop":  first, this sentence
should probably end with a colon since it introduces a list, and second,
are we always going to use capital D when talking about "the GNOME
Desktop"?  If so, need to enforce this consistently.

- "...users discover your application in order to execute it":  delete
"in order", and suggest "run" rather than "execute"

- "...and if it supports any documents add those to the document type
(MIME) registry": shorten to "and add any documents it supports to to
the document type (MIME) registry"


Placing Entries in the Menu Panel
---------------------------------

- Menu categories... make sure these are ordered in the way they will
appear by default, or if we haven't decided that yet (see Nils'
proposal), alphabetically.  Suggest following each category with a brief
description of its purpose, e.g.  "Office - word processors,
spreadsheets, financial applications, presentation programs and
associated utilities"

Menu Entry Captions
-------------------

- "(or "names" as the panel calls them)": we should probably either
ensure this is fixed in the panel (if we deem that appropriate), or call
them 'names' here as well

- There are at least two clear recommendations in the opening paragraphs
that should be split out into a Recommendations list in keeping with the
other chapters: follow the format "AppName AppType", and use the same
functional description as exisiting programs in the same general
category.  This would break up the prose, call out the recommendations
clearly, and get rid of the (i) symbol that we don't use anywhere else.

- "In user testing of MIT's Athena...": much of this paragraph is
needless repetition of the first; try to condense the two into one.

- Examples: these would probably be better in a table, they look odd as
they are.  Even better would be a table combining both the example
captions and example tooltips for them (including those in the following
Tooltips section), but this would require more substantial
restructuring.

- In some places in this section we talk about titles, in others,
captions. Be consistent.

- There are more recommendations in the paragraphs following the first
examples that should be broken out into a list: use the first format if
you can think of competitors to your app, avoid unnecessary technical
detail in captions, and keep captions succint but distinct.

- "If possible, it is better to remove...": suggest just "It is better
to remove".  Actually this should probably be a bulleted recommendation
as well.


Menu Entry Tooltips
-------------------

- Again, recommendations in body should be broken out, e.g. panel menu
tooltips should be phrased in verb form.

- "... (and hence little information...)": Could lose the parentheses
here

- Again again, tooltip examples probably better in a table showing the
caption and the tooltip


Providing a Connection Between Documents & Applications
-------------------------------------------------------

- Suggest renaming as "Connecting Documents and Applications"

- "Application & MIME database": lose the ampersand, i.e. "Application
and MIME Database"

- "association between types & applications": ditto

- "The preferred list for a particular document type..":  'preferred
list' should be italicised, quoted or whatever mechanism we're using to
indicate glossary terms (and it should be in the glossary, of course)

- "all files of type text/*... of type text/html": the MIME types need
to be typographically distinguished somehow

- The third paragraph here is a duplicate of the first and should be
removed

- In keeping with the 'add an explicit list of links at the end of each
section' idea I suggested before, might have a link to the GNOME VFS API
reference here at the end