fluid-work IRC Logs-2013-07-31

[09:03:24 CDT(-0500)] <yzen> Bosmon: ping

[09:21:52 CDT(-0500)] <Justin_o> yzen, cindyli: so just remembered after looking at the code again, that auxiliary builder is a primary builder.. it uses it as a grade.. i wonder if this is correct.. what do you think?

[09:22:35 CDT(-0500)] <yzen> Justin_o: well my understanding was that the primary and aux should be put on the builder

[09:22:37 CDT(-0500)] <cindyli> Justin_o: that's how we use primary schema from in the aux builder

[09:23:07 CDT(-0500)] <cindyli> yes, they should be moved to the builder

[09:23:20 CDT(-0500)] <Justin_o> yzen, cindyli: okay.. i'm going to try to keep them completely separate and just have the builder combine the two

[09:23:41 CDT(-0500)] <cindyli> sounds good

[09:48:51 CDT(-0500)] <michelled> yzen, Justin_o: did you see Chris's email about the Infusion version?

[09:49:35 CDT(-0500)] <Justin_o> michelled: yes.. i wasn't really sure what to recommend there.. i was waiting to talk to you guys more about what they are wanting to do.. my initial reaction would be to suggest they use master

[09:49:52 CDT(-0500)] <michelled> I don't think we should recommend that

[09:50:05 CDT(-0500)] <michelled> it would mean learning a way of doing things and then changing it immediately

[09:50:15 CDT(-0500)] <michelled> how long until we can get the schema work in?

[09:50:22 CDT(-0500)] <Justin_o> michelled: are they just making the panels and enactors?

[09:50:26 CDT(-0500)] <michelled> can it get in as is with JIRAs for the remaining work?

[09:51:06 CDT(-0500)] <michelled> Justin_o: they'll be making the entire UI, but good point

[09:51:15 CDT(-0500)] <Justin_o> michelled: we need to talk to Bosmon about one of his comments on the pull request.. unfortunately it's related to the big issue of not being able to supply the auxiliary grade as an option to the builder

[09:51:47 CDT(-0500)] <michelled> Justin_o: what does that mean in practice? can people use the tool as is?

[09:52:01 CDT(-0500)] <Justin_o> michelled: also we are still supporting the non schema version so they can start with that and adapt as needed

[09:52:39 CDT(-0500)] <michelled> Justin_o: I'd still rather show people the way we expect them to work rather than make them change in a week

[09:52:41 CDT(-0500)] <Justin_o> michelled: yes.. they can, but they either have to supply the auxiliarySchema directly into the options or they need to create a new grade as anastasia did in her branch

[09:53:00 CDT(-0500)] <Justin_o> michelled: actually it shouldn't really be changing.. they will also probably want to support both

[09:53:09 CDT(-0500)] <michelled> Justin_o: why would the discovery tool break with the new branch if the old API is still available

[09:53:12 CDT(-0500)] <michelled> ?

[09:53:34 CDT(-0500)] <Justin_o> michelled: i'm not entirely sure of that.. i was hoping to ask anastasia if she ran into anything

[09:53:39 CDT(-0500)] <Justin_o> we might have missed something

[09:53:54 CDT(-0500)] <michelled> hmmm… well, anastasiac is off today.

[09:53:59 CDT(-0500)] <Justin_o> michelled: yah

[09:54:05 CDT(-0500)] <michelled> I wonder if we should try to update to the branch and see what's up

[09:54:18 CDT(-0500)] <Justin_o> michelled: yah.. that would be a good test

[09:54:30 CDT(-0500)] <michelled> I suppose we can reply to the mail and say that enactors and panels work remains the same

[09:54:37 CDT(-0500)] <michelled> so they have someplace to start

[09:55:07 CDT(-0500)] <Justin_o> michelled: also was going to say, the building of enactors and panels should be the same regardless of using the schema or not.. the schema is just really an alternative way of configuring UIO as a whole

[09:55:16 CDT(-0500)] <Justin_o> yes

[10:19:18 CDT(-0500)] <Bosmon7> Hi Justin_o and all

[10:19:23 CDT(-0500)] <Bosmon7> How is the schema work standing?

[10:20:51 CDT(-0500)] <Justin_o> Bosmon7: hello.. actually cindyli, yzen and myself were hoping to talk to you about that

[10:21:04 CDT(-0500)] <Justin_o> Bosmon7: so we're wondering about the dynamic grade

[10:21:21 CDT(-0500)] <Bosmon7> Yes

[10:21:27 CDT(-0500)] <Bosmon7> Have you written some comments yet? : P

[10:21:39 CDT(-0500)] <Bosmon7> Or is the operation of the "primaryBuilder" still gloriously unexplained?

[10:22:07 CDT(-0500)] <Justin_o> Bosmon7: i don't think anyone has written any comments yet

[10:22:26 CDT(-0500)] <Justin_o> Bosmon7: can yo explain what this means "This use of a static grade name with dynamic material is dangerous and will prevent multiple uses of the builder. In general we need to refactor this workflow completely to remove the "dynamic invoker becomes gradename" which is currently responsible for the FLUID-5105 circularity."

[10:22:30 CDT(-0500)] <Justin_o> it's your comment from the pull request

[10:22:32 CDT(-0500)] <Bosmon7> Yes

[10:22:54 CDT(-0500)] <Bosmon7> You can't issue new defaults for the same component repeatedly, when you are trying to build a different component

[10:22:59 CDT(-0500)] <Justin_o> Bosmon7: specifically i'm not why this would prevent it from being used multiple times

[10:23:10 CDT(-0500)] <Bosmon7> Justin_o - because its defaults are constantly changing

[10:23:47 CDT(-0500)] <Justin_o> Bosmon7: ah i see

[10:24:05 CDT(-0500)] <Justin_o> now i get it.. because the grade name for "fluid.uiOptions.schemas.suppliedPrimary" is constant

[10:24:13 CDT(-0500)] <Bosmon7> that's right

[10:24:25 CDT(-0500)] <Bosmon7> It is a kind of "bad style verging on implementation risk"

[10:25:29 CDT(-0500)] <Justin_o> Bosmon7: okay.. so we can take care of that i think.. are we still able to use the dynamic grade though.. will you be able to address the issue we had with that.. or will it also need to be changed?

[10:29:03 CDT(-0500)] <Bosmon7> Justin_o - I think it would be better for you to change your strategy

[10:29:10 CDT(-0500)] <Bosmon7> Since I think there are design issues with the component as it stands

[10:31:18 CDT(-0500)] <Justin_o> Bosmon7: one of the things that yzen brought up was that it currently supports the case where the schema grade just needs to be defined for it to be used… is this something we still need to support.. in some of our brainstorming of alternative strategies, it required the integrator to supply a primarySchema, either through gradeName or directly to the builder

[10:31:27 CDT(-0500)] <Justin_o> yzen: maybe you can explain that better

[10:33:17 CDT(-0500)] <yzen> Justin_o: ya you got it pretty much correctly, there was a use case of just having aux schema and drawing primary from all registered floating defaults

[10:42:39 CDT(-0500)] <Bosmon7> Justin_o - sure, that's an important use case

[10:42:54 CDT(-0500)] <Bosmon7> But as I suggested in some of my other comments, that workflow could be improved too

[10:43:06 CDT(-0500)] <Bosmon7> In particular, by removing the auxSchema as a direct argument of the "primaryBuilder"

[10:43:27 CDT(-0500)] <Bosmon7> Could you elaborate on what you meant by "where the schema grade just needs to be defined for it to be used"?

[10:47:24 CDT(-0500)] <Justin_o> Bosmon, Bosmon7, Bosmon8: not sure which one you are now anyways.. i'm in the process of removing the auxiliary references from primary builder.. just need to add another test case and i'll have that committed

[10:48:07 CDT(-0500)] <Bosmon8> Justin_o - cool

[10:48:15 CDT(-0500)] <Bosmon8> Sorry, my "free hours" ran out in the airport here

[10:48:46 CDT(-0500)] <Justin_o> Bosmon8: no problem.. how did you come back online?

[10:49:01 CDT(-0500)] <Bosmon8> I PAID : P

[10:49:44 CDT(-0500)] <Justin_o> Bosmon8: anyways, for the statement.. i just mean that it uses the index look up to find the grades, you don't have to pass them to the component or anything.. so in this fashion the could just include the starter schema grades in the head, and they could be used by the primaryBuilder without any other integrator interaction

[10:49:50 CDT(-0500)] <Justin_o> yzen: is that correct?

[10:51:13 CDT(-0500)] <Bosmon8> Justin_o - yes, that is one of the intended integration mechanisms

[10:51:21 CDT(-0500)] <Bosmon8> After all, we should use the index for something : P

[10:51:24 CDT(-0500)] <yzen> Justin_o: yes

[10:51:27 CDT(-0500)] <yzen> lol

[10:53:53 CDT(-0500)] <Justin_o> Bosmon8, yzen: okay so we will support it.. so i guess the question is do we need to remove the dynamic grade as it is now..

[10:55:01 CDT(-0500)] <yzen> Justin_o: ok so would you be able to describe how we accumulate indexed primary schema grades without using the dynamic grade?

[11:00:02 CDT(-0500)] <Justin_o> yzen: i'm not sure how that would be possible.

[11:01:10 CDT(-0500)] <Bosmon8> You would just accumulate them somewhere else

[11:01:13 CDT(-0500)] <Bosmon8> Onto a subcomponent

[11:05:12 CDT(-0500)] <Justin_o> Bosmon8: how would that work with auxiliaryBuilder.. it will need to use the results of that.. currently these things are expanders

[11:05:53 CDT(-0500)] <Bosmon8> Justin_o - it would be far easier to use the results if they were a subcomponent

[11:05:58 CDT(-0500)] <Bosmon8> it would just be there, being a subcomponent : P

[11:06:19 CDT(-0500)] <Bosmon8> Remember that the ginger world was always much happier with that case, and it will make your dependency structure more clear

[11:06:48 CDT(-0500)] <Bosmon8> I am just worried that if we were to enable this "all in one component" case, we'd find ourselves in an endless regress of trying to use the dynamic grades system for more and more ambitious things

[11:06:49 CDT(-0500)] <Justin_o> Bosmon8: so you mean the expander in the options will wait till after the subcomponent has been initialized?

[11:07:00 CDT(-0500)] <Bosmon8> And really the workflow is fundamentally ambiguous as you have written it

[11:07:15 CDT(-0500)] <Bosmon8> "In your mind" you are clear about the ordering you want, but there is no clear way to inform the framework of it

[11:07:29 CDT(-0500)] <Bosmon8> Justin_o - yes, it was always possible even in the very old world for a component to have a dependency on its subcomponent

[11:07:46 CDT(-0500)] <Justin_o> Bosmon8: great.. okay we could do that then

[11:08:13 CDT(-0500)] <Justin_o> so basically shift the schema generation down to a subcomponent

[11:08:40 CDT(-0500)] <Justin_o> yzen: or maybe we just make the primaryBuilder a subcomponent of builder

[11:08:46 CDT(-0500)] <Justin_o> what do you think about that?

[11:08:59 CDT(-0500)] <yzen> Justin_o: i was thinking about that yes

[11:09:15 CDT(-0500)] <yzen> it would certainly help us with the dynamic grade problem

[11:09:29 CDT(-0500)] <Justin_o> yzen: okay.. i'm just about ready to get my current changes in, then can start looking at that

[11:09:41 CDT(-0500)] <yzen> cool

[11:14:31 CDT(-0500)] <Bosmon8> Don't forget the ***COMMENTS***!!!!!!!!!!!!!!!!!!!

[11:20:58 CDT(-0500)] <Justin_o> yzen: i'll fix the bug, can you add the comments to the primary builder?

[11:35:27 CDT(-0500)] <yzen> Justin_o: will do

[11:35:37 CDT(-0500)] <Justin_o> yzen: thanks.. i'll let you know when it's in

[11:53:11 CDT(-0500)] <Justin_o> yzen: the changes are all in now

[11:53:37 CDT(-0500)] <yzen> Justin_o: ok ill add comments

[11:54:47 CDT(-0500)] <Justin_o> yzen: thanks

[11:55:14 CDT(-0500)] <Justin_o> I think that's the last thing on Bosmon's current list

[13:11:54 CDT(-0500)] <system64> Hello michelled

[13:15:01 CDT(-0500)] <michelled> hi system64

[13:15:03 CDT(-0500)] <michelled> how's it going?

[13:15:56 CDT(-0500)] <mbrenn_iskme> hi jessm, I am looking through the TOC designs in the design deliverable, was wondering if the TOC widget is meant to show content sections in just the article div, or if it will allow users to selectively navigate to/show content in hidden divs as well?

[13:17:46 CDT(-0500)] <system64> michelled: Back to college today, so been busy travelling and now unpacking.

[13:18:03 CDT(-0500)] <system64> michelled: Have you filled the midsem evaluations?

[13:21:09 CDT(-0500)] <jessm> mbrenn_iskme: what do you mean hidden divs?

[13:21:21 CDT(-0500)] <jessm> mbrenn_iskme: divs hidden by the simplification?

[13:21:34 CDT(-0500)] <mbrenn_iskme> yes, I'm sorry, should have been more specific

[13:23:15 CDT(-0500)] <jessm> mbrenn_iskme: my understanding is that it's just the article

[13:23:32 CDT(-0500)] <jessm> mbrenn_iskme: i'm trying to think of a use case for a TOC that does differently

[13:23:44 CDT(-0500)] <jessm> vjoanna: or danaayotte: thoughts? ^

[13:24:08 CDT(-0500)] <michelled> system64: not yet, but I will

[13:24:13 CDT(-0500)] <michelled> have you filled your's in?

[13:24:59 CDT(-0500)] <system64> michelled: Yes, I have

[13:26:26 CDT(-0500)] <vjoanna> mbrenn_iskme, jessm: yes, the TOC is intended to have two views - one showing the hierarchy of the current page and the other the entire site-map

[13:26:51 CDT(-0500)] <vjoanna> so navigation hidden by simplify would be available through the TOC

[13:27:26 CDT(-0500)] <jessm> ah, I sit corrected

[13:28:44 CDT(-0500)] <vjoanna> I'm not sure though if we would have both views available for the demo..

[13:29:15 CDT(-0500)] <mbrenn_iskme> vjoanna: so for example using the CK-12 electron example, if the user toggled over to full site map, then the user would see a TOC like layout that included the "add to flexbook" "make a copy" links in the aside div?

[13:33:20 CDT(-0500)] <vjoanna> mbrenn_iskme: yes, something like that - we haven't quite determined how this view of the TOC would be generated

[13:34:55 CDT(-0500)] <mbrenn_iskme> vjoanna: and has there been design thought around what the user would see if they clicked on an item in the full site map TOC?

[13:35:26 CDT(-0500)] <mbrenn_iskme> would the user see this content displayed somewhere on their simplified resource page?

[13:42:58 CDT(-0500)] <vjoanna> mbrenn_iskme: i think our thinking is that the user would be taken to the page (that would also be simplified) they clicked on the site map - but this could be problematic if that page can not be simplified..

[13:47:08 CDT(-0500)] <mbrenn_iskme> vjoanna: we were thinking that it might make sense to use the TOC to make the simplification feature interactive, for example, allow the user to choose to selectively "add back in" content that has been hidden, and then easily hide it again

[13:49:49 CDT(-0500)] <colinclark> can you describe how that might work, mbrenn_iskme?

[13:54:56 CDT(-0500)] <mbrenn_iskme> sure colinclark: the user could navigate to a section in the TOC, perhaps it is titled "hidden content", or perhaps it is labeled more semantically like "side panel navigation links"

[13:56:55 CDT(-0500)] <mbrenn_iskme> the user might then be able to click a drop down arrow and see the side panel navigation links are now displayed on their simplified page, clicking the drop down arrow again would hide it, or alternatively clicking an "x" next to the side panel navigation link box

[13:58:01 CDT(-0500)] <mbrenn_iskme> we have been thinking through ways to allow users to hide pieces in the article div, and then access them again if they so choose

[13:59:43 CDT(-0500)] <mbrenn_iskme> so we thought this might make sense for content contained in other divs, already hidden by the simplify preset

[14:00:03 CDT(-0500)] <colinclark> Interesting idea

[14:00:33 CDT(-0500)] <colinclark> Do you think there's a risk that the reason someone chose to simplify the page was to remove the complexity of extra controls, widgets and distractions? Would this be too much for those users?

[14:05:05 CDT(-0500)] <vjoanna> mbrenn_skme: that could be useful, but i'm not sure how it would work with this form of simplification. since the article right now is taken out of the default layout into a linearized presentation, re-adding navigation might reintroduce a more complicated layout?

[14:05:14 CDT(-0500)] <mbrenn_iskme> colinclark: yes, we have thought about that, which is why we would want to make this interaction as simple as possible, and also make it optional for users, which is why I like the idea of toggling between "full page map" and "current page", so the user knows they can easily find everything on the full page, but can stick to the already simplified layout if they want to

[14:05:25 CDT(-0500)] <mbrenn_iskme> or sorry, that was vjoanna:

[14:07:36 CDT(-0500)] <mbrenn_iskme> vjoanna: are there ways to add these in a simplified way? Like adding them to the bottom of the page?

[14:11:16 CDT(-0500)] <mbrenn_iskme> perhaps this hide/unhide interaction only makes sense if a user has manually chosen to pieces in the article div?

[14:22:59 CDT(-0500)] <vjoanna> mbrenn_iskme: we were exploring some other options for simplify in these mockups that kept all the page navigation: http://wiki.fluidproject.org/display/fluid/%28Floe%29+UI+Options+Design+Walkthrough%2C+C.1#%28Floe%29UIOptionsDesignWalkthrough%2CC.1-simplify and http://wiki.fluidproject.org/display/fluid/%28Floe%29+Content+simplification+conceptualization

[14:27:49 CDT(-0500)] <vjoanna> and since they represent different user needs, they seem like they should be separate implementations of simplify?

[14:36:12 CDT(-0500)] <mbrenn_iskme> I think we were thinking something much more simple, that allows users to interact with the page directly and use the TOC to show them what's hidden, and to allow them to tweak the preset to their specific preferences in context, but I think it's important to give the user a "base preset" to work from, and I think the simplify preset does that well

[14:47:26 CDT(-0500)] <danaayotte> mbrenn_iskme: just to clarify, are you imagining 3 tabs then - current page, full page and full website? and the user can move items from full page (all page content) to current page (simplified content) while maintaining some kind of simplified layout?

[14:49:39 CDT(-0500)] <mbrenn_iskme> danaayotte: ahh, I think i was misunderstanding what was meant by full site, we are talking about providing a TOC for the entire site? Not just for the "full page" in the current mock ups?

[14:50:09 CDT(-0500)] <danaayotte> I think that's right. vjoanna?

[14:51:33 CDT(-0500)] <mbrenn_iskme> danaayotte: The problem we are thinking about has to do with the fact that Open Author resources in our system contain informational sections which are not part of the main article div, but that users might want to navigate to without seeing the entire complex layout

[14:54:23 CDT(-0500)] <mbrenn_iskme> this might apply to other types of digital content providers as well

[14:54:41 CDT(-0500)] <colinclark> Can you give us some concrete examples of this, mbrenn_iskme, just so we are all on the same page?

[14:56:59 CDT(-0500)] <mbrenn_iskme> for example, this resource: http://www.oercommons.org/authoring/224-art-science-and-writing-nature-s-treasure-chest/view

[14:57:24 CDT(-0500)] <mbrenn_iskme> has summary, learning goals, and licensing info in the right hand column

[14:59:16 CDT(-0500)] <mbrenn_iskme> on the other hand, we might also want to allow the user to "hide" the picture in this resource, because it is not informational

[15:25:32 CDT(-0500)] <vjoanna> mbrenn_iskme: what if summary, learning goals, and licensing were part of the article and on 'simplify' summary and learning goals are on top followed the resource and the licensing info. I guess the goal with this form of simplification is to create a read only view for the user by minimizing interactables and distractions. so in order to get any of the more interactive features of a site - the user would turn simplify off?

[15:48:30 CDT(-0500)] <mbrenn_iskme> vjoanna: thank you for clarifying that thinking, I think what we have been thinking about a few different things as far as customization and extensibility go, and have been using the Simplify preset as a concrete example to ground our thinking: 1. We can't predict how every user will like to use "simplify." 1a. How can we build in simple ways for the user to adjust how their Simplify preset functions, in context in the momen