Closed Bug 388960 Opened 17 years ago Closed 17 years ago

Provide ability to show different text depending on OS or version

Categories

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

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jason.barnabe, Assigned: nkoth)

Details

(Whiteboard: sumo_triage showfor) 

I'd like the ability to show different portions of text throughout an article based on what OS or Firefox version the user has. This functionality would be similar to Plugin Versions http://doc.tikiwiki.org/PluginVersions but with a few differences:

-The version to use would be auto-detected based on the UA. Ideally, we'd have a system where we could say specifically that something applied to Firefox 2 on Windows, or we could be more generic and say something applies to Firefox 2 on any OS or any version of Firefox on Windows.
-Only one version "chooser" would be shown, and it would say something to the effect of "This article assumes you're on [Firefox 2.0 on Windows]" (with a select box for other possibilities).
I think this should be added as well. If it is going to be added, though, then support should be put in for marking sections with key/value pairs and showing or hiding UI based on the values found dynamically for keys.

This is always where this kind of feature request leads.

One can do this and only enable, for example, a "platform" key. Later, when people ask for other stuff, there you are.

FYI, if we sniff the platform and show or hide based on that, there should also be a command to 'showAll' for the platforms.

As a FF extension, doing this would take about 10-20 lines of code. Just crawling the DOM and removing stuff. How hard would it be in tiki?

ccing Nelson.

Nelson, is this possible?
It can be done. The thing with this kind of request is that it is prone to scope creep - so we have to define requirements.

The problem with supporting filtering through multiple key-value pairs as suggested by Ray is that you will have to map each combination of these key-value pairs to options in the chooser (otherwise the chooser will become a rather non-user friendly collection of drop-down boxes).

1. The thing is that the options in the version chooser could be based on various levels of user-agent info, and would need to have custom text depending on the needs of each page. e.g. you might want "Windows", "Linux", "Mac"; or "Windows", "Others"; or "Firefox (Windows)", "IE (Windows)",......

Thus, we may need something like like {USERAGENTVERSIONS(versions=>v1+v2+v3)} which defines what versions can be chosen for that page. Since this could be an endless list of v1, v2, v3 ..., I suggest that the supported v1, v2, v3 be documented as these are added. Each of these versions are then mapped to various UserAgent detection results generated by the detection script.

2. The current versions plugin syntax:

{USERAGENTVERSIONS()}
This is the default text
---(v1)---
This is version 1
---(v2)---
This is version 2

can then be used for DIV type content.

3. In addition, it appears to me you need support for SPAN type content? This can be done quite easily by something new that defines when the content is shown or not. Other plugins already do this based on criteria other than user-agent.

{USERAGENTSHOW(versions=>v1+v2)}Stuff seen only for version 1 and 2{USERAGENTSHOW}

or 

{USERAGENTSHOW(versions=>v1+v2+default)}Stuff seen only for version 1 and 2 and default{USERAGENTSHOW}

Note that default version is necessary in the event the user agent info detected does not match any of the versions specified.

5. Finally, the useragent detection script itself. There are numerous PHP scripts for user-agent detection out there that vary in comprehensiveness of coverage, and granularity in returning results, e.g. type/version/grouping of OSes. Does Mozilla have a preferred nomenclature/script to do this? We can also port a Javascript one to PHP if it is preferred, but we should not be depending on client-side JS for this to work.

These returned results can then be mapped to the versions v1, v2, v3.... through a case loop.

In general, Nelson is completely correct. I would only point out two things.

First, it is not feature creep if it is planned for, though it may be feature creep if it is not architected in and users demand it.

Second, adding filtering capability does not suggest certain UI has to be there either at first or ever. UI can be tuned based on user feedback. Model-View-Controller design would suggest making the tools as flexible as possible, and the UI as responsive to user needs as possible, and doing those two things separately.
(In reply to comment #3)
> 1. The thing is that the options in the version chooser could be based on
> various levels of user-agent info, and would need to have custom text depending
> on the needs of each page. e.g. you might want "Windows", "Linux", "Mac"; or
> "Windows", "Others"; or "Firefox (Windows)", "IE (Windows)",......

I don't see why we would need custom text for each page. I'm perfectly fine with the idea that a page that has no OS or version distinctions still shows the entire list.

The major thing we need right now is platform: Windows/Mac/Linux. We're only supporting Firefox 2 at the moment. We'll only need browser version once Firefox 3 is out, at which point it will be Firefox 2/Firefox 3 until we drop support for Firefox 2.

> 2. The current versions plugin syntax:
> 
> {USERAGENTVERSIONS()}
> This is the default text
> ---(v1)---
> This is version 1
> ---(v2)---
> This is version 2

This looks good to me. Might want to shorten up the plugin name to "VERSIONS" or something, but that's it.

> 3. In addition, it appears to me you need support for SPAN type content? This
> can be done quite easily by something new that defines when the content is
> shown or not. Other plugins already do this based on criteria other than
> user-agent.

This would be useful, but the div is the one I see most.

> Note that default version is necessary in the event the user agent info
> detected does not match any of the versions specified.

I'd prefer that it default to a certain version (Firefox 2 on Windows) rather than having a default text.

> 5. Finally, the useragent detection script itself. There are numerous PHP
> scripts for user-agent detection out there that vary in comprehensiveness of
> coverage, and granularity in returning results, e.g. type/version/grouping of
> OSes. Does Mozilla have a preferred nomenclature/script to do this? We can also
> port a Javascript one to PHP if it is preferred, but we should not be depending
> on client-side JS for this to work.

I'm not aware of any script, but keep in mind we only care about Firefox UAs.
Target Milestone: --- → 0.3
One question here is how this would affect performance and caching, unless this would be done using javascript on the client side (which would keep the page served static).
Three things:

1. I don't think we should worry about javascript being client-side scripting and that we're requiring people to use javascript to be able to see content based on UA sniffing. Most modern sites use javascript today, and we're going to use it in other areas too (such as for the feedback form, captchas, etc).

2. The default should be the latest stable version of Firefox, so people with javascript turned off, and people surfing using other browsers, will see that documentation. 

3. (Less important) There should be a way to override this using a setting (which could use a cookie to remember the choices instead of doing the ua sniffing).
I would like to see non-relevant items being hidden w/ JS if it's important, but always falling back on full display of all information on the page if JS isn't enabled.

JS/CSS would be a good way to do this because although page size might be larger, we would still have the ability to cache the content fully.  Using PHP for UA detection could give mixed results if a user from platform A sees a cached result for a user from platform B.

Other than that, I think the comments above look good.
Assignee: nobody → nelson
Please give it a try. All of the following should work.

{SHOWFOR(browser=>firefox3)}
shows for firefox3{SHOWFOR}

{SHOWFOR(browser=>firefox2,os=>windows)}
shows either for firefox2 or windows{SHOWFOR}

{SHOWFOR(os=>linux+mac)}
shows either for linux or mac{SHOWFOR}

{SHOWFOR(os=>windows)}{SHOWFOR(os=>firefox2)}
shows for firefox2 *on* windows{SHOWFOR}{SHOWFOR}

An example. http://support-stage.mozilla.org/kb/testshowfor (it's in the sandbox and requires logging in)
Things are definitely shaping up pretty nicely!

One thing I don't get is:

{SHOWFOR(browser=>firefox2,os=>windows)}
shows either for firefox2 or windows{SHOWFOR}

Why would that be an OR (fx2 OR win) and not AND (fx2 AND win)? I can't see any use case where an OR would be requested. 

The way to create an AND is more cumbersome:

{SHOWFOR(os=>windows)}{SHOWFOR(os=>firefox2)}
shows for firefox2 *on* windows{SHOWFOR}{SHOWFOR}

I would definitely prefer if the first code block would do the same as the second. Possible?
Status: NEW → ASSIGNED
I agree. This is more intuitive. It has been done.
The remaining thing is to add some style to the UI, which I filed as bug 409269. Marking this as FIXED. Great job, Nelson!
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
I spent very little time fiddling with it last night.

I'd like to use a more realistic testcase to illustrate its implementation. If I've just told someone to disable an add-on, the Add-ons window is open and Firefox needs to be restarted. Fx3 has a restart button. Fx2 has to be exited then restarted, and exiting Firefox is different per OS. So how would the tikiwiki markup look? Without this feature, it would be:

# Restart Firefox
** __(Firefox 3)__ In the Add-ons window, click the {DIV(class=button,type=>span)}Restart Firefox{DIV} button.
** __(Firefox 2)__
*** __(Windows)__ From the menu at the top of the Firefox window, select {PATH()}File{PATH} and then select the {PATH()}Exit{PATH} menu item.
*** __(Mac)__ From the menu bar, select {PATH()}Firefox{PATH} and then select the {PATH()}Quit Firefox{PATH} menu item.
*** __(Linux)__ From the menu at the top of the Firefox window, select {PATH()}File{PATH} and then select the {PATH()}Quit{PATH} menu item.


Using SHOWFOR, what would the tikiwiki markup be? 
And if we're going to keep the [All] option, we'll need to keep the (Firefox 2), (Windows), (Mac), etc. labels; and have them only show when [All] is selected.
# Restart Firefox
{SHOWFOR(browser=>firefox3)}
*__(Firefox 3)__ In the Add-ons window, click the
{DIV(class=button,type=>span)}Restart Firefox{DIV} button.
{SHOWFOR}
{SHOWFOR(browser=>firefox2)}
*__(Firefox 2)__
{SHOWFOR(os=>windows)}
**__(Windows)__ From the menu at the top of the Firefox window, select
{PATH()}File{PATH} and then select the {PATH()}Exit{PATH} menu item.
{SHOWFOR}
{SHOWFOR(os=>mac)}
**__(Mac)__ From the menu bar, select {PATH()}Firefox{PATH} and then select
the {PATH()}Quit Firefox{PATH} menu item.
{SHOWFOR}
{SHOWFOR(os=>linux)}
**__(Linux)__ From the menu at the top of the Firefox window, select
{PATH()}File{PATH} and then select the {PATH()}Quit{PATH} menu item.
{SHOWFOR}{SHOWFOR}
the other reason why we need to keep the labels is that in the event a user has  javascript disabled, the article must still make sense.

I have another suggestion. How about I make the plugin autogenerate the labels in the form of an icon that only shows when "all is selected". Can we open another bug for this or whatever variant of this you think is best?
(In reply to comment #14)
> And if we're going to keep the [All] option, we'll need to keep the (Firefox
> 2), (Windows), (Mac), etc. labels; and have them only show when [All] is
> selected.
> 

We can just make sure the stylesheet adds text before each div, e.g.

.os-win:before { content: "Windows: "}

This would only apply to the os-all.css file, not when selecting a specific OS only, e.g. os-win.css.

One thing though, Nelson: can you shorten firefox2/firefox3 to just fx2/fx3? The shorter the syntax, the better.
(In reply to comment #16)
> the other reason why we need to keep the labels is that in the event a user has
>  javascript disabled, the article must still make sense.
>

If the user doesn't have javascript, the default should be to show firefox2.css  +os-all.css. That should be in the template or in a <noscript> tag.
 
> I have another suggestion. How about I make the plugin autogenerate the labels
> in the form of an icon that only shows when "all is selected". Can we open
> another bug for this or whatever variant of this you think is best?
> 

Again, :before would be the solution. We could also style the divs differently, e.g. with a border that separates the OSes. Again, this would only be shown when using the os-all.css file.
I don't think before works in IE.
as for the shorter names, I just committed a change for fx2/ff2/firefox2 --> firefox2, fx3/ff3/firefox3 --> firefox3, and win/windows --> windows
(In reply to comment #19)
> I don't think before works in IE.
> 

We can default to show fx2.css + os-win.css for IE, if :before doesn't work.
It is not the default that is the issue. The point is that if an IE user clicks on "All", he will see a page without the :before pseudo-elements, which will not make sense to him because the sections are unlabeled.

I can just as easily create a real div above the current div (just blame IE for the div proliferation). As a bonus, you have additional params, e.g. label=>off|div|span, to turn off, or choose between the div above, or inline span within. 

No need to file a new bug. I'm doing it right now.
OK. It's done. Let me know if you need anymore fine-tuning:

See http://support-stage.mozilla.org/kb/testshowfor2

1) Default is to create a div on top (i.e. label=>div). As you can see, there is a blue line (css adjustable) followed by a label, e.g. Firefox 2:

2) For each FORSHOW, uou have the option of setting label=>off, which is basically no label at all, or label=>span which is inline, e.g. Windows:

3) The contents of the SHOWFOR are indented (this is css controlled)

4) In addition, you can set footer=>on, which causes there to be a footer for the particular SHOWFOR, i.e. the grey line with some small words in the center (css adjustable).
Status: RESOLVED → VERIFIED
Whiteboard: tiki_feature showfor
Upstreaming of showfor is delayed because it needs refactoring, namely using jquery.

I can make the changes or let the SUMO team do it. Either way, this should be off the upstream queue for now.
Whiteboard: tiki_feature showfor → tiki_feature showfor tiki_discuss
(In reply to comment #24)
> Upstreaming of showfor is delayed because it needs refactoring, namely using
> jquery.

That's bug 483840. morgamic: any opinion about whether LPH could do this or if we want to do it?
I wouldn't upstream SHOWFOR in its current state, for what it's worth. It, among other things, requires hacking into the wiki parser to get table of contents support.
Removing this from list of features to upstream for now, since it won't be upstreamed at its current state. We need to either re-apply the current implementation locally post-5.1 upgrade, or rewrite showfor (bug 483840).
Whiteboard: tiki_feature showfor tiki_discuss → sumo_triage showfor
You need to log in before you can comment on or make changes to this bug.