fluid-work IRC Logs-2013-10-08

Owned by Fluid IRC Log Bot
Last updated: Oct 08, 2013
26 min read

[07:48:11 CDT(-0500)] <Justin_o> cindyli: i filed a jira for the text size and line spacing issue http://issues.fluidproject.org/browse/FLUID-5171

[07:51:52 CDT(-0500)] <Justin_o> cindyli: how is the rest of FLUID-5161 coming?

[08:17:54 CDT(-0500)] <Justin_o> cindyli: i'm poking around at FLUID-5171 and it seems that the panel opens after the calculations are done. Meaning that the event is fired before it's open.. like an on event instead of an after.. perhaps it has something to do with the animation, but i'm not sure

[08:18:34 CDT(-0500)] <cindyli> good finding, Justin_o

[08:24:24 CDT(-0500)] <Justin_o> cindyli: but i don't know how to get around it

[08:25:39 CDT(-0500)] <cindyli> lol

[08:28:47 CDT(-0500)] <cindyli> we'll figure out. i'm finishing off 5161 soon, after that will take a look on 5171

[08:30:44 CDT(-0500)] <Justin_o> cindyli: cool thanks.. i'm delving more and am wondering now if it is an issue with expanders

[08:40:48 CDT(-0500)] <Justin_o> cindyli: fixed the textSize, now looking at linespacing

[08:40:56 CDT(-0500)] <cindyli> Justin_o: the pull request for 5161 is ready for another round of review

[08:41:11 CDT(-0500)] <cindyli> yay, congrats, Justin_o

[08:41:16 CDT(-0500)] <Justin_o> cindyli: thanks.. i'll take a look at that soon

[08:41:30 CDT(-0500)] <cindyli> sure, how did you fix the text size

[08:46:26 CDT(-0500)] <Justin_o> cindyli: the generateTextSizeInEm invoker needed to be dynamic.. it looks like a similar approach should work for linespacing, but it doesn't seem to be (sad)

[08:46:55 CDT(-0500)] <cindyli> interesting

[08:56:31 CDT(-0500)] <Justin_o> cindyli: okay.. so i think FLUID-5171 is fixed.. perhaps we should just fold the change into FLUID-5161

[08:56:33 CDT(-0500)] <Justin_o> what do you think?

[08:56:59 CDT(-0500)] <cindyli> sounds reasonable, Justin_o

[08:57:33 CDT(-0500)] <Justin_o> cindyli: i have closed http://issues.fluidproject.org/browse/FLUID-5123

[08:58:06 CDT(-0500)] <Justin_o> maybe we can re-examine if that actually can be removed and add it to the FLUID-5161 pull request as well

[08:58:28 CDT(-0500)] <cindyli> ok

[08:59:02 CDT(-0500)] <Justin_o> cindyli: did you want me to merge the FLUID-5171 changes into the FLUID-5161 branch?

[08:59:18 CDT(-0500)] <cindyli> go ahead, Justin_o

[08:59:52 CDT(-0500)] <Justin_o> cindyli: okay.. also have you merged in master

[09:00:06 CDT(-0500)] <cindyli> yes, Justin_o

[09:02:50 CDT(-0500)] <Justin_o> cindyli: by the way, it looks like you lost the UIO icon from the demo portal

[09:03:19 CDT(-0500)] <cindyli> ah what?

[09:03:49 CDT(-0500)] <Justin_o> i guess i'll have to show you later

[09:03:52 CDT(-0500)] <Justin_o> cindyli: ^

[09:04:47 CDT(-0500)] <cindyli> which page, Justin_o not src/demos/index.html

[09:04:57 CDT(-0500)] <cindyli> uio icon still on that page

[09:05:19 CDT(-0500)] <Justin_o> cindyli: yes

[09:05:28 CDT(-0500)] <Justin_o> cindyli: by the way, i fixed FLUID-5171 in my FLUID-5161 branch

[09:05:56 CDT(-0500)] <cindyli> ok, i will merge it in

[09:07:54 CDT(-0500)] <Justin_o> cindyli: thanks

[09:13:21 CDT(-0500)] <Justin_o> cindyli: i'm looking into FLUID-5123 at the moment..

[09:13:34 CDT(-0500)] <Justin_o> i think things still work, but could you help me with a bit of testing

[09:13:50 CDT(-0500)] <cindyli> sure, Justin_o

[11:31:59 CDT(-0500)] <Justin_o> cindyli: i've added my fix for FLUID-5123 to my FLUID-5161 branch.. would you mind merging that in?

[11:33:59 CDT(-0500)] <cindyli> merged and pushed up, Justin_o

[11:34:50 CDT(-0500)] <Justin_o> cindyli: thanks.. did the changes look okay?

[11:35:01 CDT(-0500)] <cindyli> they look ok, Justin_o

[11:35:21 CDT(-0500)] <Justin_o> michelled: did you want to have another infusion 1.5 release chat at a community meeting in the coming weeks?

[11:35:36 CDT(-0500)] <Justin_o> cindyli: thanks

[11:35:43 CDT(-0500)] <cindyli> Justin_o: in terms of the IE8 failure, seems caused by framework code changes, some fluid IoC tests fail with the same error

[11:36:19 CDT(-0500)] <Justin_o> cindyli: okay.. is there a jira for that?

[11:37:51 CDT(-0500)] <cindyli> i don't find any, Justin_o, i will create one

[11:39:18 CDT(-0500)] <Justin_o> cindyli: thanks.. can you make that a blocker for 1.5 as well

[11:40:01 CDT(-0500)] <cindyli> ok, Justin_o

[12:00:06 CDT(-0500)] <Justin_o> yzen, michelled: would one of you like to review my pull request for the grunt-modulefiles plugin https://github.com/fluid-project/grunt-modulefiles/pull/2

[12:02:49 CDT(-0500)] <Justin_o> fluid-everyone: does anyone have any topics they'd like to cover in an upcoming community meeting?

[12:07:32 CDT(-0500)] <michelled> Justin_o: I think we should make sure we cover as many of the 1.5 issues as we can in the community meetings

[12:07:52 CDT(-0500)] <Justin_o> michelled: okay.. i'll book another meeting for that..

[12:09:17 CDT(-0500)] <Justin_o> here's the community meeting schedule so far http://wiki.fluidproject.org/display/fluid/Community+workshops

[12:13:38 CDT(-0500)] <Justin_o> cindyli, anastasiac: the demo portal has a link to this wiki page http://wiki.fluidproject.org/display/fluid/User+Interface+Options

[12:14:04 CDT(-0500)] <Justin_o> when should we change this? should the url be changed as part of the FLUID-5161?

[12:14:38 CDT(-0500)] <anastasiac> Justin_o, oh my… probably all of the demos have bad links. We don't really have proper 'landing pages' for any of the components any more

[12:14:48 CDT(-0500)] <anastasiac> Justin_o, what would you change it to?

[12:15:23 CDT(-0500)] <Justin_o> anastasiac: i don't know.. maybe something call Preference Framework, but not sure

[12:15:57 CDT(-0500)] <anastasiac> yeah, for the UIO demo, a link to the main Prefs Framework page might work

[12:16:49 CDT(-0500)] <Justin_o> anastasiac: you're right though it seems like a lot if not all of the links in the demo portal are broken.. maybe we can just fix them all at the same time.. and defer the UI Options one till then

[12:16:56 CDT(-0500)] <Justin_o> cindyli, anastasiac: what do you think about that

[12:17:11 CDT(-0500)] <Justin_o> or we could make this one point at preferences framework right away, even if the page doesn't yet exist

[12:17:13 CDT(-0500)] <anastasiac> we definitely need to fix them all at some point

[12:17:27 CDT(-0500)] <anastasiac> we do have a prefs framework page, you know

[12:17:33 CDT(-0500)] <anastasiac> http://wiki.fluidproject.org/display/docs/Preferences+Framework

[12:17:40 CDT(-0500)] <Justin_o> a cool

[12:17:43 CDT(-0500)] <anastasiac> (smile)

[12:17:53 CDT(-0500)] <Justin_o> i'll file a jira about fixing the rest

[12:22:01 CDT(-0500)] <colinclark> yzen: Have you written any code with Web Sockets in Node.js before for other projects?

[12:22:09 CDT(-0500)] <yzen> no

[12:23:19 CDT(-0500)] <colinclark> I suspect it's looming for the GPII (smile)

[12:23:22 CDT(-0500)] <colinclark> should be fun work

[12:27:04 CDT(-0500)] <Bosmon2> What will we do with these SOCKKETS?

[12:37:47 CDT(-0500)] <Justin_o> cindyli: merge FLUID-5161

[12:38:16 CDT(-0500)] <cindyli> yay! thanks, Justin_o

[12:38:38 CDT(-0500)] <colinclark> Bosmon2: Communicate between the PMT and the Flow Manager, most likely

[12:38:48 CDT(-0500)] <Justin_o> fluid-everyone: FLUID-5161 was merged... this involved a rather large renaming and moving of UI Options to be the preferences framework.

[12:38:59 CDT(-0500)] <anastasiac> yay!

[12:39:02 CDT(-0500)] <michelled> (smile)

[12:39:07 CDT(-0500)] <colinclark> It looks like we're going to need the ability to "provision a USB stick" via the PMT, which is a web app

[12:39:21 CDT(-0500)] <colinclark> Justin_o: Merged into master?

[12:39:59 CDT(-0500)] <Justin_o> colinclark: yes.. it's in master

[12:40:03 CDT(-0500)] <colinclark> wow!@

[12:40:31 CDT(-0500)] <colinclark> So, can I ask a few questions about it, just so I'm clear?

[12:40:38 CDT(-0500)] <Justin_o> colinclark: sure

[12:40:47 CDT(-0500)] <colinclark> I'm thinking we'll want to start explaining to people why they shouldn't use the term "UIO" any more for many things

[12:40:55 CDT(-0500)] <colinclark> and I want to make sure I've got it right

[12:41:11 CDT(-0500)] <colinclark> So a casual user of the "UIO component" still uses the same names, is that correct?

[12:41:40 CDT(-0500)] <colinclark> i.e. they call some function like fluid.fatPanelUIOptions or whatever it was previously?

[12:44:04 CDT(-0500)] <Justin_o> colinclark: well.... the change was a bit more drastic.. there is no UI Options component at all anymore

[12:44:19 CDT(-0500)] <Justin_o> colinclark: so the expectation is that most people will use the builder

[12:44:25 CDT(-0500)] <colinclark> oh

[12:44:29 CDT(-0500)] <colinclark> hmm

[12:44:45 CDT(-0500)] <colinclark> I think we should chat through this for a bit, from the perspective of user experience

[12:44:52 CDT(-0500)] <Bosmon2> Justin_o - I was a little concerned about that possible development yesterday, and I'm sorry I didn't manage to start more of a conversation about it

[12:44:54 CDT(-0500)] <colinclark> And I think I can define a few different "types" of users

[12:45:04 CDT(-0500)] <colinclark> I'll use exemplars of these types--real people

[12:45:27 CDT(-0500)] <colinclark> 1. Casual users-"I want to put UIO at the top of my web page"-Geoffrey Shea comes to mind as an example

[12:45:39 CDT(-0500)] <Justin_o> colinclark, Bosmon: sure.. here's an example of the demo though so you can see how simple it is. https://github.com/fluid-project/infusion/blob/master/src/demos/prefsEditor/js/prefsEditorDemo.js

[12:45:43 CDT(-0500)] <colinclark> 2. Power users of the component--OER Commons is probably the best example

[12:45:59 CDT(-0500)] <colinclark> 3. Developers of preferences editor tools--Chris and Alex, in particular

[12:46:17 CDT(-0500)] <colinclark> anastasiac: I think I'll need your help thinking through this, too

[12:46:33 CDT(-0500)] <Bosmon> Justin_o - it's quite simple, but it is still a little bizarre (smile)

[12:46:34 CDT(-0500)] <anastasiac> yep, I'm following. I was in on the discussion about it

[12:46:42 CDT(-0500)] <Bosmon> I think it might still be helpful to have an actual remnant of a component

[12:46:50 CDT(-0500)] <colinclark> So, user #1 comes along and says "Oh, look. It's Infusion 1.5 will a cool new version of UIO, and it includes stuff like text to speech. I want that!"

[12:46:53 CDT(-0500)] <Justin_o> Bosmon: how would that look though?

[12:47:03 CDT(-0500)] <Bosmon> Justin_o - it would look exactly as it did before (smile)

[12:47:07 CDT(-0500)] <Bosmon> Before you abolished the UIO component : P

[12:47:13 CDT(-0500)] <Justin_o> colinclark: the starter schema will still give you the starting point

[12:47:17 CDT(-0500)] <Bosmon> i.e. from the user's perspective

[12:47:26 CDT(-0500)] <Bosmon> They would actually believe there was a component

[12:47:30 CDT(-0500)] <colinclark> Justin_o: What will anastasiac end up having to explain to Geoffrey Shea?

[12:47:43 CDT(-0500)] <Bosmon> Similarly to our "wrapper functions" that we developed for different configurations of the "Reorderer"

[12:48:06 CDT(-0500)] <Bosmon> My suspicion is that you may have gone just one step too far with this demo....

[12:48:08 CDT(-0500)] <Justin_o> colinclark: i should probably let anastasiac answer that, but i would assume she say something like do what's in the demo

[12:48:19 CDT(-0500)] <anastasiac> (smile)

[12:48:42 CDT(-0500)] <colinclark> ok

[12:48:47 CDT(-0500)] <colinclark> let's walk through it, if it's okay

[12:48:53 CDT(-0500)] <anastasiac> colinclark, Bosmon, we did go back and forth with this discussion a lot, and we considered arguments on both sides of the issue

[12:49:12 CDT(-0500)] <anastasiac> mostly, we tried to envision how an actual uiOptions component would be constructed

[12:49:19 CDT(-0500)] <anastasiac> would it be an actual component, or just a function?

[12:49:27 CDT(-0500)] <Justin_o> Bosmon: we did talk through leaving the component in place... the issue was usually around how would you modify it afterwards.. and what would it be based off of .. would it be a wrapper around the builder and etc.

[12:50:06 CDT(-0500)] <anastasiac> michelled was also in on the discussion, so hopefully she's following this conversation and can contribute

[12:50:08 CDT(-0500)] <colinclark> If it's okay, I'd like to go over the specifics

[12:50:08 CDT(-0500)] <Bosmon> Justin_o - I think you can't help but admit that the code in the "prefsEditorDemo", whilst it may be quite short, is still significantly arcane

[12:50:14 CDT(-0500)] <colinclark> and then look at the motivations

[12:50:32 CDT(-0500)] <colinclark> So the key question is, for user #1, what do they need to do when they upgrade?

[12:50:46 CDT(-0500)] <colinclark> Based on the things we explained to them for the current version of UIO

[12:51:59 CDT(-0500)] <michelled> one of the things we talked about in terms of upgrading users is that we've significantly change the API for UIO from 1.4. So users wanting to use 1.5 will need to follow some directions on how to change their code.

[12:52:05 CDT(-0500)] <anastasiac> to upgrade (say, for Geoffrey Shea to upgrade), he'd need to modify his invocation of the panel to look like the demo. The part he'd need to customize for his integration would be the paths

[12:52:35 CDT(-0500)] <anastasiac> and yes, we'll need upgrade docs!

[12:52:45 CDT(-0500)] <colinclark> Ok

[12:52:49 CDT(-0500)] <colinclark> so two changes?

[12:53:21 CDT(-0500)] <anastasiac> that's what I'd say

[12:54:17 CDT(-0500)] <anastasiac> to write the docs, I'd actually go through the exercise by upgrading something simple, like the SNOW videos site or something

[12:54:27 CDT(-0500)] <colinclark> anastasiac: Can you point me to the current docs, so I can see concrete examples

[12:54:35 CDT(-0500)] <colinclark> of what we've instructed people to do today?

[12:55:10 CDT(-0500)] <anastasiac> colinclark, do you mean a general UIO tutorial? or upgrade to 1.4 instructions?

[12:55:17 CDT(-0500)] <colinclark> the UIO tutorial, yes

[12:55:29 CDT(-0500)] <colinclark> I don't know if I'm just dumb, but I can't find it in our doc site

[12:55:49 CDT(-0500)] <anastasiac> you're not dumb, the links are just a bit out of whack still

[12:55:53 CDT(-0500)] <Justin_o> colinclark, Bosmon: the other issue was did we want to present to the user just what used to be UIO or the entire stack that you'd get from running the builder.. that being the enhancer, the store, and the editor

[12:55:56 CDT(-0500)] <colinclark> the How to Guides > Infusion Components > User Interface Options link doesn't seem to go anywhere

[12:56:29 CDT(-0500)] <anastasiac> http://wiki.fluidproject.org/display/docs/Tutorial+-+Fat+Panel+UI+Options

[12:56:44 CDT(-0500)] <Bosmon> Justin_o - that thinking doesn't agree with the thinking we came up with in other similar situations

[12:56:47 CDT(-0500)] <anastasiac> yeah, that's what I mean about out-of-whack links. It's a known issue (smile)

[12:56:57 CDT(-0500)] <Bosmon> Which recognised that we have, as colinclark has been observing, several distinct communities of users

[12:56:59 CDT(-0500)] <Justin_o> Bosmon: don't know if i follow

[12:57:04 CDT(-0500)] <Bosmon> And we can't expect to have a "one thinking fits all" policy

[12:57:16 CDT(-0500)] <colinclark> Okay, so I want to be very thorough here

[12:57:16 CDT(-0500)] <Bosmon> Justin_o - I'm referring to the other "umbrella components" we have created in the past

[12:57:18 CDT(-0500)] <colinclark> So for user #1

[12:57:20 CDT(-0500)] <Bosmon> Such as the Reorderer

[12:57:46 CDT(-0500)] <colinclark> we're saying:

[12:58:00 CDT(-0500)] <colinclark> 1. based on this UIO Options tutorial, all of Section 2 will change--they'll have to link to different file names

[12:58:02 CDT(-0500)] <colinclark> is that correct?

[12:58:24 CDT(-0500)] <colinclark> Step 2, that is

[12:58:33 CDT(-0500)] <anastasiac> colinclark, yes: If they're not using MyInfusion, they'll need to know the new filenames

[12:58:38 CDT(-0500)] <colinclark> ok

[12:58:45 CDT(-0500)] <colinclark> Then Step 4 changes, too

[12:59:02 CDT(-0500)] <colinclark> Justin_o: point me again to what a user would do instead of what's described in Step 4?

[12:59:16 CDT(-0500)] <anastasiac> right; they'd do what's in the demo, instead

[12:59:37 CDT(-0500)] <anastasiac> i.e. a) create the builder, then b) invoke the "assembledPrefsEditorGrade" grade of the builder

[12:59:52 CDT(-0500)] <colinclark> Now, does a user ever have to modify their CSS or their markup with any of our "names?"

[12:59:54 CDT(-0500)] <anastasiac> rather than a) add the page enhancer, then b) invoke the fat panel

[13:00:09 CDT(-0500)] <colinclark> If something doesn't quite work, would they ever put a uio-scoped class in their markup anywhere?

[13:00:18 CDT(-0500)] <colinclark> or in their stylesheets?

[13:01:15 CDT(-0500)] <anastasiac> ah, colinclark, good questions. I'm not even thinking about CSS yet, but the default selector classes have changed for ".flc-uio-" to ".flc-prefsEditor-"

[13:01:21 CDT(-0500)] <Justin_o> anastasiac, colinclark: they would also have had to instantiate the settingstore too. that was another change since 1.4.

[13:01:29 CDT(-0500)] <Justin_o> but that is taken care of by the builder

[13:01:37 CDT(-0500)] <colinclark> The CSS names might well be a critical question here

[13:01:49 CDT(-0500)] <colinclark> since it's one thing to get an error in the JavaScript console because a name has changed

[13:01:56 CDT(-0500)] <colinclark> it's another altogether to have stuff just not work

[13:02:01 CDT(-0500)] <colinclark> or "look weird"

[13:02:07 CDT(-0500)] <anastasiac> looks the the css class names have similarly changed

[13:02:30 CDT(-0500)] <anastasiac> so the built-in styles would work, but if a custom stylesheet is using one of our classnames, they'll have to modify their stylesheet

[13:02:48 CDT(-0500)] <colinclark> How often do users have to use our classnames in their stylesheets?

[13:03:03 CDT(-0500)] <anastasiac> hm

[13:03:17 CDT(-0500)] <colinclark> When you guys were talking this through, did you guys look at the CSS for the IDI site, say, or Geoffrey's site? Or OER Commons?

[13:03:36 CDT(-0500)] <anastasiac> I did not

[13:04:31 CDT(-0500)] <Justin_o> colinclark: i think the built in styles would have to have changed either way though.. they are more analogus to operations by the preference framework than to an instance of UIO. At least in the way they are used currently.. which is something we hope to change by dropping FSS

[13:05:04 CDT(-0500)] <anastasiac> quick check of the durham art gallery site: no custom styles scoped to our class names

[13:05:07 CDT(-0500)] <colinclark> Justin_o: I'm not sure I understand

[13:05:27 CDT(-0500)] <Justin_o> colinclark: the generated css files

[13:05:54 CDT(-0500)] <colinclark> I'm not too worried about class names that we operate on

[13:06:07 CDT(-0500)] <colinclark> I'm worried about cases where people have used our classnames in "their stuff"

[13:06:23 CDT(-0500)] <colinclark> and then just see inexplicable weirdness without error messages

[13:06:37 CDT(-0500)] <Justin_o> i guess i'm not following then.. is that to say we should still have a UIO component or just that we need docs?

[13:06:39 CDT(-0500)] <anastasiac> per commons harder to check because they blend all css into just a few files, so can't tell source with just a quick check

[13:06:47 CDT(-0500)] <anastasiac> s/per/oer

[13:07:37 CDT(-0500)] <colinclark> I'm still confused, Justin_o

[13:12:22 CDT(-0500)] <colinclark> Okay, so for a user in group #2, who has perhaps done some heavier configuration or tweaking of UIO in their application, do we expect that they'll have to do much more than what user #1 does?

[13:14:11 CDT(-0500)] <anastasiac> it depends on the tweaking they've done

[13:15:03 CDT(-0500)] <anastasiac> our thoughts on what a "uio component" would do were that it would offer the "starter set" of panels, period, and if the integrator wanted other panels or fewer panels, we would tell them not to use the component, but to use the builder directly

[13:15:21 CDT(-0500)] <colinclark> yes

[13:15:24 CDT(-0500)] <anastasiac> so if that's the nature of their tweaking, then they'll need to use the builder, and learn about schemas, etc.

[13:15:41 CDT(-0500)] <colinclark> In other words, that the evolution of UIO over the past year has probably already changed or relocated just about anything that a "power user" would have configured

[13:15:47 CDT(-0500)] <colinclark> Justin_o: Is that correct? ^

[13:16:31 CDT(-0500)] <Justin_o> colinclark: yes, there were extensive changes.. the can still use grades directly though if they don't want to use the builder.. something like what is currently being done in the Exploration Tool

[13:16:43 CDT(-0500)] <colinclark> Ok

[13:16:46 CDT(-0500)] <colinclark> So our third group

[13:16:55 CDT(-0500)] <colinclark> Chris and Alex, for example

[13:17:39 CDT(-0500)] <colinclark> they're basically going to wake up one morning and be told "Everything works the same as it did yesterday, but you need to change every reference to 'uio'," is that correct?

[13:18:48 CDT(-0500)] <Justin_o> yes.. pretty much.. although hopefully that won't be too much..

[13:19:31 CDT(-0500)] <Justin_o> I think they are already using the schemas

[13:20:00 CDT(-0500)] <colinclark> Okay, so we still need to get clarity on whether we've opened up a can of worms with the CSS renaming

[13:20:14 CDT(-0500)] <colinclark> The last thing, then, is what you were discussing first, but I didn't fully follow

[13:20:36 CDT(-0500)] <colinclark> So what's the rationale for not providing a name and direct way to construct "a UI Options component?"

[13:21:23 CDT(-0500)] <colinclark> I thought one of the things we agreed on at the last community meeting was that there was still going to be a thing that, tangibly, was "that UIO thing at the top of a web page," even if technically it's just the collection of starter grades and panels

[13:21:35 CDT(-0500)] <anastasiac> well, Justin_o and michelled can chime with their recollections of the discussion, but here are some of mine:

[13:21:49 CDT(-0500)] <anastasiac> we considered just how such a "component" would be constructed

[13:22:05 CDT(-0500)] <anastasiac> would it actually be a full-fledged component? or just a wrapper function?

[13:22:59 CDT(-0500)] <anastasiac> if it's just a wrapper function, then it would likely break some of the contract we have for components (e.g. you wouldn't be able to call "fluid.defaults() to find out the defaults, etc)

[13:23:11 CDT(-0500)] <anastasiac> if it was a real component, how would we build it?

[13:23:32 CDT(-0500)] <anastasiac> right now, the builder provides a single function that invokes the store, enhancer and fat panel

[13:24:11 CDT(-0500)] <colinclark> We seem to have a concept of a "GPII Discovery Tool" component, for example: https://github.com/GPII/prefsEditors/blob/master/demos/discoveryTool/demo.js#L46

[13:24:14 CDT(-0500)] <anastasiac> basically, we ended up feeling that requiring the integrator to use the builder was not much of a burden

[13:24:15 CDT(-0500)] <colinclark> Why is this any different?

[13:25:12 CDT(-0500)] <Justin_o> anastasiac: it think you covered the main points..

[13:26:10 CDT(-0500)] <colinclark> Okay, so we have the concept of a Discovery (Exploration) Tool component

[13:26:23 CDT(-0500)] <colinclark> I'm assuming we also have components that represent the PCP and PMT and so on

[13:26:33 CDT(-0500)] <colinclark> I still don't quite understand how this guy, our old friend here, is any different

[13:26:42 CDT(-0500)] <Justin_o> colinclark: i think we need to address those issues that anastasiac mentioned to come up with a uio component that we distribute

[13:27:16 CDT(-0500)] <colinclark> What options were discussed for potentially addressing those issues?

[13:27:44 CDT(-0500)] <Justin_o> colinclark: maybe it would be helpful to start at what we expect to get from fluid.uiOptions

[13:27:59 CDT(-0500)] <colinclark> yes

[13:28:08 CDT(-0500)] <anastasiac> colinclark, (not justification, just data points for consideration): the discovery tool (as currently implemented) doesn't use the builder, but rather the fatPanel grade directly

[13:28:12 CDT(-0500)] <colinclark> Justin_o: What do you think user #1 would expect to get from it?

[13:28:23 CDT(-0500)] <anastasiac> afaik, it doesn't instantiate the store (but I might be misunderstanding)

[13:29:47 CDT(-0500)] <colinclark> That suggests to me that we haven't thought about the user experience of the Preferences Framework for external "user #1" type users

[13:29:51 CDT(-0500)] <colinclark> which is fair enough

[13:29:59 CDT(-0500)] <colinclark> we've had enough work to do just making it work (smile)

[13:30:40 CDT(-0500)] <Justin_o> colinclark: well we probably would use the builder for the Exploration Tool except that we can't because of the model transformations that it has to do and we can't support yet

[13:31:10 CDT(-0500)] <colinclark> I just want to make sure we have a plan, before we ship 1.5, for providing users with a recognizable "affordance" for constructing these types of components

[13:31:11 CDT(-0500)] <Justin_o> colinclark: if i'm user #1 i'd probably expect everything.. store, enhancer, editor

[13:31:34 CDT(-0500)] <Justin_o> colinclark: i'd expect the thing to work

[13:31:35 CDT(-0500)] <colinclark> the builder seems like a fairly low-level construct, from the perspective of user #1, no?

[13:32:05 CDT(-0500)] <anastasiac> (musing) our current sites using UIO (e.g. IDI, SNOW videos, etc) are actually still using 1.4, so we could consider upgrading them, as an exercise in learning about user #1's experience…

[13:32:21 CDT(-0500)] <colinclark> wouldn't it make sense for them to be able to create "a UIO component" or "a Exploration Tool" component, and get back a thing which has those three elements in it?

[13:32:37 CDT(-0500)] <colinclark> anastasiac: That would be a very good exercise to do, yes!

[13:32:39 CDT(-0500)] <Justin_o> colinclark: yes.. that's what i meant

[13:32:46 CDT(-0500)] <colinclark> ah, cool, Justin_o

[13:32:53 CDT(-0500)] <colinclark> so what barriers are there to doing that?

[13:32:57 CDT(-0500)] <colinclark> just time and effort?

[13:33:02 CDT(-0500)] <colinclark> or are there technical constraints?

[13:33:06 CDT(-0500)] <colinclark> or clarity constraints?

[13:33:08 CDT(-0500)] <colinclark> or something else?

[13:33:42 CDT(-0500)] <anastasiac> mostly time constraints, and also "moving target" constraints (smile)

[13:33:57 CDT(-0500)] <colinclark> ok

[13:34:12 CDT(-0500)] <anastasiac> but these kinds of integrations typically turn out to be useful excercises

[13:34:29 CDT(-0500)] <colinclark> Justin_o: Answers to those questions from the perspective of providing some kind of an affordance for user #1?

[13:34:32 CDT(-0500)] <anastasiac> would we a) upgrade to the current builder proposal? or b) try creating a component and upgrading to that?

[13:36:29 CDT(-0500)] <Justin_o> colinclark: so we did talk about that.. basically as it stands the only thing that has the whole stack in it, is what is produced by the builder... when using grades the three parts are initialized separates.. so we had two options basically 1) something that looks like what the builder uses

[13:36:29 CDT(-0500)] <Justin_o> https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Builder.js#L74-L133 or 2) assigning the output of the builder

[13:37:40 CDT(-0500)] <Justin_o> colinclark: the issue with #2 is how to assign that component to fluid.uiOptions while preserving all expected component features.. like being able to call fluid.defaults("fluid.uiOptions") to get it's defaults

[13:38:09 CDT(-0500)] <colinclark> Here's an idea that might be enlightening for me (and probably boring old news for all of you)...

[13:38:21 CDT(-0500)] <colinclark> Can someone try describing to me in plain English, rather than programmer terminology, what I get back when I call fluid.prefs.builder()?

[13:39:05 CDT(-0500)] <Justin_o> anastasiac: sounds like a job for you (smile)

[13:40:13 CDT(-0500)] <anastasiac> colinclark: you would get an object that defines two grades that you could instantiate: the "uio" grade and the "uie" grade (using the old terminology; don't know what the new is)

[13:40:27 CDT(-0500)] <anastasiac> if you create the uio thingy, you'll get the store, the enhancer and the fat panel

[13:40:37 CDT(-0500)] <anastasiac> if you create the uie, you'll get the store and the enhancer

[13:40:50 CDT(-0500)] <anastasiac> the two are also available as functions, not just grades

[13:41:17 CDT(-0500)] <anastasiac> the object will also have a heck of a lot of other stuff in it, but you won't care (smile)

[13:41:30 CDT(-0500)] <colinclark> ok

[13:41:35 CDT(-0500)] <colinclark> so that's fascinating actually

[13:41:42 CDT(-0500)] <colinclark> let me just open up this tutorial again

[13:41:53 CDT(-0500)] <colinclark> "First, we need to add the UI Enhancer component to the page."

[13:42:05 CDT(-0500)] <colinclark> " Finally, we instantiate the UI Options component itself. We do this by calling the creator function…"

[13:42:32 CDT(-0500)] <anastasiac> if it helps, we have draft docs for the Builder: http://wiki.fluidproject.org/display/docs/Builder

[13:42:32 CDT(-0500)] <colinclark> So does that mean that the output of the Builder corresponds more or less directly to these two actions in the tutorial?

[13:42:51 CDT(-0500)] <anastasiac> yes, with the added bonus of also instantiating the store

[13:43:03 CDT(-0500)] <colinclark> sweet

[13:43:11 CDT(-0500)] <colinclark> Okay, so another boring question

[13:43:53 CDT(-0500)] <colinclark> Would we have been happier, in the old days, if we could have written the tutorial this way:

[13:44:25 CDT(-0500)] <colinclark> "First, we add the <all in one component that represents 'that UI Options component on your page'> to the page."

[13:44:45 CDT(-0500)] <colinclark> And then, to quote the dorky old Apple commercial

[13:44:58 CDT(-0500)] <colinclark> "Step two? There is no step two!"

[13:45:05 CDT(-0500)] <colinclark> I might be over simplifying

[13:45:14 CDT(-0500)] <colinclark> I'm just trying to understand what we've got vs. what we had

[13:45:20 CDT(-0500)] <colinclark> it sounds like an improvement to me

[13:45:26 CDT(-0500)] <anastasiac> yes, we would have been happier (smile)

[13:45:41 CDT(-0500)] <colinclark> Cool

[13:45:44 CDT(-0500)] <anastasiac> I was arguing for that option during our discussion: "I want one-stop shopping"

[13:45:48 CDT(-0500)] <colinclark> cool

[13:45:52 CDT(-0500)] <colinclark> so we rule, is what you're saying

[13:45:57 CDT(-0500)] <colinclark> Justin_o: Guess what?

[13:45:58 CDT(-0500)] <colinclark> you rule!@

[13:46:02 CDT(-0500)] <colinclark> cindyli: Guess what?

[13:46:03 CDT(-0500)] <colinclark> you rule!

[13:46:13 CDT(-0500)] <colinclark> anastasiac, michelled, Bosmon, everyone I'm forgetting, you rule!

[13:46:48 CDT(-0500)] <anastasiac> the builder is pretty slick

[13:47:13 CDT(-0500)] <colinclark> So, what stops us from defining a component with a real name and grade, for the thing I've been awkwardly calling "<all in one component that represents 'that UI Options component on your page'>"

[13:47:16 CDT(-0500)] <colinclark> ?

[13:47:27 CDT(-0500)] <colinclark> I guess this may end up being a Bosmon question

[13:47:40 CDT(-0500)] <anastasiac> Justin_o, do you want to try to answer that one?

[13:47:48 CDT(-0500)] <colinclark> He has seen, from my recent artwork, that I'm still largely a stone age Infusion programmer

[13:47:57 CDT(-0500)] <colinclark> with my stone arrowhead init functions

[13:49:33 CDT(-0500)] <Justin_o> anastasiac: okay.. sure.. so i actually put that up here a while back, but i'll summarize again.. 1) we use grades and do the configuration in the component, and would look something like the combination of these two grades used in the builder https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Builder.js#L74-L133 2) we use the

[13:49:34 CDT(-0500)] <Justin_o> output of the builder however we probably couldn't map it to fluid.uiOptions this way and preserver all of the contract that a typical infusion component would have

[13:49:36 CDT(-0500)] <Bosmon> Better stone arrowhead functions than "arrow functions" : P

[13:50:14 CDT(-0500)] <Justin_o> colinclark: so the issue with 1) is mostly about duplication

[13:50:44 CDT(-0500)] <colinclark> sorry I'm only now finally catching up to you, Justin_o

[13:50:49 CDT(-0500)] <colinclark> and for making you repeat yourself

[13:52:01 CDT(-0500)] <Justin_o> colinclark: and it was seeming that the work to produce to make the component as well as maintaining seemed to not be worth it given the perceived (although debatable) ease of just using the builder directly as it is in the demo

[13:52:14 CDT(-0500)] <Justin_o> colinclark: although the demo example could be too simplistic i suppose

[13:53:18 CDT(-0500)] <colinclark> I guess some of it is maybe philosophical

[13:53:30 CDT(-0500)] <colinclark> but most of it, I think, is about user-friendliness

[13:53:54 CDT(-0500)] <colinclark> anastasiac's responses to the "plain English" questions suggest a perspective we want to try to accommodate

[13:53:57 CDT(-0500)] <colinclark> I think

[13:54:05 CDT(-0500)] <colinclark> I mean, we always have to measure the cost of these things

[13:54:47 CDT(-0500)] <colinclark> but I really can imagine, at one level of usage, that I as a developer, want to get my hands on a thing that I can reliable say IS a UI Options component, or is an Exploration Tool Component, or is a PMT

[13:54:50 CDT(-0500)] <colinclark> and so on

[13:55:08 CDT(-0500)] <colinclark> perhaps I'm putting too fine a point on it

[13:55:57 CDT(-0500)] <colinclark> but I think anastasiac was saying that 1) she likes that we can teach a user how to do one thing instead of two or three, which we've already accomplished and 2) she'll have to do extra work to explain what a builder is and what it produces

[13:56:12 CDT(-0500)] <colinclark> Bosmon: Any thoughts, technically, on what the best way is to accomplish this?

[13:56:22 CDT(-0500)] <colinclark> Do either of Justin_o

[13:56:30 CDT(-0500)] <colinclark> 's ideas resonate with you?

[13:56:51 CDT(-0500)] <colinclark> michelled: Did you have any look combing through some UIO-using source code for signs of classname trouble?

[13:56:58 CDT(-0500)] <colinclark> "any luck" that is

[13:57:37 CDT(-0500)] <Bosmon> colinclark - could you expand on your question slightly - or, perhaps narrow it?

[13:57:52 CDT(-0500)] <Bosmon> "I want to get my hands on a thing which I can reliably say IS a UI Options component"

[13:58:01 CDT(-0500)] <Bosmon> Which part of this problem would we like to assist with?

[13:58:27 CDT(-0500)] <colinclark> I think Justin's explanation deals with the technical problems

[13:59:24 CDT(-0500)] <colinclark> the user experience issue is largely one of providing a user with a single means for instantiating what they see as the UIO component, and ensuring it has a recognizable grade associated with it so they could, at some point, issue IoC configuration against it

[13:59:31 CDT(-0500)] <colinclark> I think, anyway (smile)

[14:00:11 CDT(-0500)] <colinclark> I think that latter point is what Justin_o means when he says "we probably couldn't map it to fluid.uiOptions this way and preserve all of the contract that a typical infusion component would have"

[14:00:21 CDT(-0500)] <Bosmon> Yes

[14:00:58 CDT(-0500)] <Bosmon> I think we have to abandon the idea of a "single means"

[14:01:07 CDT(-0500)] <Bosmon> As I think parts of our discussion have suggested

[14:01:07 CDT(-0500)] <colinclark> hmm

[14:01:14 CDT(-0500)] <colinclark> what does that mean, specifically?

[14:01:30 CDT(-0500)] <Bosmon> It means that the name "fluid.uiOptions" couldn't expect to designate different things to different people

[14:01:43 CDT(-0500)] <colinclark> Yes, that's fine

[14:02:07 CDT(-0500)] <colinclark> When I said "single means," I was referring to there being a component that represented the whole of "that UIO component up there" to user #1s

[14:02:11 CDT(-0500)] <Bosmon> Yes

[14:02:22 CDT(-0500)] <Bosmon> We should do this, and it would not be a problem

[14:02:39 CDT(-0500)] <Bosmon> Although I can't remember whether the "builder" can be directed to fabricate a component with a particular name, but if it can't, it should (smile)

[14:02:46 CDT(-0500)] <colinclark> I was just going to suggest...

[14:03:05 CDT(-0500)] <colinclark> the ability for a "user" of the builder to be able to contribute grades to the thing that gets produced

[14:03:12 CDT(-0500)] <colinclark> or something like this?

[14:03:13 CDT(-0500)] <Bosmon> It seems that the "auxSchema" can include a naemsapce

[14:03:26 CDT(-0500)] <Bosmon> namespace

[14:03:45 CDT(-0500)] <colinclark> Are there other aspects of "the contract that a typical Infusion component would have" that I should keep in mind, Justin_o?

[14:03:47 CDT(-0500)] <Justin_o> Bosmon: yes it can take a namespace, but you would get something like fluid.uiOptions.prefsEditor

[14:04:32 CDT(-0500)] <anastasiac> Bosmon, could you elaborate on how this would work? would the "fluid.uiOptions" component have the builder as a subcomponent? Would it be a wrapper function that creates the builder then invokes the constructed grade? other?

[14:04:49 CDT(-0500)] <Bosmon> It appears that it used to call itself "fluid.uiOptions.constructed"

[14:04:50 CDT(-0500)] <colinclark> hopefully other (smile)

[14:05:13 CDT(-0500)] <anastasiac> yes, that's the default namespace if none is provided (updated to "fluid.prefs.constructed")

[14:05:25 CDT(-0500)] <Bosmon> anastasiac - it would work as it works now, the builder constructs a grade with a known name

[14:05:44 CDT(-0500)] <anastasiac> so the integrator still has to create the builder then run the function? still two steps?

[14:05:56 CDT(-0500)] <anastasiac> I thought we were trying to get it down to one step (smile)

[14:06:11 CDT(-0500)] <Bosmon> So when we restore our "UIO" component, in addition to containing some of the code present in the "prefsEditorDemo", it will also define a name that is not silly

[14:06:12 CDT(-0500)] <Justin_o> colinclark: it's a real grade that gets produced but if you did something like fluid.uiOptions = outputOfBuilder then I would assume the name wouldn't exist in any IoC related context of to calls to fluid.defaults

[14:06:27 CDT(-0500)] <colinclark> right

[14:06:30 CDT(-0500)] <Bosmon> Justin_o - see my remark earlier about a sensible name (smile)

[14:06:34 CDT(-0500)] <Bosmon> anastasiac, likewise (smile)

[14:06:42 CDT(-0500)] <Bosmon> We will put this component "back into the frameworK"

[14:06:53 CDT(-0500)] <Bosmon> And so the demo will contain FEWER steps, not more

[14:06:54 CDT(-0500)] <Bosmon> fewer!

[14:07:37 CDT(-0500)] <anastasiac> so what will the component look like? what will its relationship to the builder be?

[14:07:49 CDT(-0500)] <Bosmon> It's relationship to the builder, will be that it is BUILT by the builder

[14:08:00 CDT(-0500)] <Justin_o> Bosmon: i assume what you are saying is that we run a build and use it's output

[14:08:07 CDT(-0500)] <Bosmon> Justin_o - that is right

[14:08:35 CDT(-0500)] <Justin_o> Bosmon: so maybe we just call fluid.defaults("fluid.uiOptions", {gradeNames: ["outputFromBuilderGrade", "autoInit"]

[14:08:36 CDT(-0500)] <anastasiac> so the integrator still has two steps. 1) create the builder, 2) invoke the function

[14:08:39 CDT(-0500)] <Justin_o> something like that

[14:08:51 CDT(-0500)] <Bosmon> Justin_o - that's another option, yes

[14:09:07 CDT(-0500)] <Bosmon> anastasiac - the integrator just has ONE step

[14:09:09 CDT(-0500)] <Justin_o> anastasiac: no i think thats in the uiOptions.js, so a user would directly interact with the outputed grade

[14:09:10 CDT(-0500)] <Bosmon> "instantiate the component"

[14:09:26 CDT(-0500)] <anastasiac> ok, I'm clearly not understanding something

[14:09:37 CDT(-0500)] <anastasiac> my understanding of "the component" is that it's something created by the builder

[14:09:40 CDT(-0500)] <anastasiac> that's not the case?

[14:09:42 CDT(-0500)] <Justin_o> anastasiac: i'll make a pastie.. one second

[14:09:44 CDT(-0500)] <Bosmon> anastasiac - that is the case

[14:09:48 CDT(-0500)] <colinclark> (smile)

[14:09:52 CDT(-0500)] <colinclark> awesome, thanks Justin_o

[14:10:01 CDT(-0500)] <colinclark> So, I guess to wrap up the main part of this

[14:10:09 CDT(-0500)] <colinclark> 1. Sorry to distract you all with going over this again

[14:10:14 CDT(-0500)] <colinclark> 2. It's been very informative

[14:10:30 CDT(-0500)] <colinclark> 3. We should, before shipping 1.5, provide this kind of affordance for users

[14:10:48 CDT(-0500)] <colinclark> 4. I'll send out an email to users of the preferences framework giving them a heads up that the renaming has happened

[14:11:43 CDT(-0500)] <colinclark> 5. We still need to figure out if we've got a subtle problem related to the CSS renaming

[14:11:59 CDT(-0500)] <colinclark> I think michelled is on that latter mission

[14:12:33 CDT(-0500)] <michelled> there is definitely use of uio theme names in the oercommons source

[14:12:58 CDT(-0500)] <michelled> it's actually the strategy that we recommend to make a site conform nicely when a theme is chosen

[14:13:24 CDT(-0500)] <colinclark> that's exactly what I was afraid of

[14:13:31 CDT(-0500)] <colinclark> Can you also check out they instantiate UIO?

[14:13:45 CDT(-0500)] <colinclark> does it more or less reflect our tutorial, or are they doing anything fancy?

[14:16:16 CDT(-0500)] <Justin_o> sorry about the delay.. my computer decided to lock up for a bit.. probably all the instances of sublime i'm running

[14:16:24 CDT(-0500)] <Justin_o> http://pastie.org/private/pftaoeghqsg12wn6anjqg

[14:16:25 CDT(-0500)] <colinclark> no worries (smile)

[14:17:24 CDT(-0500)] <Justin_o> Bosmon, colinclark, anastasiac: does it look okay?

[14:18:33 CDT(-0500)] <Bosmon> Justin_o - something like that, yes - although it might be more helpful if we could get some insight into what the constructed grade name actually is in any case, and guide it to be something helpful

[14:18:40 CDT(-0500)] <anastasiac> it looks lovely

[14:18:53 CDT(-0500)] <Bosmon> I guess by default it will be something like fluid.uiOptions.constructed.something?

[14:19:07 CDT(-0500)] <anastasiac> the constructed grade name is now in the "fluid.prefs.constructed"

[14:19:14 CDT(-0500)] <anastasiac> you get "prefsEditor" and "uio"

[14:19:23 CDT(-0500)] <anastasiac> so "fluid.prefs.constructed.prefsEditor"

[14:19:36 CDT(-0500)] <anastasiac> if you override the namespace with "footer" you can then use "foofer.prefsEditor"

[14:19:53 CDT(-0500)] <anastasiac> s/footer/foofer

[14:21:04 CDT(-0500)] <Bosmon> So perhaps we could achieve fluid.uiOptions.prefsEditor?

[14:21:09 CDT(-0500)] <Bosmon> Simply through configuration to the builder?

[14:21:28 CDT(-0500)] <anastasiac> yes, easily

[14:21:33 CDT(-0500)] <Justin_o> Bosmon: yes, that would be easy

[14:22:23 CDT(-0500)] <Justin_o> Bosmon: the question would be is that what we'd want?

[14:22:46 CDT(-0500)] <Bosmon> I think it has some things in its favour

[14:22:58 CDT(-0500)] <Justin_o> i just really mean the name

[14:23:03 CDT(-0500)] <Bosmon> For example, it helps to bridge the gaps between the worlds of users #1 and #2

[14:23:06 CDT(-0500)] <Bosmon> yes

[14:23:07 CDT(-0500)] <Justin_o> i like the 1 less step

[14:23:13 CDT(-0500)] <Bosmon> It is a name that can be "naturally achieved"

[14:23:21 CDT(-0500)] <Bosmon> And so it is clearer to users how they might naturally achieve other things

[14:23:34 CDT(-0500)] <Bosmon> As well as giving them easy access to all the other grade names that are constructed in the same step

[14:24:49 CDT(-0500)] <Justin_o> fluid-everyone: are you okay with fluid.uiOptions.prefsEditor as the packaged component for the preference framework

[14:25:02 CDT(-0500)] <colinclark> yup, I'm fine with it

[14:25:12 CDT(-0500)] <colinclark> and other prefsEditors will likely mirror this approach?

[14:25:20 CDT(-0500)] <colinclark> pga.explorationTool.prefsEditor?

[14:25:26 CDT(-0500)] <colinclark> or whatever

[14:25:56 CDT(-0500)] <anastasiac> seems ok to me

[14:26:03 CDT(-0500)] <Justin_o> okay.. i'll just reopen FLUID-5161 and we can make the necessary changes

[14:26:37 CDT(-0500)] <Justin_o> cindyli: did you want to make these changes or would you like me too.. i don't mind doing it.. up to you

[14:27:49 CDT(-0500)] <cindyli> Justin_o: go ahead to make changes since you seem to be more clear about all these (smile)

[14:28:41 CDT(-0500)] <Justin_o> cindyli: okay (smile)

[14:29:51 CDT(-0500)] <cindyli> thanks, Justin_o

[14:41:17 CDT(-0500)] <michelled> colinclark: in terms of your earlier question, oercommons is mostly following the tutorial. There is one listener being added programatically in the green site, but it should be a simple fix

[14:41:28 CDT(-0500)] <colinclark> ok

[14:41:31 CDT(-0500)] <colinclark> well, there you go

[14:41:39 CDT(-0500)] <colinclark> so the CSS issue isn't a trivial one

[14:41:50 CDT(-0500)] <colinclark> Have the stylesheets changed much amidst all this refactoring, Justin_o?

[14:41:54 CDT(-0500)] <michelled> nope, it's not

[14:41:59 CDT(-0500)] <colinclark> aside from the names

[14:46:26 CDT(-0500)] <colinclark> michelled: do you think it would be crazy to ship two copies of the UIO stylesheets?

[14:46:42 CDT(-0500)] <colinclark> Or doubled definitions of everything, half of them marked deprecated?

[14:52:01 CDT(-0500)] <michelled> I'd rather see two copies of the stylesheets instead of double definitions

[14:52:25 CDT(-0500)] <michelled> I imagine we could modify the css generation code to generate the two copies

[14:52:49 CDT(-0500)] <michelled> or maybe we should make another build target?

[14:53:20 CDT(-0500)] <colinclark> Either one would be fine

[14:53:55 CDT(-0500)] <colinclark> Despite my typically aggressive "I want to break backwards compatibility" stance these days, I think we should plan for something before we cut 1.5

[14:54:16 CDT(-0500)] <colinclark> I worry that the "accessibility is too hard" set will just see this as further fuel for the fire