fluid-work IRC Logs-2013-07-29

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

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

[08:08:24 CDT(-0500)] <Justin_o> Bosmon2: i see you are writing up some comments for the FLUID-4907 pull request.. cindyli and yzen ran into some issues last week related to supplying grades as options. I'm not sure if this is detailed anywhere, and perhaps yzen could provide more details.

[08:09:15 CDT(-0500)] <Bosmon7> Hi Justin_o

[08:09:40 CDT(-0500)] <Bosmon7> I am still in a conference session now and can only supply high-level comments for now, but hopefully this is something to deal with in the meantime

[08:09:47 CDT(-0500)] <Bosmon7> From what I can see, the core logic in Builder.js looks much better

[08:10:05 CDT(-0500)] <Bosmon7> I think my most serious comments relates to the treatment of array-valued I18N strings, which should not appear

[08:11:01 CDT(-0500)] <yzen> system64: hi

[08:12:02 CDT(-0500)] <yzen> Bosmon7, Justin_o yes. Very odd, I think cindyli was trying to make a test case not sure if she managed to make a failing one

[08:12:04 CDT(-0500)] <Justin_o> Bosmon7: thanks for the feedback.. we'll get started on that first

[08:13:30 CDT(-0500)] <heidiv> Justin_o i'll update those two pull req - thanks for the feedback!

[08:13:36 CDT(-0500)] <system64> yzen: Any idea how can I bind DOM events to my AJAX content in my renderer component?

[08:14:22 CDT(-0500)] <Justin_o> heidiv: np, thanks

[08:14:35 CDT(-0500)] <Bosmon7> system64 - in general you will do event binding using the jQuery decorator

[08:14:53 CDT(-0500)] <yzen> system64: I believe you can achieve that using decorators

[08:20:03 CDT(-0500)] <system64> Thanks Bosmon7, yzen I will look into decorators

[08:22:00 CDT(-0500)] <Bosmon7> system64 - another possibility is to attach suitable listeners to the component's "afterRender" event

[08:22:56 CDT(-0500)] <Bosmon7> Using the new "this-ist" record structure, with members "this" indexing into the DOM binder, and "method" referring to the required jQuery event type

[08:24:02 CDT(-0500)] <system64> Bosmon7: I will have to refresh the view? to trigger afterRender event

[08:27:27 CDT(-0500)] <Bosmon7> system64 - that's right

[08:27:41 CDT(-0500)] <Bosmon7> In a standard rendererComponent, a call to refreshView then triggers afterRender

[08:29:09 CDT(-0500)] <system64> Right now when I do that.refreshView() after appending DOM, it behaves strangely and clears the existing DOM

[08:32:51 CDT(-0500)] <system64> I'm changing DOM whenever a new user joins video conference. So if I add listeners in afterRender won't it lead to multiple event listeners?

[08:34:57 CDT(-0500)] <Bosmon7> system64 - yes, the current renderer expects to completely clear the existing DOM

[08:35:20 CDT(-0500)] <Bosmon7> If the DOM material is cleared, for which listeners are attached, jQuery will automatically ensure to remove the listeners

[08:35:46 CDT(-0500)] <Bosmon7> But you may find that the current renderer behaviour is inappropriate for you, of clearing the DOM

[08:35:57 CDT(-0500)] <Bosmon7> Unfortunately it has quite a number of limitations that we are working to remove

[08:36:26 CDT(-0500)] <system64> Bosmon7: I don't want the whole DOM of the component container to be cleared

[08:36:38 CDT(-0500)] <Bosmon7> You may well find it easier to simply clone bits of "template" DOM by hand, for example, if you are trying to maintain a dynamic list of elements

[08:36:52 CDT(-0500)] <Bosmon7> You can see this strategy inside our Uploader's "FileQueueView.js" component

[08:37:03 CDT(-0500)] <Bosmon7> It is one of the applications for which we decided the current renderer is inappropriate

[08:37:10 CDT(-0500)] <system64> Bosmon7: I just want to tell jQuery that new elements have been added, update listeners

[08:37:28 CDT(-0500)] <Bosmon7> system64 - if you are just adding new elements of the same type, you may prefer to use an event delegation model

[08:37:39 CDT(-0500)] <Bosmon7> jQuery already supports this as part of its standard event binding API

[08:38:18 CDT(-0500)] <Bosmon7> confusingly, this has now been folded into part of the responsibility of the "on" API

[08:38:20 CDT(-0500)] <Bosmon7> http://api.jquery.com/on/

[08:38:27 CDT(-0500)] <system64> Bosmon7: I'm using jQuery on, and it doesn't seem to be working (sad)

[08:38:33 CDT(-0500)] <Bosmon7> It used to be handled by a dedicated API named "delegate" which I found far more comprehensible

[08:39:06 CDT(-0500)] <Bosmon7> system64 - you are using the variant of "on" which takes 3 arguments?>

[08:40:01 CDT(-0500)] <system64> Bosmon7: I'm doing $('.foo').on('click', Function);

[08:40:10 CDT(-0500)] <system64> only 2 arguments

[08:40:48 CDT(-0500)] <Bosmon7> system64 - in that case it will not delegate

[08:41:29 CDT(-0500)] <Bosmon7> You should read the documentation section on that page which begins "another advantage of delegated events is their potential for much lower overhead"

[08:49:12 CDT(-0500)] <system64> Gotcha! I didn't read jQuery page correctly. I thought it had something to do with Fluid

[08:53:14 CDT(-0500)] <Bosmon7> We try to defer to the jQuery library whenever possible, if it takes care of a particular issue completely

[09:31:04 CDT(-0500)] <heidiv> Justin_o fyi doing gpii-136 and 140

[09:31:28 CDT(-0500)] <Justin_o> heidiv: great, thanks heidiv

[09:36:31 CDT(-0500)] <Justin_o> heidiv: FLUID-5101 has been merged

[09:36:51 CDT(-0500)] <heidiv> Justin_o tanks

[09:44:26 CDT(-0500)] <Justin_o> heidiv: GPII-142 is also in

[09:44:34 CDT(-0500)] <heidiv> thanks Justin_o

[10:01:22 CDT(-0500)] <Justin_o> Bosmon7: we're chatting here about whether or not we should keep supporting the non-schema api for UIO

[10:01:37 CDT(-0500)] <Justin_o> Bosmon7: did you have an opinion about that?

[10:04:35 CDT(-0500)] <Bosmon7> Justin_o - of course we will keep supporting it!

[10:04:54 CDT(-0500)] <Bosmon7> After all, how could the schema-based system work, except through the "non-schema API".....

[10:05:14 CDT(-0500)] <Justin_o> Bosmon7: i guess we mean specifically with the starter grades

[10:05:16 CDT(-0500)] <Bosmon7> Well, of course, we could neglect it, with the result that it would become confusing and unusable

[10:05:38 CDT(-0500)] <Bosmon7> Justin_o - the idea was always that the output of the builder when run on the "starter schemas" would be identical to the "starter grades" that we already have

[10:05:47 CDT(-0500)] <Bosmon7> It is one of the important ways that we would validate the action of the builder

[10:07:13 CDT(-0500)] <Justin_o> Bosmon7: the configuration is a bit different.. for example with model paths

[10:07:35 CDT(-0500)] <Bosmon7> Justin_o - we should ensure that it is consistent

[10:07:35 CDT(-0500)] <Justin_o> Bosmon7: i suppose we could rewrite our starter grades to be the same though

[10:10:17 CDT(-0500)] <Justin_o> Bosmon7: there are also some other differences with the way something like classnameMap is used.. since it is shared in the starter grades, but these values are passed in directly when using the schema

[10:11:57 CDT(-0500)] <Bosmon7> Justin_o - we could probably arrange for it to be shared when using the schema too

[10:12:07 CDT(-0500)] <Bosmon7> Especially since it starts life as a shared reference to the "primary block"

[10:12:23 CDT(-0500)] <Bosmon7> But that is probably not a really important inconsistency

[10:13:13 CDT(-0500)] <Justin_o> Bosmon7: i guess it depends on if you expect integrators to be mixing them together or not?

[10:13:35 CDT(-0500)] <Bosmon7> Justin_o - I expect they will not, one integrator will either use grades or schemas, but very likely not both

[10:13:44 CDT(-0500)] <Bosmon7> But we should make sure that the inconsistencies between them are not too strong

[10:15:58 CDT(-0500)] <Bosmon7> It probably doesn't require any particular action from us for now

[10:16:09 CDT(-0500)] <Justin_o> Bosmon7: okay.. so the other thing was to break out all the old starter grades into a file, and the new starter grades into a new file..

[10:16:30 CDT(-0500)] <Bosmon7> But we should supply guides to both the grades and the schema in our docs

[10:16:36 CDT(-0500)] <Justin_o> Bosmon7: so something like starterSchema.js for the new ones, but we weren't sure what to call the old ones

[10:17:06 CDT(-0500)] <Bosmon7> Justin_o - which ones are the old ones?

[10:17:21 CDT(-0500)] <Bosmon7> Surely everything that was "old" exists in some starter schema?

[10:18:35 CDT(-0500)] <Justin_o> Bosmon7: it's to group things like the starter panels, starter enactors, starter template loader and etc.. all the starter grades that we needed pre schema

[10:19:19 CDT(-0500)] <Bosmon7> Justin_o - oh, I see, the concrete equivalents of the "consolidated grades" or whatever we are calling them now

[10:20:04 CDT(-0500)] <Bosmon7> "starterCompounds.js" or something similar

[10:20:11 CDT(-0500)] <Bosmon7> Some other thing beginning with "C" : P

[10:20:56 CDT(-0500)] <Bosmon7> or "Co"

[10:22:50 CDT(-0500)] <Justin_o> Bosmon7: yes.. like these for example https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/Panels.js#L323-L464

[10:23:43 CDT(-0500)] <Justin_o> yzen, michelled, anastasiac: did you have anything to add; questions, comments, suggestions about this

[10:23:59 CDT(-0500)] <Bosmon7> Justin_o - we should at least rewrite that grade so it is a bit more "consolidated"

[10:24:06 CDT(-0500)] <Bosmon7> It still contains quite a bit of duplicated material

[10:24:34 CDT(-0500)] <Bosmon7> Well ok, perhaps it is just the "createOnEvent" ....

[10:24:48 CDT(-0500)] <Bosmon7> But yes, we should continue to maintain this grade

[10:25:57 CDT(-0500)] <anastasiac> Bosmon7, what would be the use case for someone to choose to use the non-schema method rather than the schema method (for implementing the starter set)?

[10:27:54 CDT(-0500)] <Bosmon7> anastasiac - they may discover the need to express some kind of IoC configuration which for some reason the schema builder is either temporarily or permanently incapable of expressing

[10:28:30 CDT(-0500)] <Bosmon7> Bear in mind that we intend that the aux schema to be IoC free, although we may in practice permit it

[10:28:52 CDT(-0500)] <anastasiac> ok, sounds reasonable Bosmon7. So as far as documentation goes, we're going to state that the schemas are the way to go, but if schemas don't cut it for your use case, you can use this other technique. Is that right?

[10:29:01 CDT(-0500)] <Bosmon7> anastasiac - yes

[10:41:21 CDT(-0500)] <jessm> Justin_o: when you have a moment sometime today I'd like to check in about how to get this page updated (process) http://wiki.fluidproject.org/display/fluid/List+of+Current+Fluid+Committers

[10:41:45 CDT(-0500)] <Justin_o> jessm: i can chat now

[10:42:33 CDT(-0500)] <jessm> Justin_o: ok, wrt designers, what do you think is the best process? we don't really use the repo as we used to and so our "committer" list is both outdated and not so meaningful

[10:43:21 CDT(-0500)] <Justin_o> jessm: how do you use the repo?

[10:43:40 CDT(-0500)] <jessm> Justin_o: we seem to float in and out of using it

[10:44:05 CDT(-0500)] <jessm> Justin_o: we've been putting a lot of our designs into the wiki again – esp. because C4A and PGA have wiki presense

[10:44:23 CDT(-0500)] <jessm> Justin_o: so we have two things going on:

[10:44:49 CDT(-0500)] <jessm> Justin_o: 1. we have some design committers who seem to fulfill the 6 mos of inactivity criteriun for emeritus status

[10:45:23 CDT(-0500)] <jessm> 2. we need jvass and danaayotte to be added to the list as active "committers" but that will mean not just a repo – i guess "committers" of designs

[10:47:06 CDT(-0500)] <Justin_o> jessm: right.. so i guess the first things is that the design process for commit access has never really been defined.. unless you just pick up the one we use for code commit access

[10:47:32 CDT(-0500)] <Justin_o> jessm: and i'm sort of wondering about what it means to you and the design team to have commit access

[10:47:50 CDT(-0500)] <Justin_o> especially if the repo isn't really being used at the moment

[10:48:00 CDT(-0500)] <jessm> Justin_o: yes, i think we've talked about this before in the past and used a lazy version of the commit access policy for designers

[10:48:31 CDT(-0500)] <jessm> Justin_o: so, do you think it uncontroversial to add jvass and danaayotte to the "committer" list and move erin and james to the emeritus list?

[10:48:42 CDT(-0500)] <jessm> i'll send an email to the list as well

[10:49:00 CDT(-0500)] <Justin_o> jessm: sure.. i think that shouldn't be an issue..

[10:49:10 CDT(-0500)] <jessm> ok, Justin_o thanks

[10:50:28 CDT(-0500)] <Justin_o> jessm: i'm sort of wondering though if this whole committers thing doesn't make sense for the design team, especially if we move to DAM. Perhaps what we want is access restrictions for a shared space, and then a list of people who can sign off on designs.. or something like that..

[10:51:19 CDT(-0500)] <jessm> hrm

[10:51:55 CDT(-0500)] <jessm> Justin_o: that sounds like a much larger conversation.

[10:52:25 CDT(-0500)] <Justin_o> jessm: you're probably right perhaps we can talk more about that along side the discussion of moving off of svn for the design repo

[10:52:27 CDT(-0500)] <jessm> Justin_o: when we've talked about that in the past we've quickly gotten into naming convention conversations as a way to "solve" the access restriction bit.

[10:52:38 CDT(-0500)] <jessm> yes, good, let's do that

[10:54:12 CDT(-0500)] <Justin_o> Bosmon7, yzen, michelled, anastasiac: so we can lump the schema starter grades into starterSchemas.js, any suggestion what to call the file that will hold the other starter grades?

[10:54:41 CDT(-0500)] <Justin_o> Bosmon7: i guess you were saying something like starterCompound.js

[10:55:38 CDT(-0500)] <Bosmon7> Or compounds, since I guess it contains multiple grades

[10:56:03 CDT(-0500)] <anastasiac> "starterGrades.js" ?

[10:56:09 CDT(-0500)] <anastasiac> "planB.js" ?

[10:58:50 CDT(-0500)] <anastasiac> Bosmon7, Justin_o, I'm not sure about the use of "compounds" - it's a completely new term that we've never used anywhere else

[10:59:03 CDT(-0500)] <anastasiac> we would have to explain somewhere what a "compound" is

[10:59:08 CDT(-0500)] <anastasiac> it also sounds a tad medical

[10:59:19 CDT(-0500)] <anastasiac> which is just odd

[11:03:23 CDT(-0500)] <Justin_o> Bosmon7, anastasiac: yes, there will be multiple grades in there.. but the starterSchemas.js file will have both the primarySchema starter grades and the starter auxiliary schema grade too..

[11:06:39 CDT(-0500)] <Justin_o> anastasiac. Bosmon7: i think the issue with "starterGrades.js" is that we will have other starter grades that won't go in here. Namely, the ones for the primary and auxiliary schemas. As funny as planB.js is, it's good in describing it as an alternative

[11:09:32 CDT(-0500)] <anastasiac> so maybe we should consider something else that's indicative of the fact that it's an alternative

[11:09:44 CDT(-0500)] <anastasiac> "starterPrefsAlternative"

[11:10:25 CDT(-0500)] <anastasiac> "starterSetOption2"

[11:11:33 CDT(-0500)] <anastasiac> "starterSetNonSchema"

[11:12:28 CDT(-0500)] <Justin_o> anastasiac, Bosmon7: i guess we can start by agreeing on what to call the other one.. is everyone happy with starterSchemas.js

[11:13:12 CDT(-0500)] <anastasiac> that sounds pretty reasonable to me, Justin_o, I think. You said it does have things in addition to the schemas? necessary grades, etc?

[11:14:54 CDT(-0500)] <Justin_o> anastasiac: it will have grades for primary and auxiliary schemas

[11:15:18 CDT(-0500)] <Justin_o> yzen: speaking of which does the primaryBuilder need the fluid.uiOptions.schemas grade internally

[11:15:20 CDT(-0500)] <anastasiac> yeah, I think "starterSchemas.js" seems fine. +1 for me

[11:15:27 CDT(-0500)] <Justin_o> anastasiac: thanks

[11:17:37 CDT(-0500)] <yzen> Justin_o: as far as i know it does not have it in defaults

[11:18:25 CDT(-0500)] <Justin_o> yzen: i just noticed that it is used in fluid.uiOptions.primaryBuilder.buildPrimary

[11:19:49 CDT(-0500)] <Justin_o> yzen: i had been worried about some odd dependency issues but i guess it shouldn't matter since theses functions won't get called till after the starterSchemas.js file has loaded

[11:20:35 CDT(-0500)] <yzen> Justin_o: right

[11:44:16 CDT(-0500)] <Justin_o> anastasiac: was talking with yzen.. i believe he's arguing that starterGrades.js isn't that confusing along side starterSchemas.js… which i assume is your view point as well, since you also suggested that.. so i guess for now i'll go with that and if need be we can change it later..

[11:44:50 CDT(-0500)] <anastasiac> Justin_o, yes, I think starterGrades would be fine, too

[11:45:15 CDT(-0500)] <Justin_o> okay, thanks everyone

[11:52:20 CDT(-0500)] <Justin_o> yzen: having a bit of a dependency issue.. so both the PrimaryBuilder and Auxiliary builder have a baseGrade that is also need by their accompanying starter grades

[11:53:34 CDT(-0500)] <yzen> which one is that ?

[11:53:39 CDT(-0500)] <Justin_o> the issue is where to put the base grade.. so we will end up having a case where we'll either always need the StarterSchemas.js file included or every time we have StarterSchemas.js, we will need both the PrimaryBuilder and AuxiliaryBuilder.js included first

[11:54:27 CDT(-0500)] <Justin_o> even in cases where we actually only really need one.. for example the PrimaryBuilder tests would also have to include the AuxiliaryBuilder

[11:58:40 CDT(-0500)] <yzen> i think builders will be always present togethe

[11:58:40 CDT(-0500)] <yzen> r

[11:59:19 CDT(-0500)] <Justin_o> okay… i'll keep it like that then

[12:00:35 CDT(-0500)] <yzen> Justin_o: i think that we can work with either schemas there but builder will always be comprised of the two builder grades

[12:01:20 CDT(-0500)] <Justin_o> yzen: yes.. it's really just an issue with the tests.. so i guess it's fine to have both there

[12:01:28 CDT(-0500)] <yzen> ya

[12:02:17 CDT(-0500)] <Justin_o> yzen: any luck with the grade merging issue.. i had to remove the starter auxiliary schema from the unit tests for them to pass.. since the expectation in the tests is that the starter grade won't be added

[12:02:27 CDT(-0500)] <yzen> still trying to build a test case

[12:04:07 CDT(-0500)] <Justin_o> yzen: okay.. i'll try to work around it in the demo for now

[12:04:54 CDT(-0500)] <Justin_o> yzen: is there a jira number for that issue?

[12:05:09 CDT(-0500)] <yzen> 5105

[12:05:13 CDT(-0500)] <Justin_o> yzen: thanks

[12:28:12 CDT(-0500)] <system64> Hello michelled!

[12:28:52 CDT(-0500)] <michelled> hi system64 - how's it going?

[12:29:56 CDT(-0500)] <system64> michelled: Alsmost done with the component, would be nice to have your feedback

[12:30:07 CDT(-0500)] <system64> *Almost

[12:30:26 CDT(-0500)] <michelled> great! I'll take a look today

[12:30:54 CDT(-0500)] <system64> Going to create a new repo for the main application and integrate this component into it

[12:31:11 CDT(-0500)] <michelled> sounds like a good plan

[12:31:43 CDT(-0500)] <system64> Thanks (smile)

[12:32:37 CDT(-0500)] <michelled> system64: don't forget to update your blog for the project

[12:33:55 CDT(-0500)] <system64> Sorry, will update it ASAP.

[12:35:09 CDT(-0500)] <michelled> system64: maybe put links to your project repo on your blog

[12:36:16 CDT(-0500)] <system64> Sure

[13:26:31 CDT(-0500)] <michelled> system64: is there a package.json file missing from your repo?

[13:27:47 CDT(-0500)] <system64> michelled: I'm using signalingServer as submodule

[13:28:37 CDT(-0500)] <system64> I will clone the same when I begin my main app

[13:29:15 CDT(-0500)] <michelled> system64: I tried to follow your instructions for running the demo but I'm getting an error

[13:30:18 CDT(-0500)] <system64> michelled: I think I missed the part to run 'git submodule update --init --recursive

[13:30:38 CDT(-0500)] <michelled> ah, I keep forgetting to do that when there are submodules!

[13:30:43 CDT(-0500)] <system64> Since I'm using infusion and other libraries as submodules

[13:31:34 CDT(-0500)] <system64> I stuck with submodules, since it will make it easier to test and update these libraries

[13:31:41 CDT(-0500)] <michelled> this is why Justin_o doesn't want to switch to using submodules in Infusion. I suppose it's just a habit that I need to form

[13:32:04 CDT(-0500)] <system64> (smile)

[13:38:31 CDT(-0500)] <michelled> system64: so it seems to be running now (smile) how do I use it/test it?

[13:39:28 CDT(-0500)] <system64> Just run a simple python server and open demos folder

[13:39:54 CDT(-0500)] <system64> Right now getUserMedia doesn't work on local filesystem

[13:40:05 CDT(-0500)] <michelled> yep, I've got a create room text box and a grey square below

[13:40:10 CDT(-0500)] <michelled> is that what you expect?

[13:40:43 CDT(-0500)] <system64> Yes, but it should ask you permissions for audio/video?

[13:41:39 CDT(-0500)] <michelled> ah, cool - no FF yet, is that right?

[13:41:58 CDT(-0500)] <system64> No, should work fine on FF too.

[13:42:09 CDT(-0500)] <michelled> hmmm… wonder what's up

[13:42:17 CDT(-0500)] <system64> let me check again

[13:42:26 CDT(-0500)] <system64> Usually testing on Chrome only

[13:43:01 CDT(-0500)] <michelled> ok, I restarted my browser and it's working in FF now

[13:47:12 CDT(-0500)] <michelled> system64: have you tried connecting to the server from another machine?

[13:47:50 CDT(-0500)] <system64> Not yet, but there is a server being hosted by simplewebrtc.com

[13:48:02 CDT(-0500)] <system64> I did try using that, it worked alright

[13:49:59 CDT(-0500)] <system64> But all clients behind NAT might not be able to connect. Its just 2-5% from IIRC.

[13:50:37 CDT(-0500)] <system64> To reach 100% audience we need TURN server, which means data transfer through server which is quite costly.

[13:51:27 CDT(-0500)] <michelled> system64: I imagine I'd still get asked if I want to share my audio/video - wouldn't I?

[13:52:40 CDT(-0500)] <system64> michelled: Yes, I'm asking for permissions on pageload right now

[13:52:41 CDT(-0500)] <michelled> system64: what I'm seeing is the page loaded, but no option to share my audio/video

[13:53:07 CDT(-0500)] <michelled> it works fine with the browser on the same machine as the server (smile)

[13:53:39 CDT(-0500)] <system64> Gotcha! My demo has path to socket.io hard coded!

[13:54:25 CDT(-0500)] <michelled> good catch (smile)

[13:55:04 CDT(-0500)] <michelled> system64: as you were building this component - did you find the existing Infusion documentation helpful?

[13:55:20 CDT(-0500)] <system64> I think I should host simple Node.js server on Heroku now

[13:55:54 CDT(-0500)] <system64> michelled: Documentation was lot to take in and very helpful.

[13:56:55 CDT(-0500)] <michelled> system64: cool. we are trying to improve it now and I think you have a very good perspective on what's there and what could be augmented or improved.

[13:57:27 CDT(-0500)] <michelled> when you get a chance, could you send a note to list with your thoughts on that? what was helpful, what you used, what you would have liked to see?

[13:58:07 CDT(-0500)] <system64> Sure, will do that.

[13:59:34 CDT(-0500)] <michelled> thanks!

[13:59:52 CDT(-0500)] <michelled> system64: right now your mute and fullscreen functionality are not keyboard accessible

[14:00:06 CDT(-0500)] <michelled> will you be looking at doing that next?

[14:00:48 CDT(-0500)] <system64> Yes, was about to discuss the same?

[14:01:55 CDT(-0500)] <system64> Right now these buttons are visible on hover, how can I make them accesible via keyboard?

[14:02:15 CDT(-0500)] <michelled> you can use the infusion keyboard accessibility plugin

[14:02:22 CDT(-0500)] <michelled> you should find some documentation on that

[14:02:38 CDT(-0500)] <Justin_o> yzen: i've done the file restructuring to add the StarterSchema.js and StarterGrades.js files. I've updated the demos and the tests.. For the main demo i used a work around to get it to load up. If you merge in my changes you might need to modify that part to continue your testing

[14:03:25 CDT(-0500)] <michelled> system64: you'll also want to add styling for focus so a sighted keyboard user will get the interaction they expect.

[14:03:40 CDT(-0500)] <yzen> Justin_o: cool thanks

[14:04:14 CDT(-0500)] <michelled> system64: you should also test this with a screen reader to see how well it communicates to non-sighted users

[14:04:34 CDT(-0500)] <michelled> system64: this is a good start - I'm looking forward to seeing your continued work

[14:05:28 CDT(-0500)] <system64> michelled: Thanks! How do you think the app can be made accesible to non-sighted users?

[14:06:04 CDT(-0500)] <system64> Actually Safari doesn't support WebRTC yet!

[14:06:23 CDT(-0500)] <system64> So which screen reader should I use on OSX?

[14:06:55 CDT(-0500)] <michelled> system64: ah, that's tough. do you have a windows or linux VM you can test with?

[14:08:13 CDT(-0500)] <system64> I'll try to set one up

[14:09:51 CDT(-0500)] <system64> I think a non-sighted user should only be interested in audio. Which shouldn't require any user interaction once the page is loaded.

[14:11:26 CDT(-0500)] <michelled> system64: I think they might also want to mute

[14:11:41 CDT(-0500)] <michelled> and also, a person with low vision might use a screen reader as well

[14:11:50 CDT(-0500)] <michelled> and they would almost certainly want full screen

[14:12:52 CDT(-0500)] <system64> True, I'll make the buttons keyboard accessible

[14:13:47 CDT(-0500)] <system64> I think that should solve most use cases

[15:06:28 CDT(-0500)] <yzen> Bosmon: hi