Merge lp:~jcsackett/launchpad/hidden-project-configuration-636000 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | j.c.sackett on 2010-10-28 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 11854 |
| Proposed branch: | lp:~jcsackett/launchpad/hidden-project-configuration-636000 |
| Merge into: | lp:launchpad |
| Diff against target: |
393 lines (+248/-31) 8 files modified
lib/lp/app/javascript/lp.js (+6/-0) lib/lp/registry/browser/product.py (+5/-0) lib/lp/registry/browser/tests/test_product.py (+33/-0) lib/lp/registry/javascript/team.js (+5/-5) lib/lp/registry/templates/pillar-involvement-portlet.pt (+52/-24) lib/lp/registry/templates/product-index.pt (+33/-0) lib/lp/registry/windmill/tests/test_product_configuration_hidden.py (+90/-0) lib/lp/testing/service_usage_helpers.py (+24/-2) |
| To merge this branch: | bzr merge lp:~jcsackett/launchpad/hidden-project-configuration-636000 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Henning Eggers (community) | ui | 2010-10-25 | Approve on 2010-10-27 |
| Leonard Richardson (community) | code | 2010-10-25 | Approve on 2010-10-26 |
|
Review via email:
|
|||
Commit Message
Wraps configuration links in the product involvement portlet with a collapsible that starts collapsed when all configuration steps have been taken.
Description of the Change
Summary
=======
As part of bridging-the-gap, a progress bar and other visual indicators were introduced to encourage users to fully configure their projects so we could get upstream data.
Now, when you finish configuring everything, you're still shown all the configuration links despite also being told that you're "done" configuring. To make this less visually irritating but still allow configuration to be changed easily on a fully configured product, this branch introduces a show/hide control around the configuration links. It defaults to showing if configuration isn't done, and hiding otherwise. It's largely borrowed from the show/hide of "Extra options" on other parts of Launchpad (e.g. merge proposals).
Proposed fix
============
Create show/hide control on the configuration links so you're not bothered with the links when you no longer need them, but can still access them.
Preimplementation talk
=======
Spoke with Curtis Hovey about branch goals. Spoke with Edwin Grubbs about setting up javascript in Launchpad and testing it.
Implementation details
=======
The product view has a new method that returns a boolean showing whether or not registration is done. This is used to set the classes on the block showing the configuration links.
A new javascript file, pillar.js, provides a way to set up div marked as collapsible in the same way collapsible fieldsets work in other places in the site. This uses the same toggle collapsible function to provide the actual functionality.
Tests
=====
bin/test -m lp.registry.
bin/test -m lp.registry.
Screenshots
===========
The section shown: http://
The section hidden: http://
QA
==
Open http://
Open http://
Lint
====
make lint output:
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
./lib/lp/
137: Line exceeds 78 characters.
The line that exceeds 78 characters isn't part of the diff, and is arguably most readable at its current length.
| Leonard Richardson (leonardr) wrote : | # |
Oh, you also copied some CSS--put that in the tech-debt bug as well.
| j.c.sackett (jcsackett) wrote : | # |
I'm only addressing part of the review in this comment--I'm investigating some things related to the other parts. In particular I may be able to remove the tech debt after all. Funny how things change when you look at code again.
> Wording suggestions:
>
> 1. s/"safe use this"/"safely use this"
> 2. In your explanatory text, you need to distinguish between the configuration links and the collapsible element that *contains* the configuration links.
>
> 2a. # When the Show link is clicked when it's open, it closes it.
> =>
> # When the collapsable element is open, clicking the Show link will close it.
>
> 2b. "Additionally, on a not fully configured project, it starts by showing
> the links, and can be closed."
>
> =>
>
> "On a not fully configured project, the collapsable element starts off
> open and displaying the configuration links, but it can be closed."
I've updated the comments.
> Questions that I defer to the UI reviewer:
>
> 1. Do you need that <br /> on line 270? If so, maybe it should also be conditional on view/configurat
I've killed the br. It was there b/c I thought the spacing looked a little off when I was cleaning this up for review, but on second thought I think it may be better without. So I suppose the new question for the UI reviewer is "do you have suggestions for spacing between the show/hide toggle and the actual links?"
> 2. "Configuration links" is a little vague and passive. Maybe "Configure this project" would be better wording?
I borrowed the passivity from other collapse toggles on the site. Most places we use it just show "Extra options" as the link (e.g. merge proposals). I'm not in love with the language at all. Suggestion from the UI review heartily encouraged.
| j.c.sackett (jcsackett) wrote : | # |
> The tech-debt bug: you copy a big chunk of code into activate_
So, in the clarity of a new day I realized that instead of all the complicated "what sort of node am I looking at" logic I was getting into I could just double check for a span with id=legend; throw in some of the structural changes I made to the HTML and the rest of the javascript nastiness was removed.
So now it's a few line change to the regular activate_
I think everyone can agree that's a good bit better.
> The question: I don't know if it makes sense to use waitForPageLoad when the page has already loaded. Is there a better way to wait for some Javascript to run? If so, please change this.
Turns out forElement can take classname selectors, not just element types. So that's the right kind of wait and the code has been updated.
| Henning Eggers (henninge) wrote : | # |
Thank you for this nice improvement and making Launchpad easier on the eyes ... ;-)
We chatted on IRC and came up with:
- Rename "Configuration links" to "Configuration options"
- Put a 0.5em margin under it.

After a lot of questions I've just got a tech-debt bug that needs filing, a question, and some wording suggestions. I also have some questions I'd like the UI reviewer to answer.
The tech-debt bug: you copy a big chunk of code into activate_ collapsible_ div. We talked about this on IRC and you explained that you'd tried refactoring, but changing the code to work on <div> instead of <fieldset> made it a huge pain. We agreed that you'd file a tech-debt bug and put an XXX in the code.
The question: I don't know if it makes sense to use waitForPageLoad when the page has already loaded. Is there a better way to wait for some Javascript to run? If so, please change this.
Wording suggestions:
1. s/"safe use this"/"safely use this"
2. In your explanatory text, you need to distinguish between the configuration links and the collapsible element that *contains* the configuration links.
2a. # When the Show link is clicked when it's open, it closes it.
=>
# When the collapsable element is open, clicking the Show link will close it.
2b. "Additionally, on a not fully configured project, it starts by showing
the links, and can be closed."
=>
"On a not fully configured project, the collapsable element starts off
open and displaying the configuration links, but it can be closed."
Questions that I defer to the UI reviewer:
1. Do you need that <br /> on line 270? If so, maybe it should also be conditional on view/configurat ion_links? A <br /> with nothing after it doesn't look good.
2. "Configuration links" is a little vague and passive. Maybe "Configure this project" would be better wording?