launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Aug 6, 2009 at 11:00 PM, Jonathan Lange<jml@xxxxxxxxxxxxx> wrote:
> On Tue, Aug 4, 2009 at 4:40 PM, Julian
> Edwards<julian.edwards@xxxxxxxxxxxxx> wrote:
>> Howdy Launchpadders!
>>
>> I'm sure you've seen some of the other RFCs going out asking for feedback on
>> some new 3.0 page designs, and this email is also one of those.
>>
>> The page here:
>>
>> https://dev.launchpad.net/SoyuzPackageUI
>>
>> lists the results of a sprint that the Soyuz team, together with our design
>> guru Martin Albisetti, had earlier this year.  The main aim is to reduce the
>> number of pages required to get information about packages in Launchpad, and
>> as you can see in that wiki page we want to obsolete some existing pages.
>>
>
> I made a comment on this page, but it doesn't seem like there's much there.
>
>> To do this required some large changes in the distribution source package page
>> (e.g. https://edge.launchpad.net/ubuntu/+source/alsa-utils) and the
>> distribution source package release page (e.g.
>> https://edge.launchpad.net/ubuntu/+source/alsa-utils/1.0.20-2ubuntu1)
>>
>> The wiki page here shows the current mock-ups of the general direction we want
>> these pages to head in:
>>
>> https://dev.launchpad.net/VersionThreeDotO/Soyuz/NavigationRedesignUI
>>
>> I would like to ask for your feedback on these mock-ups, in particular:
>>
>>  * Is there any information taken away that you want to see?
>>  * Is there any information that could be added?
>>  * Are there any use cases not covered by these new pages?
>>
>
> First thing I have to say is that this is an amazing improvement. I'm
> comparing these two pages:
>  https://edge.launchpad.net/ubuntu/+source/hotwire
>  http://people.canonical.com/~ed/dsp_mockup.png
>
> and the difference is very noticeable -- well done.
>
> I'll shove these pages in front of the Ubuntu Foundations team
> tomorrow and get their thoughts.
>

I showed the page to cjwatson & mpt: here's what they said (roughly):

  * (cjwatson) It's very important to have a page that has every
upload and the changelog entry corresponding to each upload. This is
different from the current changelog, since changelog entries can be
deleted. Such a page needs to be structured so that the browser's text
search can be used to quickly find things.

  * (cjwatson) On the DSPR page, it's important to be able to quickly
get at old versions of binary packages. This helps advanced users who
want to test how newer versions of packages have broken their system.

  * (cjwatson) The dspr_mockup.png file says that 'Table entries link
to build pages'. However, every build for a given (arch,
sourcepackage) will be the same.

  * (cjwatson) Saying that the only build is i386 when you really mean
architecture-independent build is confusing.

  * (cjwatson) In an ideal world, there wouldn't be "Available diffs",
you'd ask for diffs between arbitrary versions and get them. Perhaps
this is just a matter of waiting for more Bazaar integration.

  * (mpt) Way too many fonts: particularly sizes & headings.

  * (mpt) Given that the publishing history is a set of multi-value
structured data over time, it should be presented as a table, e.g.
(date, version, status, distroseries, pocket, component, section,
action, archive). Each column should be click-sortable.

  * (mpt & jml) The green on the dspr page is a little ugly.

All my words, not theirs.

And the following points also came up, which I'm just requoting from
my earlier mail:

> - Needs more space around the logo, below and to the right.
>
> - The "Get Involved" thing looks out of place, and to be honest, I
> don't think of filing a bug as 'getting involved'
>
> - Seeing "<Verbed> on <date>" makes me wonder who verbed it.
>
> - The "Full publishing history" link should be below the publishing
> history, not below the PPA list
>
> - Maybe there should be a link to browse the source code
>
> - Intermediate Ubuntu users might not be able to map from binary
> package name to source package name in their head. Should we include
> the names of the binary packages that this is built into?
>

cheers,
jml