launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #05585
Re: Managing disclosure mockups for testing
On 10 November 2010 16:39, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
>> I propose the following:
>>
>> * Two rounds of user testing.
>> - Between rounds 1 and 2 we'll update the mock-ups based on round 1's data.
>> * After round 2, a follow-up survey sent to all of the participants
>> to check that any points of confusion etc have been clarified.
>>
>> I had considered whether we should split each round into two parts:
>> one targeted at private project owners and the other at
>> observers/restricted observers. I imagine, though, that the experience
>> for observers/restricted-observers won't be much different to what
>> already exists. How will observers be notified of and manage their
>> access to private items?
>
> You bring up an interesting point. I had planned to make these pages
> only visible to owners. I am not sure I should be able to see who has
> access to an OEM project that I have permission to view. Consider the
> case of restricted observer viewing a private project. The user is
> directly subscribed to a few bugs and branches; those are the only pages
> he can view. An observer of a private project can see all the pages that
> that are launchpad.View. The observer cannot see the pages restricted to
> moderate, edit, or admin.
Are there any circumstances under which an observer/restricted
observer may wish to remove one of their privileges? I'm guessing
> I have not considered notifications to users yet. We will send emails.
> Restricted observers are bug/branch subscribers so they will be notified
> of those changes automatically. There are confidentiality issues for
> observers. When a user is removed do we send an email that will disclose
> information? Canonical's own security team added a feature to quietly
> remove a user from a team to ensure nothing is disclosed to the user. We
> probably need a similar rule for observers of private projects.
That's interesting. I'll bring it up in the testing.
>
>> Looking at the mock-ups, I think it'd be helpful to have some
>> additional mock-ups. These would just be variations on what you've
>> already produced :)
>>
>> * The page from which the disclosure listing is accessed.
>
> I will add the link to the project index.
Thanks.
>> * A version of the listing page without the people picker overlay.
>
> I did. disclosure-listiing-view and disclosure-listiing-all-users-view
> are the two views of the list page. The disclosure-listiing-add-overlay
> is just about the overlay.
My apologies.
>> * A version of all mock-ups without explanatory boxes or post-it notes.
>
> I removed the notes. I do not know what you mean by explanatory boxes.
> Maybe you mean the ajax windows to edit the user/team permissions. Those
> windows are 50% of the feature. Do you want views without the
> interactions?
Sorry, I wasn't clear. "Explanatory boxes" was a bad choice of words.
I mean that it'd be handy to have versions of those mock-ups without
the Ajax windows so that I can ask the subject to "click" on an
option, after which I can present them with the mock-up including the
relevant window.
If you want to send me the Balsamiq originals I'll edit them myself,
to save you some time.
Cheers.
--
Matthew Revell -- https://launchpad.net/~matthew.revell
Launchpad.net -- cross-project collaboration and hosting
Follow ups
References