[10:33] <SteveA> hi
[10:33] <SteveA> welcome to vilnius, jamesh 
[10:34] <SteveA> how was your vacation BjornT ?
[10:34] <BjornT> it was fine, thanks, very relaxing
[10:34] <jamesh> hi
[10:35] <SteveA> I was thinking that you guys could work together for a few days, looking at how forms and maybe widgets work
[10:36] <SteveA> we've got a bunch of problems with the forms in launchpad
[10:36] <SteveA> like, they're tricky to use
[10:36] <SteveA> we have three varieties of forms that work differently
[10:36] <ddaa> like tab-browsing them send you mad
[10:36] <SteveA> and indeed, tab browsing
[10:36] <SteveA> hi ddaa.  did you get back okay on the train?
[10:37] <ddaa> absolutely, it was only a very mild hangover compared to what I usually get at the end of sprints/conferences :)
[10:37] <BjornT> that sounds good. it'd be nice start using zope.formlib for our forms.
[10:38] <SteveA> there was also a discussion I had with a bunch of zope3 people (jim, faassen, philikon) at europython
[10:38] <SteveA> about improving formlib
[10:38] <BjornT> 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] <SteveA> that we should write notes on and take into account
[10:40] <SteveA> ok
[10:40] <SteveA> the three of us should meet up, and work out what specific things to do this week
[10:40] <BjornT> ok. gary mention he would do some changes to formlib as well, but maybe jim was aware of the changes?
[10:40] <SteveA> first by sketching out a bunch of ideas of what we could do, and things that need improving
[10:41] <SteveA> then deciding on which ones to tackle
[10:41] <SteveA> the EP discussion was only a little about formlib
[10:41] <SteveA> it was more about improving how we do view classes and link them with templates
[10:41] <SteveA> but included discussion of how to link this with use of formlib
[10:42] <BjornT> ok
[10:43] <SteveA> how about we meet for lunch in a while
[10:43] <SteveA> and then go to my place to sketch things out around a whiteboard?
[10:43] <SteveA> we should also look through the form-related bugs we have outstanding on launchpad
[10:44] <SteveA> perhaps tag them with a keyword
[10:44] <BjornT> sounds good, i'm already starting to get hungry, so anytime (an hour from now) is fine by me
[10:44] <jamesh> okay
[10:45] <SteveA> possible showers over the next hour
[10:46] <SteveA> then fine for the rest of the day
[10:46] <SteveA> james is in the e-guesthouse on evenkos g.
[10:48] <SteveA> BjornT: you'll be driving, so how about you pick up james from there at 1pm or so
[10:48] <SteveA> and then park near my place, and we'll walk together into old town?
[10:49] <BjornT> SteveA: sure
[10:50] <jamesh> So I'll wait downstairs at 1pm then
[10:50] <SteveA> ok.  I will now go put some laundry on, so I'll have clothes to wear tomorrow.
[10:52] <BjornT> cool
[10:59] <jamesh> hi mpt
[11:05] <mpt_> hi jamesh 
[11:07] <jamesh> so, what issues would you say are most important to address from a UI perspective?
[11:15] <SteveA> mpt: irssi :-)
[11:29] <mpt> So, forms
[11:29] <mpt> I guess the biggest problems involving forms are
[11:30] <mpt> 1. the tab-cycle bug
[11:31] <mpt> 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] <mpt> 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] <mpt> 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] <mpt> I guess 2 and 3 are related.
[11:37] <mpt> 5. The layout is crummy, especially for checkboxes
[11:38] <jamesh> (3) and (4) seem to call for a way to easily inject JS code into the form
[11:38] <jamesh> 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] <mpt> yes
[11:42] <SteveA> I saw a nice demo of doing that in London
[11:42] <SteveA> using some ajax stuff to do dynamic form validation using the server
[11:44] <mpt> 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] <mpt> But most of it would need JS only, e.g. missing required fields, no letters in numeric fields
[11:46] <mpt> 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
[11:52] <mpt> so the server-side and client-side validation would need to be kept reliably in sync.
[11:58] <SteveA> well
[11:59] <SteveA> I'm not so sure about your estimates of effort
[11:59] <SteveA> the thing with doing full ajax validation is that there is just one set of validation code
[11:59] <SteveA> on the server
[11:59] <SteveA> and no need to translate it into javascript at all
[11:59] <SteveA> if we were programming launchpad entirely in JS, that would be a different matter
[12:02] <mpt> hmmm, that would be one possibility
[12:02] <mpt> though it would result in a lot of extra network traffic
[12:03] <mpt> and would work in fewer browsers
[12:05] <SteveA> perhaps not a *lot*
[12:05] <SteveA> I'd leave that estimate up to an analysis rather than a gut feeling
[12:08] <mpt> Well, the amount of network traffic would be inversely proportional to how quickly you were correcting/preventing errors
[12:08] <mpt> For example, take the rule that you're not allowed to use spaces in "Name" fields
[12:09] <mpt> directly proportional, rather
[12:09] <SteveA> also... network traffic is not all that useful a measure for us
[12:09] <SteveA> latency overall is
[12:09] <mpt> If you check after each character to see whether it's allowed, that's going to be really slow
[12:09] <mpt> If you check once I leave the field, that'll be much more practical, but also a bit more annoying
[12:10] <SteveA> you check every N seconds if there was a change in data between now and the last check
[12:10] <mpt> 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] <SteveA> also, using ajax will likely have a good effect on the overall application's performance
[12:12] <SteveA> because the validation requests would be GETs, and never lock tables
[12:13] <SteveA> whereas the actual POSTs to post form data will be POSTs and often lock tables
[12:13] <SteveA> having many gets and one POST (lots of attempts, corrected by ajax, followed by a successful form submission)
[12:13] <SteveA> is better for us than a few POSTs
[12:13] <SteveA> per one form post in the workflow
[12:14] <SteveA> you'd test the validation logic just like we test any other page of launchpad
[12:15] <SteveA> 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] <sivang> ah, I see
[12:15] <mpt> First sodium, now selenium
[12:15] <sivang> heh