document the new Applications pref panel

RESOLVED FIXED in Firefox 3

Status

Firefox Graveyard
Help Documentation
RESOLVED FIXED
11 years ago
2 years ago

People

(Reporter: Steffen Wilberg, Assigned: myk)

Tracking

Trunk
Firefox 3
Bug Flags:
blocking-firefox3 +

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

11 years ago
Bug 377784 introduced the Applications pref panel, which replaced Contents -> File Types and the Feeds panel.
(Assignee)

Comment 1

11 years ago
Created attachment 280957 [details] [diff] [review]
patch v1: basic documentation of the new prefpane
Assignee: nobody → myk
Status: NEW → ASSIGNED
Attachment #280957 - Flags: review?(gavin.sharp)
(Assignee)

Updated

11 years ago
Attachment #280957 - Flags: review?(gavin.sharp) → review?(steffen.wilberg)
(Assignee)

Comment 2

11 years ago
Created attachment 280958 [details] [diff] [review]
patch v2: removes extraneous link

This version is just like patch v1 except that a link to the Content:File Types section, which no longer exists, has been removed.
Attachment #280957 - Attachment is obsolete: true
Attachment #280958 - Flags: review?(steffen.wilberg)
Attachment #280957 - Flags: review?(steffen.wilberg)
(Reporter)

Comment 3

11 years ago
Comment on attachment 280958 [details] [diff] [review]
patch v2: removes extraneous link

Thanks! I wish everyone changing the UI would update the help docs accordingly like this :-)
Only a couple of minor points:

>+<p>The <em>Applications</em> panel lets you choose applications to handle
>+  different types of content (e.g. PDF documents).  It shows you a list of
>+  content types and lets you select a handler for each type.</p>
>+
>+<p>You can choose a local application to handle any type.  For some types, you
>+  can also choose a web application to handle the type, save the type on your
>+  computer, or handle the type in &brandShortName; by a feature or plugin.</p>
For some types, you can also ... save the type. Can't we save everything to disk? If "for some types" only applies to web applications, you should move that to the end.
Do we have other "features" besides the feed preview? Maybe we should add that as an example.

I'd like the visibility of the options to be improved. Put them in a <ul> like in the doc you removed, like so:
<li><em>Use an application</em><br/>
 To choose an application to handle a content type, select the type from the
 list.  The currently-chosen application for the type will turn into a menu.
 Open the menu and select the application you want to handle the type.</li>

<li>
>+<p>If you want an application not on the list to handle the type, select
>+  <em>Choose Application...</em> from the menu.  &brandShortName; will open
>+  a dialog asking you to choose a application to handle the type.</p>

<li>
>+<p>If you want a &brandShortName; feature or a plugin to handle the type, and
>+  one is available, select it from the menu.</p>

<li>
>+<p>If you want to save the content of the type on your computer, and it is
>+  possible to do so for the type, select <em>Save to Disk...</em> from the menu.
>+  &brandShortName; will then save content of the type on your computer.</p>
>+
>+<p>If you have selected the <em>Save files to</em> &pref.singular; in the
>+  <em>Main</em> panel, it will do so automatically.  Otherwise, when you
>+  encounter content of the type, &brandShortName; will prompt you for a location
>+  on your computer to save the content.</p>
Attachment #280958 - Flags: review?(steffen.wilberg) → review-
(Assignee)

Comment 4

11 years ago
Created attachment 281249 [details] [diff] [review]
patch v3: review fixes, additional polish

(In reply to comment #3)

> For some types, you can also ... save the type. Can't we save everything to
> disk?  If "for some types" only applies to web applications, you should move
> that to the end.

"for some types" actually applies to all three options: web apps (which can't handle MIME types), features/plugins (we only have a feature for the feed type, and plugins can only handle MIME types, and there may not be a plugin for every type the user encounters), and save to disk (we don't know how to save content identified by protocol scheme types to disk, and web feeds don't support being saved to disk automatically).


> Do we have other "features" besides the feed preview? Maybe we should add that
> as an example.

That's the only one.  Adding it as an example seems like a good idea.  I have done so (and linked it to the glossary description of the feature).


> I'd like the visibility of the options to be improved. Put them in a <ul> like
> in the doc you removed, like so:
> <li><em>Use an application</em><br/>

Good idea.  I have done so.  I also updated the text to be more consistent and readable, and I linked items to glossary entries where appropriate.  Finally, I updated menu_reference.xhtml, which contained a references to the Feeds preference panel, to refer to the Applications panel instead.
Attachment #280958 - Attachment is obsolete: true
Attachment #281249 - Flags: review?(steffen.wilberg)
(Assignee)

Comment 5

11 years ago
Created attachment 281257 [details] [diff] [review]
patch v4: fixes bugs in last patch

The last patch had a few bugs in it (an extraneous closing tag and a few entities not closed with semi-colons).  Here's a patch with those bugs fixed.
Attachment #281249 - Attachment is obsolete: true
Attachment #281257 - Flags: review?(steffen.wilberg)
Attachment #281249 - Flags: review?(steffen.wilberg)
(Assignee)

Comment 6

11 years ago
Requesting wanted-1.9 for this Applications prefpane polish fix.
Flags: blocking-firefox3?
(Reporter)

Comment 7

11 years ago
Comment on attachment 281257 [details] [diff] [review]
patch v4: fixes bugs in last patch

>Index: browser/locales/en-US/chrome/help/menu_reference.xhtml
>+    using a Live Bookmark or a feed reader in the
>+		<a href="prefs.xhtml#applications_options">Applications panel</a> of
>+		&pref.menuPath;, the preview page will be skipped.</p>
untabbify, please.

>Index: browser/locales/en-US/chrome/help/prefs.xhtml
>+<p>To choose a handler for a type, select the type from the list. The current
>+  handler for the type will turn into a menu. Open the menu and select the
>+  handler you want to handle the type.</p>
...which is not exactly keyboard-friendly, but that's another bug...

>+<ul>
>+  <li><em>Choose an application</em><br/>
>+  To choose a local or web application to handle a type, select the application
>+  from the menu.  If you want a local application that is not in the menu to
>+  handle the type, select <em>Choose Application...</em> from the menu.
>+  &brandShortName; will open a dialog that lets you choose a local application
>+  to handle the type.</li>
Indent the lines below <li> by 2 spaces, please.
How about "If you want ... to handle the type, select <em>Choose Application...</em> and point &brandShortName; to its location."?

>+<p><strong>Note:</strong> when a plugin is available 
capitalize "When", please.
Attachment #281257 - Flags: review?(steffen.wilberg) → review+
(Assignee)

Comment 8

11 years ago
(In reply to comment #7)
> >+<p><strong>Note:</strong> when a plugin is available 
> capitalize "When", please.

Hmm, that contradicts the Chicago Manual of Style's recommendation for words following colons in sentences, which says to lowercase that word.

http://www.chicagomanualofstyle.org/CMS_FAQ/CapitalizationTitles/CapitalizationTitles35.html
(Reporter)

Comment 9

11 years ago
> When a colon is used within a sentence, the first word following the colon is
> lowercased unless it is a proper name. When a colon introduces two or more
> sentences, or when it introduces speech in dialogue or an extract, the first
> word following it is capitalized.
Isn't "Note:" introducing two sentences here, rather than being part of the first sentence?
We've capitalized the following word in three other locations, so I'd prefer to be consistent:
http://mxr.mozilla.org/seamonkey/search?string=Note%3A&case=on&find=%2Fbrowser%2Flocales%2Fen-US%2Fchrome%2Fhelp%2F&findi=&filter=&tree=seamonkey
(Assignee)

Comment 10

11 years ago
(In reply to comment #9)
> > When a colon is used within a sentence, the first word following the colon is
> > lowercased unless it is a proper name. When a colon introduces two or more
> > sentences, or when it introduces speech in dialogue or an extract, the first
> > word following it is capitalized.
> Isn't "Note:" introducing two sentences here, rather than being part of the
> first sentence?

Hmm, I see your point.  Now that I read it again, it does seem to be introducing both sentences.


> We've capitalized the following word in three other locations, so I'd prefer to
> be consistent:

I think we should follow the Chicago Manual of Style and lowercase the following words in those three cases, but that's another bug.

I'll capitalize the following word in this patch.
(Assignee)

Comment 11

11 years ago
Created attachment 282487 [details] [diff] [review]
patch v5: addresses review comments

(In reply to comment #7)
> (From update of attachment 281257 [details] [diff] [review])
> >Index: browser/locales/en-US/chrome/help/menu_reference.xhtml
> >+    using a Live Bookmark or a feed reader in the
> >+		<a href="prefs.xhtml#applications_options">Applications panel</a> of
> >+		&pref.menuPath;, the preview page will be skipped.</p>
> untabbify, please.

Good catch.  I have done so (and nixed a few other tabs from the files in the process).


> >Index: browser/locales/en-US/chrome/help/prefs.xhtml
> >+<p>To choose a handler for a type, select the type from the list. The current
> >+  handler for the type will turn into a menu. Open the menu and select the
> >+  handler you want to handle the type.</p>
> ...which is not exactly keyboard-friendly, but that's another bug...

If not yet keyboard-friendly, it should be possible to make it so.  But yes, this is another bug.


> >+<ul>
> >+  <li><em>Choose an application</em><br/>
> >+  To choose a local or web application to handle a type, select the application
> >+  from the menu.  If you want a local application that is not in the menu to
> >+  handle the type, select <em>Choose Application...</em> from the menu.
> >+  &brandShortName; will open a dialog that lets you choose a local application
> >+  to handle the type.</li>
> Indent the lines below <li> by 2 spaces, please.

Ok, done.  And I did a bit of reflow to make the lines look nicer now that they are indented more.


> How about "If you want ... to handle the type, select <em>Choose
> Application...</em> and point &brandShortName; to its location."?

Sounds good.  I did that, but I left "from the menu" in the sentence, since I use that phrase in all the other sentences where I talk about choosing an item.  So now the sentence reads:

If you want a local application that is not in the menu
to handle the type, select <em>Choose Application...</em> from the menu
and point &brandShortName; to its location.


> >+<p><strong>Note:</strong> when a plugin is available 
> capitalize "When", please.

Yup, capitalized.

Since bug 396989 has landed, I also changed "Save to Disk" to "Save File", and I removed the ellipses from that option, since it doesn't have ellipses.  I also corrected the grammar of one of the sentences by adding "to" to the end of it, so now it reads "Otherwise, when you encounter the type, &brandShortName; will prompt you for a location on your computer to save it to."  And I added myself to the list of contributors to prefs.xhtml.

This is the version of the patch I'll check in.  Requesting approval to check this in for 1.9.
Attachment #281257 - Attachment is obsolete: true
Attachment #282487 - Flags: approval1.9?

Updated

11 years ago
Attachment #282487 - Flags: approval1.9? → approval1.9+
(Reporter)

Comment 12

11 years ago
Please bump the date at the bottom of prefs.xhtml to the date of the checkin.
(Assignee)

Comment 13

11 years ago
Created attachment 282576 [details] [diff] [review]
patch v6: updates date

Here's the patch I checked in.  The only change between this patch and the patch that was approved is that I updated the date at the end of prefs.xhtml per comment 12.
Attachment #282487 - Attachment is obsolete: true
(Assignee)

Comment 14

11 years ago
Checking in browser/locales/en-US/chrome/help/firebird-toc.rdf;
/cvsroot/mozilla/browser/locales/en-US/chrome/help/firebird-toc.rdf,v  <--  firebird-toc.rdf
new revision: 1.63; previous revision: 1.62
done
Checking in browser/locales/en-US/chrome/help/menu_reference.xhtml;
/cvsroot/mozilla/browser/locales/en-US/chrome/help/menu_reference.xhtml,v  <--  menu_reference.xhtml
new revision: 1.50; previous revision: 1.49
done
Checking in browser/locales/en-US/chrome/help/prefs.xhtml;
/cvsroot/mozilla/browser/locales/en-US/chrome/help/prefs.xhtml,v  <--  prefs.xhtml
new revision: 1.55; previous revision: 1.54
done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Flags: blocking-firefox3? → blocking-firefox3+
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.