Closed Bug 457027 Opened 12 years ago Closed 12 years ago

Determine how to display content for Firefox 3.1

Categories

(support.mozilla.org :: Knowledge Base Software, task)

task
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cilias, Assigned: ecooper)

References

()

Details

(Keywords: fixed1.9.1, Whiteboard: sumo_only)

Attachments

(4 files, 1 obsolete file)

Firefox 3.1 is inching closer, and we're starting to see changes that will be needed in the KB.
Right now, for the browser= parameter we have:
firefox2
firefox3

If decimals are allowed, the Firefox 3.1 parameter should be:
firefox3.1

If decimals are not allowed, it should be:
firefox31
We should also change the label on firefox3 to say "Firefox 3.0" rather than "Firefox 3".
Do we have an inventory of how big the changes will be from 3.0 and 3.1? Based on what I've learned so far, I don't think the changes are big enough to warrant another selector. We have to take into consideration the added complexity of maintaining this, both content wise for the community and visually for the user. 

Unless most articles will become significantly more complex by treating both 3.0 and 3.1 as "3", this bug should be WONTFIXed.
I don't really have a complete inventory. I've started encouraging people to use user-doc-needed on 3.1 changes (that affect user documentation); and from that list we've got a few wording changes in the UI, and changes in tabbed browsing:
Bug 356830, Bug 389914, Bug 417687, Bug 448833, Bug 445499.

What if we wait until Firefox 2 support ends?
(In reply to comment #3)
> What if we wait until Firefox 2 support ends?

The number of versions isn't the qualifier, it's the added complexity vs the amount of documentation changes between the versions. 

In the Firefox 2 vs 3 case, it's pretty clear that the documentation changes are enough to warrant the need for SHOWFOR. In the 3.0 vs 3.1 case, not so much.

I'm marking as WONTFIX; if it turns out there are lots of differences between 3.0 and 3.1, let's revisit.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
How do we address UI differences from bug 356830, bug 417687, and bug 448833 ?
The changes are pretty minimal in those cases, mostly seem to be about wording. Would there be any issues with different instructions, or would the differences be mostly in the screenshots?
I don't think we're making major changes to existing features, except tabbed browsing.  Not sure what all you are currently using SHOWFOR for, but I think it doesn't make sense to not have this available for when it will be used...

We'll eventually need stuff for 3.next, 4, etc, and I don't think we'll kill the Fx2 docs right away, so I'm thinking it may make more sense to change the visual presentation and just deal with the selector stuff as the price of doing things this way.
Also, in-product help should be crisply accurate and up to date wrt wording changes, otherwise that'll look sloppy...
I'm not sure exactly what you mean Mike, but I think you highlighted one important thing here: product help.

The way I see it, we have three alternatives in how to deal with product help for Firefox 3.0.x and 3.1.x; not convinced which one is our best bet yet:

a) Add SHOWFOR support for 3.1 as well, and maintain accurate product help for both 3.0 and 3.1 with the same browser UA sniffing we're using today.  Visual presentation of the choices could be changed from: 

<Firefox 2> | <Firefox 3> | <All>

to:

Firefox <2> | <3.0> | <3.1> | All

We would then have to ensure we still keep the generic "firefox3" option in the SHOWFOR backend for everything that is shared between 3.0 and 3.1, but for the few cases where the versions differ we would use the "firefox3.0" and "firefox3.1" specific SHOWFOR blocks.

b) Don't use SHOWFOR to separate 3.0 and 3.1, but document the differences between the versions in articles where appropriate. As long as the differences between 3.0 and 3.1 are relatively small, this is the easiest option as it reduces both visual clutter and article complexity.

c) Don't use SHOWFOR to separate 3.0 and 3.1, but update the product help to support 3.1 only. Add a notification for pre-3.1 users saying "You are not running the latest version of Firefox 3. This documentation is for Firefox 3.1."

I'm guessing we don't want option c) as that might seem sloppy. Depending on the amount of changes in 3.1 vs 3.0, we want option a) or b). The question is simply: at which point does the differences between the two 3.x versions get significant enough to warrant the added complexity (for both contributors and users) to separate the versions? Surely we'll want a new SHOWFOR when Firefox 4 comes out, but for 3.1 I'm not convinced yet.

One potential combination of a) and b) would be to add backend SHOWFOR support, but still only show the options "Firefox 2" and "Firefox 3" in the user selectable interface. By default, we auto-detect anyway, and if someone selects Firefox 3 manually, we could just show Firefox 3.1 (latest). This would mean a simple visual presentation, but equally complex support articles to maintain as with option a). 

It wouldn't be without problems, though. We'd need some way to toggle between all versions anyway for contributors who want to verify that it looks OK in each version of Firefox.
Live Chat and forum contributors would also need a way to toggle between 3.0 and 3.1 as the wording changes would make a difference while giving users instructions.

I like the idea of only showing 3.0 and 3.1 on articles that have differences between the two (it would be interesting to do this with other articles, hide the selector options that don't have options in the article).  Would this be confusing to users having different options depending on the page or would it be simpler and let them know that those are the only instructions?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Add SHOWFOR support for Firefox 3.1 → Determine how to display content for Firefox 3.1
Flags: blocking-firefox3.1?
In-product articles that will need changing:

#  Page Info window

    * More is now Details (448833) 

# Options window

    * Tell me if the site I'm visiting is a suspected attack site is now Block reported attack sites (417687)
    * Tell me if the site I'm visiting is a suspected forgery is now Block reported web forgeries (417687)
    * New pages should be opened in is now Open new windows in a new tab instead (356830) 

# Tabbed browsing

    * New tab button in tab bar
    * Maybe add something about Ctrl+Tab 

All three will also require changes in screenshots.

There are also other non-inproduct articles that will be need changes in screenshots (particularly due to the new new tab button).

The big question mark is Private browsing mode. Depending how it works and how it changes the UI, the Cookies in-product article may need updating; and other non-inproduct that have anything to do with private data will need changing.
It seems this discussion has stopped. What's the verdict here? Are we using SHOWFOR? Are we going to create additional categories?
Because of product help, let's add SHOWFOR support for 3.1, and maintain accurate product help for both 3.0 and 3.1 with the same browser UA sniffing we're using today.  Visual presentation of the choices should be changed from: 

<Firefox 2> | <Firefox 3> | <All>

to:

Firefox <2> | <3.0> | <3.1> | All


We need to ensure we still keep the generic "firefox3" option in the SHOWFOR backend for everything that is shared between 3.0 and 3.1, but for the few cases where the versions differ we would use the "firefox3.0" and "firefox3.1" specific SHOWFOR blocks.

In other words, both the "3.0" and "3.1" choices would show anything in "firefox3" SHOWFOR blocks, while "3.0" would also show "firefox3.0" but not "firefox3.1", and vice verca.

The feature to only show the version choices the article applies to is a separate bug.
Target Milestone: --- → 0.9
If we can implement this soon, perhaps it would be better to use the label "3.1 Beta".
Is it important to push 3.1 articles before final release?  What we can do is start writing translating and leave everything in staging until 3.1 releases.
(In reply to comment #15)
> Is it important to push 3.1 articles before final release?

No.

>  What we can do is
> start writing translating and leave everything in staging until 3.1 releases.

Right now the only new articles would be Private browsing mode, and possibly an article on Geolocation. Other than that, the rest is about updating articles already in the KB.
<http://support.mozilla.com/en-US/kb/Updating+articles+for+Firefox+31>
It'd be fantastic if SUMO was up to date sooner rather than later so we can start using it as another channel for beta feedback...
Nelson, how much time is required to implement this? I suppose we don't have to use "Beta" in the label. We didn't do that for Firefox 3.0. :-)
This should be a simple fix to get this up; bumping up to 0.8. Nelson, can Eric do this?
Target Milestone: 0.9 → 0.8
Obviously blocks Firefox 3.1
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Blocks: 465855
No longer blocks: 465855
Assignee: nelson → smirkingsisyphus
So, this keeps the firefox3 (and ff3, fx3) showfor for content that is the same from 3.0 to 3.1 and adds 3.0 and 3.1 to showfor using the same access methods (i.e., firefox3.0, ff3.0, fx3.0, firefox3.1, etc.,) for content that is different.
Attachment #351902 - Flags: review?(nelson)
I think the inconsistency of "Firefox 2", while the others are just version numbers (no "Firefox") may be confusing. We can still preface the line with "Firefox", but only make the version numbers clickable:
Firefox: <2> | <3.0> | <3.1>

We can even get away with using "2.0":
Firefox: <2.0> | <3.0> | <3.1>
And yes, the colon after "Firefox" was on purpose. :-)
Hmm...I'll add a label feature to the plugin to see what it looks like.
Better?
Oh, "Firefox:" isn't clickable. It's just the same color because it looks weird otherwise.
(In reply to comment #27)
> Oh, "Firefox:" isn't clickable. It's just the same color because it looks weird
> otherwise.

Why does that look weird? Having a link color is potentially confusing if it's not a link, plus, we're using the non-link color for the separator | bars anyway.

<offtopic>Is there a good extension that allows you to simply edit a displayed web page on the fly so you can test variations of wording or color without asking a developer to upload a screenshot?</offtopic>
This?
Attachment #351902 - Attachment is obsolete: true
Attachment #352180 - Flags: review?(nelson)
Attachment #351902 - Flags: review?(nelson)
Comment on attachment 352180 [details] [diff] [review]
Adds the "Firefox:" label and gives it proper padding

in r20668/r20669
Attachment #352180 - Flags: review?(nelson) → review+
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
FWIW, the showfor headings within the article content when you have "All" selected, now say "2.0:", and "3:", rather than "Firefox 2:", and "Firefox 3:". I've filed bug 468830 for that.
Whiteboard: sumo_only
You need to log in before you can comment on or make changes to this bug.