> > What happens for contexts that do not have an image:logo? > > ========================================================= > > See source package screenshot at: > > http://people.canonical.com/~michaeln/menu_3-0/2-DistroSourcepkg-with- > > disabled-tabs.png > > > > IDistributionSourcePackage does not provide IHasLogo, so passes up to > > the nearest object that does, which is the distribution. > > > > Note: in this specific case we actually want to update > > IDistributionSourcePackage to implement IHasLogo and use the logo of the > > upstream project - if it has one. > > I think that we should always have a default Logo, and a plan to eventually > show something meaningful there. Yes, the tales logo formatter does this - it will display a default logo if it cannot find one for the given traversal path (ie. in the above example, if IDistribution did not provide IHasLogo, then a default logo would be displayed. I'm not sure if you are saying that you'd prefer that the formatter didn't look up the traversal path (ie. if there is no logo for the IDistributionSourcePackage then it should just display the default logo, rather than looking to IDistribution first)? If so, then I think the wider implications of that change need to be considered (and I'd suggest it isn't part of this branch). And to eventually get something meaningful here shouldn't be difficult as once the logos are displayed so visibly it will be up to the responsible teams to add IHasLogo support. > > > > > Alignment of menu text when first tab is highlighted (Code)? > > ============================================================ > > > > The provided mockup has the text of the first tab aligned with the text > > of the heading above, but does not specify what should be aligned when > > the first tab is active (ie. still the text, or the border of the > > highlight?). > > > > As a last-minute decision, I've gone with aligning the text of the first > > tab when it is not active, and the margin/highlight when it is, as shown > > by the first two examples at: > > > > http://people.canonical.com/~michaeln/menu_3-0/4-alignment-of-first-tab.png > > > > The third example shows you the other alternative (aligning the text > > even when the first tab is active). Let me know what you'd prefer. > > I feel the third option is the best. Thank you so much for laying out my > options so well :) > No probs! I've pushed the change so the third option is used. > > > The location-portlet now becomes the top-portlet > > ================================================ > > > > I'm assuming from the mockup that the location portlet will always be > > the top portlet when it is present. That is, the first content below it > > should be separated with a thin gray line (ie. a normal portlet). > > > > If this is so, it'll mean updating the 3.0 design instructions as people > > can simply add class="portlet" to their first main-area portlet. > > I don't quite understand what you mean by "location portlet". OK, so perhaps another point should have been that I don't know how to refer to this block of heading+application/navigation/facet/tabs. I started refering to it as the "location portlet" mainly because that's what it turned out to be. But let me know if there's a better or more widely used term and I'll update any comments and variable names. So basically I was trying to say above that this new "header+tabs" section is really functioning as the top-portlet - that is, a block of content that should not have a horizontal line above it but should have a horizontal line below it (as shown in your mock). So I've done this by ensuring it is a div with class="top-portlet". Therefore any following content should just have the class="portlet". If this is the case, then we'll need to update the instructions people use, which currently say: {{{ * YUI-ify * If there is more than on block on the page: * First block is class="top-portlet" * All following blocks are class="portlet" }}} to instead simply say: {{{ * YUI-ify * each block of content should have a class="portlet" }}} > > > > Other unspecified design decisions > > ================================== > > > > Hover behaviour > > --------------- > > I've just used a lower-contrasting gray. See > > > > http://people.canonical.com/~michaeln/menu_3-0/1-DistroSearch-with-hover.png > > > > Another point (which I haven't got an image for, but you can see the > > behaviour if you merge the branch) is hovering over the current selected > > tab. > > Your instincts where right here. It's great as-is. Good. > > > > Disabled location tabs > > ---------------------- > > I've grayed them out as shown at: > > http://people.canonical.com/~michaeln/menu_3-0/2-DistroSourcepkg-with- > > disabled-tabs.png > > Again, the right thing to do. Good. > > > > edge/staging warning message > > ---------------------------- > > As I've only implemented the location header/nav, I have not moved it so > > it will still appear under the current 'breadcrumb'-like structure at > > the top of the page. > > I see you still haven't moved the breadcrumbs to beneath the title. No, Julian mentioned the other day that I was only to do the nav, not the breadcrumbs. But even if you do want me to do those, I'd still prefer to do them as a separate branch - if that's ok? > To be > honest, I don't know what to do with the edge notice, but I feel it's no > longer as important to know about in which instance you are. It could very > well be something that appears next to your name "Michael Nelson (edge server) > [logout]. Hmm... yes the edge/production difference isn't so important, but I would have thought staging needs to be really obvious? Oh yes, the big demo background would do it perfectly ;). So yep, I'll deal with that with the breadcrumbs branch (it's currently sitting right under the breadcrumbs where it always was). > > Do you plan to land this change for only a few pages, without the breadcrumbs? > This is what I see when I run it locally. This change will affect any page that uses the 3-0 templates (main_only, main_side, searchless, locationless.) So, I was wanting to check with Curtis, but I was planning on landing this change without updating any other templates (it just so happens that Curtis has already landed the searchless template changes such as the Distribution search that I used in the examples here and that you can see locally). I was under the impression (from Curtis' conversion page) that we cannot yet land any changes that update templates to 3-0? (see the section "There are some bugs that must be fixed before layouts changes can start" at the beginning of the page https://dev.launchpad.net/VersionThreeDotO/UI/Conversion) And yes, as above, I'd prefer to do the breadcrumbs in a separate branch if you want me to do them. > > > Thanks for jumping on this so quickly, you make it look easy :) No probs, it was fun!