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