launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

Martin Pool wrote:
> 2009/7/27 Michael Nelson <michael.nelson@xxxxxxxxxxxxx>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Launchpad users and developers!
>>
>> I'm starting the process of updating some soyuz-pages to the new
>> 3.0-style designs, and I got stuck on the PPA index page - mainly
>> because of the huge opportunity we have to improve the page.
>>
>> I've outlined the main problem (as I see it) and have included a mock of
>> one possible solution at:
>>
>> https://dev.launchpad.net/VersionThreeDotO/Soyuz/PPAUI
>>
>> If you use the PPA page as a user or developer, I'd love to get your
>> feedback and suggestions as well as your own mocks if you have time.
>>
>> Feel free to update the wiki page directly, but for the conversation,
>> please reply here too with a summary of your thoughts.
> 
> Hi, those are pretty interesting mockups.

Hi Martin, thanks for the feedback :)

> 
> You're right that the PPA serves two audiences and is pretty busy at
> the moment.  But it's also the case that many PPA publishers are going
> to be fairly new to making packages so may not want a
> debian-archive-expert-oriented view.

Specifically which aspects of the mockup do you think are
debian-archive-expert-oriented? (I feel exactly the same way and was
trying to ensure it was welcoming to new PPA publishers).


  For them, the PPA web page
> provides important intellectual and emotional confirmation that they
> have actually done what they intended to do.

So, if I'm understanding you correctly, you are saying that it is not
enough that they can view currently building packages etc. at
+ppa/my_ppa/packages to see that info but it should be part of their PPA
summary - yes, good point.

Actually, even including the (paginated) packages at the bottom of the
page may not be sufficient (unless the initial ordering ensured that
recent uploads appeared at the top).

This *might* be the perfect thing for a side-bar portlet - recent
actions on this object (there are some pretty strict guidelines about
what can and can't appear in the 3-0 sidebar):

Firefox-3.5 (5 mins ago)
  [building-icon] currently building <-- link to build record with
version details etc)
Thunderbird-xy (2 days ago)
  [fully-built icon] Fully built

BTW: I'm currently in the process of creating permanent wiki pages for
key LP pages describing the use-cases and target audiences. I've just
drafted:

https://dev.launchpad.net/SoyuzPPAIndexPage

with the information you provided - feel free to update it of course if
I've mis-represented your points!

> 
> Emphasizing the most recent or popular individual packages is an
> invitation to treat PPAs not as software channels that you subscribe
> to, but as a passive container from which you can pick out particular
> packages to install.

That is a very good point and flaw that I hadn't thought about. Hmm.

  That's actually quite an interesting story
> because it requires less ongoing trust of the PPA maintainer, and many
> of the times when people want a PPA, like "please see if it fixes this
> bug" do just want a one-off installation not ongoing use.  However, it
> is a very different story from adding the PPA, and one that's not
> fully implemented wrt installing dependent packages.  Therefore you
> shouldn't complicate your message - stick to getting people to either
> add it or not.  (Obviously downloading particular packages will still
> be possible for people who know they want that.)

Yes - I'll have to re-think the content there. As you say, most popular
packages does not really make sense at all in the context of a software
channel.

> 
> The key case for this page is: "what is this, do I want to use it, and
> if so how do I use it?"  So the information that answers that should
> be prominent and in the top left, as you indicate with your arrows.
> But the description and the installation instructions up there.

Yes, so the new mock has the description first, and my thought was that
the most popular/recent packages would also help make that decision, but
as you've pointed out they don't. Perhaps the install instructions
should follow - or some other information which helps make the decision
(I'm starting to get the feeling that something summarising the scope of
the PPA is most relevant - as I mentioned in my reply to Max on lp-users).

> 
> Rather than just the signing key ID I'd suggest you actually give the
> command necessary to add it.  There's a big question here about
> whether you should encourage people to copy and paste random sudo
> commands or how to confirm informed consent, but I believe that just
> making it complicated doesn't really help.

Did you notice that with Karmic you won't need to do that? That is, mvo
has done the work so that we can just add 'ppa:username/ppaname' to
software sources and it automatically imports the key? But sure, we
could include the sudo command in the 'Technical details about this PPA'
drop-down (which should be perhaps 'Manual instructions for adding this
PPA' or something similar.

> 
> I'd put the stats in a portlet; that's an ideal type of information
> for a sidebar: small and rarely of interest to normal use.  You can
> make the text shorter.  (Why on earth is Launchpad only estimating the
> size?  If for implementation reasons it can be out of date or slightly
> off I don't really care...)

I don't think the stats are the type of information that fits the
guidelines for the 3-0 sidebar (actionables, subscriptions etc.), but
will find out more soon.

> 
> There may be some user confusion that if I add this archive it will
> use this much of _my_ disk?

Hmm... I'm not sure if you're referring to the image of the current PPA
page, or of the mock that I suggested. I've got a comment at the bottom
of the mock saying that if the viewer is the owner (or a member of the
owning team, or an admin - which i forgot to mention) then they will see
two extra portlets in the main area, "Build status summary" and
Repository disk usage. So if we did that, normal users wouldn't even see
the repository disk usage.

> 
> I think showing the full list of packages is useful because it gives a
> sense of whether the ppa really aligns with its purpose or whether
> it's just a random dumping ground as some of the early ones were.

Hmm... while I think the list of packages should stay there at the
bottom for the moment (I'll include it in the next mock), I am hoping
that we can find a better way to communicate the scope of the PPA
without so much detail. Something like:

For ppas with <= 5 packages:
This PPA will currently only update the following packages on your system:
  * one
  * ..

For ppas with > 5 packages, we'd just refer to the complete table.

Off topic, but it would be *great* to be able to say "This PPA only
updates the following packages on your system (you will be notified if
further packages are added in the future)." - ie. have some concept of
PPA scope built into PPAs and controlled by owners.

> 
> Two other things I'd like as a user and developer, and both I think have bugs:
> 
>  * a timeline-oriented view of changes, ideally including the
> changelog snippet and the uploader - helps characterize the PPA
>  * download counts and an estimate of the total number of subscribers
> - helps determine trust, and gives satisfaction to the maintainer
> 

Yes, agreed.

So thanks Martin for the valuable feedback - I'll go back and try again
with the mock based on this (and any further feedback).

-- 
Michael