fluid-work IRC Logs-2011-10-18
- Fluid IRC Log Bot
[08:34:39 CDT(-0500)] <heidi_> hey jameswy Justin_o can you keep us posted on the skype situation for r&d
[08:34:55 CDT(-0500)] <jameswy> heidi_: Are you not Skype'd in?
[08:35:02 CDT(-0500)] <heidi_> nope - who is calling?
[08:35:11 CDT(-0500)] <jameswy> heidi_: Jan's ringing you in.
[08:35:52 CDT(-0500)] <heidi_> jameswy cool thanks
[09:58:07 CDT(-0500)] <jhung> justin_o, can you help integrate the new Import.html with Import.js.
[09:58:35 CDT(-0500)] <jhung> selectors have changed names and we have new selectors for new buttons and item numbering...
[09:58:49 CDT(-0500)] <Justin_o> jhung: will do.. did you need that now, or can it wait till after I get the images actually uploading to the server
[09:59:37 CDT(-0500)] <jhung> It can wait. I'm going to move on to styling the rest of the application and will come back to the Import UI (DECA-170) when you're done.
[09:59:50 CDT(-0500)] <Justin_o> jhung: by the way.. does capture work for you at the moment.. i'm having problems when i try using the mock server
[09:59:59 CDT(-0500)] <Justin_o> jhung: thanks
[10:00:34 CDT(-0500)] <Justin_o> jhung: hopefully i'll get through this soon.. i'm going through a bit of a learning curve with cherrypy, python, and the server code 
but i'm getting there
[10:00:37 CDT(-0500)] <jhung> Justin_o: I haven't tried. What error are you getting?
[10:01:22 CDT(-0500)] <jhung> justin_o: pythons and pie - sounds like a Thanksgiving celebration gone wrong.
[10:01:40 CDT(-0500)] <Justin_o> jhung: it is.. it's messy and dangerous
[10:05:20 CDT(-0500)] <Justin_o> jhung: so for the error.. i had forgot i had put on a break point 
but there is an error with stitching..
[10:05:33 CDT(-0500)] <Justin_o> but i guess we're going to look at pulling that out anyways
[10:36:58 CDT(-0500)] <jhung> Sorry everyone. My connection is still very poor, so I can't join stand-up. My update - continuing work on styling Import UI for Decapod 0.5. Turning my attention to work on styling the Image Management UI today.
[11:06:36 CDT(-0500)] <athena> are there any examples of more complex uses of renderer component tree expanders?
[11:07:19 CDT(-0500)] <athena> for example, having two levels of nested repetition? or binding to something that's the result of some custom logic, rather than a simple property?
[11:07:34 CDT(-0500)] <athena> can i add something to the component tree that's not one of the repeated elements?
[11:08:42 CDT(-0500)] <athena> Bosmon: if you're around, i suspect these may all be questions for you
[11:11:36 CDT(-0500)] <yura1> athena: here's one but it's not very clean and surely complicated https://github.com/collectionspace/ui/blob/master/src/main/webapp/defaults/js/RecordList.js
[11:12:31 CDT(-0500)] <athena> thanks!
[11:12:44 CDT(-0500)] <athena> so i can kind of nest the expanders?
[11:14:13 CDT(-0500)] <yura1> yes, that's the general approach , but maybe it's going to be cleaner if the nested part is abstracted into a renderer decorator
[11:14:22 CDT(-0500)] <yura1> however nesting works just fine
[11:14:34 CDT(-0500)] <athena> looks like the way this works is that it uses the produceTree property?
[11:14:39 CDT(-0500)] <athena> i think this'll help a lot
[11:14:46 CDT(-0500)] * athena wonders why she can't ever have anything simple to do
[11:15:58 CDT(-0500)] <yura1> athena: produceTree is there because i could not present the tree as static json , bit ideally it should be a static prototree in defaults
[11:16:58 CDT(-0500)] <athena> ok
[11:20:05 CDT(-0500)] <athena> so can i nest two fluid.renderer.repeat expanders?
[11:20:11 CDT(-0500)] <yura1> yes
[11:21:24 CDT(-0500)] <yura1> athena: https://github.com/collectionspace/ui/blob/master/src/main/webapp/defaults/js/RecordList.js#L218-241
[11:21:32 CDT(-0500)] <yura1> this is the exact bit
[11:21:37 CDT(-0500)] <athena> thanks!@
[13:01:09 CDT(-0500)] <cindyli> Bosmon: are you there?
[13:12:34 CDT(-0500)] <Bosmon> Hi cindyli
[13:12:45 CDT(-0500)] <cindyli> ha, nice to see you, Bosmon
[13:13:10 CDT(-0500)] <cindyli> do you have time to chat about the refactoring of the fat panel
[13:13:22 CDT(-0500)] <Bosmon> Yes, I do
[13:13:59 CDT(-0500)] <cindyli> cool, one goal you mentioned is to get rid of the inclusion of infusion lib files form fat panel iframe html
[13:14:32 CDT(-0500)] <Bosmon> Yes!
[13:14:32 CDT(-0500)] <cindyli> i think it should be doable to get rid of UIEnhancer
[13:14:37 CDT(-0500)] <Bosmon> It is essential
[13:14:41 CDT(-0500)] <cindyli> cool
[13:14:49 CDT(-0500)] <cindyli> but in terms of UIOptions
[13:14:54 CDT(-0500)] <cindyli> since we need to render the UI
[13:15:05 CDT(-0500)] <Bosmon> The UI will also be rendered from the outside
[13:15:09 CDT(-0500)] <Bosmon> This is the whole idea
[13:15:24 CDT(-0500)] <cindyli> and pass the html into iframe?
[13:15:28 CDT(-0500)] <Bosmon> Yes
[13:15:42 CDT(-0500)] <cindyli> ok
[13:16:10 CDT(-0500)] <Bosmon> We may need a little extra framework support in the end, depending on who exactly needs to be directed to use a different jQuery
[13:16:30 CDT(-0500)] <cindyli> ok. i will leave jquery in there for now
[13:16:36 CDT(-0500)] <cindyli> step by step :-P
[13:16:56 CDT(-0500)] <Bosmon> The jQuery will need to remain
[13:17:09 CDT(-0500)] <cindyli> for toc right?
[13:17:17 CDT(-0500)] <cindyli> but we will get rid of it eventually?
[13:17:34 CDT(-0500)] <Bosmon> No, jQuery will have to remain for all time
[13:17:40 CDT(-0500)] <Bosmon> At least, as far as I understand
[13:18:03 CDT(-0500)] <Bosmon> The jQuery in the iframe is the one that will need to be delegated to perform any DOM manipulation which is touching the iframe's markup
[13:18:43 CDT(-0500)] <cindyli> ya, i thought you were thinking to inject jQuery from outside world
[13:19:41 CDT(-0500)] <Bosmon> No, the jQuery injection that will happen will progress down the component tree
[13:19:54 CDT(-0500)] <Bosmon> That is, it is the outside world which knows which is the inner jQuery - the one in the iframe
[13:20:11 CDT(-0500)] <Bosmon> Since at some point in configuration will be someone who knows how it was put there
[13:20:40 CDT(-0500)] <cindyli> ah, ok
[13:22:10 CDT(-0500)] <Bosmon> Right now you can start by pretending that everyone can use the same jQuery object
[13:22:15 CDT(-0500)] <Bosmon> And then see exactly where and when this breaks down
[13:23:13 CDT(-0500)] <cindyli> i will try, although i'm not sure if i get it right. :-P
[13:23:25 CDT(-0500)] <Bosmon> cindyli - don't worry, it will require a few attempts
[13:23:35 CDT(-0500)] <Bosmon> There is a reason we didn't do this work in the period leading up to the release....
[13:24:36 CDT(-0500)] <cindyli> ah ha
[13:25:09 CDT(-0500)] <cindyli> once the UIEnhance and UIOptions are gone from the inner iframe, we have a good chance to get rid of "fluid.uiOptions.FatPanelOtherWorldLoader"
[13:25:22 CDT(-0500)] <Bosmon> This will die completely
[13:25:31 CDT(-0500)] <Bosmon> That dismal thing
[13:25:56 CDT(-0500)] <cindyli> not that bad
[13:26:09 CDT(-0500)] <cindyli>
[13:26:24 CDT(-0500)] <Bosmon> Well, we did our best with it
[13:26:32 CDT(-0500)] <Bosmon> It is as small as we could make it, given our basic assumption
[13:26:36 CDT(-0500)] <Bosmon> That there had to be two worlds
[13:27:59 CDT(-0500)] <cindyli> now it will turn into 1.5 worlds
[13:28:33 CDT(-0500)] <cindyli> since we still need jquery in the iframe
[13:29:09 CDT(-0500)] <cindyli> i will start experimenting. any other simplifying in your mind with fat panel?
[13:35:24 CDT(-0500)] <Bosmon> cindyli - that simplification will already be quite ambitious enough
[13:35:42 CDT(-0500)] <Bosmon> You will know when you have succeeded, since the thing called fluid.uiOptions.inline will become a new parent to all 3 configurations
[13:35:49 CDT(-0500)] <Bosmon> That is, directly, rather than indirectly as it now is with fatPanel
[13:35:53 CDT(-0500)] <Bosmon> And it will then need a new name
[13:36:36 CDT(-0500)] <cindyli> ouu...
[13:37:07 CDT(-0500)] <jhung> justin_o: I just pushed up some changes to the HTML files in decapod-ui. Changed the doctype on all files to html and added Sections to allow us to namespace styles properly.
[13:37:49 CDT(-0500)] <Justin_o> jhung: great, thanks
[13:39:59 CDT(-0500)] <cindyli> thanks, Bosmon, be prepared that i will bug you from time to time with more questions.
[13:40:06 CDT(-0500)] <Bosmon> cindyli - I will look forward to it
[13:40:27 CDT(-0500)] <cindyli> thanks, :-P
[14:19:08 CDT(-0500)] <michelled> colinclark, Justin_o: anastasiac and I were talking about the uio/fss theme that she'll be tweaking for ILDH and we were wondering where that should go
[14:19:20 CDT(-0500)] <colinclark> Ah, right
[14:19:27 CDT(-0500)] <michelled> it seems to me it belongs here: https://github.com/inclusive-design/mediawiki-fss-theme
[14:19:46 CDT(-0500)] <colinclark> I think it depends on how general we're intending to be
[14:20:02 CDT(-0500)] <colinclark> heidi_ probably has some thoughts on this as well
[14:20:17 CDT(-0500)] <colinclark> The goal, in the long run, was to create themes for both WordPress and MediaWiki that were FSS-enabled
[14:20:31 CDT(-0500)] <colinclark> and that allowed us to create a skin that could largely be reused across both CMSes
[14:20:51 CDT(-0500)] <colinclark> heidi_ had started to work on a prototypal extension to the FSS, "fss-site"
[14:21:07 CDT(-0500)] <colinclark> representing some of the semantics that are consistent across many sites
[14:21:28 CDT(-0500)] <colinclark> That was the intention for the IDI's mediawiki-fss-theme repository
[14:21:51 CDT(-0500)] <colinclark> I think we perhaps aren't going to be that ambitious for this first iteration, integrating UIO in the Inclusive Learning Design Handbook
[14:21:51 CDT(-0500)] <heidi_> the theme stuff would go in handbook.floeproject.org repo michelled
[14:21:59 CDT(-0500)] <colinclark> right
[14:22:07 CDT(-0500)] <colinclark> You've got two separate MW themes in there, right heidi_?
[14:22:12 CDT(-0500)] <colinclark> floe and floe2
[14:22:15 CDT(-0500)] <colinclark> amazingly good names 
[14:22:26 CDT(-0500)] <heidi_> yep i'm guessing floe2 is the one that's being used now... can't remember
[14:22:27 CDT(-0500)] <michelled> there's also the one in greggy1's repo
[14:22:36 CDT(-0500)] <michelled> how does that overlap?
[14:22:41 CDT(-0500)] <anastasiac> colinclark, I just want to check if I understand correctly: the inclusive-design collection of themes would be base themes that could be used to give all our sites some commonality, and they'd be tweaked if necessary for a given site?
[14:23:19 CDT(-0500)] <colinclark> Yep
[14:23:29 CDT(-0500)] <colinclark> In short, we'd have FSS-enabled, CMS-specific themes.
[14:23:35 CDT(-0500)] <colinclark> But the goal is for them to contain as little as possible
[14:23:44 CDT(-0500)] <colinclark> and then there'd be a reusable FSS-based theme
[14:23:56 CDT(-0500)] <colinclark> which would work equally on top of all the CMS-specific themes
[14:23:58 CDT(-0500)] <colinclark> if that makes sense
[14:24:07 CDT(-0500)] <colinclark> it's like our original vision for the FSS in the Fluid Academic grant
[14:24:18 CDT(-0500)] <colinclark> A "universal skinning system"
[14:24:22 CDT(-0500)] <colinclark> That's the long term vision
[14:24:44 CDT(-0500)] <heidi_> i should type up an email about my fss-site experiments on IDI site this week
[14:24:47 CDT(-0500)] <heidi_> send to list
[14:24:57 CDT(-0500)] <colinclark> michelled: As I understand it, greggy1's MW UIO theme is based on one of the themes from the Inclusive Learning Design Handbook. I'm not sure which one, but I do see ILDH-related references in there
[14:25:34 CDT(-0500)] <colinclark> So, in the short term, we'll probably want to unify greggy1's fork with whichever of heidi_'s original themes is the most recent
[14:25:51 CDT(-0500)] <colinclark> And place it with the handbook repository within the Fluid Github organization
[14:25:53 CDT(-0500)] <michelled> colinclark: so I guess anastasiac should pull what she like from there and push it into the handbook repo
[14:26:21 CDT(-0500)] <colinclark> Yes. There's no direct lineage between the two repos at this point
[14:26:28 CDT(-0500)] <colinclark> so it will involve picking changes by hand
[14:26:57 CDT(-0500)] <colinclark> So the definitive repo for the handbook is this one: https://github.com/fluid-project/handbook.floeproject.org
[14:27:17 CDT(-0500)] <anastasiac> heidi_, right now the floe themes are just embedded right in with the rest of the MW instance, right? not in a separate project?
[14:27:18 CDT(-0500)] <colinclark> And we can take greggy1's great additions and get them into this repo
[14:27:27 CDT(-0500)] <heidi_> anastasiac right
[14:27:55 CDT(-0500)] <colinclark> anastasiac: The thing to know about that repository is that it represents the development and deployment context for the Handbook web site
[14:27:58 CDT(-0500)] <anastasiac> ok, so we'll just update the repo with any theme changes taken from greggy1's repo
[14:28:12 CDT(-0500)] <colinclark> We've got two key branches: master and development
[14:28:21 CDT(-0500)] <colinclark> Master contains the production instance of the Handbook
[14:28:25 CDT(-0500)] <anastasiac> yep, heidi_ has clarified which is which
[14:28:39 CDT(-0500)] <colinclark> The server is configured such that we can easily pull from master right into production
[14:28:40 CDT(-0500)] <colinclark> okay, great
[14:28:45 CDT(-0500)] <anastasiac> I'm working in development until we're ready to go public
[14:28:52 CDT(-0500)] <colinclark> That's excellent
[14:28:54 CDT(-0500)] <heidi_> the themes for all the sites will be within the CMS/site repo. the inclusive-design repos for themes were meant to share only themes but now we're sharing sites. they were also a little special in that they were sharing FSS styles so we were playing with that idea
[14:29:25 CDT(-0500)] <colinclark> In our long run vision, we'll likely separate out the themes into their own repositories...
[14:29:43 CDT(-0500)] <colinclark> Because these themes will be useful to anyone using, say, WordPress or MediaWiki
[14:29:57 CDT(-0500)] <colinclark> But in the short term, that's not something we need to offer to people
[14:30:07 CDT(-0500)] <heidi_> wouldn't they still be available from the site repo tho?
[14:30:18 CDT(-0500)] <heidi_> i guess it's more explicit to have its own repo, but necessary?
[14:30:19 CDT(-0500)] <colinclark> heidi_: yes, likely
[14:30:33 CDT(-0500)] <colinclark> Not unlike how we have extensions and plugins right in the site repository, too
[14:30:36 CDT(-0500)] <colinclark> Different purposes
[14:30:50 CDT(-0500)] <colinclark> One repository representing the "product" we offer for others to use and share and contribute to
[14:30:58 CDT(-0500)] <colinclark> The other representing the concrete state of a particular web site
[14:31:00 CDT(-0500)] <colinclark> Does that all make sense?
[14:31:30 CDT(-0500)] <heidi_> ya
[14:31:55 CDT(-0500)] <colinclark> In other words, today we're just working on a specific website
[14:32:13 CDT(-0500)] <colinclark> But we dream of being able to offer a reusable theme for several CMSes in the future, all powered by the FSS
[14:32:28 CDT(-0500)] <colinclark> The future can wait for a bit
[14:34:01 CDT(-0500)] <colinclark> heidi_: On another subject, I made you a repo for www.fluidproject.org
[14:34:06 CDT(-0500)] <colinclark> and am now getting an error from Github
[14:34:18 CDT(-0500)] <colinclark> I'll try making the other one, and hopefully Github will sort itself out
[14:34:40 CDT(-0500)] <heidi_> colinclark the IDI server doesn't let my user create dirs so i can't do 'git initi'
[14:34:43 CDT(-0500)] <heidi_> init
[14:34:47 CDT(-0500)] <heidi_> so need to wait for aaron
[14:34:52 CDT(-0500)] <heidi_> maybe it's something similar?
[14:35:43 CDT(-0500)] <colinclark> Aaron was on a plane
[14:35:47 CDT(-0500)] <colinclark> with internet access
[14:35:48 CDT(-0500)] <colinclark> so the future
[14:35:52 CDT(-0500)] <colinclark> but it looks like it has landed
[14:36:00 CDT(-0500)] <colinclark> We'll see him later this afternoon, I expect
[14:36:11 CDT(-0500)] <colinclark> The problem I was experiencing was with Github itself.
[14:36:42 CDT(-0500)] <colinclark> By the way, heidi_, I'm really excited about the thinking you've done on fss-site and the like
[14:36:47 CDT(-0500)] <colinclark> Can't wait to have you work on that when you're back
[14:37:21 CDT(-0500)] <heidi_> cool yeah it's neat that theory seems to be working out in practice
[14:37:27 CDT(-0500)] <colinclark> lol
[14:37:34 CDT(-0500)] <heidi_> nice when that happens
[14:37:47 CDT(-0500)] <colinclark> It sure is
[14:37:48 CDT(-0500)] <heidi_> so fluidproject.org repo not there?
[14:37:52 CDT(-0500)] <colinclark> It's there
[14:37:54 CDT(-0500)] <colinclark> but try clicking on it
[14:38:00 CDT(-0500)] <colinclark> seems to cause a Github error
[14:38:16 CDT(-0500)] <colinclark> Does this work for you, heidi_? https://github.com/fluid-project/www.fluidproject.org
[14:38:48 CDT(-0500)] <heidi_> colinclark we should decide if we want to incl www's in the names or not for all ya?
[14:39:06 CDT(-0500)] <colinclark> I chose to include the www. in the repo name, just for clarity
[14:39:13 CDT(-0500)] <heidi_> yeah i get "storage server under maintenance"
[14:39:15 CDT(-0500)] <colinclark> even though the site itself doesn't need it, and I hate to have to type the extra three characters
[14:39:25 CDT(-0500)] <heidi_> is that a cat or an octopus?
[14:39:29 CDT(-0500)] <colinclark> BOTH!
[14:39:31 CDT(-0500)] <colinclark>
[14:39:33 CDT(-0500)] <colinclark> That's the Octocat
[14:39:34 CDT(-0500)] <heidi_> woaha
[14:39:45 CDT(-0500)] <colinclark> We'll have to dig up the Octocat gallery for you
[14:39:51 CDT(-0500)] <heidi_> haha
[14:39:56 CDT(-0500)] <heidi_> it's a thing?
[14:40:09 CDT(-0500)] <colinclark> My idea was to clearly distinguished from, say, the handbook.floeproject.org repo
[14:40:16 CDT(-0500)] <colinclark> If you'd prefer, I can make repos without the www
[14:40:17 CDT(-0500)] <colinclark> Up to you
[14:40:22 CDT(-0500)] <colinclark> Yes, apparently the Octocat is all the rage
[14:40:26 CDT(-0500)] <colinclark> You should see their 404 page
[14:40:30 CDT(-0500)] <colinclark> If you're feeling nerdy
[14:40:41 CDT(-0500)] <heidi_> i'm cool with www or not but feels like we should be consistent... or not. no biggie
[14:40:45 CDT(-0500)] <colinclark> heidi_: https://github.com/fluid-project/notaurl
[14:40:50 CDT(-0500)] <colinclark> heidi_: You pick, I can easily remake them
[14:41:11 CDT(-0500)] <heidi_> haha nice
[14:42:08 CDT(-0500)] <heidi_> colinclark i feel like no www's might be easiest. esp cos dev.fluidproject.org will be a thing w/o www's
[14:42:14 CDT(-0500)] <colinclark> okay, that makes sense
[14:42:19 CDT(-0500)] <colinclark> I'll set 'em up now
[14:42:26 CDT(-0500)] <heidi_> thanks!
[14:42:54 CDT(-0500)] <colinclark> heidi_: https://github.com/fluid-project/fluidproject.org
[14:43:17 CDT(-0500)] <colinclark> heidi_: https://github.com/fluid-project/floeproject.org
[14:43:26 CDT(-0500)] <colinclark> Just so everyone knows, I've created a new team in Github
[14:43:27 CDT(-0500)] <heidi_> perfecto thanks
[14:43:30 CDT(-0500)] <colinclark> Called "ops"
[14:43:52 CDT(-0500)] <colinclark> This is designed for our website ops team, so that they can have access to administer and manage infrastructure-related projects
[14:44:00 CDT(-0500)] <colinclark> Currently heidi_ and huslage are our two ops team members
[14:44:06 CDT(-0500)] <colinclark> but anyone is welcome to join and lend a hand
[14:54:40 CDT(-0500)] <cindyli> Bosmon: hi
[15:10:59 CDT(-0500)] <michelled> heidi_: some octocat gear for you http://shop.github.com/products/octocat-onesie
[15:11:17 CDT(-0500)] <heidi_> lol michelled
[15:11:26 CDT(-0500)] <Bosmon> Hi cindyli
[15:11:28 CDT(-0500)] <Bosmon> How's it going?
[15:12:07 CDT(-0500)] <cindyli> see, how fast i come back with question
[15:12:49 CDT(-0500)] <cindyli> Bosmon: i'm thinking the html injection of UIO interface, into iframe
[15:12:58 CDT(-0500)] <Bosmon> Yes
[15:13:10 CDT(-0500)] <Bosmon> It is much better than coming back with questions slowly
[15:13:22 CDT(-0500)] <cindyli> haha
[15:13:54 CDT(-0500)] <cindyli> our normal way is to use viewComponent, specify a container, the UI is rendered into the container at the execution of the script
[15:14:01 CDT(-0500)] <Bosmon> Yes
[15:14:10 CDT(-0500)] <Bosmon> Our plan is to use the normal way as much as possible
[15:14:22 CDT(-0500)] <Bosmon> I guess we still have the remaining task of actually waiting for the iframe to load itself
[15:14:38 CDT(-0500)] <Bosmon> But that can be done with just an extra "createOnEvent" annotation
[15:14:53 CDT(-0500)] <cindyli> yes, with "afterRender" event
[15:15:27 CDT(-0500)] <Bosmon> Yes, that thing
[15:15:30 CDT(-0500)] <cindyli> back to the ui rendering. i'm only interested in the html that's returned from the component but don't actually yet have a container for it
[15:15:44 CDT(-0500)] <Bosmon> cindyli - what do you mean by "returned from the component"?
[15:15:53 CDT(-0500)] <Bosmon> And surely, after the "afterRender" event, the container will then exist?
[15:16:25 CDT(-0500)] <cindyli> can we still render into iframe body? i don't think so
[15:17:04 CDT(-0500)] <cindyli> that would be the same as our otherWorld component, that is to have UIOptions component ran in iframe
[15:17:44 CDT(-0500)] <Bosmon> Well, we will remove this idea of "run in"
[15:17:52 CDT(-0500)] <Bosmon> UIOptions will run in code written outside the iframe
[15:17:57 CDT(-0500)] <Bosmon> but its container will be within the iframe
[15:18:05 CDT(-0500)] <cindyli> ah ah
[15:18:09 CDT(-0500)] <cindyli> can we do that?
[15:18:12 CDT(-0500)] <Bosmon> We expect that this will be "perfectly acceptable" : P
[15:18:17 CDT(-0500)] <Bosmon> We plan to do it
[15:18:25 CDT(-0500)] <Bosmon> Subject to adjusting the component's idea of which jQuery object to use
[15:18:48 CDT(-0500)] <Bosmon> The plan is to simply give it a container inside the iframe, and "see what breaks first"
[15:19:10 CDT(-0500)] <Bosmon> Depending on what breaks, and where, we will adopt a series of strategies of increasing sophistication....
[15:19:22 CDT(-0500)] <cindyli> ah, now i see what you meant earlier with the jQuery experiment
[15:19:32 CDT(-0500)] <Bosmon> There may, for example, need to be a new renderer option which allows you to inject a custom jQuery object into it
[15:19:46 CDT(-0500)] <Bosmon> I mean, a custom "instance of the jQuery framework"
[15:20:18 CDT(-0500)] <Bosmon> On the other hand, since most of what the renderer does can be explained by innerHTML and calls to "val" etc. we may be able to get away without it
[15:20:39 CDT(-0500)] <Bosmon> colinclark, btw, will we have a group conversation soon about our IE6 support?
[15:20:45 CDT(-0500)] <colinclark> oh hi
[15:20:50 CDT(-0500)] <colinclark> Yes, that's something I'd really like to do
[15:20:52 CDT(-0500)] <Bosmon> Is it reasonable to say that for the purposes of cindyli's current work, we can neglect testing it in IE6?
[15:21:11 CDT(-0500)] <colinclark> I haven't had a lot of time to organize my thoughts here very much
[15:21:33 CDT(-0500)] <colinclark> I think, as a starting point, I'd be curious to hear areas where IE6 support causes us particular headaches
[15:21:51 CDT(-0500)] <colinclark> Especially if we can start to quantify
[15:21:58 CDT(-0500)] <colinclark> Uploader is probably a classic example
[15:22:05 CDT(-0500)] <Bosmon> It is precisely in this area - I think that, for example, that "strange code" in TableOfContents was put in because of a cross-iframe failure on IE6
[15:22:13 CDT(-0500)] <colinclark> Where the code base literally forks in half in order to provide IE support
[15:22:31 CDT(-0500)] <Bosmon> I am expecting that "whatever problems we run into" with our simplification of FatPanel, that these problems will definitely be more serious on IE6
[15:22:49 CDT(-0500)] <colinclark> My first, very sketchy thought on this subject was to drop "rich" support for IE6
[15:22:57 CDT(-0500)] <colinclark> but to continue to degrade gracefully as much as is feasible
[15:23:19 CDT(-0500)] <colinclark> So if you and cindyli can think of a scenario where we can preserve IE6 in a more limited fashion in UI Options, I'd be really keen to learn more
[15:23:21 CDT(-0500)] <Bosmon> My expectation is that these problems will be more serious than degrading, and will stop FatPanel from working at all
[15:23:33 CDT(-0500)] <colinclark> Okay
[15:23:36 CDT(-0500)] <colinclark> so that's sort of interesting
[15:24:02 CDT(-0500)] <colinclark> Could we provide a simplified alternative to FatPanel?
[15:24:09 CDT(-0500)] <colinclark> And do it dynamically for IE6?
[15:24:15 CDT(-0500)] <colinclark> I can imagine this might involve a design in itself
[15:24:17 CDT(-0500)] <Bosmon> For example, my best guess now is that if there is anything which requires us to change the renderer's API to allow a custom jQuery injected into it, it will most likey be a failure on IE6
[15:24:30 CDT(-0500)] <colinclark> ok
[15:24:41 CDT(-0500)] <colinclark> So, backing up for a second, I will show my rather fuzzy cards
[15:24:51 CDT(-0500)] <colinclark> If I were ready to make a proposal for dropping IE6 today, this would roughly be it:
[15:24:58 CDT(-0500)] <Bosmon> Well, my first idea for "what works on IE6", it would be the FullPreview and NoPreview configurations
[15:25:07 CDT(-0500)] <colinclark> 1. We no longer actively support rich interactions on IE6, except where we have currently stable implementations
[15:25:09 CDT(-0500)] <Bosmon> And say that if someone requests FatPanel, our impl degrades to one of those
[15:25:30 CDT(-0500)] <colinclark> 2. For IE6, we deliver a very simple, minimal user experience which may well legitimately compromise the elegance and efficiency
[15:25:39 CDT(-0500)] <colinclark> but will work, be stable, and easily tested
[15:25:41 CDT(-0500)] <Bosmon> But it seems hard to "degrade" to those, given that the use of FatPanel or otherwise would be a top-level design issue for the integrator
[15:25:48 CDT(-0500)] <colinclark> Bosmon: Yes, I think you're exactly right
[15:26:09 CDT(-0500)] <colinclark> We'd need to perhaps degrade to something resembling a Fat Panel that either has a little embedded preview in it
[15:26:11 CDT(-0500)] <colinclark> or does something else
[15:26:24 CDT(-0500)] <Bosmon> To me, that seems like at least a much work as making IE6 work properly
[15:26:28 CDT(-0500)] <Bosmon> as
[15:26:37 CDT(-0500)] <colinclark> That's a curious challenge in my proposal
[15:26:44 CDT(-0500)] <colinclark> which is why I haven't proposed it yet
[15:26:58 CDT(-0500)] <colinclark> jameswy: Can I interrupt you for a quick second?
[15:27:09 CDT(-0500)] <jameswy> colinclark: Yep, what's upt?
[15:27:15 CDT(-0500)] <colinclark> I have a sort of abstract question for you
[15:27:26 CDT(-0500)] <colinclark> We've started vaguely debating our IE6 support policy
[15:27:41 CDT(-0500)] <colinclark> My first stab at a proposal would be to no longer support rich interfaces for IE6
[15:27:55 CDT(-0500)] <colinclark> but to degrade gracefully to some workable but very simplified user interface
[15:28:19 CDT(-0500)] <colinclark> Could you imagine a very basic alternative to the FatPanel?
[15:28:28 CDT(-0500)] <jameswy> Hmm...
[15:28:45 CDT(-0500)] <colinclark> Bosmon: jameswy's answer to this question will likely affirm your point about the work involved
[15:28:52 CDT(-0500)] <colinclark> but let's explore it a bit
[15:29:01 CDT(-0500)] <jameswy> Yes, I can. One that's quite different, though. Almost a separate configuration in and of itself.
[15:29:08 CDT(-0500)] <colinclark> right
[15:29:23 CDT(-0500)] <colinclark> jameswy: So it'd be something like a fourth flavour of UIO
[15:29:32 CDT(-0500)] <colinclark> very different from the others?
[15:30:13 CDT(-0500)] <jameswy> Yes, possibly.
[15:30:19 CDT(-0500)] <colinclark> Okay, that helps
[15:30:27 CDT(-0500)] <colinclark> so, Bosmon, this brings us back to your very obvious economics
[15:30:36 CDT(-0500)] <colinclark> Dropping IE6 support from UIO saves us some time
[15:30:53 CDT(-0500)] <colinclark> Adding some new minimal flavour of UIO costs us fairly significant time
[15:31:03 CDT(-0500)] <colinclark> at least comparable to the time spent making things work in IE6
[15:31:41 CDT(-0500)] <colinclark> I think, from a strategic perspective, designing a simplified experience for many of our components for "unsupported browsers" is probably the right thing to do
[15:32:04 CDT(-0500)] <colinclark> The question now really becomes, "Do we want to drop IE6 for awhile, while we build up to the point where we can support a degraded experience?"
[15:32:08 CDT(-0500)] <colinclark> Funny question
[15:32:30 CDT(-0500)] <colinclark> I'm interested in everyone's thoughts about this, for whoever is listening in
[15:35:07 CDT(-0500)] <Bosmon> Personally the "dedicated degraded experience" seems like a bad plan to me
[15:35:18 CDT(-0500)] <Bosmon> And actively runs against many of our values as a community
[15:35:36 CDT(-0500)] <colinclark> How is that, Bosmon?
[15:35:44 CDT(-0500)] <Bosmon> It is a "two versions approach"
[15:35:49 CDT(-0500)] <Bosmon> With all of the evils that that entails
[15:36:04 CDT(-0500)] <Bosmon> The second version gets dedicated design, and dedicated development
[15:36:07 CDT(-0500)] <colinclark> Well, with IoC, hopefully many of the pains of such a thing is taken away
[15:36:09 CDT(-0500)] <Bosmon> And will surely lag painfully behind in both
[15:36:24 CDT(-0500)] <colinclark> I mean, UIO today arguably has three versions
[15:36:36 CDT(-0500)] <colinclark> but they also share much in common
[15:36:40 CDT(-0500)] <Bosmon> I guess it depends exactly what this version is like
[15:36:45 CDT(-0500)] <colinclark> The question is really about our boundaries
[15:36:50 CDT(-0500)] <Bosmon> If it is, for example, like the "simpleUploader" it might be only a small burden on us
[15:36:55 CDT(-0500)] <colinclark> What do we do when we can no longer afford to actively support something?
[15:37:01 CDT(-0500)] <Bosmon> But it is worth noticing that even the "simpleUploader" is the thing most likely to be broken at any time
[15:37:07 CDT(-0500)] <Bosmon> Simply because we very rarely look at it or test it
[15:37:26 CDT(-0500)] <colinclark> Yes, there is some truth to this
[15:37:37 CDT(-0500)] <colinclark> But, arguably, we really don't have a story about what we do when we can't support someone
[15:37:50 CDT(-0500)] <Bosmon> And I doubt that the "simple UIO" will be anything like as simple as the "simpleUploader"
[15:37:55 CDT(-0500)] <colinclark> with all of the often-onerous tasks that go along with "support"
[15:37:58 CDT(-0500)] <Bosmon> Since I imagine it will actually need to do something : P
[15:38:02 CDT(-0500)] <Bosmon> I mean, it will have some kind of UI
[15:38:10 CDT(-0500)] <colinclark> yes, that's correct
[15:38:11 CDT(-0500)] <Bosmon> And it will actually do something to the document
[15:38:18 CDT(-0500)] <Bosmon> So in those terms, it will actually be far from trivial
[15:38:53 CDT(-0500)] <colinclark> Presumably, though, part of our whole model is to break out of a world where we always need to have only one thing
[15:39:02 CDT(-0500)] <Bosmon> So far I am finding it very hard to think of anything we conceivably do that would be cheaper than just "making it work on IE6"
[15:39:19 CDT(-0500)] <Bosmon> Especially since we know rather more about the problems after having bashed our heads against them through our last release cycle
[15:39:24 CDT(-0500)] <colinclark> Well, not bothering to make it work on IE6 is likely cheaper
[15:39:28 CDT(-0500)] <Bosmon> Yes
[15:39:35 CDT(-0500)] <Bosmon> Anything we could do, other than that
[15:39:47 CDT(-0500)] <Bosmon> Anything else we did, would still need a full round of testing and debugging
[15:39:59 CDT(-0500)] <Bosmon> And if it didn't use the same impl as on the browsers, this would be even more expensive
[15:40:32 CDT(-0500)] <colinclark> Perhaps part of the issue is the cost associated with "support" today
[15:40:44 CDT(-0500)] <Bosmon> How do those costs break down?
[15:40:55 CDT(-0500)] <colinclark> but I don't have any really bright ideas about how to reduce that cost without also just giving up any assurance that the thing will work in places we don't test actively
[15:41:12 CDT(-0500)] <Bosmon> In IE6, that assurance would be practically worthless
[15:41:13 CDT(-0500)] <colinclark> I had hoped that we'd gather some concrete metrics about how our QA process works
[15:41:15 CDT(-0500)] <colinclark> how much it costs
[15:41:21 CDT(-0500)] <Bosmon> It is almost an axiom that something which has not been tested on IE6 will break on IE6
[15:41:27 CDT(-0500)] <colinclark> Justin_o may well have some of these insights
[15:41:31 CDT(-0500)] <colinclark> Bosmon: Yes, I think that's entirely true
[15:41:45 CDT(-0500)] <colinclark> It's quite likely that anything not testing in one area will break in that particular area
[15:41:51 CDT(-0500)] <colinclark> be it IE6 or anything else
[15:41:57 CDT(-0500)] <colinclark> IE6 just raises the risk
[15:42:28 CDT(-0500)] <colinclark> due to a complete lack of support for "we built it to standards, so it should just work"
[15:42:57 CDT(-0500)] <colinclark> What I'd like to do, in the long run, is to start to modularize our support for some environments
[15:43:05 CDT(-0500)] <Bosmon> It does raise it enormously, I think
[15:43:05 CDT(-0500)] <colinclark> the Uploader is probably the only one amenable to this sort of thing
[15:43:19 CDT(-0500)] <Bosmon> For example, when I make fixes, I test them just on FF and maybe Chrome on Windows
[15:43:25 CDT(-0500)] <colinclark> and then try to involve the community in helping with, say, IE6 support if it is important to them
[15:43:31 CDT(-0500)] <Bosmon> 9 times out of 10 this means that they work fine on all the enviroments we support, other than IE
[15:43:42 CDT(-0500)] <Bosmon> For IE6, this figure is much more like 1 time out of 10
[15:43:43 CDT(-0500)] <colinclark> but we really can't do that without viable implementations that a) work in IE6 and b) are amenable to being split off
[15:44:38 CDT(-0500)] <Bosmon> b) is sort of interesting.... so for example, after much running around the houses, we ended up with an impl of TOC for the 1.4 release that is actually quite simply
[15:44:41 CDT(-0500)] <Bosmon> simple
[15:44:45 CDT(-0500)] <colinclark> We have always asserted that the advantages of Infusion components, and of IoC, is that they enable multiple user experiences to be supported without the traditional high cost of maintenance
[15:44:45 CDT(-0500)] <Bosmon> But it is in a way "slimy"
[15:44:51 CDT(-0500)] <Bosmon> It is like a stone that has become polished smooth....
[15:44:55 CDT(-0500)] <colinclark> but I guess we don't really have a good way to make this happen in practice
[15:45:00 CDT(-0500)] <colinclark> for IE6 support, anyway
[15:45:02 CDT(-0500)] <Bosmon> We found 1 line of code that "just happens to work in all environments"
[15:45:08 CDT(-0500)] <Bosmon> But the reasons that it works are quite complex
[15:45:21 CDT(-0500)] <Bosmon> So complex that when I first came upon it during the development phase, I simply destroyed it
[15:45:30 CDT(-0500)] <colinclark> yes, that's interesting
[15:45:30 CDT(-0500)] <Bosmon> Through i) not understanding what the reasons were, and ii) they not being documented there
[15:45:44 CDT(-0500)] <Bosmon> But this is a kind of hallmark of the kinds of solutions we come up with "in the end", where IE6 is involved
[15:45:47 CDT(-0500)] <colinclark> Do you have any magical insights into IE6 support, michelled?
[15:46:01 CDT(-0500)] <colinclark> I fear we really are just faced with the traditional dichotomy everyone else faces
[15:46:04 CDT(-0500)] <Bosmon> THey don't necessarily involve a large amount of extra implementation, but they DO generally involve a large amount of extra EXPERIENCE
[15:46:04 CDT(-0500)] <colinclark> support it and pay the cost
[15:46:12 CDT(-0500)] <colinclark> or don't support it and pay the alternative cost
[15:46:28 CDT(-0500)] <colinclark> Yes, that kind of experience is very expensive, Bosmon
[15:46:44 CDT(-0500)] <colinclark> The slow, painful process of trying things out, doing research, and eventually landing on a solution
[15:47:02 CDT(-0500)] <colinclark> not to mention that this kind of situation tends to risk being discovered late int he process
[15:47:04 CDT(-0500)] <colinclark> rather than early
[15:47:11 CDT(-0500)] <Bosmon> I would guess that getting this experience might have cost us up to 50% of the time spent in the last phase of the release process for 1.4
[15:47:17 CDT(-0500)] <colinclark> Right
[15:47:22 CDT(-0500)] <colinclark> That's very very high
[15:47:27 CDT(-0500)] <Bosmon> In theory, some or a good proportion of this experience might be transferable into the future
[15:47:30 CDT(-0500)] <Bosmon> But it's hard to tell
[15:47:38 CDT(-0500)] <colinclark> I figure we've paid similarly high costs in at least the Reoderer and the Uploader
[15:47:44 CDT(-0500)] <colinclark> Probably Inline Edit also
[15:48:11 CDT(-0500)] <colinclark> I'm actually feeling slightly more cynical than you about the transferability of IE knowledge, Bosmon
[15:48:24 CDT(-0500)] <athena> so . . . if i have one of these newfangled proto-typey component tree deals . . . how would i manually render / render it? if i have renderOnInit off?
[15:48:25 CDT(-0500)] <Bosmon> Well, I doubt that much of it is transferrable in general
[15:48:42 CDT(-0500)] <Bosmon> But I believe it might be transferrable at least to future development on the same component : P
[15:48:45 CDT(-0500)] <colinclark> ooh, athena actually has an interesting question
[15:48:49 CDT(-0500)] <colinclark>
[15:49:03 CDT(-0500)] <Bosmon> athena - you just call "refreshView"
[15:49:08 CDT(-0500)] <athena> excellent.
[15:49:16 CDT(-0500)] <athena> i like answers that begin with "just"
[15:49:17 CDT(-0500)] <Bosmon> There is also a synthesised member on it called "renderer"
[15:49:22 CDT(-0500)] <Bosmon> Which has a few other methods which are helpful
[15:50:33 CDT(-0500)] <Bosmon> I mean, on the component
[15:50:47 CDT(-0500)] <athena> excellent
[15:51:21 CDT(-0500)] <colinclark> Whatcha building, athena?
[15:51:33 CDT(-0500)] <athena> eh, trying to fix up the news reader's javascript
[15:51:49 CDT(-0500)] <athena> what it has now is . . . not good
[15:52:26 CDT(-0500)] <athena> ooh ooh ooh
[15:52:27 CDT(-0500)] <athena> it works
[15:52:28 CDT(-0500)] <athena> thanks
[15:52:35 CDT(-0500)] <athena> i may get this component refactored yet
[15:52:37 CDT(-0500)] <colinclark> wicked
[15:52:47 CDT(-0500)] <athena> this is the poor sad one i was working on after the jasig conference
[15:52:53 CDT(-0500)] <colinclark> Honestly, refactoring "β¦ not good" code is one of my favourite things to do
[15:52:54 CDT(-0500)] <athena> but i keep getting pulled away on other things
[15:53:00 CDT(-0500)] <colinclark> when there isn't way too much of it, anyway
[15:53:05 CDT(-0500)] <Bosmon> What was that square, colinclark?
[15:53:08 CDT(-0500)] <athena> yeah, refactoring is good
[15:53:24 CDT(-0500)] <athena> also, bosmon assures me that this poor component is guilty of many terrible evils and of killing our users
[15:53:30 CDT(-0500)] <colinclark> Square, Bosmon?
[15:53:36 CDT(-0500)] <Bosmon> What a wicked component
[15:53:40 CDT(-0500)] <colinclark> Bosmon is so typically hyperbolic
[15:53:44 CDT(-0500)] <Bosmon> In "β¦ not good"
[15:53:48 CDT(-0500)] <Bosmon> Sometimes I am just elliptical
[15:53:48 CDT(-0500)] <athena> what!? him!?
[15:53:59 CDT(-0500)] <colinclark> or rather
[15:54:03 CDT(-0500)] <colinclark> full of hyperbole
[15:54:08 CDT(-0500)] <colinclark> which might as well be hyperbolic
[15:54:10 CDT(-0500)] <athena> actually the current implementation is terrible and does slow down the whole portal page
[15:54:13 CDT(-0500)] <colinclark> even if the dictionary doesn't agree
[15:54:14 CDT(-0500)] <athena> so it'd be good to fix
[15:54:43 CDT(-0500)] <colinclark> I thought "wicked" was the opposite of "β¦ not good"
[15:54:56 CDT(-0500)] <Bosmon> I still just see a square
[15:54:56 CDT(-0500)] <colinclark> Sort of like how the new generation use the work "sick"
[15:55:37 CDT(-0500)] <athena> i once accidentally said something along the lines of "that's wicked cool dude"
[15:55:45 CDT(-0500)] <colinclark> lol
[15:55:48 CDT(-0500)] <athena> and immediately was horrified and decided i'd lived in way too many different places
[15:55:53 CDT(-0500)] <colinclark>
[15:55:54 CDT(-0500)] <athena> mixing coasts in a bad way there
[15:56:05 CDT(-0500)] <colinclark> hey athena, while you're here...
[15:56:14 CDT(-0500)] <colinclark> I'll ask a spontaneous yet relevant question...
[15:56:25 CDT(-0500)] <athena> excellent
[15:56:30 CDT(-0500)] <colinclark> Would your community freak if Infusion 1.5, say, didn't support IE6?
[15:56:36 CDT(-0500)] <colinclark> Umm, just hypothetically, of course 
[15:56:41 CDT(-0500)] <athena> that's a good question
[15:56:45 CDT(-0500)] <Bosmon> This might be the most relevant question of the whole afternoon
[15:56:48 CDT(-0500)] <athena> maybe ask on the up-user list?
[15:57:01 CDT(-0500)] <athena> i bet we'd all love if we didn't have to support ie6 as well . . .
[15:57:06 CDT(-0500)] <athena> full of pain and horribleness
[15:57:15 CDT(-0500)] <Bosmon> Does uPortal have any plans to use UIOptions?
[15:57:42 CDT(-0500)] <colinclark> I hope it might be useful in uP some day
[15:58:05 CDT(-0500)] <colinclark> athena: I'll definitely ask on the list once we're getting a bit clearer about even what options we have
[15:58:20 CDT(-0500)] <colinclark> In the meantime, do you have any magical ideas for supporting IE6 while reducing the cost of doing so?
[15:58:40 CDT(-0500)] <athena> i think we'd really, really love to use UI options
[15:58:52 CDT(-0500)] <athena> we'd have to have some way of making time to make it work, which is of course the blocker
[15:59:03 CDT(-0500)] <athena> and then of course everything's always 5 billion times more complicated in portal-world
[15:59:06 CDT(-0500)] <athena> but it'd be totally awesome
[15:59:08 CDT(-0500)] <colinclark> We might be able to lend a hand with that at some point, athena
[15:59:10 CDT(-0500)] <athena> and, no i know nothing about ie
[15:59:14 CDT(-0500)] <colinclark> complications and all
[15:59:20 CDT(-0500)] <athena> i have a current plan that includes "install windows"
[15:59:25 CDT(-0500)] <colinclark> lol
[15:59:29 CDT(-0500)] <athena> yeah
[15:59:41 CDT(-0500)] <athena> and if you guys were up for helping w/ ui options in uportal that would be fabulous
[15:59:46 CDT(-0500)] <athena> we welcome your help anytime and always
[15:59:53 CDT(-0500)] <athena> and we've definitely talked about wanting ui options in the portal before
[15:59:57 CDT(-0500)] <colinclark> Let's see what we can do once we've found our feet after this release
[16:00:03 CDT(-0500)] <athena> awesome
[16:00:05 CDT(-0500)] <colinclark> we're sort of on a mission to put UIO everywhere we can
[16:00:07 CDT(-0500)] <athena> we miss you guys
[16:00:09 CDT(-0500)] <athena> hurray!
[16:00:19 CDT(-0500)] <athena> if you come to the unconference we could always talk about it there . . .
[16:00:27 CDT(-0500)] <colinclark> That would be so cool
[16:00:49 CDT(-0500)] <athena> but regardless working together is always awesome
[16:00:55 CDT(-0500)] <colinclark> I think we probably can't make it to this one
[16:00:57 CDT(-0500)] <colinclark> but hopefully the next one
[16:01:02 CDT(-0500)] <colinclark> it really is awesome
[16:01:06 CDT(-0500)] <athena> yeah, and to be honest i think most of us arent' staying the full week
[16:01:12 CDT(-0500)] <athena> my "free" time outside of work is a bit more limited these days unfortunately due to school
[16:01:18 CDT(-0500)] <athena> but would still love to help out where i can
[16:01:19 CDT(-0500)] <colinclark> I can imagine
[16:01:31 CDT(-0500)] <colinclark> Bosmon: So, I'm still not quite ready to let my dreams goβ¦
[16:01:45 CDT(-0500)] <colinclark> maybe I'll try one more angle
[16:01:49 CDT(-0500)] <colinclark> probably unproductively
[16:01:50 CDT(-0500)] <Bosmon> ok
[16:02:00 CDT(-0500)] <colinclark> So, let's imagine that this alternative to the current FatPanel is incredibly reduced
[16:03:08 CDT(-0500)] <colinclark> Like, it's just a bunch of simple form fields
[16:03:33 CDT(-0500)] <colinclark> A minimal amount of (hopefully) shared JavaScript to set the user's settings
[16:03:37 CDT(-0500)] <colinclark> that sort of thiing
[16:03:52 CDT(-0500)] <colinclark> Could we imagine something that didn't still represent a massive cost?
[16:04:04 CDT(-0500)] <Bosmon> I guess the interesting thing about this conversation is that it isn't really "time-symmetric"
[16:04:05 CDT(-0500)] <colinclark> I guess your point about the simple Uploader still costing a ton in terms of testing time is relevant here
[16:04:10 CDT(-0500)] <colinclark> lol
[16:04:23 CDT(-0500)] <colinclark> erm, elaborate
[16:04:30 CDT(-0500)] <Bosmon> That is - we will always have it from a point of view in which we have succeeded in getting something working in IE6
[16:04:43 CDT(-0500)] <colinclark> I don't quite know what you mean
[16:04:51 CDT(-0500)] <Bosmon> Well... today's UIO works now
[16:04:54 CDT(-0500)] <Bosmon> As does everything in the framework
[16:04:58 CDT(-0500)] <colinclark> yes
[16:04:58 CDT(-0500)] <Bosmon> In IE6
[16:05:00 CDT(-0500)] <Bosmon> By and large....
[16:05:24 CDT(-0500)] <Bosmon> So whenever we imagine some "reduced level of support", we always have to somehow imagine this being reduced from what we have now
[16:05:29 CDT(-0500)] <Bosmon> Since what we have now is mainly what we can imagine
[16:05:36 CDT(-0500)] <Bosmon> What we have in the future is stuff we haven't designed yet
[16:05:40 CDT(-0500)] <colinclark>
[16:05:53 CDT(-0500)] <Bosmon> But this always places us in the rather illogical position of somehow breaking stuff that we already have working
[16:06:02 CDT(-0500)] <Bosmon> Or ignoring the costs of having got it that way
[16:06:06 CDT(-0500)] <colinclark> I sort of hope that these two things might be largely separate
[16:06:12 CDT(-0500)] <colinclark> or at least something we can address opportunistically
[16:06:28 CDT(-0500)] <Bosmon> So for example your vision of a "reduced feature UIO" reduces it in ways which it is currently working
[16:06:43 CDT(-0500)] <colinclark> Like, for example, we could choose to continue with greater support for IE6 in some components, where it's cost-effective to do so
[16:06:50 CDT(-0500)] <colinclark> Bosmon: Yes, that's entirely true
[16:07:10 CDT(-0500)] <colinclark> In order to, theoretically, reduce the costs of continued improvement and development of it elsewhere
[16:07:32 CDT(-0500)] <Bosmon> So, we came in on this discussion since I was anticipating the chance of some increased development cost over the next 2 weeks
[16:07:40 CDT(-0500)] <colinclark> yes
[16:07:43 CDT(-0500)] <Bosmon> Due to keeping IE6 working as part of cindy's current work
[16:07:56 CDT(-0500)] <Bosmon> Unfortunately the breakage we would suffer in that case would be total
[16:08:10 CDT(-0500)] <colinclark> Right
[16:08:24 CDT(-0500)] <colinclark> We have to have some strategic direction with which to look at questions like this
[16:08:26 CDT(-0500)] <Bosmon> I guess the point I'm trying to make is.... it seems unrealistic to imagine we can actually have control of the process, whereby we "pick and choose" our level of support
[16:08:31 CDT(-0500)] <colinclark> even if we don't implement the future immediately
[16:08:41 CDT(-0500)] <Bosmon> In fact, it's precisely because these failures are unpredictable, which takes this choice away from us in most cases
[16:09:08 CDT(-0500)] <colinclark> Well, we'll have some control
[16:09:25 CDT(-0500)] <colinclark> My point was more that we needn't actively dismantle existing components where they're not faced with this situation
[16:09:36 CDT(-0500)] <colinclark> I mean, the Reorderer is quite stable
[16:09:41 CDT(-0500)] <Bosmon> Yes
[16:09:49 CDT(-0500)] <colinclark> we're don't have major new features planned for it at the moment
[16:09:54 CDT(-0500)] <Bosmon> In fact, I believe, most of these components are ones we are "no longer actively developing"
[16:09:56 CDT(-0500)] <colinclark> We don't have to ask hard questions about its IE6 support
[16:10:09 CDT(-0500)] <Bosmon> Perhaps really UIO is the only component which we really are actively developing?
[16:10:14 CDT(-0500)] <colinclark> UI Options has a roadmap of central growth and evolution over the next little while
[16:10:22 CDT(-0500)] <colinclark> At the moment, that's probably largely true
[16:10:34 CDT(-0500)] <colinclark> I'd love to have Pager on that roadmap, but it's probably not practical right now
[16:10:45 CDT(-0500)] <colinclark> Most of our other components are reaching a reasonable level of stability
[16:10:50 CDT(-0500)] <colinclark> Uploader, Reorderer, etc.
[16:11:07 CDT(-0500)] <colinclark> We have to pay some portion of the overall support costs for IE6 each time we release
[16:11:18 CDT(-0500)] <colinclark> It's a fixed cost, and it can be deferred until we next schedule a major release
[16:11:32 CDT(-0500)] <colinclark> That is the time it takes to test and qualify such components in IE6
[16:11:43 CDT(-0500)] <colinclark> The pressing question is what we're doing with actively evolving components
[16:12:03 CDT(-0500)] <colinclark> UIO is, as you say, the real key here
[16:12:08 CDT(-0500)] <Bosmon> If we're willing to defer the cost, this suggests to me that we defer it
[16:12:16 CDT(-0500)] <Bosmon> Unfortunately there is a really problematic aspect of the deferral
[16:12:36 CDT(-0500)] <Bosmon> So, there was a significant part of this release where we were not prepared to accept changes to the core framework
[16:12:50 CDT(-0500)] <colinclark> "this release" being 1.4?
[16:12:53 CDT(-0500)] <Bosmon> Yes
[16:12:55 CDT(-0500)] <colinclark> ok
[16:13:48 CDT(-0500)] <Bosmon> But if, for example, the failure that cindy is going to run in to is of the kind I am speculating it is, it couldn't be addressed without core framework changes
[16:14:04 CDT(-0500)] <colinclark> yes
[16:15:07 CDT(-0500)] <Bosmon> Well, it'll be interesting to see what kind of answer we get from the up-users lists...
[16:15:20 CDT(-0500)] <colinclark> Yes
[16:15:27 CDT(-0500)] <colinclark> I actually feel that it's a second step for us
[16:15:36 CDT(-0500)] <colinclark> the first being to get a clear idea of what options are available to us
[16:15:40 CDT(-0500)] <Bosmon> I used to be one of those most ardently in favour of keeping in IE6 support for as long as necessary
[16:15:42 CDT(-0500)] <colinclark> which I think we're still in the midst of
[16:15:46 CDT(-0500)] <colinclark> As was I
[16:15:52 CDT(-0500)] <Bosmon> But after seeing what we paid during 1.4, I am now ardently in favour of dropping it completely
[16:16:03 CDT(-0500)] <Bosmon> I don't see that we have the resources as a community to afford to pay any attention to it at all
[16:16:10 CDT(-0500)] <colinclark> Interestingly, I think we're probably awfully close to the natural point we expected to arrive at, at some point
[16:16:27 CDT(-0500)] <colinclark> I think I may be close to having to buy athena a beer for an old bet
[16:16:34 CDT(-0500)] <colinclark> or maybe I already owe her one
[16:16:35 CDT(-0500)] <Bosmon> How did the bet work?
[16:16:41 CDT(-0500)] <colinclark> I forget the details exactly
[16:16:47 CDT(-0500)] <Bosmon> THat we would be "supporting IE6 till 2016"? : P
[16:16:57 CDT(-0500)] <athena> well, i think that bet was marked 2011
[16:17:03 CDT(-0500)] <athena> but we can refresh it!
[16:17:05 CDT(-0500)] <colinclark>
[16:17:07 CDT(-0500)] <Bosmon> Which one of you chose 2011?
[16:17:11 CDT(-0500)] <colinclark> Who won the 2011 bet, athena?
[16:17:20 CDT(-0500)] <colinclark> I always make bad bets
[16:17:42 CDT(-0500)] <athena> hmm, i don't remember - have to look it up
[16:17:49 CDT(-0500)] <colinclark> glad i'm not the only one
[16:17:54 CDT(-0500)] <athena> but think it was more about celebrating if we weren't supporting IE and consoling each other if we were
[16:17:59 CDT(-0500)] <colinclark> yeah
[16:18:01 CDT(-0500)] <athena> but i put it in timecave so i can check!
[16:18:08 CDT(-0500)] <colinclark> either way, we're probably in the consoling camp still
[16:18:19 CDT(-0500)] <athena>
[16:18:22 CDT(-0500)] <colinclark> Bosmon: So, I'm still not quite satisfied (as should be expected)...
[16:18:32 CDT(-0500)] <athena> here we go!
[16:18:34 CDT(-0500)] <athena> colinclark: athena: I'll buy you beers if IE isn't dead by 2011, though.
[16:18:34 CDT(-0500)] <athena> [2:21pm] athena: lol
[16:18:34 CDT(-0500)] <athena> [2:21pm] athena: we'd need to agree on a definition of "dead"
[16:18:34 CDT(-0500)] <athena> [2:22pm] colinclark: how about:
[16:18:34 CDT(-0500)] <athena> [2:22pm] colinclark: not actively supported by uPortal or Fluid
[16:18:34 CDT(-0500)] <athena> [2:22pm] athena: sounds good to me!
[16:18:34 CDT(-0500)] <athena> [2:22pm] athena: and if we're still supporting it in 2011, i'll buy you beer and we can cry into them
[16:18:38 CDT(-0500)] <colinclark> shoot
[16:18:45 CDT(-0500)] <colinclark> So I lose
[16:18:48 CDT(-0500)] <colinclark> And suck
[16:18:50 CDT(-0500)] <colinclark> and make bad bets
[16:18:58 CDT(-0500)] <athena> and on jan 3 of this year you wrote "I owe you a gigantic beer!"
[16:19:08 CDT(-0500)] <athena> so next conference you make it to i guess i'm going to make you buy me a really big one
[16:19:13 CDT(-0500)] <colinclark> Well, the good news is that beers are involved
[16:19:22 CDT(-0500)] <colinclark> I'll buy you a whole case of 'em, whenever we next meet
[16:19:23 CDT(-0500)] <athena> it does make it better
[16:19:43 CDT(-0500)] <athena> hurray!
[16:19:46 CDT(-0500)] <colinclark> We can look at some interesting examples in the wild...
[16:19:57 CDT(-0500)] <colinclark> jQuery Mobile probably being the most successful example of working progressive enhancement
[16:22:15 CDT(-0500)] <colinclark> Arguably, with a "multiple flavours" approach,we're actually expanding our browser support
[16:22:16 CDT(-0500)] <Bosmon> I guess we would need to look at some examples of what these were
[16:22:30 CDT(-0500)] <colinclark> I guess the key argument is still that we get to some basic point...
[16:22:34 CDT(-0500)] <colinclark> where either it works or it doesn't
[16:22:41 CDT(-0500)] <colinclark> and the only way to really be confident in this is to test it
[16:22:55 CDT(-0500)] <Bosmon> Certainly we're far right now from being able to reach any mobile environments
[16:23:06 CDT(-0500)] <colinclark> I mean, if we confidently felt like we had an idiom that could generally support basic experiences
[16:23:08 CDT(-0500)] <Bosmon> Not without something like "fluidLite" and even then with considerable difficulty
[16:23:11 CDT(-0500)] <colinclark> then perhaps that would be enough...
[16:23:29 CDT(-0500)] <colinclark> stop testing on IE6, but at least have some "hooks" for the larger community to test and easily provide fixes
[16:23:39 CDT(-0500)] <Bosmon> How does jQuery mobile deal with its own download and execution costs?
[16:23:58 CDT(-0500)] <colinclark> I don't know
[16:24:04 CDT(-0500)] <colinclark> I guess it's not really the point
[16:24:09 CDT(-0500)] <colinclark> Though it's a very interesting question
[16:24:32 CDT(-0500)] <colinclark> They clearly take a bit of time up front to support a degraded but workable experience
[16:24:43 CDT(-0500)] <colinclark> and supposedly reap the benefits of it
[16:24:54 CDT(-0500)] <colinclark> We've always been pretty strong proponents of Progressive Enhancement
[16:25:06 CDT(-0500)] <colinclark> but largely asked our users to do it in the way that best suited their servers and apps
[16:25:11 CDT(-0500)] <colinclark> Which isn't unreasonable
[16:25:28 CDT(-0500)] <colinclark> I guess I'm advocating for some kind of IoC-supported style of this, out of the box
[16:25:31 CDT(-0500)] <Bosmon> So, I guess this is the nature of the paradox
[16:25:42 CDT(-0500)] <Bosmon> Well, it's not quite a paradox
[16:25:48 CDT(-0500)] <Bosmon> I guess it is more a "tragedy" : P
[16:25:53 CDT(-0500)] <Bosmon> In the style of "tragedy of the commons"
[16:26:08 CDT(-0500)] <colinclark>
[16:26:48 CDT(-0500)] <Bosmon> It's hard to imagine, considered as a set of sequential decisions, that we would ever find ourselves faced with an immediate set of choices, where we could choose to either i) simply fix up what we have in IE6 to make it work, or ii) start developing a separate simplified version
[16:26:59 CDT(-0500)] <Bosmon> Where in terms of the immediate choices i) would not be cheaper than ii)
[16:27:06 CDT(-0500)] <Bosmon> I think by the nature of our development, it is always incremental
[16:27:14 CDT(-0500)] <colinclark> yes
[16:27:15 CDT(-0500)] <Bosmon> So it would always seem an immediately superior choice to fix up what we have
[16:27:32 CDT(-0500)] <colinclark> That's why I'm arguing that this is a strategic decision
[16:27:42 CDT(-0500)] <colinclark> not necessarily one that should be rooted in immediate economics
[16:27:54 CDT(-0500)] <colinclark> I'm nervous to make this analogy
[16:28:01 CDT(-0500)] <colinclark> but it's a bit like American polics
[16:28:09 CDT(-0500)] <colinclark> politics
[16:28:28 CDT(-0500)] <colinclark> where it's hard to make a case for things costing a bit more within the course of a four year term, in order to save more money after those four years
[16:28:40 CDT(-0500)] <colinclark> In our case, it may still be impossibly too much
[16:29:00 CDT(-0500)] <colinclark> but I'm trying to imagine a situation where we might strategically pay some additional upfront cost
[16:29:12 CDT(-0500)] <colinclark> that might save us the incremental, smaller cost of IE support in the long run
[16:29:20 CDT(-0500)] <Bosmon> We might
[16:29:27 CDT(-0500)] <colinclark> I think the weakest part to my argument is still testing
[16:29:28 CDT(-0500)] <Bosmon> Were the decisions not surrounded by so many unponderables
[16:29:45 CDT(-0500)] <colinclark> the unponderables being..
[16:29:49 CDT(-0500)] <athena> ok, i have another renderer question
[16:29:57 CDT(-0500)] <colinclark> fire away, athena
[16:30:01 CDT(-0500)] <athena> i have a component that has a bunch of child components
[16:30:10 CDT(-0500)] <athena> and the parent component has a "url" option that i need to set
[16:30:19 CDT(-0500)] <Bosmon> It's hard to fully anticipate i) the full magnitude of the costs we are avoiding, ii) being sure that the separate development actually ever works out ANY cheaper than constantly patching it up, and iii) bearing in mind that the costs will certainly drop to zero some time when we finally drop IE6 support completely
[16:30:19 CDT(-0500)] <athena> and i'd like the child component to also have access to that same URL
[16:30:29 CDT(-0500)] <Bosmon> athena - inject it via IOC?
[16:30:38 CDT(-0500)] <athena> trying, but probably doing it wrong
[16:30:57 CDT(-0500)] <athena> so on the child component i have options:
[16:31:15 CDT(-0500)] <Bosmon> athena - that should in theory work fine
[16:31:17 CDT(-0500)] <athena> should it be " .options.url"? something else?
[16:31:24 CDT(-0500)] <Bosmon> oh yes
[16:31:31 CDT(-0500)] <Bosmon> Well, if it is an option, you need to add options
[16:31:41 CDT(-0500)] <Bosmon> Unless there is code that manually transfers "url" onto the component itself
[16:31:53 CDT(-0500)] <Bosmon> " " does refer to the physical component instance itself
[16:31:54 CDT(-0500)] <Bosmon> The "that"
[16:32:10 CDT(-0500)] <athena> ahh, ok
[16:32:19 CDT(-0500)] <athena> i think i get confused about when i need to actually say options and when i don't
[16:32:23 CDT(-0500)] <athena> seems to be magic in random places
[16:32:30 CDT(-0500)] <athena> but that makes sense
[16:32:31 CDT(-0500)] <athena> thanks!
[16:32:37 CDT(-0500)] <Bosmon> athena - there is a kind of logic to it
[16:32:49 CDT(-0500)] <Bosmon> And thanks to your earlier reports, 1.4 will actually provide some kind of sensible warnings in some places
[16:33:12 CDT(-0500)] <athena> sensible warnings! what is this world coming to!
[16:33:49 CDT(-0500)] <colinclark> Bosmon did a really nice job of responding to user complaints about the debugging and development experience in Infusion
[16:33:55 CDT(-0500)] <colinclark> I'm quite impressed, for the record
[16:34:01 CDT(-0500)] <Bosmon> Don't worry, if you really feel strongly about having environments which fail randomly and unpredictably with no useful diagnostics, there is now WebGL to keep you happy
[16:34:23 CDT(-0500)] <athena> lol
[16:34:29 CDT(-0500)] <athena> no actually i think i can live with that
[16:34:34 CDT(-0500)] <athena> and you guys have done a terrific job
[16:34:41 CDT(-0500)] <athena> feel like i just need to get my head around all this new stuff
[16:34:45 CDT(-0500)] <colinclark> We try our best
[16:34:51 CDT(-0500)] <Bosmon> Thanks colinclark - I need to dash off now, but let's reconvene this tomorrow
[16:34:53 CDT(-0500)] <colinclark> you're always fast to get your head around these things, too
[16:34:58 CDT(-0500)] <colinclark> Bosmon: It's a big can of worms
[16:35:07 CDT(-0500)] <Bosmon> athena - it's just as well then that we are being slower about generating the even newer stuff
[16:35:14 CDT(-0500)] <colinclark> I'm leaning towards, as a short-term strategy, deferring all IE6-related costs
[16:35:17 CDT(-0500)] <Bosmon> It will at least give you some kind of breather to get your head around the "old new stuff"....
[16:35:22 CDT(-0500)] <athena> well, the IRC help does make a difference
[16:35:27 CDT(-0500)] <colinclark> running the distinct risk that we may have to go back and patch up such breakages, Bosmon
[16:35:35 CDT(-0500)] <Bosmon> Even though it is illogical and bug-ridden in several places
[16:35:57 CDT(-0500)] <colinclark> hopefully the benefits outweigh the bugs, even today
[16:36:09 CDT(-0500)] <colinclark> I think they do, for the code I've written int he past while
[16:36:20 CDT(-0500)] <Bosmon> colinclark - sounds reasonable - although I am anticipating in this case (cindy's work) the costs will be unusually larger than expected
[16:36:26 CDT(-0500)] <colinclark> yeah
[16:36:31 CDT(-0500)] <colinclark> I think ti's probably a risk worth taking
[16:36:33 CDT(-0500)] <Bosmon> And probably requiring some additional core framework support
[16:36:53 CDT(-0500)] <colinclark> 1.4 is still so hot
[16:37:02 CDT(-0500)] <colinclark> we don't need to face a 1.5 release any time soon, I hope
[16:37:16 CDT(-0500)] <colinclark> So we can focus on rapid prototyping for now
[16:37:23 CDT(-0500)] <colinclark> at the expense of IE6 support for awhile
[16:37:24 CDT(-0500)] <Bosmon> I don't think we could manage one before the summer
[16:37:30 CDT(-0500)] <Bosmon> Possibly even not before next winter
[16:37:37 CDT(-0500)] <colinclark> hopefully we don't need one, anyway
[16:37:47 CDT(-0500)] <colinclark> A minor release is okay
[16:37:51 CDT(-0500)] <colinclark> a few bugs or whatever
[16:38:11 CDT(-0500)] <colinclark> So, unless you have a huge concern about it, let's currently not sweat IE6 support in UIO while we're prototyping
[16:38:17 CDT(-0500)] <Bosmon> ok, sounds good
[16:38:24 CDT(-0500)] <colinclark> And we'll revisit
[16:38:29 CDT(-0500)] <colinclark> For the record, this isn't a decision
[16:38:31 CDT(-0500)] <colinclark> It's not strategy
[16:38:37 CDT(-0500)] <colinclark> it's not a comment on what Infusion 1.5 will support
[16:38:40 CDT(-0500)] <Bosmon> ok
[16:38:45 CDT(-0500)] <colinclark>
[16:38:51 CDT(-0500)] <colinclark> Thanks,Bosmon
[16:38:53 CDT(-0500)] <colinclark> see you tomorrow
[16:39:01 CDT(-0500)] <Bosmon> Cheers, see you then
[16:52:00 CDT(-0500)] <athena> is there an update model method for these components?