457027 - Determine how to display content for Firefox 3.1

Status: VERIFIED FIXED

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

Description

[Chris Ilias [:cilias]]

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

Comment 1

[Chris Ilias [:cilias]]

We should also change the label on firefox3 to say "Firefox 3.0" rather than "Firefox 3".

Comment 2

[David Tenser [:djst]]

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.

Comment 3

[Chris Ilias [:cilias]]

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?

Comment 4

[David Tenser [:djst]]

(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.

Comment 5

[Chris Ilias [:cilias]]

How do we address UI differences from bug 356830, bug 417687, and bug 448833 ?

Comment 6

[Majken Connor [:Kensie]]

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?

Comment 7

[Mike Connor [:mconnor]]

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.

Comment 8

[Mike Connor [:mconnor]]

Also, in-product help should be crisply accurate and up to date wrt wording changes, otherwise that'll look sloppy...

Comment 9

[David Tenser [:djst]]

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.

Comment 10

[Majken Connor [:Kensie]]

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?

Comment 11

[Chris Ilias [:cilias]]

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.

Comment 12

[Chris Ilias [:cilias]]

It seems this discussion has stopped. What's the verdict here? Are we using SHOWFOR? Are we going to create additional categories?

Comment 13

[David Tenser [:djst]]

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.

Comment 14

[Chris Ilias [:cilias]]

If we can implement this soon, perhaps it would be better to use the label "3.1 Beta".

Comment 15

[[:Cww]]

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.

Comment 16

[Chris Ilias [:cilias]]

(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>

Comment 17

[Mike Connor [:mconnor]]

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...

Comment 18

[Chris Ilias [:cilias]]

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. :-)

Comment 19

[David Tenser [:djst]]

This should be a simple fix to get this up; bumping up to 0.8. Nelson, can Eric do this?

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

Obviously blocks Firefox 3.1

Comment 21

[E. Cooper [:ecooper]]

Attachment: Patch to update SHOWFOR to add 3.0 and 3.1 while keeping firefox3 for shared content between the versions

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.

Comment 22

[E. Cooper [:ecooper]]

Attachment: SHOWFOR tab selector for 3.0 and 3.1

Comment 23

[Chris Ilias [:cilias]]

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>

Comment 24

[Chris Ilias [:cilias]]

And yes, the colon after "Firefox" was on purpose. :-)

Comment 25

[E. Cooper [:ecooper]]

Hmm...I'll add a label feature to the plugin to see what it looks like.

Comment 26

[E. Cooper [:ecooper]]

Attachment: SHOWFOR tabs with Firefox label and colon

Better?

Comment 27

[E. Cooper [:ecooper]]

Oh, "Firefox:" isn't clickable. It's just the same color because it looks weird otherwise.

Comment 28

[David Tenser [:djst]]

(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>

Comment 29

[E. Cooper [:ecooper]]

Attachment: SHOWFOR Tabs with black label and colon

This?

Comment 30

[E. Cooper [:ecooper]]

Attachment: Adds the "Firefox:" label and gives it proper padding

Comment 31

[Nelson Ko [:nkoth]]

Comment on attachment 352180 [details] [diff] [review]
Adds the "Firefox:" label and gives it proper padding

in r20668/r20669

Comment 32

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on http://support-stage.mozilla.org/en-US/kb/Lost+Bookmarks.

Comment 33

[Chris Ilias [:cilias]]

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.