Closed Bug 771146 Opened 12 years ago Closed 11 years ago

Port Current Privacy Policies to New Privacy Hub on Bedrock

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: espressive, Assigned: jishnu)

References

Details

(Whiteboard: [sp-2012-08-14] u=user c=privacy)

Attachments

(2 files)

Draft Firefox layered policy with mocked-up interaction
7.31 KB, text/html
Details
New general privacy content
4.56 KB, text/html
Details 
I am creating this bug as the central point of communication related to the Privacy Policy hub migration to Bedrock. At the moment things are split across a bunch of bugs and it is making tracking the status very hard.

Summary of work that needs to be done
-------------------------------------

1) Implement the new design for the privacy landing page using the sandstone theme.
2) Port the current content from the main privacy and make any required changes.
3) Port the content for the following privacy policies to Bedrock: Firefox, Marketplace, Persona, Sync, Test-Pilot, Thunderbird, Websites
4) Update Firefox policy to include the new content regarding snippet impressions
5) Create dated URLs for old Firefox privacy policies
6) RSS feed for policy changes
7) Finalize design for individual privacy policies
8) Do we need printer friendly versions of all individual policies?

Priority for porting individual policies
----------------------------------------

1) Firefox
1) Thunderbird
1) Websites
2) Sync
3) Marketplace
4) Persona
5) Test-Pilot

Location of ported policies and pages
-------------------------------------

Main landing page with new design:
http://www-dev.allizom.org/b/en-US/privacy/

Firefox specific privacy policy:
http://www-dev.allizom.org/b/en-US/privacy/policies/firefox/

Location of current policies
----------------------------

http://www.mozilla.org/legal/privacy/firefox.html
http://www.mozilla.org/legal/privacy/thunderbird.html
http://www.mozilla.org/legal/privacy/websites.html
https://marketplace.mozilla.org/en-US/privacy-policy
https://services.mozilla.com/privacy-policy/
https://browserid.org/privacy
https://testpilot.mozillalabs.com/privacy.php

Which of these are safe to port?

Referenced bugs
---------------

https://bugzilla.mozilla.org/show_bug.cgi?id=755055
https://bugzilla.mozilla.org/show_bug.cgi?id=761818
https://bugzilla.mozilla.org/show_bug.cgi?id=738544
https://bugzilla.mozilla.org/show_bug.cgi?id=710886
https://bugzilla.mozilla.org/show_bug.cgi?id=753404
Hi Schalk,

I discussed these with Alex. Here are his suggestions:

FX PP Mock

- Need a prominent link back to Privacy Home
- Suggest that the navigational bar go below the block of text that summarizes the contents of the policy ("This privacy policy explains...")
- The section headers don't match those in the navigational bar
- Are the font sizes for the title of the policy and section headers the same? It looks like the section headers are a larger size. It would be good if the policy title popped a bit more on the page.

Privacy Home Mock

- I feel like the text could be laid out a bit more creatively. The content seems fine, but perhaps through the use of more graphical elements or use tables/columns, the text could be more visually appealing and better organized. 

Tom will provide elements for the boxes and should update this bug with those changes.
"Need a prominent link back to Privacy Home" - Going to add breadcrumbs to all of these.

"Suggest that the navigational bar go below the block of text that summarizes the contents of the policy ("This privacy policy explains...")" - Will move

"The section headers don't match those in the navigational bar" - I had to make some small changes to these to fit them into the nav bar, if this is not acceptable, I can change these but the nav links will wrap to a second line.

"Are the font sizes for the title of the policy and section headers the same? It looks like the section headers are a larger size. It would be good if the policy title popped a bit more on the page." - I will look into these.

"Privacy Home Mock" - This is not a mock and is based on the design provided. If there are changes, please highlight these and send additional design elements.
"Are the font sizes for the title of the policy and section headers the same? It looks like the section headers are a larger size. It would be good if the policy title popped a bit more on the page." - The font sizes are in fact the same. It must be the different context in which the text is used that makes it seem that there is a size difference.

I will change the section h1 heading to h2 and the headings following those to h3, h4 etc. and we can review after.
Hey all,

What is the status on this at the moment? Have you had some time to review the latest changes mentioned in comment 4? Also, are there any of the other policies listed in comment 1 that can be safely ported or, are they all still being rewritten and/or refined in terms of content?
? ping ?
Target Milestone: --- → 3.5
Jishnu: Can you answer comment 4 and 5? Reassign to Schalk when it's done.
Assignee: sneethling → jmenon
(In reply to Tom Lowenthal [:StrangeCharm])
> [Trying to fill in for Jishnu who is out right now.]
> 
> The current policy page design looks good. I don't see the RSS feed in the
> source; is that pending?

I assume here you are referring to the RSS of policy updates? This is done and I will add this to the source so they are discoverable.

(In reply to Tom Lowenthal [:StrangeCharm])
> What's the source for the "hero" content in this design, and how does that
> get modified?

In the source, this will by the section tag with the id privacy-promo. As far as I know this will be edited by hand. Perhaps [:rik] can provide a better/more accurate answer?
Target Milestone: 3.5 → ---
Okay, we're going to need different hero content before release. Who should we pester about that?

Design-wise, the only outstanding things I'd want to request are:

- removing the email signup form, if possible, and
- adding a detailed table of contents on the right, below the list of policies.
(In reply to Tom Lowenthal [:StrangeCharm] from comment #9)
> Okay, we're going to need different hero content before release. Who should
> we pester about that?
> 
> Design-wise, the only outstanding things I'd want to request are:
> 
> - removing the email signup form, if possible, and
> - adding a detailed table of contents on the right, below the list of
> policies.

I will have to find out about removing the signup form, it is dead simple to do, I just do not know what the 'rule' is with regards to that.

Table of contents
-----------------
There has been some discussion regarding this. Do we simply want a list of links linking to various parts of the document or, do we want the TOC to follow the user as they navigate up and down the page? 

Also, currently there is a bar at the top under the intro paragraph that links to the main sections of the policy and then each section has a link back to this. Do we want to keep this along with the TOC or remove this in favor of the TOC?
(In reply to Tom Lowenthal [:StrangeCharm] from comment #9)
> Okay, we're going to need different hero content before release. Who should
> we pester about that?

I think we can remove the hero content all together and launch without it. However, if you want to add some other promo(s) that are privacy-specific for a later release, John Slater's team can create those. Just need to file a bug and follow up with him.

> Design-wise, the only outstanding things I'd want to request are:
> 
> - removing the email signup form, if possible, and
> - adding a detailed table of contents on the right, below the list of
> policies.

I'll follow up with Winston to confirm it's OK to remove the email signup. I don't see any issue there.
(In reply to Mike Alexis [:malexis] from comment #11)

> I'll follow up with Winston to confirm it's OK to remove the email signup. I
> don't see any issue there.

Confirmed with Winston that it's OK to remove email signup.
Mike,

I sent a pull request for the removal of the hero content and the removal o the email signup form from the landing and individual policy pages, currently only Firefox.

What is left now is the addition of the TOC and then identifying which other policies I can safely convert over or, which one's should still be linked to their current location.

With regards to the TOC, is this going to be a static block in the sidebar? Thanks.

PR::https://github.com/mozilla/bedrock/pull/304
My preferred behavior for the TOC is as follows: The TOC should be in the sidebar on the right, below the list of other policies. If the TOC does not fit vertically within the viewport, no further behavior is required. If the TOC *can* fit vertically within the viewport, then as the user scrolls down, the TOC remains fixed with respect to the viewport "floating" beside the privacy policy text. Is that an unreasonable ask?
Tom, this is totally doable. Will implement it.
Whiteboard: [sp-2012-08-14] u=user c=privacy
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Hey there,

Been busy with the latest work on Socorro but, added the first version of the floating TOC to the firefox page. Please let me know what you think. Thanks!

PR: https://github.com/mozilla/bedrock/pull/323
Final changes pushed to functionality. Still need to change actual content of TOC. Please specify what the desired content needs to be. Thanks
You can see the basic idea here now: http://www-dev.allizom.org/b/en-US/privacy/policies/firefox/

The final version has not been deployed to dev yet but, this should give you the basic idea and allow for feedback. Thanks
Nice, thanks!

The ToC should just be the document outline for the HTML fragment we give you as the policy, all the way down to level 3, I think. That'll change as the text changes, of course. Let me know if any more detail is needed on that. 

Design-wise, I have a couple of requests.
1. Please align ToC box's left edge with the left edge of the "Our Privacy Policies" box that appears above it.
2. I think ToC box should appear just below the bottom of the "Our Privacy Policies" element, maybe just one or two ems below.
3. Could you give the ToC box a light background, like the main body text box?
4. A nested ordered list for the ToC probably makes a lot more sense than an unordered list.

Hopefully this isn't too tough to change; thanks again!
Tom,

Thanks for the feedback. I will implement those changes today and have it pushed to dev.
Schalk: What about creating the TOC in JS? This way, it will always be up-to-date as we evolve this document.
Rik,

I can do that. The reason I have not is because I was not sure if the people editing the content etc. would want complete control over the content that goes under the TOC.

The side bar is not very wide and seeing we are going with an ordered list that can go up to three levels deep, we are going to see some crazy line wrapping as some headings are long.

If the person editing the content has control over the content for the TOC, they can adjust as needed. Either way is possible so, I will await feedback from Tom and the others.

It is also often much easier to make a decision if you can see an example so, I will finish up the basics for the Firefox page and open a pull request for it. Once it has been merged and pushed to dev, we can decide whether we want the list to be 'dynamic' or static.
So here is a question. We want to use an ordered list for the TOC which makes complete sense but, the caveat is that ordered lists natively do not support the concept of:

1.
  1.1
  1.2
2.
3. etc.

Now there are ways around this using CSS generated content combined with JS for older browsers but, both of these completely fail from an accessibility view point as screen readers will not read out this generated text.

What would be the suggestion. Use ordered lists but, hide the counter and either display have the editor of the content add the numbers by hand or, especially if we want to dynamically build it based on headings, simply hide the counter and display no numbering?

I guess the second one then removes the 'usefulness' of the ordered list and only leaves the semantic value. Let me know what you would suggest.
Small update, VoiceOver on Mac does read the content if generated by JavaScript but not CSS. Also, it only works with either Safari or Chrome ;(
I have a strong preference for using CSS to produce the nested numbers. I would also prefer that the ToC content be served in the HTML, not generated by Javascript. If the HTML is procedurally generated on our end, that's fine, better, even. I anticipate that the final copy will include only short headings down to level 3. If not, we wrap lines; oh well.

[Strong opinion:] CSS is part of the web, and CSS includes some (procedurally-placed) content. That's what `content` is meant for. If VoiceOver doesn't read that, that's their bug, not ours. There's a CSS feature designed almost explicitly for this use case; we should use it, not a JS workaround.
Tom,

Pull request opened for the latest revisions:
https://github.com/mozilla/bedrock/pull/339

Just waiting on someone to review it and push it to dev.
Tom,

Dev has been updated, please have a look. The TOC for Firefox is very long and you will see that until one reaches the bottom buffer and the TOC stops scrolling, a lot of the content of the TOC is outside of the visible window, not sure that this is ideal but, please let me know your thoughts.

http://www-dev.allizom.org/b/en-US/privacy/policies/firefox/
That's non-final content, so it might change when we get you final text. We might also have to reduce it to only including level 1 & 2 headings; more efficient and a custom/abbreviated ToC structure might help.

That's all content, though. Another approach might be to use JS to detect if the vertical height of the ToC is larger than that of the viewport, and to disable the scroll effect in that case?
Tom,

1) Let me narrow it down to only level 1 & 2 as this will definitely make a difference and then,
2) I was also thinking of not scrolling if the TOC is taller that the available height, let me look at both of these and update dev with the changes.

Just a side not, I was under the impression that the current content for the FF policy was the final text.
This is a mock-up of new text. It's "layered", in that users click to expand/compact the content. I expect that some work will be needed to make it obvious to users that they can click to expand and contract the content. dnt.mozilla.org has a Sandstone layout which does pretty well for this, but this isn't exactly the same situation.

Two links need some love. The "Mozilla privacy policy" anchor should point to the equivalent of mozilla.org/privacy. The RSS feed anchor should point to the Mozilla policies revision RSS feed which was also created as part of this revamp.
This is new content for the hub page.
I have shown around the latest design of these pages and some new text options. Prepare for an onslaught of revision requests! Since what follows is a quite extensive, it would be lovely if you could break down which things might take how long to implement. If help is needed (dev help, more design work, other things I haven't though of) I'd love to know that too.

---

Attachment #661970 [details] is meant to supersede all the content on the Firefox privacy policy page, from "Types Of Information" all the way down to the end of the "Prior Policies" section. Appropriate new ToC content is forthcoming. I think it makes sense to disable the ToC sidebar until then. In addition, it is requested that the phrase "Last Updated:" next to the date, and the paragraph of text directly below that be removed.

More buttons! These could go in another sidebar on the Firefox policy page or perhaps a horizonal bar, like at the top of the hub page. Other visual options are also welcome. Desirable buttons include:
- Since one can click to expand and contract content, both "expand all" and "contract all" options should be provided somewhere.
- A search box which looks through both expanded and collapsed text would also be lovely.
- An "updates and history" link should summon content identical to "Recent changes" section of the hub page (see below).
- "Print" should offer the same body content in a minimal, printable stylesheet.
- "Contact" summon content identical to the contact form on the hub page (see below).

---

If that weren't enough, on the "hub" page, the text supplied in attachment #661970 [details] is meant to supplant everything from "Your information" down to the end of the "Your choices" segment. But wait, there's more! At the end of this content, should be a contact form, entitled "Contact us", with fields for a correspondent’s name, email, and message. Below *that*, a section called "Recent changes", which simply mirrors the content of the RSS updates feed.
Hey Tom,

Does this include the changes from Harvey as well? I got a mail from Jishnu on September 14 mentioning that he will fill me in once he is back from PTO. Thanks
Hey Tom,

I see Jishnu is only back on the 4th of October so, do you suggest I start work on the suggestions in comments 31 - 33 or hold off until he is back? Thanks!
I haven't spoken with Jishnu about changes from Harvey. I'd much prefer to move forward with these changes, and then I can catch up with Jishnu once he gets back from PTO. Does that make sense for you?
Blocks: 790784
We took the current draft to Harvey who wanted something a bit different. I'm planning on getting the draft of that to Harvey, Alex and everyone else this week. They will need some time with it before we get it out to you all. Basically, it's a redesign of the project. Will reach out with text soon.
Blocks: 811440
Should we keep this meta bug open until all of the product privacy policies are ported over to bedrock?
Let's close this as it's done and I will open bugs as necessary
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: