fluid-work IRC Logs-2011-06-13

Owned by Fluid IRC Log Bot
Last updated: Jun 13, 2011Version comment
35 min read

[08:02:15 CDT(-0500)] <heidi_> morning jhung - are you fat panel tabbing this morning?
[08:02:47 CDT(-0500)] <jhung> heidi_: yep.
[08:03:51 CDT(-0500)] <jhung> heidi_: you're working on the tab contents, right?
[08:04:08 CDT(-0500)] <heidi_> jhung yep. think we can get both done before noon?
[08:04:25 CDT(-0500)] <jhung> heidi_: Yes. I hope so.
[08:04:31 CDT(-0500)] <heidi_> i imagine jameswy will have a to-do list for us
[08:04:35 CDT(-0500)] <heidi_> eh james?
[08:06:32 CDT(-0500)] <jameswy> heidi_, jhung: Yep-give me till standup though-working through some things right now
[08:06:47 CDT(-0500)] <heidi_> jameswy works for us- we're fat panelling this morn
[08:07:21 CDT(-0500)] <jameswy> heidi_, jhung: great; where should I look for the latests? heidiv/fluid-4229? or jhung/FULID-4230-jhung ?
[08:08:10 CDT(-0500)] <heidi_> jameswy 4229 full without 4228 full with preview 4230-jhung fat panel but let us know when you'll work on the latter and we'll push up our work
[08:08:31 CDT(-0500)] <jameswy> heidi_: roger that
[08:08:34 CDT(-0500)] <heidi_> the first two are heidiv
[08:08:37 CDT(-0500)] <heidi_> thanks
[08:09:19 CDT(-0500)] <Justin_o> Bosmon4: So I think we started talking about the fatpanel UI Options last friday and some of the issues we were having trying to get the live preview to work, but I'll quickly reiterate those.. since it's been a few days now.
[08:10:30 CDT(-0500)] <Justin_o> Bosmon4: So the goal is to have a panel version of UIO that pulls down from the top. As you are interacting with it and changing settings the page should update automatically, but the UIO panel itself should not be affected. However, if you close the panel and reopen it, the new settings should be applied to it.
[08:12:36 CDT(-0500)] <Justin_o> Bosmon4: So the first approach we are trying is to have the UIO panel in an iframe. This way we can use a pair of UI Enhancers to independently style the UIO panel and the page.
[08:12:40 CDT(-0500)] <Bosmon4> Yes
[08:12:55 CDT(-0500)] <Justin_o> Bosmon4: So mlam and I got as far as injecting the iframe and rendering UIO into it.
[08:13:02 CDT(-0500)] <Bosmon4> My first impression is that this is impossible - and I still suspect that it probably is
[08:13:17 CDT(-0500)] <Bosmon4> It's certainly a risk we should have assessed before we embarked on this design
[08:14:13 CDT(-0500)] <Justin_o> Bosmon4: Could be, here are some of the issues we are having so far. 1) the text field sliders work, but you have to focus them in the iframe and but the mouse pointer has to be outside the iframe to actually move them. 2) the autobinding throws errors when trying to adjust the other settings
[08:14:42 CDT(-0500)] <Justin_o> Bosmon4: Yes.. I guess it is risky.. so far it's the best solution to the issue that we could think of though..
[08:14:55 CDT(-0500)] <Bosmon4> Justin_o - so the first thing we need to investigate is, for 1) whether the problem is caused directly by the slider plugin
[08:15:04 CDT(-0500)] <Bosmon4> That is, whether it can successfully be operated in an iframe at all
[08:15:16 CDT(-0500)] <Justin_o> Bosmon4: makes sense
[08:15:47 CDT(-0500)] <Justin_o> Bosmon4: I can try to whip up a test page for that
[08:15:55 CDT(-0500)] <Bosmon4> I'll look into the autobinding issues for 2) and see if they can be dealt with
[08:16:07 CDT(-0500)] <Bosmon4> But the core issue is - how were you expecting the iframes to communicate?
[08:16:35 CDT(-0500)] <Bosmon4> For example, they each have their own separate copies of jQuery and Fluid
[08:16:50 CDT(-0500)] <Justin_o> Bosmon4: good question.. i think we are hoping that since the code creating these things are on the main page, that they will come with a link between them
[08:16:52 CDT(-0500)] <Bosmon4> Which will lead to a heap of problems in all but the most simple cases
[08:17:05 CDT(-0500)] <Bosmon4> Well, what could this "link" look like? (tongue)
[08:17:51 CDT(-0500)] <Justin_o> Bosmon4: hmm.. i'm imagining something like an umbilical cord
[08:18:42 CDT(-0500)] <Bosmon4> I am just reading "Tristram Shandy" where the author, in one of his random digressions, complains that human beings are not all made of glass
[08:18:57 CDT(-0500)] <Bosmon4> But for some reason observes that, even if they were made of glass, their umbilical cord could not be made of glass...
[08:22:15 CDT(-0500)] <Justin_o> why is it that it could not be made of glass if people were all made of glass?
[08:33:36 CDT(-0500)] <Bosmon4> I'm not sure I understand his argument (smile)
[08:34:05 CDT(-0500)] <Bosmon4> Anyway, in our case, our umbilical cord, even should it exist, which connects our iframes, is not made of glass either....
[08:34:14 CDT(-0500)] <Bosmon4> It will only transmit certain things
[08:34:16 CDT(-0500)] <Bosmon4> If anything (tongue)
[08:34:35 CDT(-0500)] <Bosmon4> Mostly likely, it will only safely transmit things which can be expressed as pure JSON
[08:34:54 CDT(-0500)] <jhung> heidi_: I'm finding an odd issue where I am overriding a background-image with none, but it is not happening even though it is more specific. Any idea?
[08:35:56 CDT(-0500)] <heidi_> jhung is 'none' the correct value
[08:36:47 CDT(-0500)] <jhung> heidi_: yeah according to W3C.
[08:37:29 CDT(-0500)] <heidi_> jhung not sure then, what's over-riding it
[08:37:53 CDT(-0500)] <jhung> heidi_: reading the spec, using background-image: none will set the background to what is specified in the BODY element.
[08:38:02 CDT(-0500)] <jhung> heidi_: I wonder if we have one set...
[08:38:12 CDT(-0500)] <heidi_> hm, not sure
[08:47:00 CDT(-0500)] <jhung> heidi_: ah I figured it out. The background image was original set using a "background" property, and I was attempting to override it using a "background-image" property.
[08:47:01 CDT(-0500)] <Justin_o> Bosmon4: really.. only json.. why is that
[08:47:27 CDT(-0500)] <heidi_> jhung ah yeah. i try to never use 'background' cos it's tricky to over-ride parts of it
[08:47:51 CDT(-0500)] <jhung> heidi_: yeah.
[08:47:59 CDT(-0500)] <Justin_o> heidi_: looked at your FLUID-4215 pull request again. Just one minor change left... there was a duplicate div that I think shouldn't be there..
[08:48:09 CDT(-0500)] <heidi_> Justin_o ack, ok
[08:48:19 CDT(-0500)] <heidi_> i'll fix once i reply to fatima
[08:48:25 CDT(-0500)] <Justin_o> heidi_: thanks
[08:48:31 CDT(-0500)] <Justin_o> once that's done i'll push it in
[08:57:33 CDT(-0500)] <harriswong> Justin_o: What would you want me to add to the tableofcontent's test
[08:58:54 CDT(-0500)] <Justin_o> harriswong: i can't quite remember exactly where we left off.. i think we need to test the compoent itself though
[08:59:24 CDT(-0500)] <Justin_o> so something like init the toc component and make sure that it generates the correct headings and inserts the anchors..
[08:59:48 CDT(-0500)] <harriswong> Justin_o: yes, i think that's where we left off. Should that be inside the TableOfContentTests.js file itself?
[09:00:06 CDT(-0500)] <Justin_o> I think so
[09:00:13 CDT(-0500)] <harriswong> Justin_o: ok, thanks.
[09:01:06 CDT(-0500)] <Justin_o> harriswong: np, thanks{color}
[09:04:38 CDT(-0500)] <Bosmon4> Justin_o - each iframe is a separate "protection domain"
[09:05:06 CDT(-0500)] <Bosmon4> So, as well as having fresh copies of all the fluid and jQuery framework and internals, they also have a fresh copy of the JavaScript object builtIns
[09:06:54 CDT(-0500)] <mlam> Bosmon4, Justin_o, i guess iframes were never intended to share anything outside of itself?
[09:07:24 CDT(-0500)] <Bosmon4> mlam - hard to talk about "intention" with anything to do with HTML and the web (smile)
[09:07:41 CDT(-0500)] <Bosmon4> Certainly they were invented.... and then it was observed they might represent a vast kind of security risk
[09:12:37 CDT(-0500)] <cindyli> michelled: Justin_o, i've sent a pull request for 4171, re-factoring ui options @ https://github.com/fluid-project/infusion/pull/73. one of you might want to take a look? michelled, thanks a lot for the suggestion of save event binding, very helpful.
[09:31:03 CDT(-0500)] <jameswy> heidi_, jhung: heads up on your inbox--list of w/ and w/o preview tweaks incoming
[09:31:39 CDT(-0500)] <heidi_> great, thanks so much jameswy
[09:31:49 CDT(-0500)] <jameswy> Thank you (smile)
[09:42:27 CDT(-0500)] <huslage> hello there
[10:00:46 CDT(-0500)] <jessm> heidi_: nice email re: UIO and FSS on the users list – I found it very helpful (smile)
[10:00:50 CDT(-0500)] <jessm> huslage: greetings
[10:00:56 CDT(-0500)] <heidi_> jessm oh good, thanks
[10:08:08 CDT(-0500)] <Bosmon4> Hi cindyli, michelled - I've had a look through the FLUID-4171 branch and the changes related to the UIEnhancer, and they look good
[10:08:20 CDT(-0500)] <Bosmon4> Although I'm not sure that the idiom for the settingsStore is correct, we should probably leave it for now
[10:08:41 CDT(-0500)] <cindyli> thanks, Bosmon4 or Bosmon
[10:08:50 CDT(-0500)] <Bosmon4> (smile)
[10:08:56 CDT(-0500)] <Bosmon4> It is clearly me, rather than him (tongue)
[10:09:02 CDT(-0500)] <cindyli> (smile)
[10:09:16 CDT(-0500)] <michelled> Bosmon4: what makes you uncomfortable about the settings store?
[10:09:24 CDT(-0500)] <Bosmon4> Well, the abstraction is not really right
[10:09:34 CDT(-0500)] <Bosmon4> For a start, it assumes that whatever the settings store does is synchronous
[10:09:53 CDT(-0500)] <michelled> ah good point
[10:09:57 CDT(-0500)] <Bosmon4> Secondly, it copies the results of the fetch
[10:10:04 CDT(-0500)] <Bosmon4> Rather than just sharing the model with the cooperating component
[10:11:02 CDT(-0500)] <Bosmon4> It's sort of a bit, having the workflow and callbacks being driven from within event code like this
[10:11:11 CDT(-0500)] <Bosmon4> I was going to say, "a bit odd"
[10:11:19 CDT(-0500)] <Bosmon4> But it is really more than a bit odd, it is sort of incorrect (tongue)
[10:14:00 CDT(-0500)] <cindyli> Bosmon4, well, i thought that fetch() wins over sharing model since with fetch(), uiOptions leaves settingsStore to retrieve the settings, without the necessarity of realizing where the settings are saved in the model
[10:14:06 CDT(-0500)] <cindyli> i might be wrong
[10:14:15 CDT(-0500)] <Bosmon4> Also, whilst the "eventBinder" is a good idea, there is no need to specialise it to a "saveEventBinder" in that particular case
[10:14:20 CDT(-0500)] <Bosmon4> After all, it might bind anything (tongue)
[10:14:51 CDT(-0500)] <Bosmon4> cindyli - I think we need both something like fetch() - as well as a sharing model
[10:14:53 CDT(-0500)] <cindyli> ya, thanks
[10:14:58 CDT(-0500)] <Bosmon4> And as well as generalising this to be asynchronous
[10:15:11 CDT(-0500)] <Bosmon4> That is, whatever is fetched by "fetch" should already be considered suitable to be shared
[10:15:35 CDT(-0500)] <Bosmon4> It's very odd to write copy semantics on the OUTSIDE of each fetch call, as well as representing lamentable redundancy of code
[10:16:01 CDT(-0500)] <michelled> I wonder if the copy is a holdover from the past
[10:16:05 CDT(-0500)] <michelled> I wonder if we still require it
[10:18:08 CDT(-0500)] <Bosmon4> Well, it can't be a holdover, since the store didn't even exist in the previous commit (tongue)
[10:18:28 CDT(-0500)] <Bosmon4> It's such a shame that the changeApplier is not ready in this release... since this fetch/save should really just be changeApplier events
[10:18:45 CDT(-0500)] <heidi_> Justin_o 4215 pushed
[10:19:50 CDT(-0500)] <michelled> Bosmon4, cindyli: do you think we should push this into the repo as is or do another round of refactoring?
[10:20:04 CDT(-0500)] <Justin_o> heidi_: thanks
[10:20:30 CDT(-0500)] <heidi_> jhung anything new i should merge into fat panel?
[10:21:38 CDT(-0500)] <cindyli> michelled: let me get rid of fluid.copy
[10:21:44 CDT(-0500)] <huslage> does anyone know what alpha.idrc.ocad.ca was/is running?
[10:24:29 CDT(-0500)] <Bosmon4> michelled - if it works and passes tests, push it
[10:24:44 CDT(-0500)] <Bosmon4> As colinclark frequently observes, we need to "leave room for failure" (smile)
[10:24:54 CDT(-0500)] <colinclark> (smile)
[10:25:54 CDT(-0500)] <Bosmon4> It is never healthy to work for long periods in branches
[10:29:18 CDT(-0500)] <huslage> safari in 10.7 is pretty awesome
[10:45:16 CDT(-0500)] <colinclark> Bosmon4: 1. Code review 2. Kettle
[10:45:28 CDT(-0500)] <colinclark> those are the keys for the next few weeks
[10:45:34 CDT(-0500)] <Bosmon4> v. weww
[10:47:20 CDT(-0500)] <jhung> heidi_: I have some minor changes. I'll push up and then maybe you can help me track down this background colour issue on the selected tab.
[10:47:32 CDT(-0500)] <heidi_> jhung k
[10:47:46 CDT(-0500)] <Bosmon4> Justin_o - should I be looking at your FLUID-3671 branch?
[10:48:08 CDT(-0500)] <Justin_o> Bosmon4: yes please... mlam and I have a test page with the slider.. we can push that up there too
[10:48:22 CDT(-0500)] <Bosmon4> Does it break, or does it work?
[10:48:46 CDT(-0500)] <Justin_o> it works about as well as it does in fat paenl
[10:48:47 CDT(-0500)] <Justin_o> panel
[10:49:12 CDT(-0500)] <Justin_o> we have two sliders 1) that is created inside the iframe (this works fine) 2) one that is rendered into the iframe but created from the parent (this has the same issue)
[10:50:10 CDT(-0500)] <Justin_o> Bosmon4: we just pushed the manual test up
[10:50:31 CDT(-0500)] <Bosmon4> Justin_o - what do you mean by "created from the parent"
[10:51:36 CDT(-0500)] <jhung> heidi_: I've pushed to my branch. Do you have any changes to push out?
[10:52:08 CDT(-0500)] <heidi_> jhung not yet. so what's the issue you're having?
[10:55:54 CDT(-0500)] <jhung> heidi_: If you switch from default to Black on white, you'll see the selected tab background change.
[10:57:00 CDT(-0500)] <heidi_> jhung the width of it or?
[10:58:45 CDT(-0500)] <Justin_o> Bosmon4: i mean that a script on the parent page creates the slider using the dom that is in the iframe
[10:59:27 CDT(-0500)] <Justin_o> Bosmon4: so I think mlam and I have figured out why the mouse sliding works outside of the iframe... it's because it's bound to the document.. which in that case is the parent's document
[11:00:18 CDT(-0500)] <Bosmon4> Yes
[11:00:21 CDT(-0500)] <Bosmon4> This model could never work
[11:00:34 CDT(-0500)] <Bosmon4> As I mentioned, each iframe has its own jQuery, which implies also its own jQuery event dispatcher
[11:00:34 CDT(-0500)] <cindyli> michelled: done with the changes on 4171 pull request, https://github.com/fluid-project/infusion/pull/73
[11:00:50 CDT(-0500)] <Justin_o> Bosmon4: the keyboard events work.. but they seem to just manually update the values and etc. underneath
[11:01:11 CDT(-0500)] <michelled> thx cindyli
[11:01:15 CDT(-0500)] <heidi_> jhung?
[11:01:22 CDT(-0500)] <cindyli> np
[11:01:33 CDT(-0500)] <Bosmon4> Justin_o: The only model that can work reliably is where each frame takes responsibility for its own rendering and event binding
[11:01:41 CDT(-0500)] <Justin_o> Bosmon4: i tried removing the js from within the iframe and it still works the same
[11:02:03 CDT(-0500)] <Justin_o> Bosmon4: yes.. this would make sense.. but we would need a way for them to communicate with each other
[11:02:04 CDT(-0500)] <Justin_o> hmm..
[11:02:08 CDT(-0500)] <Justin_o> maybe we could do that
[11:02:08 CDT(-0500)] <Bosmon4> The two "fluid"s must be NEARLY uncommunicating
[11:02:28 CDT(-0500)] <Bosmon4> The only communication that can start to be established is via global objects, which will be somewhat unstable
[11:03:05 CDT(-0500)] <Justin_o> Bosmon4: i think we only need to communicate the model
[11:03:12 CDT(-0500)] <Bosmon4> There's a small chance that one jQuery.data implementation can understand the products of the other, but based on guesswork from looking at how this implementation works, I think this probably won't work
[11:03:28 CDT(-0500)] <Bosmon4> Justin_o - yes, this is what I referred to earlier about "JSON-equivalent" data
[11:03:39 CDT(-0500)] <Justin_o> Bosmon4: ah i see
[11:03:40 CDT(-0500)] <Bosmon4> Nothing "live" can/should cross the layer between the two frames
[11:03:46 CDT(-0500)] <Bosmon4> That is, no DOM nodes, and no Fluid components
[11:05:07 CDT(-0500)] <Justin_o> Bosmon4: so i guess my question would be, how would the content page know when the model has changed.. since it will have to update on the fly
[11:05:35 CDT(-0500)] <Bosmon4> Yes - somehow some kind of event handler needs to "cross over between the worlds" as part of some globally named variable
[11:05:37 CDT(-0500)] <Bosmon4> It will be pretty nasty
[11:05:40 CDT(-0500)] <jhung> heidi_: sorry. (smile)
[11:05:52 CDT(-0500)] <Bosmon4> And violate all our guidelines on "portal-friendliness"....
[11:06:36 CDT(-0500)] <jhung> heidi_: it's not the width. Actually all the widths are fine now. It's a background colour being applied to the selected list element that's inconsistent with the default style.
[11:07:05 CDT(-0500)] <Bosmon4> Justin_o - another possibility is this approach http://stackoverflow.com/questions/4101457/access-jquery-data-from-iframe-element
[11:07:26 CDT(-0500)] <Bosmon4> This explains that you need to use each frame's OWN jquery to access its own node's data elements
[11:07:47 CDT(-0500)] <Bosmon4> We can push back the problem of global access to the event handler, to becoming one of global access to the jQuery framework
[11:07:55 CDT(-0500)] <Bosmon4> Which I guess is a slightly less severe one, in some views
[11:09:05 CDT(-0500)] <Bosmon4> But we need to be very careful, thinking about usage of UIOptions in environments like uPortal
[11:09:22 CDT(-0500)] <Bosmon4> For example, they may have multiple versions of jQuery, and maybe even multiple versions of Fluid loaded
[11:09:43 CDT(-0500)] <Bosmon4> It's unclear whether it will necessarily be any easier to locate the "right Fluid" than it is to locate the "right jQuery"
[11:09:48 CDT(-0500)] <Justin_o> Bosmon4: right.. i don't think the fatpanel is intended to work in a portal... but i don't think we can prevent that from happening (smile)
[11:10:26 CDT(-0500)] <Justin_o> oh i see.. even if this is the parent page and not any particular portal, it could be a problem
[11:10:41 CDT(-0500)] <Bosmon4> Yes
[11:10:49 CDT(-0500)] <heidi_> jhung line 146 of fatpanel.css is over-riding it
[11:10:53 CDT(-0500)] <heidi_> perhaps you can tweak that?
[11:11:01 CDT(-0500)] <Justin_o> Bosmon4: but won't we know which iframe we're looking in
[11:11:02 CDT(-0500)] <Bosmon4> The central problem with this requirement is that all of our work in namespacing and insulating things with closures goes out of the window
[11:11:12 CDT(-0500)] <Justin_o> you need to get the document of that iframe to find the jquery anyways
[11:11:24 CDT(-0500)] <heidi_> jhung i'm not really sure what it should be
[11:11:24 CDT(-0500)] <Bosmon4> Any integrator of this component will need to be very careful if they expect it to work stably
[11:11:32 CDT(-0500)] <jhung> heidi_: I'll take a look...
[11:11:32 CDT(-0500)] <Bosmon4> Although for many of them it will just "work out of the box"
[11:11:43 CDT(-0500)] <heidi_> jhung it looks like it's working fine to me
[11:11:46 CDT(-0500)] <Bosmon4> If they just include jQuery and Fluid from one of our standard builder bundles, everything will be fine
[11:12:03 CDT(-0500)] <Bosmon4> But, for example, if one of them calls "jQuery.noConflict()" then all hell breaks loose
[11:12:09 CDT(-0500)] <heidi_> jhung do you want to skype and show me what it does on yr end?
[11:12:16 CDT(-0500)] <jhung> heidi_ sure
[11:13:20 CDT(-0500)] <Bosmon4> I guess we can say that the iframe with the control in it is COMPLETELY under our control
[11:13:30 CDT(-0500)] <Bosmon4> In which case, the global object structure inside it will be exactly the one we say it is
[11:13:33 CDT(-0500)] <Justin_o> Bosmon4: yes.. this is what i was thinking
[11:13:55 CDT(-0500)] <Bosmon4> In that case, we can rely on it to be addressible from outside the iframe in the "standard way"
[11:14:17 CDT(-0500)] <Bosmon4> That is, jQuery as public jQuery, and public fluid as representing the only version of fluid which is loaded into the iframe
[11:17:58 CDT(-0500)] <Justin_o> Bosmon4: yes.. so does this seem doable in a somewhat moral way?
[11:18:05 CDT(-0500)] <Bosmon4> It's conceivable (tongue)
[11:18:29 CDT(-0500)] <Bosmon4> Although we will probably need a fair amount of IoC stuff to accommodate the fact that the component is "split in two" in this configuration
[11:19:12 CDT(-0500)] <Bosmon4> It might not be too bad - we might just need to hack off the place we were just talking about with cindyli this morning
[11:19:28 CDT(-0500)] <Justin_o> Bosmon4: i missed that
[11:19:34 CDT(-0500)] <Bosmon4> The "settings store" which is notified from several places in UIOptions
[11:19:51 CDT(-0500)] <Justin_o> Bosmon4: so a shared store?
[11:20:28 CDT(-0500)] <Bosmon4> Well, the store cannot be shared
[11:20:35 CDT(-0500)] <Bosmon4> There needs to be a kind of "event relayer" put between the two components
[11:21:22 CDT(-0500)] <Bosmon4> Which is why it would be so much better if the settings store were operated via events.... we will need to stage "moon landings" for now to deal with the fact it isn't
[11:21:56 CDT(-0500)] <Bosmon4> Who knows, it may actually turn out to be safe to share the object reference to the same settings store, but we shouldn't count on it
[11:27:16 CDT(-0500)] <Justin_o> Bosmon4: interesting.. so what approach do you think should be taken
[11:27:26 CDT(-0500)] <Justin_o> i guess i'm wondering how the "moon landings" will work
[11:29:26 CDT(-0500)] <colinclark> I guess we may be able to explore events built into the underlying storage mechanism...
[11:29:52 CDT(-0500)] <colinclark> I haven't really considered whether there are existing events for cookies or local data storage, for example
[11:29:57 CDT(-0500)] <colinclark> but there may be
[11:31:01 CDT(-0500)] <Bosmon4> So - the other half of this problem occurs to me now
[11:31:15 CDT(-0500)] <Bosmon4> We need to be able to supervise the construction of the UIOptions tree on one side of the fence, from the other
[11:31:30 CDT(-0500)] <Bosmon4> That is, the configuration structure created in this world, needs to be sent "over there"
[11:31:38 CDT(-0500)] <Bosmon4> colinclark will appreciate this problem, as a loyal FRINGE fan (tongue)
[11:31:52 CDT(-0500)] <Justin_o> Bosmon4: could we inject a script block into the iframe?
[11:32:05 CDT(-0500)] <Bosmon4> Justin_o - and what would it contain?
[11:33:07 CDT(-0500)] <Justin_o> Bosmon4: i guess that depends on what is left on the parents sidde
[11:33:51 CDT(-0500)] <Bosmon4> Anyway, constructing script blocks by hand is an error-prone mess
[11:34:02 CDT(-0500)] <Bosmon4> I suggest what there should be is a kind of "general construction relayer"
[11:34:23 CDT(-0500)] <Bosmon4> Something which listens to a particular event sent from the parent, whose argument is the configuration for a component
[11:34:34 CDT(-0500)] <Bosmon4> It constructs the component, and then returns the result
[11:35:37 CDT(-0500)] <Justin_o> Bosmon4: i guess i'm not sure how this is so different than what we were trying already..
[11:35:40 CDT(-0500)] <cindyli> michelle, i pushed a bit more improvements into the pull request for 4171, according to anastasiac's finding that the demands block for fluid.uiOptions.preview can actually be gotten rid of. thanks, anastasiac
[11:35:49 CDT(-0500)] <Justin_o> Bosmon4: won't we have the same problem?
[11:36:04 CDT(-0500)] <Bosmon4> To be super-slick, you could then wrap this function as a publically-named function on the parent's side, so that you can refer to it directly in the IoC tree
[11:36:09 CDT(-0500)] <michelled> ok cindyli - is that the last push for 4171 then?
[11:36:25 CDT(-0500)] <Bosmon4> Justin_o - just because the whole tree is returned, doesn't mean we will make use of it all
[11:36:37 CDT(-0500)] <Bosmon4> The implementation will need to "use discretion" in choosing the safe parts of the tree to bind to
[11:37:05 CDT(-0500)] <cindyli> so far it is. (smile)
[11:37:40 CDT(-0500)] <Bosmon4> Anyone looking at this tree with the proper training, will see a slight distorted yellow glow surrounding it, indicating it comes from the "other side" (tongue)
[11:37:51 CDT(-0500)] <colinclark> (smile)
[11:38:01 CDT(-0500)] <michelled> cindyli: I guess I'm wondering if I should push this to the project repo now of whether you are still working on it (smile)
[11:38:10 CDT(-0500)] <colinclark> Not to neglect the fact that the proper training may involve some LSD
[11:38:25 CDT(-0500)] <cindyli> michelled: that's all so far in my mind
[11:38:34 CDT(-0500)] <Justin_o> colinclark: i don't think we'll be able to ship that with our release
[11:38:39 CDT(-0500)] <colinclark> lol
[11:38:49 CDT(-0500)] <Bosmon4> hahahaha
[11:39:04 CDT(-0500)] <Bosmon4> Or perhaps even stiffer drugs
[11:39:33 CDT(-0500)] <Bosmon4> "Cortexifan" ...
[11:39:38 CDT(-0500)] <colinclark> (smile)
[11:39:46 CDT(-0500)] <colinclark> Fringe nerdity aside...
[11:40:03 CDT(-0500)] <colinclark> Justin_o, it sounds like you need more details to implement something like this
[11:40:11 CDT(-0500)] <Justin_o> colinclark: yes
[11:42:02 CDT(-0500)] <michelled> cindyli: ok, it's pushed into the project repo
[11:42:03 CDT(-0500)] <Bosmon4> We can call the part of the tree that "comes back from the other side" the "Peter tree" ....
[11:44:14 CDT(-0500)] <colinclark> (smile)
[11:44:42 CDT(-0500)] <colinclark> Bosmon4: What's the best way to start to break down the architecture with Justin_o, so you can both start to explore it and implement it?
[11:44:47 CDT(-0500)] <cindyli> thanks, michelled
[11:44:52 CDT(-0500)] <Bosmon4> Just like the real one, he will have two different parent component trees competing to be his "father"...
[11:45:37 CDT(-0500)] <Bosmon4> colinclark - I guess we need to vet the existing UIOptions component hierarchy, so we can be clear about which things we will need to have "two of" - and where the "other-worldly tree" will fit in
[11:46:15 CDT(-0500)] <Bosmon4> The wrapper function "fluid.fatPanelUIOptions" will need to become quite complex
[11:46:56 CDT(-0500)] <Bosmon4> Part of its configuration will be instantiated directly, and part of it will go to the "other world" and come back
[11:47:22 CDT(-0500)] <heidi_> jhung your tab fix up incl the reset button?
[11:47:37 CDT(-0500)] <colinclark> Bosmon4 and Justin_o: I guess the issue of time really starts to surface here
[11:48:08 CDT(-0500)] <colinclark> We know that Walter and Belly dedicated decades to their dimension-hopping research
[11:48:21 CDT(-0500)] <Bosmon4> hahaha
[11:48:39 CDT(-0500)] <colinclark> Justin_o: I guess our next most promising option was to ask implementers of the component to make the fat panel version a sibling to all of their content
[11:48:59 CDT(-0500)] <colinclark> so that we could safely target class name manipulations on an element separate from UIO itself
[11:49:06 CDT(-0500)] <colinclark> This is, we know a pretty sub-optimal situation
[11:49:35 CDT(-0500)] <colinclark> but are we better to pursue it over some pretty experimental world-crossing schemes with iFrames for this release?
[11:49:45 CDT(-0500)] <colinclark> Thinking of our desire to freeze by the end of the week
[11:50:12 CDT(-0500)] <Justin_o> colinclark: do we need fatpanel for this release?
[11:50:18 CDT(-0500)] <Justin_o> maybe that's a jameswy question
[11:50:20 CDT(-0500)] <colinclark> hmm
[11:50:33 CDT(-0500)] <colinclark> I'd be pretty worried if we decided dump the fat panel altogether
[11:50:38 CDT(-0500)] <colinclark> that would leave us only with the whole-page option?
[11:50:48 CDT(-0500)] <Justin_o> colinclark: yes
[11:51:24 CDT(-0500)] <colinclark> Maybe jameswy's priorities will be a surprise to me, but I am quite concerned about shipping a UIO that doesn't itself exhibit our core value of flexible presentation
[11:51:42 CDT(-0500)] <colinclark> But, hey, we've got to ship at some point (wink)
[11:52:02 CDT(-0500)] <Justin_o> colinclark: that's sort of the reason why i'd be worried about shipping a suboptimal solution
[11:52:05 CDT(-0500)] <Bosmon4> I'm looking at the design mockups here - does fatpanel really behave differently to skinny panel in this regard?
[11:52:07 CDT(-0500)] <colinclark> Justin_o: Are you saying that you think it's preferable to not ship with Fat Panel than to do the "wrapped siblings" solution?
[11:52:27 CDT(-0500)] <colinclark> Bosmon4: No, it's just that we already decided not to ship the skinny panel for this release
[11:52:35 CDT(-0500)] <Bosmon4> ah ok, thanks
[11:53:03 CDT(-0500)] <jameswy> colinclark, Justin_o: Is it an issue with the live preview?
[11:53:05 CDT(-0500)] <Justin_o> colinclark: i'm not set either way... but am thinking of it now
[11:53:14 CDT(-0500)] <colinclark> Justin_o: sure, that's reasonable
[11:53:20 CDT(-0500)] <Justin_o> jameswy: well.. it's all based on that
[11:53:37 CDT(-0500)] <colinclark> jameswy: The problem is the apparent complexity of not styling UIO, but styling the rest of the page
[11:54:01 CDT(-0500)] <colinclark> It's turning out to be quite difficult in a model where we say "keep your page as it is, but just toss in UI Options"
[11:54:18 CDT(-0500)] <Bosmon4> Well, we are still shipping the "dialog model" configuration, right?
[11:54:20 CDT(-0500)] <jameswy> I mentioned toward the end of last week that if there's a problem with the timing of when the options get applied to the page, we can look into design alternatives to work around it for this release.
[11:54:36 CDT(-0500)] <Bosmon4> "full page" as its called
[11:54:42 CDT(-0500)] <colinclark> Bosmon4: There are two configurations we've been planning...
[11:54:44 CDT(-0500)] <colinclark> the panel
[11:54:51 CDT(-0500)] <colinclark> of which there are two flavours, and we'll ship the fat flavour
[11:55:06 CDT(-0500)] <colinclark> and the full page, which is designed to be placed on a page in itself
[11:55:15 CDT(-0500)] <colinclark> with a separate Preview area, etc.
[11:55:34 CDT(-0500)] <colinclark> The key to the panel versions is that they just interact with the page directly
[11:55:34 CDT(-0500)] <Bosmon4> ok
[11:56:02 CDT(-0500)] <Bosmon4> But what do we mean by "on a page in itself"?
[11:56:13 CDT(-0500)] <Bosmon4> It's still conceivable that this could come up as a "very large dialog"?
[11:56:23 CDT(-0500)] <colinclark> That's conceivable
[11:56:30 CDT(-0500)] <colinclark> but dialogs are often really quite terrible
[11:56:43 CDT(-0500)] <colinclark> the elegance of the panelized versions is that they're not modal
[11:56:48 CDT(-0500)] <colinclark> they're just there, along with the rest of the page
[11:56:53 CDT(-0500)] <Bosmon4> Yes
[11:57:01 CDT(-0500)] <Bosmon4> I guess we face a difficult range of choices
[11:57:22 CDT(-0500)] <colinclark> jameswy: I'm a bit hesitant in this case to push out some kind of design compromise for the sake of shipping asap
[11:57:44 CDT(-0500)] <colinclark> Assuming that the panelized versions really do represent a preferred idiom
[11:57:47 CDT(-0500)] <colinclark> which I think they do
[11:58:05 CDT(-0500)] <colinclark> I mean, I'm interested in your ideas for design alternatives as workarounds
[11:58:14 CDT(-0500)] <Bosmon4> Perhaps the "world relay" solution wouldn't be too vast to take on
[11:58:22 CDT(-0500)] <Bosmon4> But we should be prepared for a lot of susprises
[11:58:26 CDT(-0500)] <Bosmon4> surprises
[11:58:45 CDT(-0500)] <colinclark> But if it's just a workaround, it'll precipitate the need to cut a 1.5 afterwards to address the real design goals
[11:58:51 CDT(-0500)] <colinclark> which is also not ideal
[11:59:05 CDT(-0500)] <colinclark> Bosmon4: I suspect your right, in regards to surprises
[11:59:34 CDT(-0500)] <colinclark> you're
[11:59:39 CDT(-0500)] <colinclark> awful
[11:59:42 CDT(-0500)] <colinclark> terrible
[12:00:07 CDT(-0500)] <colinclark> wait
[12:00:12 CDT(-0500)] <colinclark> you're not awful
[12:00:16 CDT(-0500)] <colinclark> my grammar mistake was awful
[12:00:24 CDT(-0500)] <colinclark> i'll stop typing now
[12:00:30 CDT(-0500)] <colinclark> (smile)
[12:01:40 CDT(-0500)] <Bosmon4> Please don't, we need a continuingly TYPING CATT (tongue)
[12:01:49 CDT(-0500)] <Bosmon4> So - I guess we should draw up our list of options
[12:02:06 CDT(-0500)] <Bosmon4> Make some guess about how great their costs are, either in terms of design compromise or development
[12:02:26 CDT(-0500)] <Bosmon4> I guess it is looking now like the "sibling approach" really is a reasonable compromise for this release
[12:02:52 CDT(-0500)] <colinclark> I'm just musing aloud to the King
[12:02:56 CDT(-0500)] <colinclark> sorry, I should have mused aloud here
[12:02:59 CDT(-0500)] <Bosmon4> I hadn't looked at our current range of design choices in detail recently...
[12:03:14 CDT(-0500)] <colinclark> I feel very hesitant to push out a release that makes compromises on either
[12:03:20 CDT(-0500)] <Bosmon4> But I don't think that i) we can ship a component without some form of live preview
[12:03:20 CDT(-0500)] <colinclark> a) interaction polish
[12:03:26 CDT(-0500)] <colinclark> b) implementer user experience
[12:03:39 CDT(-0500)] <colinclark> it seems to me that compromising our panel design causes a)
[12:03:52 CDT(-0500)] <colinclark> and possibly the sibling approach risks b)
[12:03:54 CDT(-0500)] <Bosmon4> or ii) fail to ship a component which can be dropped into a markup page non-modally
[12:03:57 CDT(-0500)] <colinclark> yes
[12:04:02 CDT(-0500)] <colinclark> we're on the same page here!
[12:04:05 CDT(-0500)] <Bosmon4> hahaha
[12:04:05 CDT(-0500)] <colinclark> though you with roman numerals
[12:04:21 CDT(-0500)] <colinclark> jameswy: We need you here a bit, boss
[12:04:29 CDT(-0500)] <Bosmon4> Though I with Roman Numerals, and you as KING PENGUIN!
[12:04:40 CDT(-0500)] <colinclark> I was saying to Justin_o that I'm hesitant to push out a release to meet a deadline
[12:04:50 CDT(-0500)] <colinclark> only to cause us to have to ship again to fix workarounds in, say, a month
[12:04:54 CDT(-0500)] <Bosmon4> ok
[12:04:55 CDT(-0500)] <colinclark> QA is a fixed cost
[12:05:03 CDT(-0500)] <colinclark> so we may be better to hold for awesomeness
[12:05:07 CDT(-0500)] <Bosmon4> In THAT case, I see our option as simply embarking on the task of WORLD RELAY
[12:05:08 CDT(-0500)] <colinclark> within a single QA cycle
[12:05:13 CDT(-0500)] <Bosmon4> And accept whatever costs it brings to us
[12:05:20 CDT(-0500)] <colinclark> rather than iterate towards awesomeness, causing multiple QA cycles
[12:05:29 CDT(-0500)] <colinclark> though I realize what I'm saying is pretty risky
[12:05:36 CDT(-0500)] <colinclark> michelled is probably raising an eyebrow or two
[12:05:46 CDT(-0500)] <Bosmon4> I guess we should think about how this affects our choices for our DC demo next month
[12:06:04 CDT(-0500)] <Bosmon4> In some ways this might be good, if our resources are not used for QA between now and then (smile)
[12:06:11 CDT(-0500)] <colinclark> (smile)
[12:06:14 CDT(-0500)] <jameswy> Ah, so, higher upfront cost. More on the downpayment, less on the interest.
[12:06:19 CDT(-0500)] <Bosmon4> A demo is just a demo after all
[12:06:24 CDT(-0500)] <colinclark> jameswy: (smile)
[12:06:52 CDT(-0500)] <colinclark> Bosmon4: Yeah, the DC thing is interesting, and I do think it release
[12:07:01 CDT(-0500)] <colinclark> since presumably we will want to use a polished UIO as part of it
[12:07:06 CDT(-0500)] <colinclark> We're also not officially on the hook for a demo
[12:07:12 CDT(-0500)] <colinclark> just "white papers"
[12:07:26 CDT(-0500)] <colinclark> My approach has been to favour backing up talk with some illustration
[12:07:36 CDT(-0500)] <colinclark> otherwise talk is just an opportunity for confusion (wink)
[12:07:47 CDT(-0500)] <Bosmon4> Yes well... by mid-July, the interaction might well be polished
[12:07:49 CDT(-0500)] <Bosmon4> Just not QAed (tongue)
[12:10:25 CDT(-0500)] <colinclark> jameswy: I guess the first thing is to confirm that the panelized experience, as you've designed it so far, is really where we want to be
[12:10:36 CDT(-0500)] <colinclark> in other words, if we were to come up with some novel design workarounds for this release
[12:10:50 CDT(-0500)] <colinclark> will we still ultimately want to solve the real problem?
[12:11:02 CDT(-0500)] <colinclark> that is, our ability to transform "the page" without affecting UIO
[12:11:13 CDT(-0500)] <colinclark> If that's the case, then I'm tempted to pursue the real solution
[12:11:37 CDT(-0500)] <colinclark> Bosmon4, Justin_o: On your end, you guys hold some of the keys to implementer user experience...
[12:12:00 CDT(-0500)] <colinclark> do you think implementation some kind of universe-crossing solution will be too complex, or cause confusion amongst users of the component?
[12:12:13 CDT(-0500)] <Bosmon4> colinclark - hopefully this will be nothing that bothers our users
[12:12:27 CDT(-0500)] <Bosmon4> The "hidden world" is intended to be something self-contained, as an implementation detail of the system
[12:12:43 CDT(-0500)] <Bosmon4> It may well confuse US though
[12:13:08 CDT(-0500)] <Justin_o> Bosmon4: okay.. i'd just want to make sure that an integrator will be able to easily configure UI Options still.. without constantley breaking it
[12:13:21 CDT(-0500)] <Bosmon4> Since the wrapping function for the creator will do something like the shenanigans that fluid.uploader does with its options, only somewhat worse
[12:13:27 CDT(-0500)] <colinclark> yeah
[12:13:43 CDT(-0500)] <jameswy> colinclark: Yes, ultimately, I think we still want the experience of transforming the page without affecting UIO. The alternatives are: a) the status quo (affect UIO and the page simultaneously, in which case we risk UI seasickness), or b) slip in a user-triggered delay to all the effects (a la full page preview-- "save and apply")
[12:13:59 CDT(-0500)] <colinclark> Our analogous solution is quite confusing, Bosmon4 (smile) (fluid.uploader, I mean)
[12:14:24 CDT(-0500)] <colinclark> jameswy: ok
[12:14:25 CDT(-0500)] <Bosmon4> colinclark - yes
[12:14:31 CDT(-0500)] <colinclark> so a slight variation on the question, then
[12:14:58 CDT(-0500)] <colinclark> if we waited six months, between 1.4 and 1.5, with one of these workarounds in place (either seasickness or "save and apply")
[12:15:14 CDT(-0500)] <colinclark> how much of a barrier to UIO being awesome is it?
[12:15:19 CDT(-0500)] <colinclark> if you know what I mean
[12:15:36 CDT(-0500)] <jameswy> I wish I had an awesomeness scale... (tongue)
[12:15:41 CDT(-0500)] <colinclark> lol
[12:15:42 CDT(-0500)] <colinclark> yeah
[12:15:43 CDT(-0500)] <colinclark> me too
[12:15:43 CDT(-0500)] <Bosmon4> colinclark - although it is somewhat simpler if we just neglect the case for now that someone wants to create a fat panel UI Options component via IoC
[12:15:53 CDT(-0500)] <colinclark> true, Bosmon4
[12:15:57 CDT(-0500)] <Bosmon4> I guess it is simpler overall, since we don't need the thing to actually be "polymorphic"
[12:16:07 CDT(-0500)] <colinclark> So, I guess I'll summarize some of our goals...
[12:16:08 CDT(-0500)] <Bosmon4> The real complexity in fluid.uploader comes from the fact that we expect the name fluid.uploader to be stable
[12:16:16 CDT(-0500)] <Bosmon4> Even if it creates something totally different each time
[12:16:22 CDT(-0500)] <colinclark> Short term, our goal is to get Infusion 1.4 out the door--it's got lots of great things in it
[12:16:39 CDT(-0500)] <colinclark> Where "Infusion 1.4" is actually defined as a really good refresh of UIO and FSS
[12:16:45 CDT(-0500)] <Bosmon4> Whereas I think we can legitimately tell our users to just use the name "fluid.fatPanelUIOptions" for now, if they actually want a fat panel solution
[12:16:46 CDT(-0500)] <jameswy> Seasickness is would be terrible. That won't do. "Save and apply" is a good stop-gap and isn't terrible. If anything, it'd be conventional. But I think a fully functional live preview would be really fantastic indeed.
[12:17:01 CDT(-0500)] <colinclark> Medium term, though, I think we're trying to shift a little bit...
[12:17:10 CDT(-0500)] <colinclark> we need to get to the point where we're actually using our own tools
[12:17:25 CDT(-0500)] <colinclark> assembling them in ways where people can actually see our vision for personalization in action
[12:18:10 CDT(-0500)] <colinclark> We need to get ourselves to a position where we can offer content-things like our web sites, our learning tools such as the Design Handbook and the Inclusive Learning Handbook-in a beautiful and personalizable way
[12:18:33 CDT(-0500)] <Bosmon4> Yes, that seems very important
[12:18:41 CDT(-0500)] <colinclark> So, I'm thinking worst case scenario here
[12:19:12 CDT(-0500)] <colinclark> which can probably be translated, given my level of general optimism, into "general pragmatism"
[12:19:20 CDT(-0500)] <Bosmon4> I pointed someone to one of our resources once, and he was surprised it didn't even adapt to the fact he was on a mobile device
[12:19:29 CDT(-0500)] <Bosmon4> Let alone show any more subtle form of adaptibility (tongue)
[12:19:44 CDT(-0500)] <colinclark> That we spend the next six months, leading from a nice demo in D.C. for July into a personalized instance of the Inclusive Learning Handbook in fall...
[12:19:59 CDT(-0500)] <colinclark> and won't really have an opportunity to push out a new UIO or Infusion in the interim
[12:20:06 CDT(-0500)] <colinclark> even if we ourselves need them
[12:20:19 CDT(-0500)] <colinclark> Bosmon4: Yes, exactly!
[12:20:25 CDT(-0500)] <colinclark> We need to start with the basics and keep going
[12:20:42 CDT(-0500)] <colinclark> So, jameswy, in that situation
[12:20:55 CDT(-0500)] <Bosmon4> I guess we should try to push out 1.4 in somewhat less than 6 months - if only for users like athena7
[12:20:56 CDT(-0500)] <colinclark> where you'll be busy designing the next steps in personalized learning
[12:21:15 CDT(-0500)] <colinclark> Bosmon4: Oh for sure
[12:21:17 CDT(-0500)] <colinclark> I was meaning 1.5
[12:21:32 CDT(-0500)] <Bosmon4> My guess is we could push out a framework with a "proper" UI Options for something like July 31st
[12:21:39 CDT(-0500)] <Bosmon4> What do you think?
[12:21:49 CDT(-0500)] <colinclark> how bad a position would we be in if we just shipped "save and apply" and focused on "making things" for the next 6 months or so?
[12:22:07 CDT(-0500)] <colinclark> I'd defer to Justin_o and co. on that question
[12:22:34 CDT(-0500)] <Justin_o> colinclark: we'd probably have to support both types
[12:22:43 CDT(-0500)] <Bosmon4> My opinion is that "save and apply" would be pretty poor - but "IANAD"
[12:22:48 CDT(-0500)] <Bosmon4> I Am Not A Designer
[12:23:18 CDT(-0500)] <jameswy> colinclark: It wouldn't be a "bad" position per se... just not great. Getting it working the way it was designed to would still be best, for all places where we make it work.
[12:23:25 CDT(-0500)] <jameswy> I should note one thing:
[12:24:35 CDT(-0500)] <jameswy> The whole premise of having the fat & skinny panels over the full page versions is that you do get that live effect. Putting in the stop gap is really raining on the purpose of having a fat/skinny panel.
[12:24:45 CDT(-0500)] <huslage> Bosmon4: i read that as "I A NAD"
[12:24:46 CDT(-0500)] <huslage> which made me laugh
[12:25:03 CDT(-0500)] <colinclark> lol
[12:25:04 CDT(-0500)] <huslage> apparently i never left high school
[12:25:07 CDT(-0500)] <colinclark> lol
[12:25:25 CDT(-0500)] <colinclark> Justin_o, jameswy: There's something else lurking here...
[12:25:25 CDT(-0500)] <huslage> installing over a remote console is for the birds, FYI.
[12:25:35 CDT(-0500)] <colinclark> I'm thinking about a) and b) again
[12:25:44 CDT(-0500)] <colinclark> a) === "interaction experience"
[12:25:52 CDT(-0500)] <colinclark> b) === "implementer experience"
[12:25:58 CDT(-0500)] <colinclark> there may well be other bits of polish lurking
[12:26:08 CDT(-0500)] <colinclark> we know we've made some compromises on b) in order to ship on time
[12:26:23 CDT(-0500)] <colinclark> I think anastasiac's experience learning how to add new controls and panels to UIO will be enlightening
[12:26:29 CDT(-0500)] <colinclark> and I can imagine that we can live with some rough edges here
[12:26:48 CDT(-0500)] <colinclark> but ideally we'll leave ourselves in a good enough situation for 1.4 that we don't feel a burning fire to turn out a 1.5 right away
[12:26:53 CDT(-0500)] <colinclark> so that we can focus on using and integrating our own stuff
[12:26:58 CDT(-0500)] <colinclark> which I think will be a lot of fun
[12:27:14 CDT(-0500)] <colinclark> So, I heard something phrased very diplomatically there, jameswy
[12:27:25 CDT(-0500)] <colinclark> "raining on the design goals of the panel"
[12:28:10 CDT(-0500)] <colinclark> Justin_o and jameswy: I feel like you guys are the real bosses here for this release
[12:28:27 CDT(-0500)] <colinclark> though I really want everyone to share thoughts and opinions
[12:29:32 CDT(-0500)] <colinclark> The best I can do is outline the goals, which I guess we can expand into "A polished UIO and FSS for Infusion 1.4, leading into an iteration or two spent using and integrating our own stuff in places such as the Inclusive Learning Handbook"
[12:29:34 CDT(-0500)] <jameswy> Justin_o, colinclark: where I stand in a nutshell: I'd love to see it working as intended. If time's an issue, we can put in a stopgap.
[12:32:31 CDT(-0500)] <colinclark> I think time is the key question here
[12:33:02 CDT(-0500)] <colinclark> Despite unknowns, do you have a sense of scope and time for this iFrame universe-crossing, Justin_o and Bosmon4
[12:33:04 CDT(-0500)] <colinclark> ?
[12:34:02 CDT(-0500)] <Bosmon4> Yes, my sense is that we should expect this to cost us on the order of 1-2 weeks
[12:34:05 CDT(-0500)] <Bosmon4> We may "get lucky"
[12:34:17 CDT(-0500)] <colinclark> ok
[12:34:25 CDT(-0500)] <Bosmon4> I mean, my "John Norman" estimate for this task would be about 2 days (tongue)
[12:34:31 CDT(-0500)] <colinclark> lol
[12:34:42 CDT(-0500)] <colinclark> jameswy: I haven't had a chance to catch up with your review, but are there other areas of UIO today that you think need substantial time and polish
[12:34:53 CDT(-0500)] <colinclark> again, using the goal of "reasonably awesome" as a metric
[12:35:15 CDT(-0500)] <jameswy> colinclark: I don't think so. Most things on my list are relatively trivial fixes.
[12:35:21 CDT(-0500)] <colinclark> cool
[12:35:22 CDT(-0500)] <colinclark> michelled: Are there any other areas of code-level/implementer UX roughness that you think are worth contemplating for 1.4 at this point
[12:35:29 CDT(-0500)] <jameswy> That said, I haven't been given the heads up for a fat panel review yet.
[12:35:54 CDT(-0500)] <jameswy> Still waiting on heidi_ and jhung for that.
[12:35:56 CDT(-0500)] <colinclark> and cindyli, anything on your mind?
[12:36:12 CDT(-0500)] <Justin_o> jameswy: The one big thing that we haven't thought about for fat panel is those options that you never want to affect UIOptions itself
[12:36:48 CDT(-0500)] <jameswy> Justin_o: Ah? Might be good to think about it then, (smile)
[12:36:57 CDT(-0500)] <Justin_o> jameswy: (smile)
[12:37:12 CDT(-0500)] <Justin_o> so i think we'd need to the live preview stuff for that
[12:37:23 CDT(-0500)] <Justin_o> so that would likely also be out in the stop-gap version
[12:37:38 CDT(-0500)] <michelled> colinclark: I'm trying to get UIEnhancer cleaned up for 1.4
[12:37:51 CDT(-0500)] <michelled> colinclark: I haven't had a chance to look at the API changes yet
[12:38:14 CDT(-0500)] <michelled> if we are going to delay the 1.4 release we should consider the ants refactoring
[12:38:26 CDT(-0500)] <colinclark> anastasiac: So far is your experience that is it is possible to extend UIO, if not entirely straightforwardly?
[12:38:31 CDT(-0500)] <michelled> it might be too big but it would be nice to do 1 major API change instead of 2
[12:38:38 CDT(-0500)] <Justin_o> jameswy: we may also need the improved configuration to be able to selectively have options that don't affect certain ui enhancers
[12:39:10 CDT(-0500)] <Justin_o> michelled: i'd agree that a single major api change would be nicer
[12:39:19 CDT(-0500)] <anastasiac> colinclark, so far it seems that way. I've got it loading another template into the main page, and I'm just working out how to update the default UIEnhancer model so that there are values to render
[12:39:24 CDT(-0500)] <Bosmon4> Ok
[12:39:31 CDT(-0500)] <Justin_o> i worry about the amount of changes someone will have to go through in 1.5 all over again, if we don't address some of these issues now
[12:39:47 CDT(-0500)] <Bosmon4> My sense is that if we go for ants, this will push us back at the least another 2 weeks, if not more
[12:40:16 CDT(-0500)] <Justin_o> Bosmon4: another two weeks on top of the extra two weeks you just mentioned?
[12:40:17 CDT(-0500)] <colinclark> In theory, Bosmon4 and michelled, could we antify and panelize concurrently in an effective way?
[12:40:35 CDT(-0500)] <Bosmon4> The thing about ants is that since it is a major refactoring, the particular branch that ants are on would be totally unusable during the period
[12:41:20 CDT(-0500)] <Bosmon4> colinclark - I think the kinds of work ought to be orthogonal... but I think in practice, it probably wouldn't turn out that way
[12:41:34 CDT(-0500)] <Bosmon4> Since a major part of "ants" would be smashing up the containment structure of the component hierarchy
[12:41:42 CDT(-0500)] <colinclark> we tend to work a lot together, anyway
[12:41:51 CDT(-0500)] <colinclark> which places a bit of extra cost on concurrency
[12:42:04 CDT(-0500)] <Bosmon4> But my sense is that it would be quite confusing for us to take on these two piece of work concurrently
[12:42:31 CDT(-0500)] <Bosmon4> If we are to take them on for the same release, we should do ants FIRST and then world relay strictly afterwards
[12:42:50 CDT(-0500)] <colinclark> I guess the other question is if there is an interim degree of antifying we can do?
[12:42:53 CDT(-0500)] <Justin_o> Bosmon4: but wouldn't a large portion of the work for the iframe one, be developing the communication between the two pages.. this feature, I imagine, doesn't really need to be strictly tied to UIO
[12:42:59 CDT(-0500)] <colinclark> without introducing really unpleasant API changes in 1.5
[12:43:17 CDT(-0500)] <Bosmon4> Justin_o - parts of the work would be fine, yes - but there will be a lot of "plumbing gunge" inside the fat panel wrapper function
[12:43:29 CDT(-0500)] <Justin_o> Bosmon4: yes.. i could see that
[12:43:44 CDT(-0500)] <Bosmon4> This wrapper actually needs to know in some detail what the subcomponent substructure actually is
[12:43:48 CDT(-0500)] <Justin_o> I guess that's another issue.. are we happy with the wrappers actually
[12:44:00 CDT(-0500)] <Bosmon4> Since it will be "cherry picking" an event handler here, a model there, to "send between the worlds"
[12:44:18 CDT(-0500)] <Bosmon4> Well, we are not happy with the wrappers, but that's a whole different kettle of fish
[12:44:35 CDT(-0500)] <Bosmon4> I'm not particularly happy with destabilising the core framework right now, and I expect colinclark isn't either
[12:44:48 CDT(-0500)] <Bosmon4> We had just managed to get it to a point where crazy things stopped happening to it every week (tongue)
[12:44:49 CDT(-0500)] <michelled> ah, good point - the wrappers should be fixed for 1.4 regardless of what ever else we do
[12:45:14 CDT(-0500)] <Bosmon4> Ah, I thought that Justin_o was talking about the wrappers from the angle of "core framework support for wrappers"....
[12:45:23 CDT(-0500)] <Bosmon4> Are there other things wrong with them apart from not being framework-ised?
[12:46:05 CDT(-0500)] <Justin_o> Bosmon4: what do you mean by "framework-ised" exactly.. as now i'm not sure what I meant (smile)
[12:46:41 CDT(-0500)] <colinclark> From my perspective, "core framework support for wrappers" where "wrappers" are defined as "the way we enable users to easily select among component flavours, as in Reorderer or UI Options" is the key issue
[12:46:59 CDT(-0500)] <Bosmon4> I think we identified a few times over the last few months that a core requirement for the framework is to be able to specify these kinds of wrappers declaratively
[12:47:00 CDT(-0500)] <colinclark> and am 100% in support of not adding framework support for such things in Infusion 1.4
[12:47:16 CDT(-0500)] <colinclark> Despite equally being 100% convinced that they are a necessary and valuable feature
[12:47:19 CDT(-0500)] <colinclark> (smile)
[12:47:27 CDT(-0500)] <Bosmon4> Rather than having to write them as "wrapper gunge" as we do now, in fluid.uploader and many other places
[12:49:27 CDT(-0500)] <colinclark> So, I think we're probably due to chat again about our Ants idea
[12:49:34 CDT(-0500)] <colinclark> And get a better sense of scope for them
[12:49:43 CDT(-0500)] <colinclark> It's been nice to assume we can defer the work to a future release
[12:49:44 CDT(-0500)] <colinclark> and I think we can
[12:49:58 CDT(-0500)] <colinclark> but there is a cost to implementers, and it's pretty high
[12:50:02 CDT(-0500)] <colinclark> if the API keeps rolling
[12:50:06 CDT(-0500)] <colinclark> I need to get some lunch
[12:50:14 CDT(-0500)] <colinclark> Can we chat through it again a bit in, say, an hour?
[12:50:18 CDT(-0500)] <colinclark> 3 pm
[12:50:20 CDT(-0500)] <colinclark> EDT
[12:50:20 CDT(-0500)] <Bosmon4> ok, sure
[12:50:25 CDT(-0500)] <colinclark> which is late for you, Bosmon4
[12:50:34 CDT(-0500)] <colinclark> 8 pm BST?
[12:50:39 CDT(-0500)] <colinclark> seems like dinner time (smile)
[12:50:49 CDT(-0500)] <Bosmon4> I'll be around
[12:50:54 CDT(-0500)] <colinclark> ok
[12:50:57 CDT(-0500)] <colinclark> cindyli: you free?
[12:51:05 CDT(-0500)] <cindyli> ya, colinclark
[12:51:09 CDT(-0500)] <colinclark> everyone else is welcome to join
[12:51:13 CDT(-0500)] <colinclark> we can either chat here or on skype
[12:51:17 CDT(-0500)] <colinclark> not sure what makes the most sense
[12:51:19 CDT(-0500)] <colinclark> probably skype
[12:51:38 CDT(-0500)] <Bosmon4> Yes
[12:51:45 CDT(-0500)] <Bosmon4> We will need to be able to talk nonsense at a high rate :PP
[12:51:53 CDT(-0500)] <colinclark> lol
[13:13:33 CDT(-0500)] <heidi_> jhung how's it going? i'm trying to figure out why for yellow/black the colours are reversed in UIO... weird
[13:17:50 CDT(-0500)] <Justin_o> heidi_: i pushed FLUID-4215
[13:17:58 CDT(-0500)] <heidi_> Justin_o phewf (smile)
[13:17:59 CDT(-0500)] <heidi_> thanks
[13:18:27 CDT(-0500)] <heidi_> Justin_o unit tests passed ok? i feel like they weren't at some point
[13:19:07 CDT(-0500)] <heidi_> i think i fixed them tho
[13:20:18 CDT(-0500)] <Justin_o> heidi_: i forgot to check that again.. and no they don't pass (sad)
[13:20:25 CDT(-0500)] <heidi_> ahhk
[13:21:08 CDT(-0500)] <heidi_> Justin_o right, we made changes on the container thing
[13:21:09 CDT(-0500)] <heidi_> i'll fix
[13:21:21 CDT(-0500)] <Justin_o> heidi_: okay.. thanks
[13:21:27 CDT(-0500)] <Justin_o> can you reopen the jira again too
[13:21:47 CDT(-0500)] <heidi_> the jira that won't die
[13:21:47 CDT(-0500)] <heidi_> yep
[13:22:01 CDT(-0500)] <Justin_o> heidi_: (smile) i think this should be the last nail in it's coffin though
[13:22:10 CDT(-0500)] <heidi_> hehe
[13:36:21 CDT(-0500)] <heidi_> Justin_o can i skype you for a second?
[13:36:45 CDT(-0500)] <Justin_o> heidi_: sure
[13:36:54 CDT(-0500)] <Justin_o> logging in now
[13:45:08 CDT(-0500)] <heidi_> Justin_o thanks, pushed
[13:45:38 CDT(-0500)] <Justin_o> heidi_: thanks
[13:45:53 CDT(-0500)] <heidi_> jhung how goes it
[13:46:56 CDT(-0500)] <Justin_o> heidi_: can you also make a new pull request for FLUID-4215
[13:47:07 CDT(-0500)] <heidi_> Justin_o right, ya
[13:47:33 CDT(-0500)] <Justin_o> heidi_: thanks
[13:48:13 CDT(-0500)] <heidi_> Justin_o sent
[13:52:56 CDT(-0500)] <jhung> hey heidi_.
[13:53:09 CDT(-0500)] <Justin_o> heidi_: okay.. close FLUID-4215 again
[13:53:26 CDT(-0500)] <jhung> Sorry, pidgin doesn't blink when I get a ping in IRC.
[13:53:54 CDT(-0500)] <Justin_o> colinclark: are you still looking at this pull request https://github.com/fluid-project/infusion/pull/68
[13:54:03 CDT(-0500)] <heidi_> Justin_o it is closed
[13:54:03 CDT(-0500)] <colinclark> yep
[13:54:13 CDT(-0500)] <colinclark> One thing at a time, but yes
[13:54:57 CDT(-0500)] <Justin_o> heidi_: yes.. i closed it.. .i had meant to put a "d" at the end of "close" (smile)
[13:55:05 CDT(-0500)] <heidi_> figured (wink)
[13:55:58 CDT(-0500)] <jhung> heidi_: Cool that you're taking on the reversed colours for y-b and b-y. I'm making tweaks to b-y tabs.
[13:56:29 CDT(-0500)] <heidi_> jhung i think it's related to the !important injection colinclark is gonna do... tho colin, need a hand with that?
[13:57:24 CDT(-0500)] <colinclark> I don't think I'll get to it today, heidi_
[13:57:24 CDT(-0500)] <colinclark> b
[13:57:28 CDT(-0500)] <colinclark> but I will need your help soon, heidi_
[13:57:29 CDT(-0500)] <jhung> heidi_: .ui-widget-content has a background image.
[13:57:52 CDT(-0500)] <heidi_> jhung aha!
[13:57:55 CDT(-0500)] <jhung> heidi_: line 62
[13:58:04 CDT(-0500)] <jhung> of blackyellow.css
[13:58:20 CDT(-0500)] <heidi_> jhung cheers
[13:58:40 CDT(-0500)] * jhung raised mug
[14:00:37 CDT(-0500)] <colinclark> fluid-everyone: Who'd like to join our chat about UI Options architecture this afternoon?
[14:00:57 CDT(-0500)] <Justin_o> colinclark: count me in
[14:01:40 CDT(-0500)] <michelled> me please!
[14:01:49 CDT(-0500)] <anastasiac> I'd like to lurk
[14:01:51 CDT(-0500)] <mlam> count me in
[14:01:55 CDT(-0500)] <cindyli> me pls
[14:11:32 CDT(-0500)] <Justin_o> michelle I've pushed your FLUID-4288 pull-request
[14:11:45 CDT(-0500)] <michelled> thanks Justin_o
[14:15:28 CDT(-0500)] <heidi_> jhung make sure to put all the fat panel styles in the .fl-uiOptions-fatPanel namespace
[14:15:40 CDT(-0500)] <heidi_> ex. if they tabs elsewhere on the page, these styles shouldn't affect them
[14:16:14 CDT(-0500)] <jhung> heidi: yes. I've started to put those in.
[14:25:35 CDT(-0500)] <heidi_> jhung i think i'll wait till you're done before adding my styles in. ill see to jameswy's list for the other layouts now - ping me when yr done
[14:36:35 CDT(-0500)] <jhung> heidi_: ok.
[14:49:17 CDT(-0500)] <jhung> heidi_: I'm going to stop now and continue work later tonight. I did some work locally, but I'm going to reverse it because I think I touched too many lines (some styles that were good, are now messed up).
[14:49:53 CDT(-0500)] <heidi_> jhung ok - i'll continue w/ panel styling tomorrow when yr done
[14:50:02 CDT(-0500)] <jhung> k
[15:12:09 CDT(-0500)] <heidi_> jameswy what does this one mean: When using keyboard to move slider, it affects the preview window if the slider is at the very end
[15:13:03 CDT(-0500)] <jameswy> heidi_: Say you're using the keyboard to slide the text size to the right... you get it to the very end... and then you keep pressing right... the preview window scrolls to the right too!
[15:13:42 CDT(-0500)] <heidi_> jameswy oh i see - cos the preview gets scrollbars after a certain font-size. bizarro
[15:13:44 CDT(-0500)] <heidi_> hmm
[15:14:07 CDT(-0500)] <jameswy> heidi_: Weird, right?
[15:14:17 CDT(-0500)] <jameswy> Also, what's the word on fat panel? Is it ready for review yet?
[15:14:51 CDT(-0500)] <heidi_> jameswy jhung is still working on fixing the tabs but you could review it without the b/y themes
[15:15:29 CDT(-0500)] <jameswy> heidi_: Great. Should I pull it from his repo or yours?
[15:15:34 CDT(-0500)] <heidi_> i think those are the only bits left
[15:15:46 CDT(-0500)] <heidi_> jameswy ill merge in jon's work and push to mine, one sec
[15:17:14 CDT(-0500)] <jameswy> heidi_: Cools. Lemme know which branch to check out.
[15:17:25 CDT(-0500)] <heidi_> jameswy k, heidiv/FLUID-4230
[15:34:48 CDT(-0500)] <heidi_> jameswy are you happy with that preview page - did you want to change the content/layout/etc at all?
[15:35:38 CDT(-0500)] <jameswy> heidi_, wasn't anastasiac working on a preview page of some sort at one point? Memory's foggy.
[15:36:00 CDT(-0500)] <heidi_> jameswy i thought so too, but that page is instead a 'real world' demo
[15:36:03 CDT(-0500)] <heidi_> not a preview page
[15:36:14 CDT(-0500)] <anastasiac> jameswy, yes: it's in the manual-tests folder: SomeKindOfNews.html
[15:36:25 CDT(-0500)] <anastasiac> oh, right
[15:36:37 CDT(-0500)] <anastasiac> yes, it was a real-world demo I created, not a sample preview page
[15:36:37 CDT(-0500)] <anastasiac> sorry
[15:36:46 CDT(-0500)] * anastasiac should finish reading before answering
[15:37:01 CDT(-0500)] <jameswy> Haha.
[15:37:07 CDT(-0500)] <jameswy> Tis all good.
[15:37:33 CDT(-0500)] <heidi_> so jameswy did you want to improve the preview page at all or is it ok
[15:38:06 CDT(-0500)] <jameswy> heidi_: Hm... the current preview isn't ideal, but I don't mind it for this release. It's a relatively minor issue compared to some of the tweaks I'll be listing for the fat panel.
[15:38:27 CDT(-0500)] <heidi_> jameswy yikes - fat panel not great?
[15:39:01 CDT(-0500)] <jameswy> heidi_: It's really good! Just needs a bit more lovin' (smile)
[15:39:09 CDT(-0500)] <heidi_> ok cool (wink)
[15:39:51 CDT(-0500)] <jameswy> I'm punching out for the day--catch up with you with more UIO stuff in the morning, heidi_
[15:40:06 CDT(-0500)] <jameswy> Thanks for all the awesome work you've been doing on it!!
[15:40:06 CDT(-0500)] <heidi_> werd up, have a nice night jameswy!
[15:40:16 CDT(-0500)] <heidi_> thanks for the great mock ups (wink)