[wp-trac] [WordPress Trac] #43981: Privacy notices page: improve UX and readability

WordPress Trac noreply at wordpress.org
Wed May 9 05:23:47 UTC 2018

#43981: Privacy notices page: improve UX and readability
 Reporter:  idea15        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  General       |     Version:
 Severity:  normal        |  Resolution:  duplicate
 Keywords:  gdpr          |     Focuses:

Comment (by danieliser):


 > So that will result in a page having 1000 sections because that's what
 plugin authors decided to do? There's a first problem that I see.

 Exactly what happens as it is now ;). If I generate text for a box, it is
 appended to the default text inserted into the editor (at the bottom,
 separate from the rest), and we are really to expect users to go back and
 manually merge it up where it goes?

 That is what I want to prevent. Common sections should be standardized
 with filters to append additional information (cookies, analytics, data
 usage etc).

 But if the common sections don't cover your localized needs, then there
 are ample ways you can add that info, I mean its WordPress. Actions,
 filters & editors oh my.. ;)

 >> WordPress is supposed to be easy for users to get going.

 > WordPress yes, the regulations / laws / policies are not. So there's a
 really really thin fine line that we shouldn't step over imho.

 Correct, and we are again going to assume that the lay masses that use
 WordPress are going to go above and beyond what the defaults that WP core
 gives them? I'm betting heavily on not. Since WordPress has the resources(
 community ) behind it to facilitate decent legaleeze, and to provide a way
 of easily merging like/similar data ahead of time.

 > > I will have to start with the core policy suggestions, rewrite
 accordingly, then move on to manually merge in the data from 10+ plugins
 one at a time, each having different data that has to be merged into the
 same policy template core already suggested, not just appended to.

 > And that's what you would/should do if you had 3 plugins saying 'We
 gather analytics' under the data section you would again have to filter
 the 2 extras out and re-write it to the tone that you speak with your

 Well as it is currently there will end up being 3 completely different
 "Analytics" sections which need to manually be merged. My proposal above
 again simplifies this. We know common sections like cookies, analytics,
 data usage, 3rd party services etc are gonna need to be there for most
 sites. I'm saying make it easy for plugins to send their text directly
 under those sections in the core suggested text.

 Will they still have to rewrite it in their own tone, that is a given (if
 they even bother). But my proposal doesn't change that, it simplifies it
 in that they will be able to reword all of the analytics lines at once,
 not one here, another down the page (which you then cut and paste back at
 the top).

 > I didn't understand at all here. cookies shouldn't be listed at the
 bottom by themselves what bottom? My plugins cookies will be listed on the
 policy that I'm pushing to the core. You can take that and do as you
 please with it as with any other information that I might be adding.

 To clarify this is the same point I've been making above and I think we
 are really on the same page, just not communicating it the same.

 If your plugin adds to the core text output (as it is now), it gets
 appended to the bottom. So if you add a list of cookies and a heading
 above them, that info will come after the very last line of the core text.
 Meaning the user then has to cut it and paste it back up where the core
 Cookies section exists already, delete the heading you inserted etc. Very
 tedious if you have 20 plugins all basically inserting mini privacy
 policies one after the other and expecting the user to merge them, or even
 to realize they need to.

 1. Core Policy Default Text
 2. Plugin A output (containing info that needs to be merged into 1 above,
 while also removing all the headers needed)
 3. Plugin B, & C and on and on.

 Ok, so my full proposal I believe will check all of your boxes. From your
 replies, I think your main issue is that they have to rewrite it in their
 tone & freedom to update as they see fit.

 Since they will always have to rewrite in their own tone from both core
 and plugins, that really doesn't matter. We are simply talking about the
 way all of the info is presented, not the words used.

 As for freedom, my suggestion is still to provide the default text still,
 so what they do in the editor after that is completely up to them. I just
 don't want to have to both reword all that text & have to merge it

 See my other ticket for context & example of what I'm suggesting #44010.

 Also in that ticket I mention using the existing Revision Diff system to
 allow updated default text to be compared side by side with their own. So
 it all can work nicely over time if we let it. Most are considering the
 immediate implications of getting a policy live, few are considering how
 difficult its gonna be to manage over time adding and removing info.

 So consider that if we standardize output of cookies, analytics usage, and
 various other things, generating policy updates will be much easier,
 familiar to those using revisions, and less time consuming. That is what
 I'm advocating for.

Ticket URL: <https://core.trac.wordpress.org/ticket/43981#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list