On Mon, Aug 30, 2010 at 4:09 PM, Matthew Revell <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
