launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Tue, Aug 31, 2010 at 5:16 PM, Michael Nelson
<michael.nelson@xxxxxxxxxxxxx> wrote:
> On Mon, Aug 30, 2010 at 4:09 PM, Matthew Revell
> <matthew.revell@xxxxxxxxxxxxx> wrote:
>> Hello Julian, Michael,
>>
>> I have placed the transcripts of the round 2 interviews, along with
>> suggestions that I've drawn from those interviews, here:
>>
>> https://dev.launchpad.net/LEP/DerivativeDistributions/UserTestingRound2
>>
>> Please let me know if you need me to clarify anything or would like
>> further testing.
>
> Thanks Matthew for transcribing and summarising all the info - it's
> invaluable. And thanks Peter, Colin and Loïc for taking the time to
> give such feedback.
>
> I'm currently looking at the three difference pages only (Mockups 3, 4
> and 5 in the interview, Julian was working on the new distribution
> series page) and based on a first reading of the interviews, below is
> an outline of how I plan to update those mockups tomorrow with a few
> questions (I'll re-read through the transcript as I do it to catch all
> the smaller details and in case I've missed anything). If you can
> answer any questions or correct any wrong assumptions, please do!:

And here's a first-cut that addresses the points:

https://dev.launchpad.net/LEP/DerivativeDistributions?action=AttachFile&do=get&target=derived-series-diffs_uiround2.png

It makes the table itself much simpler by including much of the detail
in the drop-down.

Let me know if this does not address your issues, or if it raises new
ones. The main issue from my point of view is that now, to blacklist
an item, you have to first expand the row, then click blacklist. If it
is likely that you'll have a page of 50 items and want to blacklist
them all, this will not be an option and we'd need to put the button
back to "Blacklist selected packages".

Cheers,
Michael

>
>
> Viewing packages that have previously been blacklisted/ignored
> ==============================================
> It seems there's agreement that "blacklist" is the better term,
> although Colin points out that blacklist implies ignoring all versions
> of the package, not just the current
> version (more on that later).
>
> Aside from the blacklisted/ignored word confusion, the link:
>
> "There are currently 6 [new] Lucid packages that have been ignored."
>
> caused confusion on two other fronts:
>  1) the term new was in one case understood as new items to be
> considered on this page (ie. how could I have then ignored them),
> rather than packages new to Lucid that are not in derilucid. The
> solution is easy: get rid of the word "New".
>  2) Why would I want to see just the blacklisted packages - wouldn't
> it make more sense to have an option to include them in the normal
> results? (Peter).
>
> Solution:
> I think we can address (2) by removing this text alltogether and
> instead, as Peter suggests, having an extra check-box in the search:
>
> [] include blacklisted packages
>
> which is unselected by default. This would be consistent across all
> the difference pages. Selecting this option would ensure that all
> items that have been blacklisted/ignored (whether for a specific
> version or all versions) are included in the results. This would mean
> that there is no option to display *only* blacklisted items.
>
>
> Marking a package as blacklisted/ignored
> ==============================
>
> Assuming the two desired options are to:
>  1) mark a package so that it will not be displayed in the list by
> default ever again (ie. even when new versions are uploaded).
>  2) mark a package so that it will not be displayed in the list by
> default until there is a change (ie. a new version uploaded to either
> series).
>
> It sounds like "blacklist" is definitely the correct term for (1), but
> how can we differentiate the above? I can think of two options:
>  * "blacklist all versions" and "blacklist this version"
>  * "blacklist all versions" and "ignore this version"
>
> I'll assume the former unless I hear otherwise.
>
> Also, based on Loic's feedback, I'll remove the option to "Blacklist
> all selected packages" (which would be quite difficult given the two
> blacklisting options anyway), and replace it (somehow) with an
> individual action for each difference.
>
>
> Be explicit about *source* packages where possible
> ==================================================
>
> Noted. Where space permits, I'll update all references.
>
>
> Last common version information
> ===============================
>
> From Colin and Loic's input, it seems the last common version info is
> useful, but not generally useful enough to warrant a column. Loic
> suggests including it on the diff, Colin is OK with a mouseover or a
> more information toggle.
>
> The more information toggle is more general and will allow us to
> present other information as necessary (eg. eventually latest
> changelog entries etc., or the various types of diffs discussed
> below), as well as free-up space in the table for more pertinent info
> (like Uploaded by).
>
>
> Clarify what the search searches on
> ===================================
>
> OK, I'd assumed people would only be searching for packages with a
> certain name (and that including the descriptions in the search would
> cloud the results). I'll make that explicit, but if that assumption is
> wrong, please let me know - we can do either or both.
>
>
> Consider which diffs are useful and should be available
> ========================================
>
> This is hard, at least given the column restriction. That is, giving
> the different types of diffs an appropriate textual link in such a
> small space.
>
> That said, this could be another example of why a drop-down more-info
> section for each row could be very useful. This would allow us to
> present the various diffs without the restriction of the column width.
>
> Regarding the auto-generation of diffs, Julian's main concern was that
> we'll fill the librarian unnecessarily, but based on Colin's feedback,
> it sounds like we could be sensible about the diff generation. Would
> the following work?
>
> 1) For packages that have changed in derilucid, but not lucid (ie. the
> lucid version is the last common version), we list only one diff
> (last-common-version to derilucid version), and we don't auto-generate
> as its not necessary for making a decision. (?)
>
> 2) For packages that have changed in lucid but not in derilucid (ie.
> the derilucid version is the last common version), we list only one
> diff (last-common-version to lucid version), and we *do* auto-generate
> it, as it will be required to make the decision to sync.
>
> 3) For packages that have diverged (changes in both), we list two diffs:
>  * last-common-version to derilucid version
>  * last-common-version to lucid version
> and we auto-generate both so that
>
> Obviously we need to ensure that we remove references to diffs once
> package differences are resolved (so the librarian isn't filled up)
>
> Colin mentioned: "You never really want a diff from the current
> version in Lucid to the current version in Derilucid unless one of
> those is also the common version. Otherwise you have this unreadable
> diff.". I'd assumed this diff would be necessary in the following
> scenario:
>  1) New version uploaded to Derilucid
>  2) Derilucid changes merged upstream and uploaded, resulting in a new
> Lucid version, at this point, although the currently published version
> numbers are different, the diff of current version in Lucid to current
> version in Derilucid would show you that you can now sync wouldn't it?
> (ie. there would just be small changelog differences?). Let me know
> anyway.
>
>
> Use the word 'Sync' instead of 'Include'
> ========================================
>
> Colin points out that 'Sync' is the term used generally for verbatim
> copy. So I'll change "Include selected packages in Derilucid" to "Sync
> selected packages into Derilucid".
>
> Cheers,
> Michael
>