fluid-work IRC Logs-2009-06-17

[07:55:15 EDT(-0400)] * heidi_ (n=thesumme@bas5-oshawa95-1176470261.dsl.bell.ca) has joined #fluid-work
[08:25:11 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:37:10 EDT(-0400)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[08:44:39 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[09:21:53 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[09:22:41 EDT(-0400)] * yura1 (n=yura@142.150.154.136) has joined #fluid-work
[09:26:47 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:36:15 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined #fluid-work
[09:42:26 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined #fluid-work
[09:54:09 EDT(-0400)] * clown (n=clown@142.150.154.121) has joined #fluid-work
[09:57:27 EDT(-0400)] * heidi__ (n=thesumme@bas5-oshawa95-1176458046.dsl.bell.ca) has joined #fluid-work
[10:15:34 EDT(-0400)] * yura1 (n=yura@142.150.154.101) has joined #fluid-work
[10:32:43 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[10:47:37 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[10:54:04 EDT(-0400)] * mackrauss (n=armin@142.150.154.101) has joined #fluid-work
[11:01:58 EDT(-0400)] * Bosmo1 (n=Bosmon@78-105-207-102.zone3.bethere.co.uk) has joined #fluid-work
[11:02:47 EDT(-0400)] <Bosmo1> I am pointing out to Justin, that unless there are dedicated controls for selecting exclusions in the build tool, then there is no sense to maintaining any of the state for the excludes
[11:02:51 EDT(-0400)] <Bosmo1> Since, logically there can be none
[11:03:07 EDT(-0400)] <Bosmo1> "If you want a simple subset of the problem to work on, the only subset that is there is the subset that doesn't handle excludes"
[11:04:05 EDT(-0400)] <Bosmo1> Colin is telling me to be very patient in explaining this
[11:04:43 EDT(-0400)] <Bosmo1> Notice there is a very clear distinction between things which are "not included", and things which have been "explicitly excluded"
[11:05:09 EDT(-0400)] <Bosmo1> The UI, in order to remain consistent, needs to, in the "include-directed" section of the UI, make sure that it is maintained as a set which is always closed under dependency
[11:05:39 EDT(-0400)] <Bosmo1> Otherwise users could very easily select a build which will simply not work, simply by unticking things
[11:06:01 EDT(-0400)] <Bosmo1> The "minimal requirements" for this are the ones we see in the mootools interface - although I am not sure they are the best ones
[11:06:26 EDT(-0400)] <Bosmo1> These minimal requirements are i) whenever anything is ticked, anything that it depends on is ticked, ii) whenever anything is unticked, anything which depends on it is unticked
[11:06:39 EDT(-0400)] <Bosmo1> This at least keeps the UI consistent, but it is still not easily reversible
[11:06:53 EDT(-0400)] <Bosmo1> And it is extremely bad to create a UI which does not present the user with a clear route to get back to a state that they were just in
[11:07:16 EDT(-0400)] <Bosmo1> There is a natural expectation that ticking something, followed by unticking it, will lead to something "at least very close to the previous state"
[11:07:48 EDT(-0400)] <Bosmo1> If you do not do this, they will curse you and heap jagged heaps of bricks upon your head
[11:08:19 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:08:49 EDT(-0400)] <colinclark> Bosmo1: This question of excludes is a good one, and it will involve some more design work.
[11:08:54 EDT(-0400)] <Bosmo1> Yes
[11:09:06 EDT(-0400)] <Bosmo1> Justin was keen to be able to start working with a possibly simplified version of the interface
[11:09:07 EDT(-0400)] <colinclark> Clearly excludes for Infusion doesn't work like the MooTools builder shows it.
[11:09:33 EDT(-0400)] <colinclark> We can clearly see that adding stuff, correcting stuff that was mistakenly added, and defining excludes are very different processes.
[11:09:35 EDT(-0400)] <Bosmo1> But I think it has to be argued, that the only simplified version, that is at all consistent, is one that doesn't handle "excludes" at all
[11:09:48 EDT(-0400)] <colinclark> I'm suggesting exactly that for now.
[11:09:51 EDT(-0400)] <Bosmo1> cool
[11:09:58 EDT(-0400)] <colinclark> Justin_o is focusing on a prototype to show at all-hands.
[11:10:13 EDT(-0400)] <colinclark> So, given that we really want some design thinking put into excludes, let's just side-step the issue for now.
[11:10:42 EDT(-0400)] <colinclark> Interestingly, excluding items is something 90% of our users will never do.
[11:11:04 EDT(-0400)] <Bosmo1> Yes
[11:11:12 EDT(-0400)] <colinclark> So let's focus on the biggest impact, which is additions. I actually imagine a separate stage of the Builder workflow for managing excludes, and this is one we can skim over for now.
[11:11:17 EDT(-0400)] <colinclark> Justin_o, Bosmo1: Seem reasonable?
[11:12:38 EDT(-0400)] <colinclark> Indeed, I suspect the whole approach of checkboxes that can be selected/deselected isn't quite right for our system.
[11:12:50 EDT(-0400)] <colinclark> In that, someone could select Reorderer and will have jQuery checked for them automatically.
[11:13:04 EDT(-0400)] <colinclark> If they uncheck jQuery, what will happen?
[11:13:39 EDT(-0400)] <Bosmo1> My suggestions were either i) two separate sets of checkboxes, one for includes and excludes, and ii) a 3-state system where they were merged into one row
[11:14:00 EDT(-0400)] <Justin_o> Bosmo1: what is your 3-state system
[11:14:13 EDT(-0400)] <Bosmo1> A row can be in one of three states
[11:14:28 EDT(-0400)] <Bosmo1> i) neither included nor excluded, ii) included but not excluded, iii) included AND excluded
[11:14:37 EDT(-0400)] <Bosmo1> Which could be shown in 3 different colours, perhaps
[11:14:56 EDT(-0400)] <Bosmo1> These are the only 3 states that make sense - it would be senseless to talk about excluding something that had not already been included
[11:15:19 EDT(-0400)] <Bosmo1> Anyway, I thought we were on the trail of a simple demonstration system
[11:15:24 EDT(-0400)] <Bosmo1>
[11:15:29 EDT(-0400)] <Justin_o> Bosmo1: i think it may make sense to define that as 1) included, 2) not included 3) excluded
[11:15:51 EDT(-0400)] <Bosmo1> Justin_o: No, talking about "excluded" in isolation is not sensible
[11:16:16 EDT(-0400)] <Bosmo1> And probably misleading
[11:16:17 EDT(-0400)] <Bosmo1>
[11:16:40 EDT(-0400)] <Bosmo1> And I ordered them in the way I did, to appeal to their "likely workflow"....
[11:16:56 EDT(-0400)] <Justin_o> yes... so for simplification
[11:17:04 EDT(-0400)] <Bosmo1> In the beginning, every item starts off in "state 0" - neither included nor excluded..... by ticking them, you can bring them into "state 1" - included
[11:17:20 EDT(-0400)] <Bosmo1> Only after ticking them, does the control appear, which might move them into "state 2" - included but then excluded
[11:17:37 EDT(-0400)] <Justin_o> I could start by building it with only the includes considered
[11:17:46 EDT(-0400)] <Bosmo1> Yes
[11:17:48 EDT(-0400)] <Bosmo1> That is the best option
[11:18:01 EDT(-0400)] <Justin_o> the only draw back would be that if you select "reorderer" but not "jQuery" you'll still get "jQuery"
[11:18:03 EDT(-0400)] <Bosmo1> It is all that any other framework has done, in any case
[11:18:12 EDT(-0400)] <Bosmo1> That is not a drawback
[11:18:19 EDT(-0400)] <Bosmo1> It means that the build file that is created actually works
[11:18:35 EDT(-0400)] <Bosmo1> We have to bear in mind that our user base that wants "excludes" is a highly specialised one
[11:18:43 EDT(-0400)] <Justin_o> right... i agree
[11:19:05 EDT(-0400)] <Bosmo1> We may even hide all of this "excludes" functionality behind some kind of "Advanced" tab
[11:19:10 EDT(-0400)] <Justin_o> i think we need to facilitate it... but we can worry about it later... i think colinclark is right.. in that our current workflow/design doesn't seem to work
[11:19:25 EDT(-0400)] <Bosmo1> Since it will be all to easy for users to come along to the site, tick a bunch of stuff, and then construct a build which actually doesn't work
[11:19:50 EDT(-0400)] <Justin_o> Bosmo1: exactly, which is fine if that's what they want, but as you said most won't
[11:20:05 EDT(-0400)] <Bosmo1> The "default expectation" behind the mind of the "default user" is that they will be given builds that work
[11:20:49 EDT(-0400)] <colinclark> +1
[11:21:26 EDT(-0400)] <Justin_o> thanks guys
[11:44:00 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[12:49:15 EDT(-0400)] * mackrauss (n=armin@142.150.154.101) has joined #fluid-work
[12:51:49 EDT(-0400)] <clown> Bosmo1: FYI on "undefined" in C: the header math.h defines functions/macros for handling things like NaN, pos/neg infinity, and such like. I no longer accept the claim that "this is C, we can't deal with that". In fact, I now find it hard to believe that any modern language can't deal with those concepts.
[14:04:32 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[14:05:40 EDT(-0400)] * laurel1 (n=Laurel@142.150.154.178) has joined #fluid-work
[14:09:29 EDT(-0400)] * fj40001 (n=Jacob@142.150.154.106) has joined #fluid-work
[14:40:11 EDT(-0400)] * yura (n=yura@142.150.154.101) has joined #fluid-work
[14:43:33 EDT(-0400)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[15:25:03 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[15:25:03 EDT(-0400)] * clown (n=clown@142.150.154.121) has left #fluid-work
[15:29:11 EDT(-0400)] * clown (n=clown@142.150.154.121) has joined #fluid-work
[16:18:54 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[16:51:29 EDT(-0400)] * davetrey (n=davetrey@139.pool85-50-142.dynamic.orange.es) has joined #fluid-work
[17:39:08 EDT(-0400)] * clown (n=clown@142.150.154.121) has left #fluid-work
[17:42:07 EDT(-0400)] * alisonbenjamin (n=alisonbe@dsl-207-112-76-95.tor.primus.ca) has joined #fluid-work
[18:08:38 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[18:10:10 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[18:33:54 EDT(-0400)] * davetrey (n=davetrey@139.pool85-50-142.dynamic.orange.es) has joined #fluid-work
[18:34:23 EDT(-0400)] * davetrey (n=davetrey@139.pool85-50-142.dynamic.orange.es) has left #fluid-work
[21:10:23 EDT(-0400)] * fj4000 (n=Main@CPE0018f85ab63e-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work