launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

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!:


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