fluid-work IRC Logs-2011-10-18
[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)]