fluid-work IRC Logs-2013-07-17

Owned by Fluid IRC Log Bot
Last updated: Jul 17, 2013Version comment
15 min read

[07:49:33 CDT(-0500)] <Justin_o> cindyli: morning cindy, how are things going with that pull request you were working on?

[07:49:55 CDT(-0500)] <cindyli> Justin_o: done.

[07:50:14 CDT(-0500)] <cindyli> wanna chat about next steps for schema work?

[07:56:42 CDT(-0500)] <Justin_o> cindyli: would you like to start in on the i18n stuff we chatted about in the channel yesterday?

[08:11:05 CDT(-0500)] <Justin_o> cindyli: yzen is going to look at the pull request from Bosmon that addresses the issue we ran into the other day with the components merging. I'm going to fix up the naming and structure issues with builder.js

[08:11:57 CDT(-0500)] <cindyli> thanks, Justin_o, i have a couple of questions regarding the i18n, do you have a minute to chat about that?

[08:13:04 CDT(-0500)] <Justin_o> cindyli: sure

[08:20:58 CDT(-0500)] <yzen> cindyli: Justin_o so the pull request fixes our test but unfortunately not the uio problem, ill try to make another one

[08:25:28 CDT(-0500)] <cindyli> oh, no

[08:25:33 CDT(-0500)] <Justin_o> yzen: really.. (sad)

[08:25:41 CDT(-0500)] <yzen> ya

[08:30:04 CDT(-0500)] <system64> Hello yzen

[08:30:12 CDT(-0500)] <yzen> system64: hi

[08:31:03 CDT(-0500)] <system64> Is there any demo for kettle apart from the gpii repo?

[08:32:25 CDT(-0500)] <yzen> system64: the current one, no unfortunately not

[08:33:46 CDT(-0500)] <system64> Is it possible to run the prefServer using kettle without depending on gpiiFramework

[08:34:04 CDT(-0500)] <Justin_o> yzen, cindyli: have you seen this http://emmet.io

[08:34:42 CDT(-0500)] <Justin_o> there is also a plugin for sublime text that adds emmet's functionality in

[08:34:55 CDT(-0500)] <yzen> Justin_o: yes saw that one

[08:35:06 CDT(-0500)] <system64> Justin_o: Its awesome, but no plugins for vim

[08:35:27 CDT(-0500)] <Justin_o> system64: have you tried sublime text.. it's pretty good

[08:36:31 CDT(-0500)] <system64> Justin_o: Just trying to shift away from Sublime these days.

[08:37:06 CDT(-0500)] <Justin_o> ah (smile)

[08:37:29 CDT(-0500)] <system64> Justin_o: Brackets is going to be the future for HTML/CSS editing IMHO.

[08:37:43 CDT(-0500)] <system64> Open source too <3

[08:39:49 CDT(-0500)] <Justin_o> system64: right i remember this one now.. i haven't looked at it though

[08:41:29 CDT(-0500)] <Justin_o> yzen, cindyli: does this look more like what we expect after our chat with Bosmon yesterday?

[08:41:31 CDT(-0500)] <Justin_o> https://github.com/jobara/infusion/blob/FLUID-4907/src/webapp/components/uiOptions/js/Builder.js

[08:43:09 CDT(-0500)] <Justin_o> as you can tell from the comment i still need to figure out the namespace.. or i could combine the consolidatedGrade and enhancer grade into one and you'd only get one or the other?

[08:43:30 CDT(-0500)] <cindyli> a few questions, Justin_o

[08:43:53 CDT(-0500)] <cindyli> 1. should "consolidatedGrade" be called "assembledGrade" or something like finalGrade

[08:44:32 CDT(-0500)] <cindyli> 2. "enhancerGrade" is an instance of assembler.uie? i thought we are merging uie and uio together

[08:45:17 CDT(-0500)] <Justin_o> cindyli: sure we could change the name to one of those. assembledGrade might be better.

[08:45:32 CDT(-0500)] <Justin_o> cindyli: you can still get a uiEnhancer without a UIO

[08:45:38 CDT(-0500)] <Justin_o> we need to keep supporting that

[08:46:02 CDT(-0500)] <yzen> Justin_o: i m guessing line 43 is still not final right ?

[08:46:42 CDT(-0500)] <Justin_o> yzen: no that was what i mean about the namespace needs to be figured out still or we need to only produce one output grade

[08:47:30 CDT(-0500)] <yzen> k

[08:47:31 CDT(-0500)] <Justin_o> yzen, cindyli: i guess the nice part about having two is that you wouldn't have to write separate schemas

[08:47:46 CDT(-0500)] <Justin_o> but the drawback is you'd be doing extra work all the time

[08:47:59 CDT(-0500)] <Justin_o> sorry, not you, but the framework i guess

[08:48:29 CDT(-0500)] <cindyli> Justin_o: what do u mean "have to write separate schemas"?

[08:49:02 CDT(-0500)] <Justin_o> cindyli: for example you create a site that has UIO on some pages, but only enhancers on the other.. you'd have one schema that included panels and one that didnt'

[08:49:20 CDT(-0500)] <cindyli> ok, i see

[08:53:07 CDT(-0500)] <cindyli> yzen and Justin_o, from yesterday's discussion for i18n, we are going to break message bundle into several json files based on panels. these json files will be loaded in via templateLoader. as u know, templateLoade is already loading panel templates. it currently takes in one "prefix" option that specify the common path to the template directory. Since the message json files will be sitting in a different directory. what do you think the bes

[08:53:16 CDT(-0500)] <cindyli> two methods:

[08:53:30 CDT(-0500)] <cindyli> 1. 2 options for templatePrefix and messagePrefix

[08:55:15 CDT(-0500)] <cindyli> 2. one prefix option that has the common part shared by both template and message bundle directory, such as "uio/", each template declares "%prefixhtml/textSize.html" and message as "%prefixmessage/textSize.json"

[08:55:27 CDT(-0500)] <cindyli> i personally prefers (1)

[08:55:47 CDT(-0500)] <Justin_o> cindyli: what does the templateLoader do actually

[08:56:18 CDT(-0500)] <cindyli> Justin_o: loads in physical files

[08:58:10 CDT(-0500)] <Justin_o> cindyli: what does "loads in" mean.. what does it do with them?

[09:01:24 CDT(-0500)] <cindyli> Justin_o: if you meant the actual functionality, the API for fetchResources might explain better: "automates the likely tedious work of performing multiple back-to-back AJAX requests for resource (be they markup, JSON or otherwise) and collecting the responses."

[09:02:15 CDT(-0500)] <Justin_o> cindyli: okay, cool thanks.. that's what i wanted to know.. whether or not there was something specific it was doing with the templates.. but it sounds like it handles things the same

[09:03:22 CDT(-0500)] <yzen> cindyli: i like the 1st option too

[09:03:25 CDT(-0500)] <Justin_o> cindyli: i think maybe what we should do then is to change the name to something like resourceLoader and allow it to take in any number of prefixes

[09:03:46 CDT(-0500)] <yzen> Justin_o: ya that sounds right

[09:05:28 CDT(-0500)] <cindyli> cool, thanks, Justin_o and yura, i will rename it and handle two prefixes for now

[09:16:49 CDT(-0500)] <cindyli> Justin_o, yzen, i merged in master that has Bosmon's fix into our 4907 branch. starting fat panel demo gives "can't convert undefined to object". do you have the same problem?

[09:17:07 CDT(-0500)] <yzen> yes

[09:17:17 CDT(-0500)] <yzen> I'm writing a test case that shows at least that

[09:17:28 CDT(-0500)] <yzen> plus the fact that it does not actually fix our problem

[09:17:31 CDT(-0500)] <cindyli> ok

[09:20:38 CDT(-0500)] <Justin_o> yzen, cindyli: i've made some more changes to the builder.. how do you like this now https://github.com/jobara/infusion/blob/FLUID-4907/src/webapp/components/uiOptions/js/Builder.js

[09:21:50 CDT(-0500)] <yzen> Justin_o: looks good https://github.com/jobara/infusion/blob/FLUID-4907/src/webapp/components/uiOptions/js/Builder.js#L34 should be assembler.uio

[09:22:02 CDT(-0500)] <cindyli> i like this, Justin_o. those names are much more clear

[09:22:30 CDT(-0500)] <Justin_o> yzen, cindyli: thanks.. i'll fix up that mistake and the unit tests

[09:34:52 CDT(-0500)] <colinclark> michelled: I think nightly builds are hot

[09:35:08 CDT(-0500)] <michelled> colinclark: I agree (smile)

[09:36:05 CDT(-0500)] <colinclark> What do you think we can do to extend such hotness to the the also-hot Discovery Tool?

[09:36:44 CDT(-0500)] <michelled> colinclark: we are planning on having a nightly build - it's on our to do list. I was hoping to see avtar to get it set up, but perhaps I should just send him a note

[09:36:56 CDT(-0500)] <michelled> Justin_o: you didn't speak to avtar about the nightly build, did you?

[09:37:08 CDT(-0500)] <Justin_o> michelled: not recently no

[09:39:35 CDT(-0500)] <colinclark> I think it's a pretty worthwhile effort

[09:40:47 CDT(-0500)] <michelled> yes, we'll get it up (smile)

[09:51:33 CDT(-0500)] <colinclark> hey yzen, are you around?

[09:51:34 CDT(-0500)] <kasparnet> yzen: ping

[09:51:50 CDT(-0500)] <yzen> kasparnet: pong

[09:51:51 CDT(-0500)] <yzen> colinclark: yes

[09:52:03 CDT(-0500)] <colinclark> kasparnet was under the impression that you didn't exist

[09:52:05 CDT(-0500)] <kasparnet> yzen: damn you yura – been looking for you on skype

[09:52:20 CDT(-0500)] <yzen> oh sorry it was off

[09:52:25 CDT(-0500)] <colinclark> kasparnet: yzen was just preventing you from having interesting off-channel technical discussions (tongue)

[09:52:40 CDT(-0500)] <kasparnet> colinclark: actually it's true

[09:52:53 CDT(-0500)] <colinclark> yzen: you rule!

[09:53:15 CDT(-0500)] <yzen> (smile)

[09:53:48 CDT(-0500)] <colinclark> Justin_o: michelled, Bosmon and I had a pretty good session going through the process of customizing UIO last night

[09:53:57 CDT(-0500)] <colinclark> resulting in the "Prototutorial" you might have seen

[09:54:15 CDT(-0500)] <colinclark> It seems like it's going to be a pretty good system once we have it clearly documented with lots of examples

[09:54:34 CDT(-0500)] <colinclark> and it occurred to me that it's really prime territory for authoring tools

[09:54:50 CDT(-0500)] <colinclark> I was speculating that it would be quite cool to be able to load up all this UI Options configuration

[09:55:01 CDT(-0500)] <michelled> colinclark: where did you decide to put the wiki page?

[09:55:09 CDT(-0500)] <colinclark> and be able to customize panels by dragging them around or removing them

[09:55:30 CDT(-0500)] <colinclark> and then having a palette of all the available panels that you could add your editor

[09:55:31 CDT(-0500)] <colinclark> it'd be great

[09:55:41 CDT(-0500)] <michelled> that would be nice

[09:55:44 CDT(-0500)] <colinclark> I decided to put in the post-1.4 documentation wiki for Infusion

[09:55:57 CDT(-0500)] <colinclark> http://wiki.fluidproject.org/display/docs/Prototutorial+-+Creating+a+new+Panel+using+the+UI+Options+Preference+Framework

[09:57:13 CDT(-0500)] <Justin_o> colinclark: sounds good

[09:58:07 CDT(-0500)] <colinclark> Justin_o: Based on your conversation yesterday, do you have a clear sense of how i18n will fit into these examples?

[09:58:22 CDT(-0500)] <colinclark> We illustrated how to make a message bundle, but I guess we didn't really wire it up to one of the configurations

[09:58:44 CDT(-0500)] <colinclark> in my response to Claudia I mentioned that I thought it would probably go into the auxiliary schema, but I wasn't 100% if that is also your idea

[10:01:41 CDT(-0500)] <Justin_o> colinclark: cindyli is starting in on that work now.. i think it will look something like the way templates are past right now, but they'd also be able to pass in a single consolidated bundle for all of the components

[10:03:01 CDT(-0500)] <colinclark> cindyli: Can you update that tutorial when you know more about how it will work?

[10:03:18 CDT(-0500)] <cindyli> where's that tutorial, colinclark

[10:03:26 CDT(-0500)] <cindyli> oh, above, got it

[10:04:39 CDT(-0500)] <cindyli> sure, i can update it when the implementation is finalized

[10:04:50 CDT(-0500)] <colinclark> cool

[10:10:24 CDT(-0500)] <michelled> colinclark: not sure if you saw that yzen put the Festival server code into the fluid project space: https://github.com/fluid-project/FestivalTextToSpeechService

[10:10:35 CDT(-0500)] <colinclark> I did!

[10:10:37 CDT(-0500)] <colinclark> I was delighted

[10:11:27 CDT(-0500)] <michelled> yzen: can you arrange with avtar to get our nightly for TTS demo using this repo now instead of yours?

[10:12:18 CDT(-0500)] <yzen> michelled: sure thing

[10:12:31 CDT(-0500)] <michelled> thx!

[10:43:33 CDT(-0500)] <colinclark> hey anastasiac, michelled, I was thinking about new UIO documentation

[10:43:41 CDT(-0500)] <colinclark> Last night's session went so well

[10:43:55 CDT(-0500)] <colinclark> where we just asked questions and talked through "how will this work?" even if it wasn't quite ready to work

[10:44:18 CDT(-0500)] <colinclark> And it seems to me that this could be picked up on pretty much right away with a few different tasks

[10:44:29 CDT(-0500)] <colinclark> First, I think there are several other cases we could start to build examples for

[10:44:57 CDT(-0500)] <colinclark> Perhaps going through the process of answering, "now that I have the cat size panel in place, how do I add a few others?"

[10:45:11 CDT(-0500)] <colinclark> and "What if I wanted to reuse existing panels from the UI Options starter set?"

[10:45:25 CDT(-0500)] <colinclark> I think there's also some concepts we could start to explain

[10:45:37 CDT(-0500)] <colinclark> such as "what is a primary schema and an auxiliary schema?"

[10:45:44 CDT(-0500)] <colinclark> and "How are they different, and why are they different?"

[10:45:53 CDT(-0500)] <colinclark> And "What exactly is this preferencesMap thing?"

[10:58:23 CDT(-0500)] <michelled> colinclark: this makes sense

[11:14:59 CDT(-0500)] <anastasiac> colinclark, that's about the same as my line of thinking

[11:15:07 CDT(-0500)] <colinclark> cool

[11:15:19 CDT(-0500)] <anastasiac> I've been starting to sketch out some of the "what are these schema things" answers

[11:15:35 CDT(-0500)] <colinclark> cool

[11:15:38 CDT(-0500)] <anastasiac> and I want to go through the exercise of using the schemas to add the video player panels to UIO

[11:15:46 CDT(-0500)] <anastasiac> to confirm the process of adding custom panels

[11:15:49 CDT(-0500)] <colinclark> really great idea!

[11:15:56 CDT(-0500)] <anastasiac> it was a really helpful exercise with the previous version

[11:16:04 CDT(-0500)] <anastasiac> so just waiting on a working branch

[11:16:11 CDT(-0500)] <anastasiac> as soon as its ready, I'll do that

[11:38:34 CDT(-0500)] <Bosmon> Justin_o, cindyli, yzen, michelled

[11:38:48 CDT(-0500)] <michelled> hi Bosmon

[11:39:00 CDT(-0500)] <Bosmon> In going through our UIO Builder design yesterday witn colinclark and michelled it occurred to me that there is a serious problem with our current design for the "auxiliary schema"

[11:39:17 CDT(-0500)] <Bosmon> In that it fails to meet one of our most important use cases, that of easily allowing "panels to be removed"

[11:39:36 CDT(-0500)] <michelled> removed when and why?

[11:39:48 CDT(-0500)] <Bosmon> We had this in earlier versions but unfortunately it fell on the floor during one of our redesigns (I have to hold myself responsible for this mistake)

[11:40:47 CDT(-0500)] <Bosmon> michelled - it was an important use case, prompted by anastasiac, I believe, that it should be very easy for someone to say, "I want a configuration of UIO which is exactly like the 'starter configuration' only that panel X is missing"

[11:40:51 CDT(-0500)] <Bosmon> For any particular X

[11:41:16 CDT(-0500)] <Bosmon> Now this is sort of possible given working on "raw grades" but it is not possible given our current format for the "auxiliary schema"

[11:41:24 CDT(-0500)] <Bosmon> Since both the panels and enactors are held in arrays, rather than in hashes

[11:41:46 CDT(-0500)] <Bosmon> It seems to be our current model that the auxiliary schema is now being held in the options for a particular grade

[11:42:25 CDT(-0500)] <Bosmon> I'm not quite sure why this is, but it is exacerbating the existing problem somewhat, since it makes it still less likely that someone would fish the schema out and bash on it directly to remove the material for the panels they want

[11:42:58 CDT(-0500)] <colinclark> ooh this is all interesting

[11:43:01 CDT(-0500)] <Bosmon> So I think we need to think of a revision to the aux schema format whereby everything is stored in keyed hashes

[11:43:28 CDT(-0500)] <Bosmon> It was silly of me to suggest arrays since they always lead to difficulties, but we must all have been particularly dim that day

[11:43:50 CDT(-0500)] <colinclark> i feel dim most days

[11:45:59 CDT(-0500)] <michelled> Bosmon: so this would mean the 'enactors' and 'panels' arrays turn into objects?

[11:46:15 CDT(-0500)] <Bosmon> michelled - yes

[11:46:51 CDT(-0500)] <Bosmon> I was even thinking we might revert to our old model where we just threw them into the same "keyed section" that is in the so-called "primary block"

[11:47:03 CDT(-0500)] <Bosmon> I think we were briefly considering a design of that kind

[11:48:00 CDT(-0500)] <anastasiac> Bosmon, it sounds like we're now considering using something more like "Option 2" on the wiki page: http://wiki.fluidproject.org/display/fluid/Auxiliary+Schema+for+UIO+Preferences

[11:48:05 CDT(-0500)] <michelled> I'm not certain what you mean - would you have an enactor property in the 'catSize' object?

[11:48:17 CDT(-0500)] <michelled> http://wiki.fluidproject.org/display/docs/Prototutorial+-+Creating+a+new+Panel+using+the+UI+Options+Preference+Framework

[11:48:19 CDT(-0500)] <Bosmon> michelled - yes, that is what I am imagining

[11:49:44 CDT(-0500)] <Bosmon> anastasiac - somewhat with the structure of "option 2", yes - but with the difference that the user would add "type" fields to the "enactor" and "panels" blocks

[11:49:59 CDT(-0500)] <anastasiac> right

[11:50:20 CDT(-0500)] <michelled> cindyli, Justin_o, yzen: what do you think?

[11:51:38 CDT(-0500)] <Justin_o> Bosmon: sure.. so we would satisfy the removal requirement by changing a type to fluid.emptySubcomponent?

[11:51:49 CDT(-0500)] <Bosmon> "Let's a memorandum make: arrays are nature's sole mistake"

[11:51:57 CDT(-0500)] <Bosmon> Justin_o - yes, I think so

[11:52:59 CDT(-0500)] <colinclark> I'm a bit dim...

[11:53:03 CDT(-0500)] <colinclark> Are you guys suggesting something like this?

[11:53:07 CDT(-0500)] <colinclark> https://gist.github.com/colinbdclark/6022369

[11:54:06 CDT(-0500)] <Justin_o> colinclark: that's my understanding

[11:54:52 CDT(-0500)] <Bosmon> colinclark - yes, that's my current proposal

[11:55:11 CDT(-0500)] <colinclark> cool

[11:55:15 CDT(-0500)] <Bosmon> In the case a panel covers multiple settings, you can dump its definition into any of the blocks of the ones it handles

[11:55:22 CDT(-0500)] <colinclark> it's nice to have a look at it, just to be sure

[11:55:39 CDT(-0500)] <Bosmon> I mean, in fact whichever block anything is in (other than the schema reference) is arbitrary, but it is just helpful for ALIGNMENT

[11:55:44 CDT(-0500)] <colinclark> I guess we aren't interested in a case where a single preference has multiple enactors associated with it?

[11:55:57 CDT(-0500)] <Bosmon> (had some interesting chats about ALIGNMENT with Clayton last week)

[11:56:04 CDT(-0500)] <Bosmon> colinclark - can you say more about that situation?

[11:56:15 CDT(-0500)] <colinclark> I can't think of a concrete use case

[11:56:23 CDT(-0500)] <Bosmon> In any case, we could handle it by just generating spurious "extra" blocks with different keys

[11:56:32 CDT(-0500)] <colinclark> ah

[11:56:36 CDT(-0500)] <Bosmon> I guess it is could be a slightly confusing model by some views

[11:56:42 CDT(-0500)] <colinclark> yes

[11:56:47 CDT(-0500)] <Bosmon> Perhaps not dissimilar to the way we have "free keys" in our current "staticEnvironment"

[11:59:11 CDT(-0500)] <colinclark> So you think it would be possible to have both the "catOptions.moreFoodEnactor" and the "catOptions.goToTheNeighboursHouseAndSecretlyEatEvenMoreFood" enactor to coexist, bound to the same underlying preference, Bosmon, even if it is slightly confusing to do so?

[12:00:51 CDT(-0500)] <Bosmon> colinclark - yes

[12:02:33 CDT(-0500)] <colinclark> Bosmon: Would I do something like this, then? https://gist.github.com/colinbdclark/6022369

[12:03:25 CDT(-0500)] <Bosmon> colinclark - exactly

[12:03:29 CDT(-0500)] <colinclark> cool

[12:03:40 CDT(-0500)] <Justin_o> Bosmon: how would that affect the model relay, which is keyed off of the key in the auxSchema

[12:04:11 CDT(-0500)] <michelled> colinclark: do you have an opinion on domain for the nightly builds of the prefs editors repos?

[12:04:31 CDT(-0500)] <michelled> we are planning on two builds one for the fluid repo and one for the gpii repo

[12:05:02 CDT(-0500)] <Bosmon> Justin_o - can you explain more?

[12:05:32 CDT(-0500)] <colinclark> michelled: no, any suggestions?

[12:06:33 CDT(-0500)] <michelled> build.fluidproject.org/prefsEditors for the fluid repo

[12:06:46 CDT(-0500)] <michelled> do you know if there is a nightly for anything GPII related yet?

[12:06:51 CDT(-0500)] <colinclark> no

[12:06:54 CDT(-0500)] <Justin_o> Bosmon: the model relay uses the key from the auxiliary schema to be the external model path

[12:07:11 CDT(-0500)] <colinclark> could we also have an alias for "discoveryTool"

[12:07:11 CDT(-0500)] <Justin_o> perhaps cindyli could elaborate more on that

[12:07:30 CDT(-0500)] <michelled> that's a good idea colinclark

[12:07:36 CDT(-0500)] <Bosmon> Justin_o - yes ok, that's fine

[12:07:49 CDT(-0500)] <Bosmon> Since the key is only used for that purpose in the "primary block material"

[12:07:56 CDT(-0500)] <Bosmon> The key is actually irrelevant for panels and enactors

[12:08:01 CDT(-0500)] <Bosmon> but is just there for ALIGNMENT

[12:08:13 CDT(-0500)] <Justin_o> Bosmon: not sure if follow.. what would the model relay use then?

[12:08:38 CDT(-0500)] <Bosmon> Justin_o - it uses that key, just as now

[12:09:13 CDT(-0500)] <Bosmon> But the key only has that purpose for what we used to call the "primary block material", which is now the part outside any "panels" or settings" blocks

[12:09:24 CDT(-0500)] <Justin_o> in colinclark's configuration the model relay would cat size:value for catOptiosn.moreFoodEnactor and catSizeOtherEnactor: value for the other one

[12:09:33 CDT(-0500)] <Justin_o> shouldn't they be sharing the same external model though

[12:10:12 CDT(-0500)] <Bosmon> Justin_o - the key they use is already defined by the "catSize": {

[12:10:12 CDT(-0500)] <Bosmon> "type": "catOptions.size",

[12:10:14 CDT(-0500)] <Bosmon> block at the top

[12:10:23 CDT(-0500)] <Bosmon> I guess if you find it confusing, our users certainly will (smile)

[12:12:27 CDT(-0500)] <Justin_o> Bosmon: yes.. i'd find that a bit confusing.. i wouldn't have expected that.. and i am guessing it is just keyed off of whatever happens to come first?

[12:12:55 CDT(-0500)] <Bosmon> Justin_o - no

[12:13:02 CDT(-0500)] <Bosmon> it is keyed off the one which has the raw "type" field in it

[12:13:11 CDT(-0500)] <Bosmon> Which lies at top level inside the block

[12:40:41 CDT(-0500)] <colinclark> Hey mbrenn_iskme, how's it going?

[12:41:34 CDT(-0500)] <mbrenn_iskme> hi colinclark just getting started for the day, planning to enter our team's dev plans in the fluid wiki

[12:41:43 CDT(-0500)] <colinclark> Cool!

[12:41:46 CDT(-0500)] <colinclark> glad to have you here

[12:42:03 CDT(-0500)] <mbrenn_iskme> thanks! Looking forward to more collaboration for sure

[12:42:32 CDT(-0500)] <colinclark> me too!

[13:37:32 CDT(-0500)] <Justin_o> fluid-everyone: we'll be doing the community meeting now.. the topic will be about our build-scripts.. since this will all be done on Skype could you please let me know if you'd like to join

[13:38:36 CDT(-0500)] <jessm> greggy: need your help

[13:41:14 CDT(-0500)] <anastasiac> hey, yzen, how's the new theme styling?

[13:41:43 CDT(-0500)] <anastasiac> yzen, is this better?

[13:41:53 CDT(-0500)] <yzen> anastasiac: thanks

[13:41:58 CDT(-0500)] <Justin_o> fluid-everyone: ^^^^

[13:42:10 CDT(-0500)] <cindyli> me, Justin_o

[13:44:30 CDT(-0500)] <Justin_o> colinclark, Bosmon: did either of you want to join the build scripts community meeting

[13:47:32 CDT(-0500)] <Justin_o> fluid-everyone: since it's only local people at the meeting we'll just meet at the back of the office.. here's the pirate pad for people to follow https://www.piratepad.ca/p/build-scripts

[13:48:42 CDT(-0500)] <Bosmon> Justin_o hi

[13:49:24 CDT(-0500)] <Justin_o> Bosmon: would you like to join

[13:49:31 CDT(-0500)] <Bosmon> Justin_o - would be cool if possible

[13:49:36 CDT(-0500)] <Justin_o> Bosmon: sure

[14:03:06 CDT(-0500)] <mbrenn_iskme> Hi all, I've started a page in the fluid wiki for ISKME's dev plans for PGA tools

[14:03:22 CDT(-0500)] <mbrenn_iskme> you can find it here: http://wiki.fluidproject.org/display/fluid/ISKME+Enhance+Bar

[14:05:57 CDT(-0500)] <colinclark> hey mbrenn_iskme, that's great

[14:06:06 CDT(-0500)] <colinclark> I tweaked a bit of the markup so your links show up properly

[14:06:58 CDT(-0500)] <colinclark> it looks like there's a lot of connection with the work michelled and her team have been working on

[14:07:08 CDT(-0500)] <colinclark> do you think you could use the same designs and code?

[14:07:37 CDT(-0500)] <colinclark> They've got the text enlargement, contrast, simplify, text to speech features in place

[14:08:14 CDT(-0500)] <colinclark> oh, and the "more text", which sounds a lot like your "Descriptions"

[14:09:02 CDT(-0500)] <colinclark> Have you thought at all about how you will communicate the capabilities and features of a particular piece of content? For example, how you'd tag the content so you knew if a section of it was a "hazard"

[14:29:59 CDT(-0500)] <mbrenn_iskme> No we haven't dug too deeply into that right now, at the moment we are implementing all of these content transformations on open author resources, so we'll probably be creating some solution that utilizes the the Access_Hazard field in our metadata framework for items including Flashing, Simulation, and Sound

[14:30:58 CDT(-0500)] <mbrenn_iskme> this is part of the AY11 extension, and will be adopted by Schema.org soon

[14:34:15 CDT(-0500)] <mbrenn_iskme> colinclark: also, we have implemented ARIA long desc on images, and have thought about a way to utilize these descriptions for display on the page, but not sure if that's a good way to go

[14:34:51 CDT(-0500)] <colinclark> right, I was going to suggest that we look at this. anastasiac, Jutta, and I are part of that working group

[14:35:27 CDT(-0500)] <colinclark> anastasiac actually wrote an early draft of that metadata, and has been working on AccessForAll, so she's a good person to chat with if you have any questions

[14:35:47 CDT(-0500)] <mbrenn_iskme> thanks, that's great to know!

[14:35:58 CDT(-0500)] <colinclark> mbrenn_iskme: As for image descriptions, we've talked about a few different approaches, which michelled can probably fill you in on once she's out of her meeting

[14:36:18 CDT(-0500)] <mbrenn_iskme> great, I'll check in with her

[14:36:30 CDT(-0500)] <colinclark> longdesc is one option. We've also looked at using the new HTML5 "details" tag to provide an extended layer of textual information

[14:36:42 CDT(-0500)] <colinclark> I think probably we'll want to use both approaches

[15:18:26 CDT(-0500)] <Justin_o> fluid-everyone: notes from the build scripts meeting http://wiki.fluidproject.org/display/fluid/Grunt+based+build+scripts+planning

[15:18:54 CDT(-0500)] <michelled> thx Justin_o

[15:26:37 CDT(-0500)] <Bosmon> Thanks, Justin_o