=== Ursinha is now known as Ursinha-afk [02:01] * sinzui kicks about the channel wondering if he is alone [02:02] hi [02:03] I am not alone! [02:03] anybody here for the Q&A session? [02:03] otherwise there seems to be a bad failure in buildbot [02:04] With thumper off, I do not think their are any launchpad-code hackers about at this time [02:04] right [02:05] cancel it? [02:05] But I hope that anyone who is watching launchpad change has a question that I can answer [02:05] postpone? [02:05] wait and see? [02:05] I am up at this time hacking on 3.0. I it is no bother to linger [02:05] michael and jono will not be attending. I have been talking the thumper every day about 3.0 [02:06] So I was hoping to practice answers with a small antipodean crowd [02:09] * sinzui kicks about the channel wondering if he is alone [02:14] looks like it [02:15] sinzui: You listed the wrong channel in #launchpad-dev. [02:15] I did where shoule I be [02:16] * sinzui looks at email [02:16] I interpreted the ' meeting' in '#launchpad meeting' as being a typo. [02:16] As in, a dupe word. [02:17] I see #launchpad-meeting [02:17] I will answer questions any where [02:18] wgrant: I did file about about the missing query information from the edge and lp.net pages [02:18] sinzui: I saw that; thanks. [02:19] wgrant: I merged two sections and wrongly guarded everything [02:19] where are the breadcrumbs going in UI 3.0? That wiki page still lives on wiki.c.c. [02:19] Between the branding/watermark/location/blah and app tabs? [02:20] We do need to move that. There is nothing secrete and a lot teams have not seen it since it is in a awkward place to go [02:20] The mockup that I have seen place the breadscrumbs under the wrongly named heading-slot [02:21] Which heading is heading-slot? [02:21] There are three that could be incorrectly called that. [02:21] yes. [02:21] * wgrant checks the template. [02:21] https://edge.launchpad.net/launchpad-registry [02:22] ^ There should be breadcrumbs under the Green

The Launchpad Registry [02:22] Under? That doesn't sound right. Won't that sometimes be 'Edit The Launchpad Registry'? [02:22] Or is that the odd grey heading which appears rarely? [02:23] If you were to view a form page The breadcumbs are in the same place, but the heading above it is demoted to a
[02:23] The form label becomes the
an is under the breadcrumbs [02:23] Ah, that makes sense. [02:24] Think of the three heading as 1) a watermark 2) a context heading and 3) the page title/heading [02:24] sinzui: Should the context and page headings be omitted if either is the same as the watermark? [02:24] 'cause they're not on the new pages, and it looks silly. [02:25] But this is still hard to engineer and review because both parties must know when to pass the page title/heading to the heading slot to prevent duplicate titles [02:25] Your question has not been settled. The answer is no, but I do not think anyone likes that answer [02:26] The case you point out is a pillar, person, or top-level colllection. [02:26] The project edit and index pages, for example, look pretty strange with the differently duplicated headings. [02:26] yes they are [02:26] But I suppose otherwise the descendant objects would have different numbers of headings for their edit forms. [02:27] To combine the watermark heading and the context heading requires some clever work because editable titles cannot be autocreated by the layout [02:28] wgrant: If we solve the editable title issue, I think we would consider dropping the context header [02:29] sinzui: Oh. I thought the watermark would get an inline edit link. But that idea formed in my mind before I realised how shallow that heading was. [02:29] Right [02:29] We will solve this, but I am not certain we will do it for 3.0 [02:30] We need to make the logo editable in the page and we need to communicate it is editable [02:30] We have an idea EdwinGrubbs will start work on in the next two weeks [02:31] Good, good. [02:31] The registry will loose its colur [02:31] Hm? [02:31] Answers will get a colour refinement [02:32] The reason is that blue and green mean links in Launchpad . [02:32] Ah. [02:32] I noticed that the Blueprint and Answers involvement link colours are too close to the background for my liking. [02:33] indeed that bug has not been filed. [02:33] The new project index view also exposes the wrong release for download. [02:34] The set answer contact page is very confusing because it is just links and headings-- blue ans blue on white. [02:34] really? [02:34] Yes. [02:34] It was showing bzr 1.18rc1 until today. [02:34] That comes from a query that was considered proven [02:34] But that's a flaw in the data model :( [02:34] The rdf link is a problem [02:35] I think it needs to die. [02:35] Or go down the bottom [02:35] Or just generally hide. [02:36] I argue that we move into the information portlet since the info is an alternate of the portlet info [02:36] poolie and I discussed dropping RDF. [02:36] It certainly doesn't belong in the Downloads portlet. [02:37] And it causes it to show up on projects where it makes no sense. [02:37] I was strongly inclined to do it since the FOAD and DOAP is useless from my inspection [02:37] I found that there are a minority of users who are using it [02:37] If people know what FOAF and DOAP are, they can probably find an obscure link. [02:37] s/FOAD/FOAF/ [02:37] FOAF was useful once upon a time. [02:38] And I think REVU might still use it. [02:38] My fallback proposal was to add a meta instruction to the page to indicate there is an RDF alternate for the page [02:40] We need help converting blueprints [02:41] It is assigned to the registry team, but my team already has 3 times more templates than other teams [02:41] I considered working on some Blueprint stuff. But, well, I think Blueprint needs to go away and be subsumed into Bugs. [02:41] I am told that that is unlikely [02:41] Damn. [02:42] I think the next best thing is to give them feature parity so that the similarities make the argument more compelling [02:42] * thumper reads scrollback [02:42] I am sure blueprints would be more successful if it's statues, events, and email were like bugs [02:43] Blueprint and Bugs each have sets of unique features, all of which would be useful for the other. [02:43] No one has brought up the NavigationalMenus, the bane of every developer's existence [02:43] Are NavigationMenus those grey-turned-black things that lurk at the top of the old pages? [02:44] There is a request to create a small task/todo application. It is assigned to the registry for evaluation [02:44] YES they are [02:44] There are many names for them. [02:45] And they are very confusing and easy to miss. [02:45] It takes ages to work out how to alter a person's OpenPGP keys. [02:45] Looking at the designs we (me) assumed they would go away, a failed 2.0 experiment [02:45] * thumper never like the navigational menus in the first place [02:46] mpt did. beuno announced they were going away on the day he took over the UI [02:46] sinzui: To what level should I be filing bugs on new UI bugs? [02:47] eg. the unconditional "padding-bottom: 0.3em" on 3.0
s, which makes the actions portlet too tall. [02:47] We are being pretty details. I have bugs for each portlet I am working on [02:48] Engineers started speaking up on the CSS this week. I think we have all seen enough to know what does not work [02:48] The
elements were updated today I think [02:48] We should have bugs on these issues. [02:49] There was an accidental reuse of of the summary class that makes search results look very large [02:50] wgrant: when I change a detail, I search the bugs to see if I can fix something else at the same time [02:50] The same thing happens on ArchiveActivateView when there are existing PPAs. [02:50] The registry had 50 UI bugs when this started. I think we should try to solve all of them [02:51] was that converted? [02:51] It was. [02:51] damn [02:51] But the view it uses to list the PPAs wasn't. [02:51] Yet. [02:51] It's the same listing view that's used on the person index, so it should be fixed when that goes 3.0. [02:52] I can adjust the CSS rules. I think this also relates to the overlap of object attributes [02:52] title and displayname, summary and description and homepage [02:53] Oh, also, the project summary looks far too fat here. [02:53] Am I the only one who thinks this? [02:54] I am uncertain. [02:54] I think the issue is how much info was put in it [02:55] The description of the summary is lacking, and I'm not sure if any existing projects do it properly. [02:55] Actually, launchpad-project's works very well. [02:55] I agree [02:56] launchpad-registry... not so much. [02:56] I have been meaning to rewrite the registry [02:56] It was given to me. I like Ed' RDF work, but the registry is not really about that [02:57] Maybe it was initially. [02:57] yes there are foaf and doap directories in the tree still [02:57] Huh. I thought those were removed ages ago. [02:57] after 3.0 I think we can rename some directories [02:58] We are stilling find tests and templates in the wrong place. The effort to update everything is making us clean up a lot [02:58] I've seen a lot of stuff in canonical.launchpad that should really be moved out to the app packages. :( [02:58] yep [02:59] That is officially the foundations team, they have had other priorities over the past year [02:59] thumper and I started moving items there because it is frankly easier to find [03:00] Mmm. It has definitely made it rather harder to find, but that's just because everything is spread around horribly. [03:00] everything in canonical/launchpad/webapp should become canoncial/lazr The code is too intermixed to separate it easily [03:01] webapp/tales is getting lot of work. We should try to move that soon. Maybe give up on lazr and move it to lp/app [03:02] There are a lot of old tests or unowned code that needs sorting out in c.l [03:03] I think structural subscriptions should become the registry's domain [03:03] * sinzui would like to take sprints form blueprints too [03:03] They should. [03:03] Shouldn't c.l.webapp.tales be cut into lots of pieces and thrown into different apps, rather than all going into lp.app? [03:03] I am adding links to create sprints from the series pages [03:04] wgrant: yes it should [03:04] absolutely. [03:04] wgrant: I did the first yesterday [03:04] sinzui: I don't think it's a good idea to link to sprints before they're improved. [03:05] There are some ancient tests (canonical/launchapd/doc/menu.txt comes to mind) that can be dismantled because they duplicate other tests [03:05] wgrant: yes, I would commit to fixing them when I move them [03:06] I do not think the need to be dependent on blueprints. There are date and report issue that need fixing [03:06] Why has the bounty tracker not been purged completely like the calendars were years ago? [03:07] Or is it meant to maybe be revived at some point? [03:07] there was some thought about resurrecting it. [03:07] well that thought certainly died before 2.0 [03:08] We are driven to work on business priories. while 20% of our time should be spent one clean up the code and tree, I do not think it is being done my every engineer [03:09] It would have been cleaned up if it was a specific team or person's responsability [03:09] It is going to be removed either by the registry team or the soyuz team because we have bounty templates we are obligated to remove [03:10] Ah. [03:11] I do not have access to the script that generates the progress report === matsubara is now known as matsubara-afk [03:11] It shows the templates that need converting [03:11] The one on devpad run by mars? [03:12] yes [03:12] there is a branch for it [03:12] That would be nice [03:12] We can push the static ajax data and the output file to a public location === danilo-afk is now known as danilos === Ursinha-afk is now known as Ursinha === matsubara-afk is now known as matsubara === mrevell is now known as mrevell-lunch === salgado-afk is now known as salgado === mrevell-lunch is now known as mrevell [15:00] Do I dare start a meeting [15:01] * beuno cheers [15:01] Well [15:01] time to start [15:02] #startmeeting [15:02] Meeting started at 09:02. The chair is sinzui. [15:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:02] me [15:02] Let's try a rollcall just so I know how many people are listening [15:03] ha [15:03] I'm here to learn from any discussions too! [15:03] me [15:03] me [15:03] me [15:04] I seem to have missed jtv in both sessions [15:04] okay. we can start. [15:05] Does anyone have a question about UI 3.0 [15:05] I will ask a question then [15:06] * bigjools raises hand [15:06] beuno: The registration information should appear in the header. bug should it appear all the time? I am certain it should appear for an index of a context object, but what about a alternate view of it? [15:07] s/bug/But/ [15:07] sinzui, I think only on the overview [15:07] it's not that important [15:08] beuno: when I look at the mirror listing for a distro, should I see then the distro's registration info [15:08] beuno: it is for some tests, but only on the index [15:08] this sort of thing breaks down a bit on the packaging pages [15:08] so there's your answer [15:08] "only on the index" [15:09] That is easier to do. I can provide both automatic rules and a slot to override it [15:09] * sinzui worries about every page. [15:09] thanks beuno [15:09] bigjools: you have a question? [15:10] is there a general plan to deal with the type of objects that have no narrative to show under the title? [15:10] I do not think so [15:11] rockstar: has a similar issue with answers, where the narrative should not be separated from the comments, so the details is first [15:11] in a page I was doing mechanical changes to, the distroarchseries index, there's no narrative, and I need to go straight into a two column grid [15:12] That can happen with milestones and releases too [15:12] bigjools: their narrative is optional, so the design must DTRT [15:12] what is DTRT in this case? [15:13] beuno: Have you seen a design that we can use to implement without thinks for objects we are not redesigning? [15:13] yeah, that'd be nice, since I have a few pages that have details portlets that I need to move inline somewhere [15:14] bigjools: I do not know. I think the infrastructure or design rules should be clear enough that I do not need to think [15:14] bigjools: that is exactly the problem that rockstar encountered [15:14] bigjools: is this issue blocking DSP? [15:15] not really, I think we've settled on that now [15:15] because we found a sentence to start the page with? [15:15] * beuno reads the scrollback [15:15] sort of, I gave it a "This package has XXX new bugs and XXX open questions" [15:16] could I see a screenshot or a page of this? [15:16] I'm not sure I fully understand it [15:16] I ponder what this means about these kids of artefacts. Do we consider them self-explanatory? [15:16] have a look at https://edge.launchpad.net/ubuntu/jaunty/i386 and tell me how you would redesign it [15:17] bigjools: distroarchseries is the i386 details of karmic? [15:17] beuno: you've already seen that DSP page quite a few times :) [15:17] sinzui: it exists to be able to do binary package searches for that architecture [15:18] but it doubles as an index I guess [15:18] does it really need it's own page then (I know you do not want to invest a lot of time) [15:18] exactly, this was supposed to be a simple mechanical change :) [15:18] bigjools, I think that moving the information beneath the search box is TRTTD [15:18] * sinzui merge milestones and releases to reduce duplication [15:19] beuno: yeah, I have it to the right at the moment, it doesn't look quite right [15:19] it also has a separate template for +search that is 95% the same as +index, so I merged them [15:20] bigjools, it sounds like we need a better answer for moving that type of portlet into the content rather than the description-less issue [15:21] I onlt mentioned the description-less stuff because curtis said it looked weird on the DSP page :) [15:21] but yeah, this is another issue to work out [15:22] I don't think the lack of description in itself is a problem [15:22] the question was whether it was good or not to put a two-column portlet arrangement immediately below the title [15:23] not in this case [15:25] So do we want to set this as an action item to define a no-think-required way to handle narrativeless pages? [15:25] that means more work for me, so I'm not 100% sure of it [15:26] heh [15:26] but I will work with someone to figure out a pattern :) [15:26] I think the issue is that a page cannot start with two columns, so we must always have a piece of content that can be used as a top-portlet [15:26] so I think what I did on the DSP was fine [15:26] even w/o the extra text I added [15:28] we could do with some styling to bottom pad the
in the main content though, it butts up too close to the rest of the content [15:28] bigjools: by making the search the first content and it span all main, does this create a second problem? That the arch information is now spanning two columns and it creates unwanted whitespace? [15:28] maybe it doesn't need 2 columns? [15:28] sinzui: I've not tried that layout yet, I started with a two column arrangment to see how it looked [15:29] bigjools, I think that there's no padding because breadcrumbs are coming, and they will have it [15:29] coolio [15:29] 2 columns is optional, never required [15:29] the other thing is that I know beuno will hassle me for just moving the details portlet inline as it doesn't look that good [15:29] I believe that many listing/collection pages will never use 2 columns [15:29] I like being predictable [15:30] which means making it a 2-column
I guess [15:30] I have a question too - has anyone opened a bug for the watermark heading (h1/h2) issues that we've always known about, but not yet had time to fix? (ie. https://edge.launchpad.net/ubuntu/+search) [15:30] bigjools: I expect the details/info to be in the upper left of every page. [15:30] sinzui: that would displace the search form [15:30] * sinzui does not want to search the page for that information [15:31] bigjools: I ti not the first item on any approved design [15:31] I think search forms should always be at the top [15:31] bigjools: it is the second [15:31] for example, the search form on the distro index page mockup was in the wrong place for me [15:32] bigjools: the general rule of pages (on the whole WWW) is first state what the page is about, then provide some details. then provide things that you can do [15:32] bigjools: It has not been approves [15:32] bigjools: It has not been approved [15:33] bigjools: we will discuss that design today. The issue is not just the importance of the field, but the links that relate to it [15:34] ok [15:34] bigjools: if we do not place content is a consistent manner, users will report a bug. [15:34] so beuno said above that on my DAS page the search should come ahead of the details [15:34] bigjools: so if we try to make an exception, we should be prepared to unmake it if users point out the issue [15:35] well, because I feel that those aren't really details, as the title really asys it all [15:35] says, even [15:35] and I say the detail comes after it like the pillar pages [15:35] indeed [15:36] oh I should also mention that the search results come at the bottom of the page now [15:36] since I removed the ridiculous second +search template that was 95% similar [15:36] so that's another reason to place the info beneath the search feild [15:36] so you don't move it around on the page when searching [15:37] it won't...? [15:37] you'd just have: [15:37] ______________ SEARCH [15:37] the details is also below the search results [15:37] [info] [15:37] [results] [15:37] no, I think the details should go when you search [15:37] argh [15:37] :) [15:38] * sinzui this thinks is the same as when a project puts 8 paragraphs of homepage content, pushing project details below the fold. [15:38] so much for "no-think" changes :) [15:38] this is why I put the info on the right! [15:38] well, there always some thinking, otherwise sinzui would just write a script that did all the work [15:39] lol [15:40] I assume that someone has read the details before searching. Once the user has searched, the results are the most important [15:40] I think search, results, details is the best order in the circumstance [15:41] or in a side portlet... [15:41] * bigjools hides [15:41] * sinzui gets nightvision goggles [15:41] lol [15:42] bigjools: are you concerned that the details are below the fold after a user has searched? [15:42] details are clutter and distraction in a search results page [15:42] beuno: that is my point [15:42] below the fold is fine with me [15:42] we know the user is only going to look at the results [15:43] bigjools, it can't be that hard to only how the details if there's no results [15:43] beuno: yeah easy to fix [15:43] good, then it's done! [15:44] it just goes to show there's no such thing as a mechanical change, even on the most trivial of pages [15:44] look at the damn thing... [15:44] it's gone a search form and a details portlet FFS :) [15:45] We have discovered a rule that collections can place alternate links to lists in the side portlets. /people and /project will use this [15:45] and /projectgroups /distros /sprints [15:46] beuno: Question listing and bug lists also have alternate views of the list. can they be in the side portlets too? [15:46] to refine: beuno suggested no info icon and a very simple word for the links (e.g. People) [15:46] sinzui, I think intellectronica has listed them as such in his mockup, yes [15:47] he did [15:47] I suggest to bac to move them inline for the mirror listing pages. he may want to reconsider [15:47] * sinzui thinks the two links looked better inline [15:48] yeah, they do look good in-line [15:48] beuno: the +global-action view that makes the side portlet links never generates a header because it si always first. [15:49] beuno: since there can be two portlets of links, should we have an alternate layout that add the menu title? [15:50] sinzui: in the examples i've done, i don't think a menu title would be useful [15:51] sinzui, if things are clearly grouped by actions and links [15:51] I don't think a heading is needed [15:52] I am happy to not make an new named view [15:53] beuno: is there are rule for the use of "view" and "show" in link text? [15:53] "View" takes you away, "show" is inline/ajax [15:54] sinzui, I wouldn't use them unless they're part of a phrase [15:54] I think the color of the links should be the ones that tip you off what it's going to do [15:54] The use of view and show see arbitrary [15:54] although I agree that "show" should only be used for inline actions [15:56] We prefer "register" over "create" since in may cases, launchpad is modeling what has happen in the real world. [15:56] Are you registering a milestone or creating it? [15:57] for projects this semantic difference many imply placeholder versues hosted projects [15:57] true [15:58] I think my brain is telling me that I want to create a milestone [15:58] but I think you're right that we model reality rather than crate it [15:58] beuno: I bring this up because we are doing a lot of menu reporganisation. a link might uses a different term in two different menus. [15:59] sinzui, yes, it's grat that you do [15:59] * sinzui needs to pick a term and update the old tests [15:59] sinzui, I think I'd use create, as it's clearer for users [16:00] and, not use "view" in a link ever, and only "show" if you need to for inline displaying [16:00] "create" something in LP, "register" something external, like a mirror [16:01] "register" sort of feels "sign up"-ish to me [16:01] beuno: but "view" is the action in all th top-level listings? [16:01] sinzui, not after I worked on it with barry :) [16:03] We have talked for an hour [16:03] If no one has any further questions, I will close this meeting [16:03] We can always talk on #launchpad-dev [16:04] sinzui: just the one I asked before... [16:04] I have a question too - has anyone opened a bug for the watermark heading (h1/h2) issues that we've always known about, but not yet had time to fix? (ie. https://edge.launchpad.net/ubuntu/+search) [16:04] noodles775: I do not know about a bug [16:05] I think we should report one so that someone can fix it [16:05] sinzui: yep, doing so now. [16:05] I need to report a bug about adjusting the CSS so that .summary is not giant in all cases [16:07] thank you everyone for participating [16:07] #endmeeting [16:07] Meeting finished at 10:07. [16:07] thanks for hosting this sinzui! [16:07] * deryck lurked but found it useful. [16:07] thanks sinzui [16:07] cheers sinzui [16:09] Also, beuno, sinzui, can we discuss the question beuno had about https://edge.launchpad.net/ubuntu/+ppas [16:09] I think cprov landed that with your approval sinzui, but beuno is uncertain about the second (default context.title) heading, which is the same as the root-context heading in the watermark. [16:10] Thanks sinzui ! [16:11] I think cprov followed the rules. I agree it looks wrong [16:12] sinzui: so, we should in that case fill the heading slot with the
Ubuntu Personal Package Archives
right? [16:12] This is why I stopped working on the heading. The rules seem arbitrary. I cannot explain the rules, so I am not qualified to hack on them [16:13] Only when we are looking the context's index page do we override the heading-slot [16:15] I expect to see a lot of this when the many team views are updated [16:15] yeah it makes no sense on +ppas === Chex_ is now known as Chex [16:15] I do not think we should be talking about this There should be a rule in the code and it DTRT [16:16] I do not know how to write the rule. thinking about is was very frustrating [16:16] yes, that would be ideal - but to create that rule we have to talk about it. Yes, I can imagine it was frustrating. [16:16] I decided I need to work on my team's pages [16:16] Yep. [16:17] Maybe an exception to the above rule could be: except when you are on a view of the root-context? (although it seems unnecessarily complex) [16:17] Deep in my heart, I think this design is flawed. I was very sad when I had to add that slot. It was such a F'up in the 1.0 design [16:18] I will not be surprised if 4.0 removes it again [16:18] Yeah, that's not fun. [16:19] I'll have a think about it and maybe run something by you on monday. [16:19] noodles775: now that we have a new way if identifying the watermark, maybe we can have the context-slot never render if the context is also IPrimaryContext [16:20] sinzui: but, just in case you know it yourself, everyone thinks you've done an amazing job coordinating this effort! [16:20] sinzui: yeah, that's a great idea! (As there's no need for breadcrumbs - is that right?) [16:20] my self-esteem is directly proportional to the number of branches I land [16:20] well [16:20] heh... you sound like cprov ;) [16:21] I think that is still the rul [16:21] e [16:21] * sinzui finds beuno to ask === salgado is now known as salgado-lunch === matsubara is now known as matsubara-lunch === gary_poster is now known as gary-lunch === matsubara-lunch is now known as matsubara === gary-lunch is now known as gary_poster === salgado is now known as salgado-brb === salgado-brb is now known as salgado === salgado is now known as salgado-afk === matsubara is now known as matsubara-afk