=== ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad-meeting === SteveA [n=steve@195.182.78.95] has joined #launchpad-meeting === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad-meeting === jamesh [n=james@81.16.227.227] has joined #launchpad-meeting [10:33] hi [10:33] welcome to vilnius, jamesh [10:34] how was your vacation BjornT ? [10:34] it was fine, thanks, very relaxing [10:34] hi [10:35] I was thinking that you guys could work together for a few days, looking at how forms and maybe widgets work [10:36] we've got a bunch of problems with the forms in launchpad [10:36] like, they're tricky to use [10:36] we have three varieties of forms that work differently [10:36] like tab-browsing them send you mad [10:36] and indeed, tab browsing [10:36] hi ddaa. did you get back okay on the train? [10:37] absolutely, it was only a very mild hangover compared to what I usually get at the end of sprints/conferences :) [10:37] that sounds good. it'd be nice start using zope.formlib for our forms. [10:38] there was also a discussion I had with a bunch of zope3 people (jim, faassen, philikon) at europython [10:38] about improving formlib [10:38] i'll send a mail to gary today to see where he's at with his widget work, it'd be nice starting to use them as well, since it's hard to improve the current widgets [10:38] that we should write notes on and take into account [10:40] ok [10:40] the three of us should meet up, and work out what specific things to do this week [10:40] ok. gary mention he would do some changes to formlib as well, but maybe jim was aware of the changes? [10:40] first by sketching out a bunch of ideas of what we could do, and things that need improving [10:41] then deciding on which ones to tackle [10:41] the EP discussion was only a little about formlib [10:41] it was more about improving how we do view classes and link them with templates [10:41] but included discussion of how to link this with use of formlib [10:42] ok [10:43] how about we meet for lunch in a while [10:43] and then go to my place to sketch things out around a whiteboard? [10:43] we should also look through the form-related bugs we have outstanding on launchpad [10:44] perhaps tag them with a keyword [10:44] sounds good, i'm already starting to get hungry, so anytime (an hour from now) is fine by me [10:44] okay === SteveA checks a weather report [10:45] possible showers over the next hour [10:46] then fine for the rest of the day [10:46] james is in the e-guesthouse on evenkos g. [10:48] BjornT: you'll be driving, so how about you pick up james from there at 1pm or so [10:48] and then park near my place, and we'll walk together into old town? [10:49] SteveA: sure [10:50] So I'll wait downstairs at 1pm then [10:50] ok. I will now go put some laundry on, so I'll have clothes to wear tomorrow. [10:52] cool === mpt_ [n=mpt@203.118.156.188] has joined #launchpad-meeting [10:59] hi mpt [11:05] hi jamesh [11:07] so, what issues would you say are most important to address from a UI perspective? === sivang [i=sivan@ubuntu/member/sivang] has joined #launchpad-meeting === mpt [n=mpt@203.118.156.188] has joined #launchpad-meeting [11:15] mpt: irssi :-) [11:29] So, forms [11:29] I guess the biggest problems involving forms are [11:30] 1. the tab-cycle bug [11:31] 2. validation feedback is very poor - often errors don't explain the problem, suggesting that maybe it's not easy enough to say to Zope "this is the kind of data I want in this field" [11:32] 3. validation only ever happens after you've submitted the form, not before (e.g. impossible characters aren't ignored when you type them) [11:35] 4. No easy construction of dependent controls -- e.g. when you arrive at the Blueprint front page an obvious thing to do is to register a specificaiton, but sabdfl rejected the bug solely because there isn't an easy way to create a form with different branches for product/distribution [11:35] I guess 2 and 3 are related. [11:37] 5. The layout is crummy, especially for checkboxes [11:38] (3) and (4) seem to call for a way to easily inject JS code into the form [11:38] we've got a few forms that add JS in different ways already, so it would be nice to have a standard way to do it [11:41] yes [11:42] I saw a nice demo of doing that in London [11:42] using some ajax stuff to do dynamic form validation using the server [11:44] I guess Ajax would be the last 10% of the benefit and the last 50% of the effort, e.g. "That ID is already taken" [11:46] But most of it would need JS only, e.g. missing required fields, no letters in numeric fields [11:46] and that would need to be auto-generated because you'd have to be doing equivalent validation on the server anyway, since you can't trust the client === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad-meeting [11:52] so the server-side and client-side validation would need to be kept reliably in sync. [11:58] well [11:59] I'm not so sure about your estimates of effort [11:59] the thing with doing full ajax validation is that there is just one set of validation code [11:59] on the server [11:59] and no need to translate it into javascript at all [11:59] if we were programming launchpad entirely in JS, that would be a different matter [12:02] hmmm, that would be one possibility [12:02] though it would result in a lot of extra network traffic [12:03] and would work in fewer browsers [12:05] perhaps not a *lot* [12:05] I'd leave that estimate up to an analysis rather than a gut feeling [12:08] Well, the amount of network traffic would be inversely proportional to how quickly you were correcting/preventing errors [12:08] For example, take the rule that you're not allowed to use spaces in "Name" fields [12:09] directly proportional, rather [12:09] also... network traffic is not all that useful a measure for us [12:09] latency overall is [12:09] If you check after each character to see whether it's allowed, that's going to be really slow [12:09] If you check once I leave the field, that'll be much more practical, but also a bit more annoying [12:10] you check every N seconds if there was a change in data between now and the last check [12:10] if you check when I'm about to submit the form, that's only one transmission for the whole form, but it's more annoying still [12:12] also, using ajax will likely have a good effect on the overall application's performance [12:12] because the validation requests would be GETs, and never lock tables [12:13] whereas the actual POSTs to post form data will be POSTs and often lock tables [12:13] having many gets and one POST (lots of attempts, corrected by ajax, followed by a successful form submission) [12:13] is better for us than a few POSTs [12:13] per one form post in the workflow === sivang wonders how would that be tested, to make sure ajax validation is doing the right thing. [12:14] you'd test the validation logic just like we test any other page of launchpad [12:15] then there would be some standard lightweight stuff to do the ajax request that either is not tested or is tested using a selenium test [12:15] ah, I see [12:15] First sodium, now selenium [12:15] heh === mpt [n=mpt@203.118.156.188] has left #launchpad-meeting ["http://mpt.net.nz/"]