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 (smile) 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 (smile)

[10:05:20 CDT(-0500)] <Justin_o> jhung: so for the error.. i had forgot i had put on a break point (sad) 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 (smile)

[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> (smile)

[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 (smile)

[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. (smile)

[13:40:06 CDT(-0500)] <Bosmon> cindyli - I will look forward to it (smile)

[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 (tongue)

[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" (smile)

[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 (smile)

[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 (smile) 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> (smile)

[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 (smile)

[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 (smile) 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 (sad)

[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 (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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> (smile)

[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 (smile)

[15:52:26 CDT(-0500)] <athena> ooh ooh ooh

[15:52:27 CDT(-0500)] <athena> it works

[15:52:28 CDT(-0500)] <athena> thanks (smile)

[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!? (smile)

[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 (smile)

[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> (smile)

[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 (wink)

[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 (smile)

[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 (tongue)

[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 (smile)

[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 . . . (tongue)

[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 (smile)

[16:05:40 CDT(-0500)] <colinclark> (smile)

[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> (smile)

[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 (tongue)

[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 (smile)

[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)]