launchpad-dev team mailing list archive

[Dan Harrop-Griffiths <dan@xxxxxxxxxxxxx>]

Hi Curtis,

There are lots of great ideas to discus here - however my main aim is
to have some useable mock-ups to use for the tests that I've set up
for tomorrow so I'm going to take this discussion back to us and the
product team.

Dan

On 29 February 2012 16:25, curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
> On 02/29/2012 08:39 AM, Dan Harrop-Griffiths wrote:
>> Hi Curtis,
>>
>> Sorry to hear you've been ill - I hope you're feeling better now.
>>
>> I wasn't able to start the tests today as I wanted to talk to you
>> about the mock-ups. Thank you for presenting me with a range of
>> options, however I don't think it'd be viable to ever implement some
>> of these systems as they're more complex than what's needed. Last week
>> we agreed that a simple filtering system would be sufficient for this
>> feature.
>>
>> I'll go through the mock-ups:
>>
>>  1. Use the ajax filtering style used by pickers.
>> I personally think the number of options is daunting
>>
>> If this is the same system we had in the previous round, then I'm fine
>> with this. Users would prefer to see just 'similar results,' eg: Mo,
>> Max, Maurine, Mary when looking for 'Mary' rather than a list of
>> seemingly unrelated results, but I think this is fine as it wasn't a
>> big gripe, just a small aside from 1 of the 5 users during testing.
>>
>> 2. Use the column filters used by derived distro differences
>> I think this is okay, but I dislike that I need to change multiple
>> columns to do an audit
>>
>> I didn't understand what you meant by this until I'd spoken to
>> Matthew. Although I think in theory this is a good idea, we're
>> applying a whole new kind of filtering system here. I don't think we
>> need it to be anywhere near as complex. I'm pretty sure that last week
>> we agreed that being able to find 'Ian' in a list of 20 people, by
>> typing 'Ian' into a filter in the name column should be sufficient.
>> Having a filter that only showed 'some' is also sufficient for the
>> 'info type' column.
>>
>> 2.1 Choose to see the team members
>>
>> I thought we'd agreed that this wasn't necessary. It's a great extra
>> feature, but I don't think we need it.
>
> Not so. This is a requirement for about 5 people in Canonical. Members
> of the pm team are required to audit *everyone* who has access to
> proprietary information. They use a script that checks bug and branch
> subscribers now. Project sharing will break their scripts -- We must
> provide an alternative. No commercial organisation will trust that they
> can manage disclosure if it is not possible to get a list of everyone
> their information is shared with and know how it as shared
>
>> 2.2 Chose to see Some for each policy - Yes, this is a useful thing to
>> do, but not in this way. A filter in the column heading for 'info
>> type' that has 'show some' would be sufficient.
>>
>> 3. Use a configure overlay like bug columns.
>> I would use this.
>>
>> I'm not sure what you mean by a configure overlay? I'm guessing it's
>> something that would be more evident on the working prototype.
>
> All the Launchpad popups are not popups (which are windows). Lp uses
> JavaScript to create an overlay that appears to be above the page content.
>
>> 3.1 Choose everything I want to see in a single action.
>>
>> This looks pretty much like the old system that we didn't think worked
>> or would be used. If this mock-up is just to show users, so we can get
>> a contrast in opinion/options, great. But I don't think it'd be a good
>> idea to ever get this implemented.
>
> hmm. So why did we implement it in bug columns?
>
>>> 4. Put everything into the page like answers does
>>>   This is fine, but I think most users will never need to use it.
>>
>> Thanks for this option, it will be interesting to have people comment
>> on this as an alternative. However I agree that it will most likely
>> never be used, and I don't think it'd be useful to most users.
>
> This is largely the same form we tested last time with new words and re
> took it out of the expander.
>
>> Other things:
>>
>> The '+share' button is still on the mock-ups. The point of moving the
>> search box was to retire this button, as it was confusing to 4/5 users
>> I tested it with. Can we please remove it from the mock-ups?
>
> I cannot image how to share with people then. Search *only* finds users
> that you have shared with. It does not search the million+ users in Lp.
> We created the person and person+sharing picker to share with people.
>
> THIS IS HOW IT WILL BE. We do not have html forms to support this level
> of interaction. I will not work on this project in 2013.
>
>> The 'summary info' sits above the search box. My suggestion was to
>> have these side by side rather than on top of one another. I don't
>> think the pages works as well in the 'on top of' format, as you kind
>> of have to scan the summary info before you get to the search
>> function. Rather than it being an 'extra', it becomes a visual blocker
>> to the search.
>
> I wanted to same space. It can be out side.
>
>> I'd like to use the side by side view option if this is possible -
>> there may be a space issue, but I think we can probably fit thing sin
>> with a bit of rephrasing of copy if necessary.
>
> There will not be a space issue. This layout is the same that is used
> on the person page.
>
> --
> Curtis Hovey
> http://launchpad.net/~sinzui
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp
>