Closed Bug 412265 Opened 17 years ago Closed 16 years ago

Support for "in-product mode"

Categories

(support.mozilla.org :: General, defect, P1)

Product:
support.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: djst, Assigned: nkoth)

References

Details

(Whiteboard: tiki_feature, tiki_upstreamed) 

For Firefox 3 in-product help support, we need to make the site behave differently when accessed by Firefox 3. This could be realized with a parameter in the URL, e.g. http://support.mozilla.com/kb/Firefox+Help?mode=inproduct, which would tell the site that the page is requested by in-product help.

In this mode...

* The focus should be on presenting the article (tutorial, how-to, etc) to the user; nothing else. We would not show links to other projects, for example.

* We will want to use a separate stylesheet, hiding things like the top menu, possibly items in the sidebar, etc.

* The search bar would only search "documentation" articles, e.g. tutorials, how-to's, and references. See http://wiki.mozilla.org/Support:PRD#Content_Types.

* The site would remain in this "in-product mode" as the user navigates between articles. For example, if the user searches for bookmarks, and clicks on the first link which is a generic article about bookmarks, the next search performed would still just search "documentation" articles, as explained above.

* From the search results, there should be a link allowing you to also include "support" articles in the results. Clicking this link would effectively leave the "in-product mode" of the site, which will reveal the site's full content.

* From the search results, there should be links allowing you to ask for help (which would also leave this "in-product mode" to show a page listing the different ways to get help, e.g. forums and live chat).
Blocks: 412266
OS: Mac OS X → All
Hardware: PC → All
Severity: normal → blocker
Priority: -- → P1
No longer blocks: 412266
Blocks: 421149
Status: NEW → ASSIGNED
Assignee: nobody → nelson
Status: ASSIGNED → NEW
I doing this http://support.mozilla.com/kb/Firefox+Help?style_mode=inproduct, to make clear that this is a style_mode. There are already other "modes", such as "sort_mode" and this is by convention better than just "mode".
can the user login to sumo in in-product mode? What happens when a user that is already logged in to sumo goes to sumo in in-product mode?
still working on the search page - bug 421149, also the link to In-product Main page depends on bug 412266. Otherwise, the proof of concept is now on support-stage. Probably too crippling though, as all the modules are gone. Suggestions?
(In reply to comment #2)
> can the user login to sumo in in-product mode? What happens when a user that is
> already logged in to sumo goes to sumo in in-product mode?

I don't think it makes sense to be logged in and still in in-product mode. While it shouldn't be disallowed to be logged in and still use the style_mode=inproduct, I don't think it should have any effect.

ok. this is now fixed on support-stage. Please file individual new bugs for refining look and feel of in-product mode. Thanks.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I noticed that this hasn't been pushed to production yet. When it does, will we need to update the help topic URIs to include "style_mode=inproduct"?
Yes
http://support.mozilla.com/tiki-searchresults.php?locale=en-US&style_mode=inproduct&q=installing&sa=

Searching for "installing" in in-product mode gives me 0 results on help articles, but "Installing Firefox" is actually a help article. Why is this? Is the google caching not updated more than every other month or something?!
When is this going to be applied to support.mozilla.com?
Okay, verified on production.
Status: RESOLVED → VERIFIED
Whiteboard: tiki_feature
I've looked through the code to figure out exactly what in-product mode meant. I don't think it can be upstreamed directly as it's far from a centralized feature.

In tiki 4.0+, perspectives may be used instead to achieve this goal. Essentially, perspectives are an additional set of preferences to apply on top of the default ones, applying a different set of configurations. For example, it could change the header to remove links to other products, disable modules and such. Most of the configurations made currently with the mode could be replaced with individual preferences that can then be managed by the perspectives, avoiding the propagation of conditional code for this specific requirement.

Currently, switching perspective can be made by using a module or calling the underlying script directly. An alternate mode is to bind the perspective to a domain name. Adding a standardized parameter in the URL to select a perspective is not impossible to do. However, I would want this to be done as part of the global tiki initialization rather than on pages where it's expected to be used.
Whiteboard: tiki_feature → tiki_feature, tiki_discuss
(In reply to comment #11)
> An alternate mode is to bind the perspective to a
> domain name. Adding a standardized parameter in the URL to select a perspective
> is not impossible to do. However, I would want this to be done as part of the
> global tiki initialization rather than on pages where it's expected to be used.

We discussed this and agreed that using perspectives is a reasonable approach for this feature, as long as it's possible with a URL parameter like we do it now. 

Another thing we discussed was memcache and that it's important that this solution also works with that.
What would the anticipated issues with memcache?
Probably none, but we don't really know how perspectives work. As long as it works with memcache, we should be fine. :)
Because the inproduct mode parameter is managed through rewrite rules, it would probably just be a matter of changing style_mode=inproduct to perspectiveId=123 and to modify the line where the perspective data is obtained to look for an override in the URL. If all links clicked put in the parameter correctly, it will be transparent.

The page cache includes the style_mode as part of the key. It wouldn't be much of an effort to use perspectiveId instead.
Sounds good to me.
Whiteboard: tiki_feature, tiki_discuss → tiki_feature
Not exactly an upstream, but the issue is resolved.

perspectiveId is now available globally as an argument. The rewrite rules can be updated to write it instead of the inproduct mode.

Perspectives have to be created for this to work. Currently, there is no UI for that, but they can be created quite easily either directly in the database or through profiles.
Whiteboard: tiki_feature → tiki_feature, tiki_upstreamed
Perspective UI is now available for Tiki5
http://doc.tikiwiki.org/Perspectives
You need to log in before you can comment on or make changes to this bug.