privacy portlet is not visible enough for indicating private objects

I'll put together a few mock ups we can look at :)

We've landed a branch that returns a Not Found when trying to visit a private team that you don't have permission to view. This doesn't directly address this bug report, but I'll leave it to Martin to decide if it's enough to close this bug or not.

It doesn't actually address the bug report at all - the issue I think we
need to solve is when you *do* have access to a private project page, it
should be clear that you are in a private project. There is an
indication of this, but it is small and not very obvious at all. (Not
concerned about when you don't have permission to access it - as far as
I know that always gave you some sort of error/no permission).

Martin. Is this bug still relevant? Launchpad does not have private projects. Private bugs, branches, and teams do have the privacy aside. I think all the work that can be done is done.

I am marking this fixed because all private objects use the public/private status portlet.

I understand if you want to close this bug, but I think the most accurate status is "Won't Fix" rather than "Fix Committed". The small, discreet public/private status portlet doesn't really address the problem I was trying to describe in my original bug report at all.

Yes, I agree that the portlet exists. And if you look for it, you easily find it. But when you are working on lots of bugs on both public and private projects, it is easy to overlook. Particularly when you are adding a comment to an existing bug, and the portlet has scrolled off the screen. It continues to be very very easy to mistake public and private bugs, and to comment on a public bug as if it were private. Our customers have seen this, and have expressed concern. When we are working in a private project (and commenting as such), there is no obvious change in the appearance when you move to a public bug. And as a result, customer sensitive comments have been accidentally added to public reports.

My original request was requesting something much more dramatic than the subtle portlet. I was thinking of a different coloured background, a large "private" watermark across the background, or something like that. The portlet serves only as information if you are seeking it. I was looking for something that served as information/reminder even when you aren't seeking it.

If this is against some standards of LP design, then I can live with that but I really don't think Fix Committed is the appropriate status for this bug, since it does nothing to actually address the original problem.

I agree we should do better.
I'll try and sneak this into 2.2.6

On Sun, 2009-05-24 at 15:52 +0000, Jane Silber wrote:
...
> Yes, I agree that the portlet exists. And if you look for it, you
> easily find it. But when you are working on lots of bugs on both public
> and private projects, it is easy to overlook. Particularly when you are
> adding a comment to an existing bug, and the portlet has scrolled off
> the screen. It continues to be very very easy to mistake public and
> private bugs, and to comment on a public bug as if it were private.
...

There are NO private projects in Launchpad. That feature is proposed for
4.x.

I think there are two issues here. One, the pubic private box is not
very visible, and it can scroll out of view when you are doing something
like commenting at the bottom of the page. Few users know that all
projects private (even Canonical employees).

> My original request was requesting something much more dramatic than the
> subtle portlet. I was thinking of a different coloured background, a
> large "private" watermark across the background, or something like that.
> The portlet serves only as information if you are seeking it. I was
> looking for something that served as information/reminder even when you
> aren't seeking it.

I think you are asking for the private background that Launchpad 1.0
used to show that all information about the page was private.

Let's make privacy a ubiquitous color/background so that any fragment of
the page is clearly private. Make that a 4.0 requirement. We can
implement it early. Actually, Martin has not clearly defined that for
3.0 UI. Make this a 3.0 requirement that we can fix in July/August.

--

__C U R T I S C. H O V E Y_______
Guilty of stealing everything I am.

Hi Martin.

Since we want to update the team page UI in 2.2.7, I would like a design or suggest of how we can present private things like teams, bugs, and branches so that no matter what part of the page you have scrolled to, it is clear that there it is private. I think this implies we want background change, something tiled on the page margins that cannot be missed.

base-layout supports this feature. I rotated the image used for privacy. When a private object is loaded, a stripe is drawn on the left margin. We need final art, or if the art I added is acceptable, we can close this bug.

I think the right thing to do is have a different background color all together. Not too shocking, but subtle enough so that you know that you're looking at something special.
I will work on this before 3.0.

I am marking this bug fix committed because we have the correct behaviour for 3.0. changes to the body.private style can be made after 3.0 in a trivial landing.

Unfortunately, the current UI has not been enough and created problems. I will propose a stronger indicator of private objects, mostly likely a background to the whole page.

This is one way of making it more visible

That looks like a mistake. We could have Private and Private Demo tiled on an angle like we do staging now. or we could have a Escher-like background tile of naked people--nothing says private like naked people

Martin, when you said "unfortunately, the current UI has not been enough and created problems", what was the current UI you were talking about and what problems specifically did it have?

Yet Another UI Opinion follows, feel free to ignore:

To my eyes, just having the diagonal-grey-and-white-stripey-lines thing along the borders of the relevant rectangular areas would be great. It would extend naturally to things like private comments on bugs, etc, too. IOW, we want something that can be applied naturally to sub-objects of an enclosing object, when the enclosing object itself may or may not be private. Background color could do it too, but when the entire background color is Y instead of X, some people may not notice it, because their eyes are tuned to differences not absolutes. A border pattern doesn't have that issue.

Karl, from conversation with others, the current UI is the UI we have today: barber pole on the left margin, privacy box on the top right.

The problems it has is this: if you are working with private stuff all day, you want *public* stuff to be really obviously different. The pole is too subtle. One customer I spoke to didn't even realize it was a thing.

I had this idea during my lunch. I was thinking of a multi-lingua keep-away tape that police place blockade an area with. I image tiling the message along the vertical borders of all private pages. Something like the attached image:

Don't we do that already on private bugs?

We do, but what does a vertical stripe mean? Where is it documented. You can see horizontal version next to the word privacy in the privacy box, but not everyone makes a connection. The bug was reopened. We could have locks on the page, but the user might think that means secure, not secret.

There is an older proposal to tile private in the background as is done with staging (demo). I personally think this is unhelpful because the small contrast from the background and light text an be hard to read. I believe part of the issue here is that this is expected to work for Canonical partners who are not conformable working in English.

So non-english may imply not-familiar-with-western-cultural-idioms as well.

Here is a proposal to signify private objects (mockup attached). Essentially we display a static notification at the top of the page when viewing a private object. This notification will stay on the screen as you scroll down, but can be hidden.

This seems like a fairly important issue (i.e. the consequences of users not understand they are viewing a public/private object can have serious ramifications) which I think calls for something as obvious as this.

The issues with this solution I can see:

A. It takes up screen real-estate (but can be hidden).
B. If the message is hidden you're back to just the portlet to signify private/public.
C. It introduces a new UI construct.
D. When you are viewing a public object you only have the portlet to signify the status.
E. It does not really address non-english speakers (apart from showing a big orange bar on private objects... maybe that is enough).

I'm not entirely sure of the use cases for this. Jane, maybe you can comment on whether this implementation would be sufficient?

Hi Huw.

This is a good approach. The construct could be reused for site messages such as read-only mode. I do not think there is a real estate issue since you allow the user to hide to hide it. We may want to test multiple languages again. My test was positive. It was pointed out that it was missing traditional Chinese which is used in Taipei.

I like it! How hard is it to implement?

I'm not sure if the shade of orange is appropriate, since it looks a fair bit like the Ubuntu orange, which has brand values that tend away from secret bugs. I'll see if I can find Ivanka today to take a look.

I've just spoken with Ivanka. She agrees that the orange is too close to the Ubuntu orange and that using it to communicate secrecy goes counter to the brand values.

The volume level is good however. We should take a colour that's already part of Launchpad's (over-broad) palette.

Other thoughts from Ivanka:
 * the bar might be too similar to bars generated by browser's for ad-block or password saving. Huw, can you please check a few browsers to make sure it's different enough?
 * because the privacy notice can be dismissed, it might be worth experimenting with variations of the barber pole design – make it wider, give it stronger colours etc.

Fixed in stable r12697 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12697>.

This broke sprites. Makefile was fixed in 12707.

Deployed, but behind feature flag.

This is now enabled for ~canonical on production.

I have changed this bug status back to "in progress" because private team pages are missing the privacy ribbon. Either this bug is about fixing *all* private objects, or we mark this bug as fix released and report bugs for each object that is missing the presentation.

So pages I know of that have just the subtle security theming:
 - private teams & all their child pages
 - private branches & all their child pages
 - private merge proposals (inherited from branch privacy)
 - private ppas & all their child pages
 - embargoed uploads (I think, someone in soyuz could confirm).

All these objects also add the private class to the body element.

Bug comments are also missing the privacy ribbon.

The ribbon does not appear to built on to use the body element's private CSS class.

So, being a long time launchpad user, I was used to the privacy stripes on the side of the bug. Now normally on a private bug, I've noticed the red bar on top. However, I was just pointed to a private bug that I didn't notice was private until I already started discussing it (luckily I said nothing sensitive). My eyes naturally gravitated towards the description since I wanted to know what the bug was about. I ignored the top part of the window until my second or third glance at the screen where I then noted it was private.

Should we disable the current beta that canonical staff see, if this
being put on hold?

@lifeless I believe the teal squad will be tackling this as part of their disclosure work.

Ok cool

The current problem is that the privacy presentation is bug-centric, but the
issue is about all launchpad pages. base-layout.pt is responsible for setting
the private class on the body element of every page. We want an implementation
that shows the privacy ribbon when the body has the private class. I think
there are several smaller issues/bugs that need fixing to truly close this
bug.

1. display_privacy_notification() must move from bugtask_index.js to a module
   in app.
2. bugtask-index.pt currently injects js
   var bug_private
   using an if-not tales clause. I expect the display_privacy_notification()
   js function to use the body class. This will make the function compatible
   with other Lp pages.
   * I assume some adjustments will be needed to ensure that changing the
     body class enables and disabled to ribbon
3. base-layout.pt uses fmt:public-private-css which uses IPrivacy() to adapt
   the context to a private/public css classes. We use the adapter because
   we know that many objects are private because their containing object
   may be private (has a .private attribute). I believe that adapters are
   missing.
   * We need individual adapters to support artefacts that can be private,
     subordinate objects that belong to bugs, branches, and archives. eg:
     def bugcomment_to_privacy(comment):
         return comment.bug.private
   * We know that the IPrimaryContext can be private. This means teams and
     every subordinate object is private,
     def primary_context_to_privacy(obj):
         return IPrimaryContext(obj).private
   * Both artefact and primary rules must work together. Even when the
     primary context is public, an artefact like a bug in traversal can
     be private. Maybe all privacy adapters must also call the primary
     context adapter first.
   This class us issue might be four bugs for privacy adapters:
   primary context, archive, bug, branch

Fixed in stable r13614 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13614>.

This has only been released to ~canonical and ~launchpad-beta-testers.