launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

Hi Brad.

I looked at the two proposals to (partially) address these issues:
* [Launchpad must state the project's official services]
   https://bugs.launchpad.net/launchpad-registry/+bug/597738

* [Encourage projects to configure the bug tracker]
   https://bugs.launchpad.net/bugs/70613

http://people.canonical.com/~bac/product-index-progress-2.png

        This is the most important of your proposals. I was initially
        inclined to do something like this because we could place the
        information high up on the page. I think this is a weak idea now
        that I can see it. You placed the setup portlet next to the
        Involvement portlet, and yet this small separation is enough to
        make it impossible for me to know how to enable the the
        Involvement portlet.
        
        We want the user to connect that configuring an app like the bug
        tracker can enable/disable the involvement portlet. It should be
        clear that other users cannot contribute to a project until this
        information is provided.
        
        Note that we want to show the configure links to anyone with
        permission to fix information. The portlet cannot be show just
        to owners; the permissions to set the project's development
        branch are broader than setting the bug tracker.

http://people.canonical.com/~bac/product-index.png

        I think this proposal has promise. There is some issue in that
        this portlet can be low on the page. We cannot control how many
        items are in the downloads portlet. Well, we can limit the
        number, or we could switch the positions of the two portlets. I
        think the issue here is how often do users need each portlet. I
        think Involvement is more important--Downloads is fundamentally
        broken [1]. Placing the Involvement portlet below the action
        portlet brings the configure actions closer to the global
        actions. Other objects place the Involvement links as the first
        item in the side portlets. We need a rule that clearly states
        the order of side portlet content.
        
        I think the progress bar will be more affective between the
        involvement links and the configurations links. We want the user
        to see what apps can be used, a indication that something is
        missing, and finally a way to provide the missing information.
        
        "Setup" conveys a one-time action, where as "Configure" conveys
        on-going control. We chose "Configure" in the links and URLs
        because we recognise these pages are often revisited after
        registration and setup. Maybe be can use a terse heading like
        "Configuration progress" above the progress bar.
        
        This mockup implies that we abandon the strike-thru presentation
        for unconfigured apps. I do not know why the unconfigured
        involvement links are missing or when the disappeared. Edwin
        used a strike-thru presentation to indicate something special
        about the action:
                /!\ -Report-a-bug-
        
        ProductInvolvementView.visible_disabled_link_names certainly
        needs fixing. As we are the owners of
        https://edge.launchpad.net/libxml2,
        we should be seeing links configure everything but branches. The
        view will only prompt for use to provide the project branch.
        Do we want to abandon visible_disabled_links?
        
        The double-icon is a bit odd. It is a inconsistent with how it
        is used in the distro pages to indicate that the upstream has or
        has not provided the information. In the distro pages, we state
        the kind of information, then show an ✖ for unknown or a ✔ for
        configured. Maybe?
                (/) Configure bug tracker ✖

[1] Downloads is fundamentally broken. Users want in order of
precedence: a distro archive, a PPA, a downloadable package, a
downloadable release, a branch. The ways users really want to get
software are not present. The Download portlet caters to distro
packagers and win/mac packages. It sucks to be an Ubuntu user. We cannot
decide of the portlet is for stable or development downloads, so the
user cannot trust what is listed. Maybe we should move the content of
the portlet into the main content where we can elaborate about what it
is? We need to replace +downloads with +get-software.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part