fluid-work IRC Logs-2013-07-03
- Fluid IRC Log Bot
[08:10:42 CDT(-0500)] <colinclark> hey Kasper__
[09:02:00 CDT(-0500)] <Justin_o> cindyli, yzen: okay.. so i'm getting confused again.. in the preferenceMap, the paths on the left are for the internal model of the component? or the external model that is shared?
[09:02:16 CDT(-0500)] <cindyli> Justin_o: internal i think
[09:02:16 CDT(-0500)] <Justin_o> http://pastie.org/private/joujbu7uhezkgwx1unama (look at the top one)
[09:02:26 CDT(-0500)] <Justin_o> so it should have been "model.value"
[09:02:28 CDT(-0500)] <Justin_o> ?
[09:03:06 CDT(-0500)] <cindyli> yes, Justin_o
[09:03:32 CDT(-0500)] <Justin_o> cindyli: thanks
[09:03:49 CDT(-0500)] <cindyli> np
[09:12:54 CDT(-0500)] <clown_mtg> jhernandez, are you around?
[09:21:06 CDT(-0500)] <cindyli> Justin_o and yura, i've finished expanding our "@" references in the auxiliary schema. shall we chat about the next step for auxiliary builder in terms if or how the expanded auxiliary should be processed before being handed to uio builder
[09:21:34 CDT(-0500)] <Justin_o> cindyli: sure we can chat
[09:26:08 CDT(-0500)] <anastasiac> Justin_o, what's your thinking on adding the new low-contrast theme to UIO?
[09:26:39 CDT(-0500)] <Justin_o> anastasiac: you mean to the new demo or to the existing one
[09:26:56 CDT(-0500)] <anastasiac> I mean to UIO itself, as one of the colour-contrast options
[09:27:39 CDT(-0500)] <heidiv> anastasiac i'm thinking the theme might not be production-ready until we figure out how to deal with theme images…. font icon vs. creating pngs for button borders etc
[09:28:06 CDT(-0500)] <heidiv> we also have "more" "close" "gripper" images in there
[09:28:11 CDT(-0500)] <anastasiac> what do the existing themes do now?
[09:28:31 CDT(-0500)] <heidiv> existing themes have their own images
[09:30:10 CDT(-0500)] <heidiv> jhung how much work would it be to switch those few icons (maybe not button borders) to font icons? we could adapt/update the FSS button styling perhaps
[09:30:25 CDT(-0500)] <anastasiac> have we not converted the themes to icon fonts yet? Justin_o, michelled seems to remember a pull request?
[09:30:28 CDT(-0500)] <heidiv> relates to the email you just sent out
[09:30:44 CDT(-0500)] <heidiv> anastasiac not yet FSS - just UIO, inline edit, and uploader
[09:31:20 CDT(-0500)] <anastasiac> could we create the necessary images for the low-contrast theme? how much work would that be?
[09:31:42 CDT(-0500)] <jhung> heidiv: It may be complicated because the icon fonts need to go into before or after pseudo elements. So for the button borders this is really not ideal because we'll end up with 2 or 3 icons per button.
[09:31:53 CDT(-0500)] <jhung> I would prefer a non-icon approach if possible.
[09:32:06 CDT(-0500)] <heidiv> jhung - thoughts? i don't really like the idea of creating border images for our buttons. antiquated solution
[09:32:33 CDT(-0500)] <heidiv> and we want to convert images to font icons in FSS soon
[09:32:48 CDT(-0500)] <jhung> heidiv: yeah, but the solution is really ugly.
[09:32:57 CDT(-0500)] <heidiv> yep
[09:33:09 CDT(-0500)] <jhung> Per button we have at least 2 images, right? A start cap and the end cap.
[09:33:35 CDT(-0500)] <jhung> Icons need to be created for those. Then separate containers for those in the markup.
[09:33:46 CDT(-0500)] <heidiv> 4 images per button
[09:34:02 CDT(-0500)] <jhung> So at least 4 elements per button.
[09:34:05 CDT(-0500)] <heidiv> buttons-med-bg.png, buttons-med-cap.png, buttons-titlebar-bg.png, buttons-titlebar-cap.png
[09:34:22 CDT(-0500)] <heidiv> i don't think we should recreate these, but use css instead
[09:34:29 CDT(-0500)] <jhung> yeah agreed.
[09:34:36 CDT(-0500)] <heidiv> and font icons for more/close/gripper
[09:34:46 CDT(-0500)] <jhung> Maybe look into using better semantic markup?
[09:35:23 CDT(-0500)] <jhung> heidiv: those gripper icons (as well as some others) are a different problem.
[09:35:34 CDT(-0500)] <jhung> Icon fonts can't recreate their 3D effect.
[09:35:46 CDT(-0500)] <jhung> So we lose their original visual fidelity.
[09:36:02 CDT(-0500)] <heidiv> jhung we'd have to investigate what changes would be needed to update our theme buttons from images to css
[09:36:15 CDT(-0500)] <heidiv> markup vs just classes? i'm guessing both
[09:36:34 CDT(-0500)] <jhung> yeah probably both heidiv.
[09:36:36 CDT(-0500)] <heidiv> we could prob find a different looking gripper icon
[09:37:09 CDT(-0500)] <heidiv> tho it just looks like a bunch of dots to me
[09:37:24 CDT(-0500)] <jhung> heidiv: re: gripper - true, but i'm a bit wary of changing the visual appearance since we don't know how end users have implemented FSS.
[09:37:50 CDT(-0500)] <jhung> if you look at Coal theme's gripper, it looks inset.
[09:38:01 CDT(-0500)] <heidiv> jhung yeah, i guess i'm thinking new stuff for the new contrast theme only, for now?
[09:38:56 CDT(-0500)] <jhung> heidiv: that is one option heidiv.
[09:40:18 CDT(-0500)] <heidiv> jhung if we can find a simple solution for updating the button styles, would adding font icons to my new theme be straight fwd? for those 3 icons
[09:40:59 CDT(-0500)] <heidiv> a font file, and updating the classes to use icons vs images, right?
[09:44:04 CDT(-0500)] <jhung> heidiv: I would recommend that we try to use CSS and semantic markup solution for the buttons. Then for the other stuff (like gripper, close icon etc) we will use an icon font. This would be only for the new theme and would be predominantly flat in appearance (no 3d).
[09:44:24 CDT(-0500)] <jhung> does that summarize it?
[09:44:56 CDT(-0500)] <heidiv> jhung let's do it… could you make that font for me? Justin_o does jhung's summary look like a good approach? then we could add it to UIO proper.
[09:45:15 CDT(-0500)] <heidiv> and add some feedback to jhung's email to the list about updating fss themes
[09:50:44 CDT(-0500)] <Justin_o> heidiv, jhung: that sounds like a good approach..
[09:53:03 CDT(-0500)] <Justin_o> jhung, heidiv: will this make it incompatible with the other themes, in terms of markup
[09:53:32 CDT(-0500)] <heidiv> Justin_o just looking at the button's markup in our theme tests…. <a class="fl-button-right settings" href="#"><strong class="fl-button-inner">Settings</strong></a>
[09:54:00 CDT(-0500)] <heidiv> for bkwards compatibility, we can ignore "button-inner" class and just set fl-button-right to be a border. even tho that semantically doesn't make sense
[09:54:19 CDT(-0500)] <heidiv> then add another class for styling <button>
[09:54:23 CDT(-0500)] <heidiv> ?
[09:55:40 CDT(-0500)] <Justin_o> heidiv: hmm.. seems like things won't just work for anyone who has already implemented it though, if they would need to add another class for styling buttons
[09:59:09 CDT(-0500)] <heidiv> Justin_o styling fl-button-right would work for old implementations (using <a> as a button) and we would also support styling <button>
[10:00:30 CDT(-0500)] <Justin_o> heidiv: oh i see you mean you would add styling for buttons as well as anchors
[10:00:30 CDT(-0500)] <Justin_o> okay..
[10:00:39 CDT(-0500)] <Justin_o> so the only issue is the non-semantic name of the class
[10:00:52 CDT(-0500)] <heidiv> Justin_o right
[10:05:28 CDT(-0500)] <Justin_o> heidiv: i guess we could alias that with another name..
[10:05:31 CDT(-0500)] <Justin_o> something like
[10:05:46 CDT(-0500)] <Justin_o> fl-button-style, fl-button-right: {}
[10:06:32 CDT(-0500)] <jhung> Justin_o: yeah that's a good compromise.
[10:06:53 CDT(-0500)] <heidiv> yes that's what i was thinking
[10:07:03 CDT(-0500)] <heidiv> fl-button-right wouldn't be used, just for bkwards compat
[10:07:32 CDT(-0500)] <jhung> heidiv: So would that mean we'd still need to have border images?
[10:07:45 CDT(-0500)] <heidiv> jhung no
[10:07:53 CDT(-0500)] <jhung> heidiv: cool.
[10:08:01 CDT(-0500)] <jhung> heidiv: so let's go for it. 
[10:08:37 CDT(-0500)] <jhung> heidiv: I'll start looking into converting some of those icons into fonts.
[10:22:50 CDT(-0500)] <michelled> cindyli, Justin_o: are we set on using 'enactors' or 'actions'? we seem to have a mixture in the repo right now
[10:25:05 CDT(-0500)] <Justin_o> michelled: hmm.. i'm not entirely sure.. you are right that we should settle on one though.. cindyli do you know?
[10:25:07 CDT(-0500)] <cindyli> michelled: we set on "enactors" as i understand. "actions" seems only used for "starterActions". Should we replace it with "starterEnactors" too?
[10:25:35 CDT(-0500)] <michelled> yes, let's be consistent
[10:26:01 CDT(-0500)] <cindyli> ok
[10:57:51 CDT(-0500)] <colinclark> Bosmon: So, I hear we need an arsonist!
[10:58:02 CDT(-0500)] <colinclark> Tell me about your experience with the ChangeApplier
[10:58:20 CDT(-0500)] <colinclark> Is it the transactional features, or other parts of it?
[10:58:31 CDT(-0500)] <Bosmon> It is the transactional features
[10:58:44 CDT(-0500)] <Bosmon> Which, as we may recall, were designed specifically for use in the Pager round about 2010
[10:58:50 CDT(-0500)] <Bosmon> And were never used for any other use case since then
[10:59:05 CDT(-0500)] <colinclark> yes, that's right
[10:59:13 CDT(-0500)] <Bosmon> Even for a "White Elephant Generalisation", their fit to their original problem is somewhat poor 
[10:59:18 CDT(-0500)] <colinclark> I remember you recently commented that we had all of that infrastructure, but no real use cases
[10:59:35 CDT(-0500)] <michelled> cindyli: I'm not sure if you already say this, but we still have text-sizer in the html templates
[10:59:37 CDT(-0500)] <colinclark> Tell me about the nature of the original problem that drove the development for the Pager
[11:00:17 CDT(-0500)] <Bosmon> The Pager has a very strange kind of model... I guess at the time it seemed we were on the verge of an avalanche of finding components with similar models, but in fact no further examples appeared
[11:00:23 CDT(-0500)] <Bosmon> I guess you could call its model "self-reactive"
[11:00:36 CDT(-0500)] <cindyli> michelled: ah, missed that, will fix it in the new pull request
[11:00:42 CDT(-0500)] <cindyli> thanks
[11:00:44 CDT(-0500)] <Bosmon> Here we are talking about the little model it has, that has fields such as "pageIndex", "pageCount", "totalRange", "pageSize"
[11:00:45 CDT(-0500)] <michelled> np
[11:01:20 CDT(-0500)] <Bosmon> Several of these fields have values which are constrained by several of the others, which is actually quite a complex scenario
[11:01:49 CDT(-0500)] <Bosmon> In the "old pager" this was done by lots of manual code and "if" statements, but as well as being rather messy, this was actually the biggest source of dependency risk in the component
[11:02:18 CDT(-0500)] <Bosmon> So I guess we could say that despite the "failure" of the transactional features of the new ChangeApplier, they have at least met their basis purpose in allowing the component to be refactored
[11:02:23 CDT(-0500)] <Bosmon> basic purpose
[11:02:43 CDT(-0500)] <colinclark> right
[11:02:49 CDT(-0500)] <Bosmon> Since this "little model" gains some extra fields in the "PagedTable" component that are not present in the "Pager" component - in particular the sort direction and sort key
[11:03:01 CDT(-0500)] <colinclark> So what do you envision the next steps for the ChangeApplier to be?
[11:03:13 CDT(-0500)] <Bosmon> In the "old pager", the little method where all of these fields were dealt with at once was the worst point of dependency risk in the entire component, and the last problem to be fixed in the refactoring
[11:03:51 CDT(-0500)] <Bosmon> I think that we need to continue along the lines we currently are, and improve the power of the "ModelRelay" system that cindyli and others are designing for UIO, and improving the ModelTransformations system
[11:04:00 CDT(-0500)] <Bosmon> Neither of which were developments we were really considering in 2010
[11:04:19 CDT(-0500)] <Bosmon> But it's obvious that the system of "guards" that we have drawn up to describe the operation of a "self-reactive changeApplier" is faulty
[11:04:31 CDT(-0500)] <Bosmon> We should be describing directly required transformations and constraints on VALUES
[11:04:50 CDT(-0500)] <Bosmon> Rather than as we do with the "transactional ChangeApplier", expect people to directly write code which operates on streams of CHANGEEVENTS
[11:05:07 CDT(-0500)] <Bosmon> People should write the value filters and constraints as ModelTranformation documents
[11:05:29 CDT(-0500)] <Bosmon> And then the system should infer the required filtration of the ChangeEvent stream from this automatically
[11:05:58 CDT(-0500)] <Bosmon> Similarly to the way that a simple Transformation document allows two ChangeAppliers to be connected together by the ModelRelay systems that we are currently working on
[11:06:34 CDT(-0500)] <Bosmon> I guess this will mean that our current system of things like "guards" and "postGuards" etc. will bite the dust - in fact noone used them since 2010 since their implementation was unstable and incomprehensible
[11:06:54 CDT(-0500)] <kasparnet> Bosmon, colinclark, michelled: arch meeting now
[11:06:59 CDT(-0500)] <Bosmon> There's still a bit of a "cognitive gap" in figuring out how to describe constraints between values that are meant to operate in a particular ORDER
[11:07:21 CDT(-0500)] <Bosmon> For example, in discovering that the "pageIndex" is out of range of the "pageCount", it is the former which has to give way and not the latter
[11:07:50 CDT(-0500)] <Bosmon> Similarly, if the "pageCount" mismatches its value which can be inferred from "pageSize" and "totalRange" it is that one which gives way
[11:08:12 CDT(-0500)] <Bosmon> So there needs to be some kind of "hierarchy of constraints" which it is not possible to describe simply as a ModelTransformation document
[11:09:17 CDT(-0500)] <colinclark> This is very interesting
[11:09:36 CDT(-0500)] <colinclark> I think I need to break down the particular example in the page to understand this clearly
[11:15:32 CDT(-0500)] <michelled> avtar: the branch we are working on is: https://github.com/fluid-project/infusion/tree/discovery-tool-demo
[11:15:42 CDT(-0500)] <michelled> Justin_o: ^
[11:15:57 CDT(-0500)] <colinclark> How come we're going to do the discovery tool in a branch of Infusion?
[11:16:03 CDT(-0500)] <michelled> we haven't put anything interesting in it yet, but an automated build would be awesome
[11:16:30 CDT(-0500)] <Bosmon> michelled - didn't yzen create a new github repository under GPII for work such as this?
[11:16:47 CDT(-0500)] <avtar> michelled: perfect. thanks!
[11:16:51 CDT(-0500)] <michelled> colinclark: we talked about doing it as another integration demo. do you think it should be a separate repo?
[11:17:00 CDT(-0500)] <michelled> hang on avtar - I might have jumped the gun
[11:17:05 CDT(-0500)] <avtar> too late
[11:17:14 CDT(-0500)] <avtar> i'm attached to that repo
[11:17:18 CDT(-0500)] <michelled>
[11:17:49 CDT(-0500)] <Justin_o> avtar: your level of commitment is astonishing
[11:17:55 CDT(-0500)] <michelled> Bosmon: I think this belongs under the fluid space rather than GPII
[11:17:56 CDT(-0500)] <colinclark> Yes, I think it should be a different repository
[11:18:14 CDT(-0500)] <colinclark> Why do you think it belongs there, michelled?
[11:20:02 CDT(-0500)] <michelled> I thought it was Floe/PGA. Am I wrong?
[11:20:41 CDT(-0500)] <colinclark> This is an interesting conversation
[11:20:41 CDT(-0500)] <michelled> yzen: where is your GPII repo?
[11:20:48 CDT(-0500)] <colinclark> We're in the midst of the architecture meeting at the moment
[11:20:57 CDT(-0500)] <colinclark> and I'd like to give it more time that I've got for the next 30 minutes or so
[11:21:24 CDT(-0500)] <yzen> colinclark: are you talking about the prefEditors repo ?
[11:21:29 CDT(-0500)] <colinclark> I can say this much: I feel pretty clear, in my own mind, that it shouldn't be in a branch of Infusion
[11:21:30 CDT(-0500)] <Bosmon> yzen - we are
[11:21:57 CDT(-0500)] <colinclark> I think we can have a discussion clarifying whether it should be part of the GPII prefsEditor repository or not
[11:22:06 CDT(-0500)] <colinclark> I just need a few minutes 
[12:05:34 CDT(-0500)] <colinclark> Ok
[12:05:34 CDT(-0500)] <colinclark> repositories
[12:05:34 CDT(-0500)] <colinclark> and where an early prototype of the Discovery Tool preference editor should live
[12:05:52 CDT(-0500)] <colinclark> I can imagine jessm may also have some thoughts on this
[12:06:07 CDT(-0500)] <colinclark> From my perspective, I'd like to see the PGA work as closely aligned with the larger GPII community as possible
[12:06:13 CDT(-0500)] <jessm> jessm? thoughts? keywords!
[12:06:21 CDT(-0500)] <colinclark> lol
[12:06:22 CDT(-0500)] <colinclark>
[12:06:30 CDT(-0500)] <colinclark> in part to remind the project team that this is a piece of a larger effort
[12:06:39 CDT(-0500)] <colinclark> that there are different preferences tools for different users and use cases
[12:07:01 CDT(-0500)] <colinclark> I guess one question is if we think there will be opportunities for harmonization or code sharing with the other two preference editors
[12:07:04 CDT(-0500)] <colinclark> the PCP and PMT
[12:07:19 CDT(-0500)] <colinclark> both of which will live in that prefsEditor repository that yzen created
[12:07:30 CDT(-0500)] <michelled> I had thought of the discovery tool as a flavour of UIO and thought that once it was production worthy it would ship with the component
[12:07:45 CDT(-0500)] <colinclark> So, I guess this points to something big
[12:08:04 CDT(-0500)] <colinclark> I fear we're getting to the end of the usefulness of the name "UI Options component"
[12:08:23 CDT(-0500)] <colinclark> I've started to use the term "UI Options Framework" in the documentation I've been writing
[12:08:42 CDT(-0500)] <colinclark> but have found that it still points people back to "that thing at the top of some websites that lets you make the font bigger or change the contrast"
[12:09:10 CDT(-0500)] <colinclark> michelled: How is your notion of a "flavour of UIO" different from what the PCP and PMT are?
[12:11:26 CDT(-0500)] <michelled> I suppose my notion might be archaic and comes from the concepts of full page, full page with preview and fat panel.
[12:12:04 CDT(-0500)] <michelled> when we moved the full page demos into the manual tests, we said they would eventually be replaced by PCP and/or PMT
[12:12:27 CDT(-0500)] <michelled> I guess I'm not clear on what it is we want in the Infusion repo anymore.
[12:13:38 CDT(-0500)] <Bosmon> Well, we certainly want at least the "framework" itself
[12:13:42 CDT(-0500)] <Bosmon> And its "starter configuration"
[12:13:47 CDT(-0500)] <Bosmon> We may want little else there
[12:14:11 CDT(-0500)] <colinclark> I think that's probably right...
[12:15:22 CDT(-0500)] <colinclark> I expect that the "starter" configuration will look something like joanna's latest wireframes for the "fat panel"
[12:15:44 CDT(-0500)] <colinclark> I'm having trouble finding them at the moment. When I search in the wiki for "UI Options wireframes" I still get Gary's old designs with the vegetables in them
[12:16:26 CDT(-0500)] <colinclark> Ah, here: http://wiki.fluidproject.org/display/fluid/%28Floe%29+UI+Options+Design+High+Fidelity%2C+C.1
[12:16:48 CDT(-0500)] <colinclark> I guess the thing we have to unpack a bit is, "what is UI Options?"
[12:16:49 CDT(-0500)] <colinclark> It
[12:17:08 CDT(-0500)] <colinclark> It's more than "a component" at this state in its evolution
[12:17:30 CDT(-0500)] <colinclark> where "a component" is, in many people's minds, "a specific widget or control you can put in a web page"
[12:17:42 CDT(-0500)] <colinclark> We have, of course, a much more expansive notion of the word "component"
[12:18:03 CDT(-0500)] <colinclark> but the point is that, I think, UI Options is now increasingly a "tool that you use to build preference editors"
[12:18:12 CDT(-0500)] <colinclark> Does that seem about right to you, michelled?
[12:19:59 CDT(-0500)] <michelled> well, I do think that's true colinclark - but I also feel that Infusion might be having an identity crises. I think people will want access to preference editors that they can just use with minimal work. in my mind, Infusion delivers (delivered?) that.
[12:20:23 CDT(-0500)] <michelled> this seems to point to the what the KING was been saying about pulling the framework out from the components
[12:20:47 CDT(-0500)] <michelled> unfortunately, he's at soccer right now
[12:22:03 CDT(-0500)] <colinclark> Okay, so we can unpack some of this
[12:22:17 CDT(-0500)] <colinclark> The identity crisis issue, perhaps you can elaborate on
[12:22:42 CDT(-0500)] <colinclark> The other question is, do we think that the Discovery Tool is the sort of thing that someone would just pop into their application? Or is it broader in scope?
[12:25:08 CDT(-0500)] <michelled> when the tool is integrated with the full workflow that involves setting more fine grained setting of course it is broader. what I'm not sure about is whether it's useful on its own.
[12:29:54 CDT(-0500)] <michelled> vjoanna, danaayotte: where do we expect the discovery tool to be used?
[12:33:24 CDT(-0500)] <colinclark> I wasn't able to attend your scoping meeting about the DT recently
[12:33:32 CDT(-0500)] <colinclark> but I assume this was probably discussed
[12:33:43 CDT(-0500)] <colinclark> The DT is interesting in that it needs to be closely integrated with a "content delivery system"
[12:34:02 CDT(-0500)] <colinclark> Since, ultimately, the user will be explore the range of preferences and settings available to them within particular content
[12:34:31 CDT(-0500)] <colinclark> but it's also notable that the DT will ultimately stretch beyond just a particular kind of content
[12:34:51 CDT(-0500)] <colinclark> also offering users ways to play around with native assistive technology and settings
[12:35:02 CDT(-0500)] <colinclark> such as, say, a screen magnifier
[12:35:07 CDT(-0500)] <colinclark> or tools like Read & Write Gold
[12:35:35 CDT(-0500)] <colinclark> Which means that an aspect of it will be connected to or aware of a local GPII installation
[12:35:57 CDT(-0500)] <colinclark> so that it can send "preference preview" events to a local Flow Manager
[12:39:24 CDT(-0500)] <colinclark> Also, if I remember correctly, the Discovery Tool also had a kind of "preferences summary" view that was something akin to the PMT
[12:39:34 CDT(-0500)] <colinclark> where you could see what actual preferences were stored in your set and tweak them
[12:39:35 CDT(-0500)] <jessm> so, identity crisis indeed
[12:40:44 CDT(-0500)] <colinclark> What is the identity crisis?
[12:40:53 CDT(-0500)] <jessm> colinclark: michelled: just the other day i said (before my ears fell off my head) I can imagine the DT is the same thing as the PCP as the UIO in some implementations. it's a sign of the brilliance of it being a platform, but makes for very confusing conversations
[12:41:21 CDT(-0500)] <jessm> i can say the PMT feels different because of the additional features
[12:41:51 CDT(-0500)] <jessm> but we have a museum PCP mock-up that looks a lot like UIO on a kiosk and doesn't look that different from the DT
[12:43:06 CDT(-0500)] <colinclark> I really love how you've taken on the Infusion philosophy from a design perspective, jessm
[12:43:28 CDT(-0500)] <colinclark> In that it doesn't mean a whole lot, technically, to say "the PMT is different from the PCP"
[12:43:46 CDT(-0500)] <colinclark> in that they are both implementations of the UI Options framework
[12:43:51 CDT(-0500)] <colinclark> different views or configurations of it
[12:44:05 CDT(-0500)] <colinclark> but nonetheless very interrelated
[12:44:19 CDT(-0500)] <jessm> it's intirely danaayotte and jvass' faults
[12:44:45 CDT(-0500)] <colinclark> Yes, I blame vjoanna and danaayotte for being awesome 
[12:44:57 CDT(-0500)] <jessm> exactly
[12:45:02 CDT(-0500)] <colinclark> I'm hesitant to call it an identity crisis
[12:45:02 CDT(-0500)] <colinclark> but the point is notable
[12:45:07 CDT(-0500)] <jessm> what i love about all the tools is the top-hat and underpants part
[12:45:17 CDT(-0500)] <colinclark> woah
[12:45:32 CDT(-0500)] <colinclark> And people say Bosmon uses strange references
[12:45:54 CDT(-0500)] <jessm> just like the uploader component you can dress these guys up and take them to the opera, or you can strip them down to underpants and take them to a cookout
[12:45:58 CDT(-0500)] <Bosmon> jessm - is this anything to do with the "underpants gnomes business model"?
[12:46:18 CDT(-0500)] <jessm> colinclark: it goes back to Portland when you showed me the uploader in its underpants!
[12:46:21 CDT(-0500)] <colinclark> so awesome
[12:46:26 CDT(-0500)] <colinclark> is this what happens on the 4th of July?
[12:46:37 CDT(-0500)] <colinclark> y'all bbq in your underpants?
[12:46:43 CDT(-0500)] <jessm> what? it's the 3rd!
[12:46:50 CDT(-0500)] <jessm> oh right
[12:46:51 CDT(-0500)] <Bosmon> I think it is only the 4th July currently in the KIRIBATI ISLANDS
[12:47:01 CDT(-0500)] <colinclark> sorry
[12:47:10 CDT(-0500)] <jessm> tomorrow underpants bbq
[12:47:12 CDT(-0500)] <colinclark> yes
[12:47:14 CDT(-0500)] <colinclark> that's what I meant
[12:47:19 CDT(-0500)] <jessm> maybe!
[12:47:23 CDT(-0500)] <colinclark> Although it is unusual, I do know what day it is today
[12:48:03 CDT(-0500)] <jessm> let me dig up the german museum kiosk sketches
[12:48:19 CDT(-0500)] <Bosmon> jessm - now that could only lead to a Monty Python result
[12:48:28 CDT(-0500)] <Bosmon> "I don't believe you have any DUEHRER IN THIS KIOSK AT ALL!"
[12:48:35 CDT(-0500)] <jessm> lol
[12:48:36 CDT(-0500)] <colinclark>
[12:48:51 CDT(-0500)] <colinclark> Anyway, this fact that the various preference editors aren't strictly delineated...
[12:49:13 CDT(-0500)] <colinclark> The good news is, first, that we've got a common technical framework with which they can all be built and configured
[12:49:30 CDT(-0500)] <colinclark> Secondly, we've got an awesome design team who is tackling their user experience holistically
[12:49:42 CDT(-0500)] <Bosmon> Justin_o - will there happen to be a Community Meeting today?
[12:50:27 CDT(-0500)] <colinclark> So, the name is increasingly insufficient
[12:50:40 CDT(-0500)] <colinclark> but we have "the UI Options framework," which all three tools will be built from
[12:50:55 CDT(-0500)] <colinclark> four if you want to count the "thing we currently know as UI Options"
[12:51:10 CDT(-0500)] <colinclark> You could call it the "web PCP" if you were so inclined
[12:51:40 CDT(-0500)] <colinclark> So the UIO framework should undoubtedly be part of Infusion
[12:51:50 CDT(-0500)] <colinclark> since we want to offer it to anyone doing the work of building a preference editing tool
[12:52:02 CDT(-0500)] <colinclark> and we always like to ship default configurations and useful, high-level components
[12:52:05 CDT(-0500)] <jessm> yes, exactly, web PCP
[12:52:14 CDT(-0500)] <colinclark> so the (sorry for the name) "web PCP" should ship alongside the framework as an exmplar
[12:52:47 CDT(-0500)] <colinclark> From there, the "native PCP" and the PMT are both being built in the context of the GPII Github org
[12:52:59 CDT(-0500)] <colinclark> I think there's a lot of benefit to also building the DT in that context
[12:53:11 CDT(-0500)] <colinclark> good to remind everyone working on the project that there's a big picture
[12:53:23 CDT(-0500)] <colinclark> beyond any single content authoring or delivery system
[12:55:18 CDT(-0500)] <michelled> ok. what do you think we should do with the code we currently have for the full page versions of "web PCP"
[12:55:39 CDT(-0500)] <colinclark> We don't really see those as a "product"
[12:55:43 CDT(-0500)] <colinclark> sorry for the word, jessm
[12:56:13 CDT(-0500)] <colinclark> So they really just serve as exemplars for how you can build different types of preference editors with the UI Options Framework
[12:56:14 CDT(-0500)] <colinclark> I think
[12:56:20 CDT(-0500)] <colinclark> is that what others think, too?
[12:57:04 CDT(-0500)] <jessm> so, remind me of the details – yzen had a thread onlist about naming the "basic" or "starter" configuration
[12:57:09 CDT(-0500)] <michelled> I'm a little uncomfortable with having code in the main repo that we aren't using for something that we are expecting to be in production
[12:57:37 CDT(-0500)] <michelled> it's too easy for us to forget it and have it break without our knowledge
[12:57:38 CDT(-0500)] <jessm> i think that hinted at where we are now — deciding what are unique instances or exemplars
[12:57:57 CDT(-0500)] <colinclark> I'm pretty sure vjoanna said months ago that those full-page views weren't ever intended to be real
[12:58:38 CDT(-0500)] <michelled> yes, my understanding was that we were temporarily keeping it in the repo until we replaced it with PCP/PMT - but I must have misunderstood that.
[12:58:59 CDT(-0500)] <colinclark> jessm: Yes, we have a "starter" configuration that represents, or should represent, roughly those C.1 wireframes
[12:59:24 CDT(-0500)] <Bosmon> michelled - hopefully we rely on more than "expecting it to be used in production" for our ability to keep code working
[12:59:36 CDT(-0500)] <colinclark> so what's wrong with that idea, michelled?
[12:59:40 CDT(-0500)] <colinclark> why did you misunderstand?
[13:00:24 CDT(-0500)] <michelled> and I guess I'd like to make the distinction between the code https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uiOptions/js/FullPreviewUIOptions.js and the demo https://github.com/fluid-project/infusion/blob/master/src/webapp/tests/manual-tests/html/uiOptionsFullWithPreview.html
[13:00:31 CDT(-0500)] <colinclark> the idea of eventually replacing those with pointers to the PMT or PCP or discover tool or any number of other things, i mean
[13:00:43 CDT(-0500)] <colinclark> what kind of distinction?
[13:02:22 CDT(-0500)] <michelled> well, having a demo that shows ways of using the framework is great - the first link I sent could be considered part of the framework
[13:02:31 CDT(-0500)] <michelled> but it sounds like we wouldn't actually be using it anywhere
[13:02:41 CDT(-0500)] <michelled> that was what I was concerned about leaving in the repo
[13:02:47 CDT(-0500)] <michelled> or at least, leaving it where it is
[13:03:31 CDT(-0500)] <Bosmon> michelled - what's behind this?
[13:03:34 CDT(-0500)] <Bosmon> What real risks do you see?
[13:03:35 CDT(-0500)] <michelled> my misunderstanding was that I thought the PCP and PMT core code would eventually be in the infusion repo rather than the infusion repo having pointers out to it.
[13:04:09 CDT(-0500)] <michelled> Bosmon: the same risk we just finally got rid of by removing our ancient portal integration demo
[13:04:14 CDT(-0500)] <Bosmon> Perhaps we should remove the Uploader, the Reorderer, and the Pager from the framework too
[13:04:19 CDT(-0500)] <Bosmon> Since they are not "actually used anywhere"
[13:04:20 CDT(-0500)] <michelled> the one that spent more of it's time broken in the repo than working
[13:04:30 CDT(-0500)] <colinclark> Justin might agree to that
[13:04:53 CDT(-0500)] <michelled> that's what I was hinting at before - the KING has been suggesting that for some time now
[13:05:02 CDT(-0500)] <colinclark> But it's a good point...
[13:05:07 CDT(-0500)] <colinclark> He's been suggesting it for some time,
[13:05:11 CDT(-0500)] <colinclark> and I was quite against it
[13:05:32 CDT(-0500)] <colinclark> until he proposed a very awesome and time-intensive (to build) cross-repository Builder
[13:05:48 CDT(-0500)] <colinclark> Until we're ready to tackle that, I can't see any real benefit to removing components from the framework
[13:06:02 CDT(-0500)] <colinclark> and in fact I think it risks the thing you're most concerned about
[13:06:11 CDT(-0500)] <colinclark> which is inadvertent and unnoticed breakage
[13:06:43 CDT(-0500)] <colinclark> I mean, from a very big picture perspective, I'd love to decouple the components from the framework
[13:06:56 CDT(-0500)] <colinclark> since i think people are often confused by the idea that the components ARE Infusion
[13:07:08 CDT(-0500)] <colinclark> but honesty I think that has much to do with our documentation and demos as anything else
[13:07:35 CDT(-0500)] <colinclark> And having these "exemplars" of how our framework can be used in a variety of ways to create very different types of user interfaces
[13:07:47 CDT(-0500)] <colinclark> from a shared base of code and configuration
[13:07:52 CDT(-0500)] <colinclark> that goes a long way to explaining the dynamic
[13:08:22 CDT(-0500)] <colinclark> There's an interesting question about how we keep things working and up-to-date
[13:08:36 CDT(-0500)] <colinclark> why is it that the Uploader didn't break, but the uPortal demo often did?
[13:08:42 CDT(-0500)] <colinclark> what's different about these two things
[13:08:43 CDT(-0500)] <colinclark> ?
[13:08:55 CDT(-0500)] <anastasiac> so I'm a little confused. The things we currently have in our 'components' folder: are those actual widgets we expect people to use in their sites/apps, or are they exemplars of how to use the framework to build their own widgets, or both, or something else?
[13:08:59 CDT(-0500)] <Bosmon> Actually the Uploader did break : P
[13:09:04 CDT(-0500)] <colinclark> Bosmon: in the end, it looks like we're having our community meeting right now
[13:09:12 CDT(-0500)] <Bosmon> "if a component breaks in the forest and nobody hears it....>"
[13:09:45 CDT(-0500)] <Bosmon> And what is the topic of the meeting?
[13:09:49 CDT(-0500)] <Bosmon> "What, in fact, are we up to?" : P
[13:10:09 CDT(-0500)] <colinclark>
[13:10:26 CDT(-0500)] <colinclark> anastasiac: They are undoubtedly both
[13:10:43 CDT(-0500)] <colinclark> this speaks my earlier point about how we have a different notion of what a "component" is
[13:11:00 CDT(-0500)] <anastasiac> yes, we need a different name for the "widget" components
[13:11:19 CDT(-0500)] <colinclark> I guess my hope is that we don't really have these things, so much
[13:11:34 CDT(-0500)] <Bosmon> They serve at least a 3rd purpose, and possibly several others...
[13:11:47 CDT(-0500)] <Bosmon> They validate the fact that the framework is useful for building something that someone at at least one time genuinely wanted
[13:12:12 CDT(-0500)] <colinclark> yes
[13:12:18 CDT(-0500)] <Bosmon> And in theory, any of them could become "useful" again
[13:12:48 CDT(-0500)] <anastasiac> colinclark, could you elaborate on "my hope is that we don't really have these things, so much"
[13:12:54 CDT(-0500)] <Bosmon> The components force us to put our money where our mouth is, in terms of the idea that "we build things so that they can be maintained"
[13:13:04 CDT(-0500)] <Bosmon> Unless we actually DO maintain them, there is no way to validate this
[13:13:15 CDT(-0500)] <colinclark> anastasiac: I'm afraid the subtlety will be hard to convey
[13:13:19 CDT(-0500)] <colinclark> but we don't make "widgets"
[13:13:29 CDT(-0500)] <colinclark> We don't make things that just are
[13:13:37 CDT(-0500)] <colinclark> "I ams what I am"
[13:13:51 CDT(-0500)] <colinclark> The Pager is a fine example, since it's topical these days
[13:14:06 CDT(-0500)] <colinclark> It's clearly a whole collection of pieces that you can use and assemble in different ways
[13:14:19 CDT(-0500)] <colinclark> depending on what kind of information you are paging, etc.
[13:14:40 CDT(-0500)] <colinclark> But we certainly like to ship good, usable default configurations
[13:15:01 CDT(-0500)] <colinclark> Including, say, a pager that can relatively easily page through a big set of JSON objects or whatever
[13:15:43 CDT(-0500)] <colinclark> I can only imagine that, deep in our wiki, there are dozens of transcripts from this channel where we've discussed this relationship between the framework, the components, their default configuration, and the various demos we've got
[13:15:59 CDT(-0500)] <colinclark> over the past 6 years of being Fluidic
[13:16:55 CDT(-0500)] <colinclark> So, we build a framework for building apps
[13:17:11 CDT(-0500)] <colinclark> and with that framework, we build components that are themselves incredibly configurable
[13:17:41 CDT(-0500)] <colinclark> from there, we design beautiful and useful configurations of those components that people can drop into their own applications and pages
[13:18:14 CDT(-0500)] <colinclark> and we also offer them examples, demos, and documentation that clearly conveys the point that these components aren't just what they look like in their default configuration.
[13:18:23 CDT(-0500)] <colinclark> Seem right?
[13:18:51 CDT(-0500)] <anastasiac> of course, none of this is a surprise
[13:19:19 CDT(-0500)] <anastasiac> I was just confused by your hope that we don't have these things. It sounded like you hoped we would get rid of them
[13:19:36 CDT(-0500)] <anastasiac> clearly, that's not what you meant
[13:19:48 CDT(-0500)] <colinclark> no no
[13:19:52 CDT(-0500)] <colinclark> sorry if i was unclear
[13:19:56 CDT(-0500)] <colinclark> our components are cool
[13:20:23 CDT(-0500)] <colinclark> I buy Justin_o's ultimate argument that they probably should be better modularized
[13:20:34 CDT(-0500)] <colinclark> and allowed to grow and be selected a bit more independently
[13:20:47 CDT(-0500)] <colinclark> But I think the only way to do that with an awesome user experience is to have a really hot Builder
[13:21:13 CDT(-0500)] <colinclark> and unless someone's got an exciting weekend project that they want to work on, I don't see it happening right now
[13:21:38 CDT(-0500)] <colinclark> I think michelled's point is really much less about identity, and much more about how we can avoid breaking stuff that we think is worthwhile
[13:21:48 CDT(-0500)] <colinclark> I suspect our notion of "worthwhile" plays into this a lot
[13:21:55 CDT(-0500)] <colinclark> things that don't feel important don't get a lot of attention
[13:23:33 CDT(-0500)] <michelled> yeah, although it does help to have the long term vision of eventually moving the components outside and having an awesome builder
[13:24:07 CDT(-0500)] <colinclark> Someday, it will be great
[13:24:25 CDT(-0500)] <Bosmon> Everywhere, there will be jetpack sluggs
[13:24:31 CDT(-0500)] <colinclark> lol
[13:24:34 CDT(-0500)] <michelled> so, it seems pretty clear with that vision that we don't want DT or really any future component in the Infusion repo
[13:24:52 CDT(-0500)] <Bosmon> michelled - I might draw the line at saying "any future component"
[13:24:59 CDT(-0500)] <Bosmon> It depends a lot on what its dependency profile and usage model is
[13:25:02 CDT(-0500)] <colinclark> I'm not sure it's so much a case of "any future component"
[13:25:04 CDT(-0500)] <colinclark> ha
[13:25:04 CDT(-0500)] <colinclark> but I'd defer to Justin_o
[13:25:09 CDT(-0500)] <colinclark> yes, I think that's a fairly pragmatic approach
[13:25:35 CDT(-0500)] <colinclark> my impression was that Justin_o hoped that we would avoid putting large new components into Infusion if it was viable to separate them
[13:25:46 CDT(-0500)] <michelled> I'm good with DT being developed in the GPII repo, but there are other concerns if we go that route - namely, how do we work?
[13:25:46 CDT(-0500)] <Bosmon> That seems reasonable
[13:26:04 CDT(-0500)] <Bosmon> I don't think we have any upcoming plans for "new components" although this might well change with the P4A work
[13:26:06 CDT(-0500)] <michelled> we currently have a very clear process for getting things into the infusion repo
[13:26:23 CDT(-0500)] <michelled> with a clear list of code reviewers and final committers
[13:26:31 CDT(-0500)] <Bosmon> For example things like a tree control or a general-purpose JSON editor might well end up in the core repo under our current model
[13:26:59 CDT(-0500)] <colinclark> michelled: yes
[13:27:17 CDT(-0500)] <colinclark> The list of committers is different in the GPII repository
[13:28:34 CDT(-0500)] <colinclark> Any suggestions for how to approach that?
[13:28:42 CDT(-0500)] <michelled> yeah, I guess in terms of the current DT sprinting team, only Yura would be able to code review and commit
[13:29:06 CDT(-0500)] <colinclark> I guess you could have a fork of the prefsEditor repo in the fluid-project space and do most of your detailed reviews there
[13:29:19 CDT(-0500)] <Bosmon> I expect to be around too
[13:29:21 CDT(-0500)] <colinclark> or we could lean on yzen and Bosmon for reviews on their way into the GPII repo
[13:29:26 CDT(-0500)] <Bosmon> And it's a project I expect to be fairly closely involved with
[13:29:31 CDT(-0500)] <colinclark> That will be great
[13:30:17 CDT(-0500)] <colinclark> My first impression is to do a fluid-project fork of prefsEditor
[13:30:17 CDT(-0500)] <colinclark> prefsEditors
[13:30:27 CDT(-0500)] <colinclark> and to do our detailed, fast-moving reviews there
[13:30:34 CDT(-0500)] <Bosmon> that sounds like a good model to me, colinclark
[13:30:41 CDT(-0500)] <colinclark> followed by regular pull requests to the GPII org repo
[13:30:53 CDT(-0500)] <colinclark> to stay very closely in sync (and visibility) with the other preference editors teams
[13:31:05 CDT(-0500)] <colinclark> in that regard, michelled, the DT team can serve as an exemplar
[13:32:20 CDT(-0500)] <michelled> avtar: you know what this means? we'll work on the master branch and we aren't forced to use jenkins
[13:32:44 CDT(-0500)] <avtar> michelled: sorry, i haven't been following the conversation
[13:32:46 CDT(-0500)] <anastasiac> colinclark, it looks like the prefsEditor repo is intended to hold DT, PCP, PMT. If that's right, are there any guidelines for how the content of the repo should be structured? Create a folder called "discoveryTool"? something like that?
[13:32:47 CDT(-0500)] <avtar> on a call at the moment
[13:33:28 CDT(-0500)] <Bosmon> anastasiac - top-level dirs for each major configuration style seems reasonable to me
[13:33:30 CDT(-0500)] <michelled> np avtar - I'll ping you with the repo when we are ready with it
[13:33:44 CDT(-0500)] <anastasiac> there seems to be a single test file for all prefs editors? I imagine we'd change that?
[13:33:55 CDT(-0500)] <Bosmon> I imagine that is just a placeholder
[13:34:32 CDT(-0500)] <Bosmon> Jura generously gave of his time after 11pm the night just before an early morning euro meeting to put together that repo in double-quick time
[13:34:36 CDT(-0500)] <avtar> michelled: http://s3.amazonaws.com/rapgenius/1291131680_two-thumbs-up.jpg
[13:35:02 CDT(-0500)] <colinclark> I like your new sunglasses, avtar
[13:35:25 CDT(-0500)] <avtar> just trying new things
[13:37:03 CDT(-0500)] <michelled> avtar: here it is: https://github.com/fluid-project/prefsEditors
[13:37:10 CDT(-0500)] <anastasiac> colinclark, would issue tracking for this be in the GPII issue tracker, or still FLUID? would this be under FLUID jiura, or a GPII one?
[13:37:47 CDT(-0500)] <michelled> I think we'll expect to get pull requests to the master branch of that repo and then will make pull requests back up to the GPII repo. what do you think Justin_o?
[13:39:27 CDT(-0500)] <colinclark> hmm, that's a good question, anastasiac
[13:39:40 CDT(-0500)] <colinclark> I don't see a huge advantage one way or another
[13:39:49 CDT(-0500)] <colinclark> does anyone else?
[13:39:56 CDT(-0500)] <Bosmon> Logically, these should be GPII JIRAs, if the upstream repo is with the GPII
[13:40:34 CDT(-0500)] <Justin_o> Bosmon: i agree with that
[13:41:02 CDT(-0500)] <Justin_o> michelled: i think that makes sense, but how fine grained do we want things.. should each of our pull requests be matched in kind to one to the gpii repo?
[13:41:29 CDT(-0500)] <Bosmon> Since the review processes are different, there is no need to match pull requests
[13:41:33 CDT(-0500)] <michelled> likely not Justin_o.
[13:41:55 CDT(-0500)] <Bosmon> I imagine there will be fewer, more agglommerated pull requests to GPII than to fluid's fork of it
[13:42:06 CDT(-0500)] <Bosmon> But we would only actually resolve the JIRAs once they hit the upstream repo
[13:42:10 CDT(-0500)] <Justin_o> okay, Bosmon what do you mean by the review processes are different.. is it because they've already been reviewed once?/
[13:42:23 CDT(-0500)] <Bosmon> Justin_o - they have been reviewed once, and the reviewers are different!
[13:42:45 CDT(-0500)] <Bosmon> I imagine GPII review for stuff coming from fluid's fork might be more of just a "rubber-stamping" exercise
[13:42:46 CDT(-0500)] <Justin_o> Bosmon: are the requirements the same?
[13:42:55 CDT(-0500)] <Justin_o> Bosmon: okay
[13:43:13 CDT(-0500)] <Bosmon> We aim for the requirements to be the same
[13:43:18 CDT(-0500)] <anastasiac> using GPII issue tracking makes sense to me. There's a component for the PCP there already, but nothing for the DT. Would it make sense to have one? Who would have perms to create one?
[13:43:28 CDT(-0500)] <Bosmon> As whenever a GPII community member asks us about commit standards, we invariably refer them to Fluid's
[13:43:53 CDT(-0500)] <Justin_o> Bosmon: cool.. that will prevent any confusion
[13:44:15 CDT(-0500)] <Bosmon> Although Christophe has made a dedicated page for this on the GPII wiki
[13:44:57 CDT(-0500)] <Justin_o> can someone post a link to the gpii jira instance
[13:45:23 CDT(-0500)] <Justin_o> so i guess that means we should start moving our liras over there now too
[13:45:27 CDT(-0500)] <anastasiac> Justin_o: http://issues.gpii.net/browse/GPII
[13:45:34 CDT(-0500)] <Justin_o> anastasiac: thanks
[13:45:37 CDT(-0500)] <Bosmon> Justin_o - do we have any JIRAs that refer to this project in particular?
[13:45:43 CDT(-0500)] <Bosmon> The Discovery Tool?
[13:45:56 CDT(-0500)] <anastasiac> yes, we've created at least one or two so far
[13:46:19 CDT(-0500)] <anastasiac> Bosmon, would you have permission to create a Discovery Tool component in the GPII issue tracker?
[13:46:37 CDT(-0500)] <Justin_o> Bosmon: yes as anastasiac says we have a few.. they are showing up on this page now http://wiki.fluidproject.org/display/fluid/Floe+Iteration+Plan
[13:46:37 CDT(-0500)] <Bosmon> It looks like I can
[13:48:47 CDT(-0500)] <Bosmon> anastasiac - ok, it is now there
[13:49:52 CDT(-0500)] <anastasiac> thanks, Bosmon
[13:51:16 CDT(-0500)] <Justin_o> yzen: would you be able to setup the default structure for the prefEditors for us to work with for the DT
[13:51:48 CDT(-0500)] <colinclark> wow this is great
[13:51:56 CDT(-0500)] <colinclark> glad this is going to work
[13:52:00 CDT(-0500)] <yzen> Justin_o: i ll try to find some time, i think a reasonable example is the NPTGathering tool in GPII project
[13:52:12 CDT(-0500)] <colinclark> michelled: Do we need to somehow address your concerns about stuff breaking in Infusion?
[13:52:33 CDT(-0500)] <Bosmon> We could address them by making a release
[13:52:58 CDT(-0500)] <michelled> colinclark: we don't need to talk about this right now, but I'm wondering if we should remove the full page UIOs from the repo
[13:53:26 CDT(-0500)] <colinclark> Bosmon: Can you suggest a good time for cutting an Infusion release?
[13:53:31 CDT(-0500)] <colinclark> That sounds like a smart-assed question
[13:53:33 CDT(-0500)] <colinclark> but it's not
[13:53:40 CDT(-0500)] <Bosmon> colinclark - I believe we could start the process next week
[13:53:46 CDT(-0500)] <Bosmon> As soon as my Pager pull request gets in
[13:53:48 CDT(-0500)] <colinclark> michelled: Could we turn them into tutorials?
[13:54:11 CDT(-0500)] <colinclark> Bosmon: I more meant, "a time when you have someone to help you cut the release'
[13:54:14 CDT(-0500)] <michelled> yes, that would be possible
[13:54:35 CDT(-0500)] <Bosmon> colinclark - surely then that is a question for that person
[13:54:54 CDT(-0500)] <Bosmon> I'm imagining, perhaps, a KINGG
[13:54:57 CDT(-0500)] <Bosmon> So long since we have been ruled over
[13:55:01 CDT(-0500)] <michelled> seems to me we couldn't cut the release until at least the schema work is done
[13:55:02 CDT(-0500)] <colinclark>
[13:55:21 CDT(-0500)] <Bosmon> I think we could cut the release without the schema work
[13:55:30 CDT(-0500)] <colinclark> I think our last idea was to try to limit the release testing to 2 days or something?
[13:55:34 CDT(-0500)] <Bosmon> The question is whether that would be a good use of our time
[13:55:38 CDT(-0500)] <colinclark> Anyway, there's no way we can do that until post-DT sprint
[13:57:09 CDT(-0500)] <colinclark> I think we should do it, though
[13:57:13 CDT(-0500)] <colinclark> Late August?
[13:57:14 CDT(-0500)] <colinclark> When it's hot
[13:57:25 CDT(-0500)] <colinclark> and people are feeling aimless
[13:57:26 CDT(-0500)] <Bosmon> ok
[13:57:40 CDT(-0500)] <colinclark> what do you think, Justin_o?
[13:59:58 CDT(-0500)] <avtar> michelled: i'm free now
[14:00:27 CDT(-0500)] <Justin_o> colinclark: +1 for august.. i don't have any preference right now for when in august, but definitely after the DT sprint
[14:00:34 CDT(-0500)] <colinclark> ok
[14:00:47 CDT(-0500)] <colinclark> inconveniently, I'm on vacation in late august
[14:00:54 CDT(-0500)] <colinclark> as I can imagine some others are
[14:01:05 CDT(-0500)] <colinclark> I think we can probably just squeeze it in whenever we have a few free days
[14:01:14 CDT(-0500)] <colinclark> with whomever happens to be around and interested
[14:01:20 CDT(-0500)] <avtar> michelled: just to confirm, we're using the master branch of this https://github.com/fluid-project/prefsEditors repo?
[14:02:07 CDT(-0500)] <Justin_o> avtar, michelled: i wonder if we'd want to use the one from gpii or if there are plans to build that one already
[14:06:11 CDT(-0500)] <michelled> Justin_o: if we are doing most of our quick development in the fluid repo and then making pull requests to the GPII repo, I'd like to see the Fluid repo build
[14:06:25 CDT(-0500)] <michelled> we could have them both build, that would be fine.
[14:07:14 CDT(-0500)] <michelled> Justin_o: there are fewer reviewers for the GPII repo and it's likely that we will bottleneck there.
[14:09:55 CDT(-0500)] <Justin_o> michelled: okay.. that makes sense.. ultimately if ours is working the gpii one should work as well
[14:11:03 CDT(-0500)] <colinclark> So, michelled is heading off soon for a nice vacation in Cuba
[14:11:11 CDT(-0500)] <colinclark> does anyone need anything from her before she goes?
[14:11:25 CDT(-0500)] <colinclark> now's a good time to ask questions if you don't know what you'll be busy with for the next week or so
[14:11:46 CDT(-0500)] <avtar> dance lessons, please
[14:12:34 CDT(-0500)] <colinclark> IRC dance lessons
[14:12:56 CDT(-0500)] <avtar> michelled: i'll ping Justin_o with the build info
[14:13:25 CDT(-0500)] <Justin_o> michelled: if you could help any cuban baseball players defect and join the blue jays i'd be happy.. we could use the help
[14:13:35 CDT(-0500)] <Justin_o> avtar: thanks
[14:13:46 CDT(-0500)] <colinclark> michelled: Starting pitchers preferred
[14:13:52 CDT(-0500)] <michelled>
[14:14:15 CDT(-0500)] <michelled> avtar: you know there was a groupon for hip hop lessons recently
[14:14:38 CDT(-0500)] <avtar> i kinda like the idea of irc dance lessons now
[14:15:32 CDT(-0500)] <avtar> hope you have a great vacation though
[14:15:50 CDT(-0500)] <michelled> thx
[14:26:22 CDT(-0500)] <Bosmon> yzen - yay KETTOL!
[14:26:47 CDT(-0500)] <yzen> Bosmon: it is a wip though
[14:26:57 CDT(-0500)] <Bosmon> So is everything
[14:27:19 CDT(-0500)] <colinclark> yay kettol?
[14:27:29 CDT(-0500)] <Bosmon> colinclark - https://github.com/GPII/kettle/pull/1/files
[14:27:48 CDT(-0500)] <colinclark> I wonder why I didn't receive an email notification
[14:28:30 CDT(-0500)] <colinclark> this is exciting, yzen
[14:28:55 CDT(-0500)] <colinclark> yzen: I'm glad you decided to include the dataSources, too
[14:29:03 CDT(-0500)] <yzen>
[14:29:12 CDT(-0500)] <yzen> now I'm fixing the tests
[14:29:13 CDT(-0500)] <colinclark> I can't think of a more apt thing to include in Kettle than a component called callbackWrappingPromiseDataSource
[14:29:14 CDT(-0500)] <yzen>
[14:29:37 CDT(-0500)] <Bosmon> Yes
[14:29:50 CDT(-0500)] <Bosmon> I suspect with the new Infusion, that component is no longer necessary
[14:30:16 CDT(-0500)] <Bosmon> Unfortunately I can't seem to find a place to put the KETTOL logo
[14:31:24 CDT(-0500)] <Bosmon> yzen - now that we have the ability to look up any component back to its instantiator in closed form, our network of complex things like ThreadLocals and callbackwrappers is probably unnecessary
[14:31:45 CDT(-0500)] <yzen> it is fun thpugh
[14:32:17 CDT(-0500)] <colinclark> lol
[14:32:23 CDT(-0500)] <colinclark> ThreadLocals are fun?
[14:32:31 CDT(-0500)] <colinclark> Did yzen really just say that?
[14:32:33 CDT(-0500)] <Bosmon> yzen already started on the pills yesterday
[14:32:38 CDT(-0500)] <colinclark> lol
[14:32:39 CDT(-0500)] <Bosmon> Remember what he said about TypeScript : P
[14:32:45 CDT(-0500)] <colinclark> oh yes
[14:32:48 CDT(-0500)] <colinclark> Coolz
[14:33:08 CDT(-0500)] <colinclark> zomg, coolz callbackwrapper
[14:33:10 CDT(-0500)] <yzen> type script is awesome
[14:33:17 CDT(-0500)] <Bosmon> ZOMGGGG!!!!
[14:33:32 CDT(-0500)] <Bosmon> I had forgotten about ZOMGGING : P
[14:34:04 CDT(-0500)] <colinclark> I've been zomging pretty consistently
[14:34:10 CDT(-0500)] <colinclark> Darcie just sort of looks at me like I'm an idiot
[14:34:24 CDT(-0500)] <Bosmon> hahaha
[14:34:38 CDT(-0500)] <colinclark> so why is typescript cool, yzen?
[14:35:01 CDT(-0500)] <yzen> cmon types
[14:35:08 CDT(-0500)] <colinclark> lol
[14:35:20 CDT(-0500)] <colinclark> you rule, yzen
[14:35:33 CDT(-0500)] <colinclark> i'm literally lol'ing
[14:35:36 CDT(-0500)] <colinclark> and zomg'ing
[14:36:19 CDT(-0500)] <colinclark> "In the TypeScript Playground, you can hover over identifiers to see their types."
[14:36:38 CDT(-0500)] <Bosmon> Certainly you'd find it hard to find anyone to argue with the proposition "types are cool"
[14:36:46 CDT(-0500)] <Bosmon> Unless you were to chuck a brick in the channel here : P
[14:41:20 CDT(-0500)] <colinclark> yzen: as far as I'm concerned, Kettle is pretty cool
[14:41:36 CDT(-0500)] <yzen>
[14:51:17 CDT(-0500)] <anastasiac> cindyli, do you know if the UIO modelRelay would allow me to transform something between the panel's internal model and the UIO model? e.g. if the panel has a boolean and I want to translate that into selections.theme of "bw" if true, "default" if false?
[14:52:17 CDT(-0500)] <cindyli> anastasiac: modelRelay doesn't have that ability yet
[14:55:03 CDT(-0500)] <anastasiac> ok, cindyli, so we'd have to do something like the VideoPlayer does, which is define its own modelRelay, right?
[14:55:55 CDT(-0500)] <cindyli> yes, anastasiac
[15:03:51 CDT(-0500)] <michelled> fluid-everyone: anastasiac and I were looking through some open resources and think this one is a good candidate for the DT demo: http://www.ck12.org/physical-science/Electrons-in-Physical-Science/lesson/user%3AamNhcmdpbGxAc3RjbGFpcmN5Y2xvbmVzLm9yZw../Electrons/
[15:04:08 CDT(-0500)] <Justin_o> fluid-everyone: I'm going to set assigned some of our future community meetings for work on a new builder.. we can collaborate together.. this coming wednesday though will have a lot of people away. so i'll start these the week after.. does anyone who will be be around have anything they'd want to cover for next week.. if not we'll just skip it
[15:04:09 CDT(-0500)] <michelled> it's cool because it's got text, pictures, videos and diagrams
[15:05:05 CDT(-0500)] <michelled> also, who can resist extremely dangerous lightning
[15:05:38 CDT(-0500)] <colinclark>
[15:05:54 CDT(-0500)] <colinclark> I'll be interested to hear what jessm and danaayotte and vjoanna think
[15:08:55 CDT(-0500)] <danaayotte> I like electrons
[15:09:22 CDT(-0500)] <colinclark> Do we know what license it's distributed under?
[15:10:19 CDT(-0500)] <michelled> CC non commercial share alike
[15:10:36 CDT(-0500)] <Justin_o> cindyli, yzen: sadly i have to run soon, but could you both go over our schema plans with Bosmon
[15:10:42 CDT(-0500)] <Justin_o> if you have time
[15:10:58 CDT(-0500)] <yzen> Justin_o: k
[15:12:06 CDT(-0500)] <Justin_o> yzen: thanks
[15:12:39 CDT(-0500)] <jessm> i'm imagining an electron game!
[15:13:04 CDT(-0500)] <colinclark> There were several electricity-related PHeT sims
[15:13:16 CDT(-0500)] <colinclark> including the quite remarkable "John Travoltage" sim
[15:13:47 CDT(-0500)] <jessm> OMG yes
[15:13:49 CDT(-0500)] <danaayotte> attraction, or repulsion?? you decide...
[15:13:59 CDT(-0500)] <colinclark> lol
[15:16:31 CDT(-0500)] <colinclark> http://phet.colorado.edu/en/simulation/balloons
[15:17:16 CDT(-0500)] <colinclark> http://phet.colorado.edu/en/simulation/travoltage
[15:22:17 CDT(-0500)] <anastasiac> cindyli, do you know if it's now possible to add modelChanged listeners using the listeners: block of the defaults?
[15:22:46 CDT(-0500)] <Bosmon> anastasiac - it is not
[15:22:52 CDT(-0500)] <Bosmon> THis work is described by http://issues.fluidproject.org/browse/FLUID-4258 which is not yet implemented
[15:23:19 CDT(-0500)] <Bosmon> yzen has a sketch for such a system in one of his UIOptions branches
[15:23:23 CDT(-0500)] <anastasiac> thanks, Bosmon
[15:23:49 CDT(-0500)] <Bosmon> You will see that this is the last unreformed element in my rewrite of your "fiveStar" demo
[15:23:50 CDT(-0500)] <Bosmon> https://github.com/amb26/infusion/blob/db8c7576f59594aeef95516c51c2377ec20ecf94/src/webapp/demos/keyboard-a11y/js/five-star.js
[15:24:22 CDT(-0500)] <colinclark> that'll be hot when yzen's sketch becomes real
[15:27:49 CDT(-0500)] <Bosmon> It will!
[16:34:37 CDT(-0500)] <Bosmon> colinclark - I just wrote up http://issues.fluidproject.org/browse/FLUID-5082
[16:34:45 CDT(-0500)] <Bosmon> I could swear I wrote something about it before, but I don't seem to be able to find it
[16:35:01 CDT(-0500)] <Bosmon> There doesn't seem to be a mailing list post or an existing JIRA
[16:35:59 CDT(-0500)] <colinclark> This seems pretty reasonable to me
[16:36:06 CDT(-0500)] <colinclark> I know we talked about it, probably when I was in Boulder
[16:36:18 CDT(-0500)] <Bosmon> Perhaps I just remember talk
[16:36:24 CDT(-0500)] <colinclark> it could be
[16:36:26 CDT(-0500)] <Bosmon> Although I would swear I ran something past Justin_o
[16:36:32 CDT(-0500)] <colinclark> Anyway, the proposed strategy makes sense to me
[16:36:40 CDT(-0500)] <colinclark> and it seems quite helpful
[16:36:46 CDT(-0500)] <Bosmon> Thanks
[16:37:02 CDT(-0500)] <colinclark> You'll need to store some kind of marker to tell the framework if the namespace was autogenerated?
[16:37:11 CDT(-0500)] <Bosmon> yes
[16:37:18 CDT(-0500)] <Bosmon> It would need a modification to the base framework
[16:37:53 CDT(-0500)] <Bosmon> If two listeners arrive with the same "soft" namespace they simply accumulate as usual
[16:38:13 CDT(-0500)] <Bosmon> If a 3rd one arrives with the same explicitly assigned namespace it clears out all existing ones
[16:38:55 CDT(-0500)] <Bosmon> At least, this is the other result of today's SHOWWER-TTIME THOUGHTS
[16:39:30 CDT(-0500)] <Bosmon> It does seem important to preserve the old invariant that "two people, neither of whom supply a namespace, should not override each other"
[16:40:52 CDT(-0500)] <Bosmon> But it seems crucial to get this in for the "1.9" release or what we will call it, otherwise things like the "fiveStar" demo become unhelpfully incomplete in their current form
[16:41:14 CDT(-0500)] <colinclark> ok, that seems reasonable
[16:41:21 CDT(-0500)] <Bosmon> I didn't want to complicate the configuration by sticking in all these "should-be inferred" namespaces, but without it, the component fails to be completely configurable
[16:41:42 CDT(-0500)] <colinclark> So we're saying that two people who don't explicitly provide namespaces are just completely unaware of each other
[16:41:51 CDT(-0500)] <Bosmon> Yes, that's right
[16:41:56 CDT(-0500)] <colinclark> and thus the second person could not be consciously overriding the other
[16:41:59 CDT(-0500)] <colinclark> fair enough
[16:42:36 CDT(-0500)] <Bosmon> As soon as someone explicitly supplies a namespace, and they happen to "guess right", they succeed in overriding all previous users of that namespace, both auto-generated and explicit
[16:45:45 CDT(-0500)] <colinclark> it makes sense to me
[16:45:51 CDT(-0500)] <Bosmon> cool
[16:49:40 CDT(-0500)] <Bosmon> Since the core components are meant to be "production-grade", I've mostly been putting in the namespaces by hand, when I could remember
[16:49:45 CDT(-0500)] <Bosmon> But once this goes in, I can take them out again