fluid-work IRC Logs-2013-03-19

[07:30:44 CDT(-0500)] <Justin_o> Bosmon: Hello.. i was trying to setup a grade to apply to the empty UIO to fill it up with settings panels, but it didn't seem to work… i filed a jira and added a test case in my branch http://issues.fluidproject.org/browse/FLUID-4937

[07:35:14 CDT(-0500)] <Justin_o> to work around this i'm just using the grade in place of UIO since it itself, has uiOptions as a grade. This seems to work fine for now. I'll start splitting off the settings into individual panels now.. which looks like I'll only really need to do for the first panel. Since the other two are similar to their modern counterparts already

[07:35:34 CDT(-0500)] <Justin_o> Bosmon: you might also want to look at our UIO tasking page. http://wiki.fluidproject.org/display/fluid/User+Interface+Options+Iteration+Planning

[08:50:00 CDT(-0500)] <heidiv> Justin_o do you recall why the height of the UIO iframe is inline?

[09:05:20 CDT(-0500)] <Justin_o> heidiv: i'm not sure.. Bosmon might have an idea, as he made some changes to make the height dynamic

[09:05:44 CDT(-0500)] <heidiv> ah, right

[09:05:55 CDT(-0500)] <heidiv> because if size is changed, on reload it should be larger

[09:06:18 CDT(-0500)] <heidiv> i'll look to see where to change that default height...

[09:07:56 CDT(-0500)] <Bosmon7> Hi Justin_o - I'm looking at your FLUID-4937 issue

[09:08:04 CDT(-0500)] <Bosmon7> But it doesn't seem you've committed it to a branch?

[09:08:42 CDT(-0500)] <Bosmon7> Hmm

[09:08:43 CDT(-0500)] <Bosmon7> You did

[09:08:46 CDT(-0500)] <Bosmon7> I'm confused now

[09:09:09 CDT(-0500)] <Bosmon7> Sorry, ignore me, I am confused

[09:10:47 CDT(-0500)] <heidiv> Justin_o will the reset be moved out this iteration?

[09:16:30 CDT(-0500)] <Justin_o> Bosmon7: thanks for looking

[09:18:25 CDT(-0500)] <Justin_o> heidiv: yes.. i think the reset button should be moved down. UIO already has a method for reset, so you should be able to bind to it. I guess it should be part of fatPanel instead of UIO per se.. right now UIO is looking for a reset bottom in its template though. I'm not yet sure what will happen if it doesn't find it, but i was talking with michelled about this last week and we may remove those automatic bindings to buttons in UIO for res

[09:18:26 CDT(-0500)] <Justin_o> save, apply and etc.

[09:21:19 CDT(-0500)] <heidiv> ok cool

[09:48:55 CDT(-0500)] <Bosmon7> Hi Justin_o - thanks for your test case - I have issued a fix to pull request https://github.com/fluid-project/infusion/pull/271

[09:49:13 CDT(-0500)] <Bosmon7> This is cumulative with the FLUID-4921 branch which I think michelled is reviewing, which also has an update

[09:52:09 CDT(-0500)] <Justin_o> Bosmon7: thanks, much appreciated… i'll check in with michelled about when the pull can go in.. i think she had left you some comments on it

[10:09:17 CDT(-0500)] <alexn1> Bosmon7: hi there

[10:10:11 CDT(-0500)] <alexn1> Bosmon7: I have a question for you if you have a minute

[11:22:53 CDT(-0500)] <Bosmon7> Hi alexn1

[11:37:08 CDT(-0500)] <heidiv> jhung Thinking I should leave the look of the display w/without preferences UIO the same. ie. not change the inputs for all, just for fat panel. thoughts?

[11:37:28 CDT(-0500)] <heidiv> cos i think all 3 will still be present this iteration

[11:53:07 CDT(-0500)] <jhung> ^heidiv not sure i'm following.

[11:53:39 CDT(-0500)] <heidiv> jhung ah, well most of the inputs right now are styled in UIOptions.css (global for all 3 versions of UIO)

[11:53:53 CDT(-0500)] <jhung> ah.

[11:54:04 CDT(-0500)] <heidiv> i think i'm going to not edit that file tho, to preserve the look of the other 2 (which will eventually fall away, but not yet)

[11:54:19 CDT(-0500)] <jhung> yeah

[11:54:20 CDT(-0500)] <heidiv> so i'll just style the inputs for fat panel, overriding the global for now

[11:54:36 CDT(-0500)] <heidiv> does that make sense?

[11:54:59 CDT(-0500)] <jhung> sure

[11:55:27 CDT(-0500)] <heidiv> ok cool. it'll just mean the other two look totally different, but that's already a given

[11:55:57 CDT(-0500)] <jhung> yep

[11:56:36 CDT(-0500)] <jhung> fluid-everyone: jvass and I were having a conversation about the images shown under the "Graphics" heading here http://wiki.fluidproject.org/display/fluid/User+Interface+Options+design+high+fidelity%2C+C.1

[11:57:36 CDT(-0500)] <jhung> Currently heidiv and I are using these images in UIO styling. jvass asked why not do these in CSS and / or icon fonts.

[11:58:45 CDT(-0500)] <jhung> What are the reasons for / against implementing strictly in CSS / fonts?

[12:00:42 CDT(-0500)] <heidiv> so if we used a font icon for the slider handle for example, the current image would be replaced by a div with the word "handle" in it (ligature) and styled to replace this with an icon.

[12:01:10 CDT(-0500)] <heidiv> does that make ok sense semantically? i'm thinking it does… and there's likely aria we can add to describe it's abilities

[12:01:15 CDT(-0500)] <heidiv> its

[12:02:21 CDT(-0500)] <heidiv> arashs would you be able to add these sorts of images to that font?

[12:02:30 CDT(-0500)] <jvass> heidiv, would we be able to use just css for the slider handle?

[12:04:00 CDT(-0500)] <heidiv> jvass to create the circle with drop shadow and lines in it? possibly, tho i worry about cross-browser issues, resizing… as a font it would need to be monotone

[12:04:28 CDT(-0500)] <heidiv> or would the lines inside be an icon

[12:05:06 CDT(-0500)] <heidiv> i also don't want to over-complicate… just because we can do something maybe doesn't mean we should. what are the benefits to doing this in css vs image?

[12:07:12 CDT(-0500)] <jvass> heidiv, it would be less of a hassle to export every contrast theme and size

[12:08:07 CDT(-0500)] <heidiv> jvass yes that's a nice plus. we could try and see what happens? not sure how to do the inside green lines… thoughts? icon?

[12:08:33 CDT(-0500)] <jhung> Hybrid approach - both css and font heidiv?

[12:10:05 CDT(-0500)] <jvass> yes, the green lines could be an icon, or we could replace them with a circle

[12:10:28 CDT(-0500)] <heidiv> we also need to attach proper semantics to it… so perhaps the div would hold the word "handle" and some aria. clown is there a role that makes sense for a slider handle?

[12:10:56 CDT(-0500)] <alexn1> Bosmon7: sorry I was away for lunch. Actually I already figured out my problem. Justin_o helped me with it.

[12:11:15 CDT(-0500)] <heidiv> n/m clown, role="slider" is already used

[12:11:27 CDT(-0500)] <heidiv> so that's good… ok will try it

[12:12:25 CDT(-0500)] <arashs> yes heidiv we can do that, but as jvass mentioned, we can only do monotone

[12:13:09 CDT(-0500)] <heidiv> ok arashs , we're going to try css… stay tuned

[12:13:26 CDT(-0500)] <arashs> if you want we can try and see how it would work (having different elements as fonts)

[12:13:49 CDT(-0500)] <arashs> heidiv: ok cool.

[12:13:50 CDT(-0500)] <heidiv> ya, worth trying. will see how this goes first…

[12:15:11 CDT(-0500)] <heidiv> lunch bbs

[12:16:36 CDT(-0500)] <Justin_o> heidiv, jhung: you can take a look at either cindyli or my branches. we have the panels separated now and each has it's own template file. At the moment for fat panel this means 6 tabs

[12:16:58 CDT(-0500)] <Justin_o> my branch: https://github.com/jobara/infusion/tree/FLUID-4927-b

[12:17:33 CDT(-0500)] <Justin_o> cindyli's branch: https://github.com/cindyli/infusion/tree/FLUID-4927

[12:17:40 CDT(-0500)] <Justin_o> both branches should be in sync

[12:25:26 CDT(-0500)] <clown> heidiv: just saw your notes about slider above. yes, typcially put the slider role on the thumb, since that's what gets keyboard focus (typcially). So, confirming role="slider".

[12:26:22 CDT(-0500)] * clown wishes he could spell "typically"...

[12:37:32 CDT(-0500)] <heidiv> thanks clown (wink)

[12:37:50 CDT(-0500)] <heidiv> Justin_o oh awesome

[12:38:28 CDT(-0500)] <heidiv> Justin_o jvass will we be keeping line height and text style , now that we have the ability to remove them?

[12:38:46 CDT(-0500)] <heidiv> i don't see them in the mockups but i'm not sure if that's cos they're deprecated or just not present here

[12:38:57 CDT(-0500)] <Justin_o> heidiv: let me know if you want the markup changed. We can do just about anything i think, provided the flc- classnames are the same

[12:39:20 CDT(-0500)] <heidiv> markup should be ok but will let you know

[12:42:13 CDT(-0500)] <Justin_o> heidiv: thanks

[12:42:42 CDT(-0500)] <Justin_o> heidiv: we'll probably have to sync up at some point on where we want the title of the setting to show up, since of the ones that were in the text panel, it has the title twice.

[12:43:36 CDT(-0500)] <heidiv> title twice… hmm

[12:43:46 CDT(-0500)] <heidiv> Justin_o not sure what you mean

[12:45:52 CDT(-0500)] <heidiv> Justin_o n/m i see what you mean

[12:45:54 CDT(-0500)] <heidiv> (smile)

[12:46:01 CDT(-0500)] <heidiv> i had removed them on my end

[12:46:26 CDT(-0500)] <Justin_o> heidiv: ah okay..

[12:52:21 CDT(-0500)] <heidiv> Justin_o i checked out your branch and will work off it

[12:52:44 CDT(-0500)] <Justin_o> heidiv: cool, thanks

[13:00:36 CDT(-0500)] <heidiv> Justin_o can we Skype? i have some weirdness

[13:01:00 CDT(-0500)] <Justin_o> sure.. one second

[13:02:58 CDT(-0500)] <heidiv> Justin_o hm, maybe it's my end… i removed tabs before but i see you still have them

[13:03:48 CDT(-0500)] <heidiv> Justin_o n/m all good when i hide all the tabs - we won't have those anymore

[13:04:45 CDT(-0500)] <heidiv> Justin_o hm, they're all in separate <ul>s tho - they should be in one <ul> and each panel an <li>, yes?

[13:18:38 CDT(-0500)] <heidiv> hey jhung in http://wiki.fluidproject.org/display/fluid/User+Interface+Options+Iteration+Planning did you create a jira for the "Implement a new panel style " task?

[13:18:47 CDT(-0500)] <heidiv> i should rename my branch to whatever that jira is

[13:19:32 CDT(-0500)] <jhung> Nope I didn't create a Jira. Let me see if there is one.

[13:20:34 CDT(-0500)] <jhung> I'm going to create one now heidiv

[13:20:41 CDT(-0500)] <heidiv> sweet

[13:22:37 CDT(-0500)] <heidiv> Justin_o i feel like even the <li> should be in the fat panel template vs. the pref one

[13:23:36 CDT(-0500)] <heidiv> yeah, it has to be actually

[13:26:26 CDT(-0500)] <jhung> heidiv: I created a Jira, but it's a single line. http://issues.fluidproject.org/browse/FLUID-4938 Not sure what else needs to be added to it.

[13:26:56 CDT(-0500)] <heidiv> jhung ok thanks

[13:29:37 CDT(-0500)] <Justin_o> heidiv: okay, that's fine, then the template for the individual settings panels could just be a div or something

[13:29:52 CDT(-0500)] <heidiv> Justin_o ya changed to divs. all coming together...

[13:30:14 CDT(-0500)] <Justin_o> heidiv: that's great

[14:59:12 CDT(-0500)] <heidiv> Justin_o do "sliderOptions" in SettingsPanels.js correspond w query ui options? i want to make them have a value colour like http://jqueryui.com/slider/#colorpicker

[15:00:56 CDT(-0500)] <colinclark> kasper_, yzen, Bosmon: Okay, so. Hi.

[15:01:17 CDT(-0500)] <colinclark> kasper_ and I were just on a really nice call with Claudia about the rule-based matchmaker

[15:01:32 CDT(-0500)] <colinclark> It turns out that their ideal goal for the RB MM is to actually operate on common terms.

[15:01:33 CDT(-0500)] <colinclark> Fancy that!

[15:01:38 CDT(-0500)] <colinclark> So here's the problem...

[15:02:08 CDT(-0500)] <colinclark> Somehow, without anyone really thinking through it carefully, it was decided that the pilot testing must be done by gathering application-specific preferences from the testers

[15:02:17 CDT(-0500)] <Justin_o> heidiv: looks like it.. if you check out line 344 in SettingsPanels.js you can see some options specified

[15:02:28 CDT(-0500)] <colinclark> I had advocated for a kind of "virtual wizard" experience where we also gathered common terms from the user, too

[15:02:42 CDT(-0500)] <colinclark> but kasper_ and Claudia thought that this was likely too much to ask from the pilot testers right now

[15:02:54 CDT(-0500)] <Justin_o> also on line 428 you can see that it just it creates a slider with those options

[15:03:04 CDT(-0500)] <colinclark> So at the moment, the RBMM is designed to deal with "exceptional" cases--conflicts or cases where a device/platform can't accommodate a user's preference

[15:03:20 CDT(-0500)] <colinclark> It does no transformation of its own, and is intended to delegate to the transformer

[15:03:25 CDT(-0500)] <Justin_o> heidiv: i guess there might be some other options in there as well for the aria stuff

[15:03:39 CDT(-0500)] <colinclark> kasper_ raised the critical issue for us, which is that we aren't yet confident in our ability to invert our existing transforms

[15:03:47 CDT(-0500)] <colinclark> The pilots are coming up fast, but we still have some time

[15:04:27 CDT(-0500)] <colinclark> I suggested a possible short-term workaround, which is to, rather than inverting the transforms in the Solutions Registry, to create a new set of "backwards" rules representing the conversion from app-specific -> common

[15:04:42 CDT(-0500)] <colinclark> This transformation could then be run by the RBMM prior to it operating on the preferences set.

[15:04:57 CDT(-0500)] <Bosmon8> colinclark - that may prove useful as a set of test cases for inversion in any case

[15:05:10 CDT(-0500)] <colinclark> Do you think, then, Bosmon8, that it's a good first step?

[15:05:17 CDT(-0500)] <Bosmon8> colinclark - I think so, yes

[15:05:24 CDT(-0500)] <Bosmon8> And will also help to clarify our expectations on inversion

[15:05:55 CDT(-0500)] <Bosmon8> I maintain to kasper_ that it is perfectly possible to achieve "100% of possible inversion" without the need for clever tricks ("pockets")

[15:06:02 CDT(-0500)] <Bosmon8> Even if the transforms themselves are not perfectly invertible

[15:06:29 CDT(-0500)] <Bosmon8> I believe that there is a natural level of performance that represents "all possible inversion" that we can and should achieve, and that will be recognisable to the user

[15:07:54 CDT(-0500)] <Bosmon8> If we weren't on the hook for all the UIO stuff, I would have said this wouldn't be to difficult in practice before the pilots

[15:08:01 CDT(-0500)] <Bosmon8> But unfortunately we are stretched rather thin

[15:10:39 CDT(-0500)] <colinclark> yes

[15:10:39 CDT(-0500)] <colinclark> ok

[15:10:53 CDT(-0500)] <colinclark> I chatted briefly to anastasiac about lending kasper_ a hand with it

[15:10:59 CDT(-0500)] <colinclark> and Claudia is also willing to write some

[15:11:13 CDT(-0500)] <colinclark> so that should be a good starting point

[15:11:17 CDT(-0500)] <colinclark> and as you say, we can use this as test data for finishing up the code to ensure invertibility

[15:11:22 CDT(-0500)] <anastasiac> yes, kasper_, I'd be happy to help in any way I can

[15:16:23 CDT(-0500)] <Bosmon8> Cool!

[15:16:29 CDT(-0500)] <Bosmon8> Thanks for those merges, michelled!

[15:16:36 CDT(-0500)] <Bosmon8> The trunk framework is now in pretty good shape

[15:17:48 CDT(-0500)] <michelled> np Bosmon8

[15:17:51 CDT(-0500)] <colinclark> I'm so far behind on code reviews at this point

[15:17:56 CDT(-0500)] <colinclark> it's great to have you working on them, michelled

[15:17:57 CDT(-0500)] <michelled> Justin_o: the fix you need is in now (smile)

[15:18:03 CDT(-0500)] <michelled> (smile)

[15:18:10 CDT(-0500)] <Justin_o> michelled: excellent, thanks

[15:18:10 CDT(-0500)] <colinclark> At this point, kasper_ and I agreed that he will just create a "Pilots" mega branch for GPII

[15:18:22 CDT(-0500)] <Bosmon8> What will be in this branch, colinclark?

[15:18:25 CDT(-0500)] <colinclark> and that one of us will review it for Absolute Evil

[15:18:32 CDT(-0500)] <colinclark> and then we'll review in more detail each individual pull request

[15:18:39 CDT(-0500)] <colinclark> Bosmon8: Whatever is required to make the pilot testing work

[15:18:51 CDT(-0500)] <Bosmon8> colinclark - do we have a rough inventory of what that is?

[15:18:56 CDT(-0500)] <michelled> kasper_: you probably will want to update to infusion master now - it has the fixes you need too

[15:18:57 CDT(-0500)] <colinclark> kasper_ does

[15:19:04 CDT(-0500)] <colinclark> and there is a wiki page that has a summary

[15:19:10 CDT(-0500)] <Bosmon8> I guess it includes a number of the windows branches that I have not looked at for a very long time

[15:19:14 CDT(-0500)] <Bosmon8> For which I am sorry

[15:19:54 CDT(-0500)] <colinclark> Yes, you're signed up to look at them when you get a chance

[15:20:06 CDT(-0500)] <colinclark> and it now seems like we've got another breakage in Node with the 0.10 release

[15:20:20 CDT(-0500)] <colinclark> I filed a JIRA for it based on a mailing list thread: http://issues.gpii.net/browse/GPII-94

[15:21:42 CDT(-0500)] <Bosmon8> colinclark, thanks

[15:21:55 CDT(-0500)] <colinclark> Boyan seems to think it's node-ffi related

[15:21:57 CDT(-0500)] <Bosmon8> Seems that node-ffi was up with relatively recent node 0.9.x

[15:22:03 CDT(-0500)] <Bosmon8> But I don't see any updates there for a month

[15:22:06 CDT(-0500)] <colinclark> interesting

[15:22:30 CDT(-0500)] <Bosmon8> I imagine it's ok to tell all our partners to use 0.8.x until further notice

[15:23:25 CDT(-0500)] <Justin_o> Bosmon8: I'm trying out the code changes now for merging gradeNames.. although now if i add the gradeName, my applier seems to disappear.. getting an error that it is undefined

[15:23:44 CDT(-0500)] <Bosmon8> Justin_o - could you make up a further test case? : )

[15:24:01 CDT(-0500)] <Justin_o> Bosmon8: i'll see what i can do (smile)

[15:31:20 CDT(-0500)] <Justin_o> Bosmon8: hmmm simple test seems to be working.. so i think i'll have to dig in a bit more to see what the difference is. I won't have time tonight though, but i'll look into it more tomorrow