VersionThreeDotO/Soyuz/PPAUI/Inputs

Not logged in - Log In / Register

Page purpose and use-cases

See purpose and use-cases for PPA th index page.

Email conversation with Kiko 2009-07-24 (v1)

On Fri, Jul 24, 2009 at 09:40:21PM +0200, Michael Nelson wrote:
> > So I still feel strongly about it - but that said, I understand that you
> > guys know the (current developer) users' needs much better than I do.
> > I'd still like to ask Martin for his thoughts too (he'll probably just
> > say exactly what you've said, but it'll just let me feel that I've done
> > what I could ;) ).

So maybe I should have prefixed this whole discussion by saying that I
love the page you proposed! I think that some developers will like it,
but I fear that some will miss the old view. However, I should have said
that since I loved it you can definitely try it out on edge and then let
the end-user tell us if it should win!

> > If the first five (or n) source packages are displayed in the normal
> > table at the bottom of the page, with the normal filter etc., but as
> > soon as you use it (ie. click for the next page of results or filter)
> > the request is handled by the +ppa/name/packages url, then all the
> > copy/delete packages functionality can still be moved to that url, and
> > when I interact with the source packages on the +ppa/name page I then
> > see just the source packages. Kind of similar to how we include the
> > search form on the distribution page, which just lets the +search url
> > handle the results.

That might be a good compromise, though I wonder if the project owner
wants to delete packages, etc, if he'll find that link.

>>>> > >>>     - We're still missing action links (see the Get involved
>>>> > >>>       section) in a portlet
>>> > >> Hmm... but how can someone get involved with someone else's PPA (other
>>> > >> than using the software). Soon they'll be able to report bugs (?) but
>>> > >> not yet. There will certainly be room for the side portlet when we have
>>> > >> action links that should go in there...
>> > > 
>> > > For the PPA owner there are PPA-wide operations, though, right?
> > 
> > Only changing the details of the PPA? (ie. the 'edit' operation on the
> > current resource identified by the url). Everything else is handled by
> > separate urls (copying pkgs/deleting pkgs/viewing builds/adding private
> > access etc.) Or maybe I forgot something?

I was actually referring to the links to these separate URLs! ;-)

>> > > Yeah, but everybody PPA owner's browser right now has the PPA page
>> > > loaded in history, and not something/packages.. ;-)
> > 
> > Sure, but I'm not sure how relevant that is? The first time an owner
> > visits his/her PPA they *want* to see the overview of their PPA, and it
> > is just one very obvious step to view the packages when they need to.

Okay, so let's frame this differently. Is the overview we're displaying
here useful enough to the owner that he'll be okay with using it instead
of viewing the package list?

I suspect that the most frequent use case for an owner visiting the PPA
page is checking to see whether the package he uploaded was accepted,
built, etc. I think if we take that into account we'll find a design
that he'll love, even if for some operations what he needs is off on
another page.

> > suggestion. Would you mind if I run it by Martin as a final stop,
> > otherwise I'll just update the mockup with your suggestions and send it
> > to the lists for discussion.

Oh, I'm happy for Martin to overrule me in this design -- I was just
giving feedback, not deciding for you (I know I do that some-times, but
this is not one of them! ;-)

Email conversation with Max Bowsher 2009-07-28 (v1)

Max Bowsher wrote:
> > Michael Nelson wrote:
>> >> 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.
> > 
> > I like most of this, but do have a few suggested changes:

Thanks for the feedback Max!

> > 
> > 1. Even with a "user" hat on, I still want to see at a glance what
> > packages a PPA can offer me *and* I want to see what packages I may not
> > want, but may be letting myself in for by adding the PPA to my sources.
> > I don't think "recent" or "most popular" should be the only determining
> > factor for display on the front page - I'd prefer full information on
> > which source package names exist in which series be visible.

As a technical user, 'recent' and 'most popular' should definitely not
be the only determining factor for adding a PPA to your sources, and in
this case, would the option I mentioned on the wiki page deal with that
concern? :

"Option 1: To smooth the transition, we could keep the list of source
packages at the bottom of the page, but any interaction with it (ie.
filtering or paginating) will then use the +ppa/ppa_name/packages url to
handle the request."

(note: I don't think we can display all packages in one hit - as there
could be hundreds, but allowing people to browse the packages directly
from the front page is probably a good idea, as you suggested).

My second thought here is, I wonder if there is a way to summarize the
information required for you (well, users who are less advanced) to make
that judgment. For example, we could encourage small focused PPAs by
displaying "This PPA currently updates only the following packages on
your Ubuntu 9.10 system: firefox-3.5."  when the archive has < 5
packages or something (auto detecting the distroseries)?

> > 
> > 
> > 2. A common use case is to do simultaneous uploads for all supported
> > series - this would overflow the proposed "recent uploads" section with
> > various series of a single source package name, in a single batch of
> > uploading. Options to fix this include restricting the "3 most X
> > packages" lists to a single series (autodetected with changeable
> > dropdown, as exists for the sources.list lines), or (potentially tricky)
> > batching uploads for the same source package name that occur within an
> > hour or so of each other.

Good point. I'm guessing we'd only include packages that were
successfully built in the "most recently uploaded packages" (perhaps
"Latest package updates" would be better?) But I think it would need to
be grouped somehow. Hmm. "gnome-panel in Ubuntu Gutsy and Karmic -
uploaded 3 days ago". I think we could grab the latest three unique
source package names uploaded.

> > 
> > 
> > 3. It would be really nice if the owner's description field could make
> > use of a severely restricted subset of HTML or wiki-esque markup - e.g.
> > bold, italic, font-size.

Yes, generally for description fields across LP...

https://bugs.edge.launchpad.net/soyuz/+bug/392123

That would be great to do soon, the spec linked from there talks about
moin, but ReST would be just a nice.


> > 
> > 
> > Max.
> > 

Email conversation with Martin Pool 2007-07-29 (v1)

Martin Pool wrote:
> > 2009/7/27 Michael Nelson <michael.nelson@canonical.com>:
>> >> -----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).

Reply email from Martin Pool 2009-07-31

2009/7/29 Michael Nelson <michael.nelson@canonical.com>:

>> >> 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).

Nothing in your mockup; this was in response to the comment on splitting it.

> >  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.

I'm not sure if it needs to including things building or waiting to
build, but a view of recently changed packages would be good.

I think you also need to somehow convey a bit more strongly that there
are two views: what's currently in the archive (which changes over
time); and things trying to get into the archive (including the queue,
failed builds, etc.)  But this is probably less urgent than the main
view.


>> >> 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 didn't know that.  It is pretty cool.

> >

>> >> 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.

That would be nice.  I think phrasing like "will currently only
update" is inappropriate until you actually add this feature...

IRC conversation with Martin Pool 2009-07-31 (v2)

<noodles775> Hey poolie, thanks for the feedback re. ppa-index ideas. I was wondering whether you got to take a look at the new mockup? I tried to ensure that it deals with a number of your points?
<poolie> thanks for listening
<poolie> i hadn't clicked the new one yet but i can look now
<noodles775> Thanks! https://dev.launchpad.net/VersionThreeDotO/Soyuz/PPAUI#Idea%202.%20Re-focusing%20the%20purpose
<poolie> noodles775: it looks nice
<mrooney> dear launchpad, I honor your achievements with this blog post: http://mrooney.blogspot.com/2009/07/launchpad-is-now-automatic-magical.html
<poolie> I really like the top part, including
<poolie> the "owned by %s"
<poolie> mpt would point out that "read about installing" is a poor hyperlink text :)
<noodles775> Yeah, kinda necessary when people can name their PPA "Official Mozilla Security PPA" if they like.
<noodles775> Yes, I' just used what's on the current one... good point. I'll update it.
<poolie> so i can see where you're going but i still have concerns about the "currently updates only ..."
<noodles775> Yes, I'd done this version before your latest email...
<poolie> firstly that it's just a point-in-time thing
* warp10 (n=andrea@host30-154-dynamic.3-79-r.retail.telecomitalia.it) has joined #launchpad
<poolie> and also that even for quite well focussed ppas there might just be quite a few packages
<poolie> most of which the user doesn't care about or recognize
<noodles775> what would be the problem when there were, say, 15 pkgs?
<poolie> because packages are smaller than the end user's idea of applications
<poolie> i guess basically i don't understand what this gives you beyond the package list down the bottom
* boomer (n=prinice@unaffiliated/boomer) has joined #launchpad
<noodles775> The aim was that it summarises information for a decision. Ie. if there were 15 pkgs, it would say "This PPA updates 15 packages on your system. You can browse those packages below and subscribe to be notified of new packages..blah"
<poolie> sounds a bit like filler to be frank
<noodles775> So I guess it is only ever summarising information that is present in the table.
<noodles775> Yeah, ok. You're not the only one to question the duplication :)
<poolie> how about instead: make it obvious that your can subscribe
<poolie> make it obvious what the packages are
<poolie> and use the space maybe for some stats like
<poolie> 15 packgase
<poolie> 23 uploads in the last month
<poolie> 4 packages building and 3 waiting to build
<poolie> oh, and i'll tell you what, the nice thing is that the build counts gives you a nice way to show developers what happened to their stuff
<poolie> without necessarily having a portlet
<noodles775> Great idea (the building stats will be present for owners/admins etc. already - see the note on the mockup).
<noodles775> Hmm... were you against the build-summary-status only displaying for owners/admin etc.? (see note bottom left of mockup.)
<poolie> because one of the issues you have to struggle with here is that you fire off with dput and then things become a bit invisible
<poolie> i am against that actually
<noodles775> Yep, as in you think it should always be visible?
<poolie> i think generally, everyone should see the same page unless there's a good reason otherwise (like private data etc)
<poolie> otherwise you get this "that's funny, why can't you see it" reaction
<noodles775> Yes, good point.
<poolie> mm
<poolie> and it seems possible that there'll be an interaction like this
<poolie> dev: ok i've uploaded a fix to the ppa, please try it
<poolie> user: i can't see it
<poolie> well, this will probably happen anyhow, but at least showing that stuff is building or waiting may help
<noodles775> Why wouldn't they be able to see it? (ie. the latest uploads with their state?)
<poolie> my mistake, they would see it there
<noodles775> ah ok.
<poolie> oh, the other big reason why people should see data they we don't expect them to use in this context -
<poolie> it helps them learn what the system can do
<noodles775> +1
<poolie> people will probably see someone else's ppa before they create their own
<noodles775> Great... thats excellent feedback, thanks! Anything else? (I'll try to do a v3 sometime later today).
<noodles775> s/thats/that's
<poolie> so the thing i meant by a timeline view is something like this - above or below the package list, have something a bit like a bug activity view
<poolie> with items like
<poolie> firefox-3.5-thoaeu-1234124-1234-124 by _Martin Pool_ at 2009-07-31 12:22 **waiting to build**
<poolie>  * firefox now starts much faster
<poolie>  * no more bugs
<noodles775> OK - so people can see what changed in the latest upload, yeah, that is helpful info.
<poolie> so then it's like an overall changelog for this ppa, not a timeline of builds as such, but a timeline of packages, including the current state of those uploads, whether they succeeded, failed or whatever
<poolie> right, and so you get a sense of what kind of work's being done here
<poolie> hm
<poolie> i wonder if "You can update your system" is making too much of an assumption people are running karmic?
<poolie> some people on Windows will find these pages through a google search :)
<poolie> hilarity ensues :)
* goshawk has quit (Remote closed the connection)
<noodles775> heh, yes, we could make that "You can update your Ubuntu <distroseries> ..." when we autodetect...
<poolie> more seriously people on jaunty will probably get stuck
<noodles775> and present something else when it' pre-karmic that is more direct.
<poolie> also remember people may be browsing from one system but ssh'd to another
<poolie> so of course you need a way around autodetection
<noodles775> Yes, but those people would surely know to look at the technical details (key/apt-get url), don't you think?
* goshawk (n=quassel@93-34-51-220.ip48.fastwebnet.it) has joined #launchpad
* dneary (n=dneary@ALyon-152-1-34-252.w83-205.abo.wanadoo.fr) has joined #launchpad
* doctormo has quit (Remote closed the connection)
* warp10 has quit ("Scotty, beam me up")
* mtaylor (n=mordred@camelot.inaugust.com) has joined #launchpad
<poolie> yes, as long as there's a drop-down to get the right system within that it's fine

IRC conversation with Martin Pool on 2009-08-06

<noodles775> Hi poolie, I forgot to mention, I updated the PPA mock with your comments: https://dev.launchpad.net/VersionThreeDotO/Soyuz/PPAUI
<noodles775> I've integrated the timeline with the latest-uploads (as otherwise it would have been duplicating some of the info). See what you think anyway.
<poolie> k
<poolie> noodles775: is there any general policy or plan for when to use portlets in ui 3?
<noodles775> poolie: yes, quite specific actually
* noodles775 finds the link
<poolie> i'd say basically that looks good
<poolie> very good
<noodles775> Does the page have actions that create objects or notifications, does
<noodles775>       it have a subscriber's list, does it have notification (events) to 
<noodles775>       show recent activity?
<noodles775> From: https://dev.launchpad.net/VersionThreeDotO/UI/Conversion
<noodles775> Thanks!
<poolie> there's a couple of things i mentioned before, maybe after you mentioned this
<poolie> the link text "How do I use ..."
<poolie> and that you should be clear, i think, that ppa:cprov only works on karmic
<poolie> "27 packages are included in this PPA for your system" -- i don't know what you mean by "for your system"
<noodles775> Yes, I forgot to include the note on the image that the text only display that if the user is using karmic.
<poolie> why not just delete that, it seems redundant with the list below
<noodles775> Hmm... for your Ubuntu 9.10 system.
<noodles775> True.
<poolie> i really like the notifications
<poolie> you may need to modify the changelog entries a bit to make them fit in there.
<noodles775> Great! (it was your input that created it ;) ).
<noodles775> Yes, perhaps truncated with a link... we'll have to see how it fits.
<noodles775> BTW: Thanks for all your input inte LP3-0 generally, looking at the list, you're becoming the main source of input :)
<poolie> ok, that conversion page makes sense and it looks like it fits what you're doing
<poolie> thanks, i hope it helps
<noodles775> It does indeed.
<poolie> it looks like it's going well
<poolie> so as i mentioned on the other thing
<poolie> i'm a bit concerned that two columns plus portlets will be unwieldy on the little netbooks kids use these days ;-)
<poolie> your mockup would probably scroll horizontally even on my fairly oldfashioned x series thinkpad
<noodles775> I'm not 100%, but I think YUI grid might even collapse the two columns into one when there is not enough space.
<poolie> oh, wow
<poolie> ok
<noodles775> I'm not sure, I just noticed that happening when I was playing with a different mock. We should try to ensure it does something sensible though.
<poolie> overly wide layouts was a big annoyance in lp 1.x
<poolie> probably before your time here
* wgrant has nearly forgotten was 0.0 was like.
<noodles775> yes, I wonder if it's worth a general email to lp-dev on the topic?
<noodles775> I'm *guessing* (as it was before my time) that they were table-based columns, which wouldn't fold.
* noodles775 checks yui grid examples.
<poolie> good night
<lifeless> ciao
<noodles775> Night poolie

VersionThreeDotO/Soyuz/PPAUI/Inputs (last edited 2009-08-06 08:16:10 by michael.nelson)