fluid-work IRC Logs-2013-07-03

[08:10:42 CDT(-0500)] <colinclark> hey Kasper__

[09:02:00 CDT(-0500)] <Justin_o> cindyli, yzen: okay.. so i'm getting confused again.. in the preferenceMap, the paths on the left are for the internal model of the component? or the external model that is shared?

[09:02:16 CDT(-0500)] <cindyli> Justin_o: internal i think

[09:02:16 CDT(-0500)] <Justin_o> http://pastie.org/private/joujbu7uhezkgwx1unama (look at the top one)

[09:02:26 CDT(-0500)] <Justin_o> so it should have been "model.value"

[09:02:28 CDT(-0500)] <Justin_o> ?

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

[09:03:32 CDT(-0500)] <Justin_o> cindyli: thanks

[09:03:49 CDT(-0500)] <cindyli> np

[09:12:54 CDT(-0500)] <clown_mtg> jhernandez, are you around?

[09:21:06 CDT(-0500)] <cindyli> Justin_o and yura, i've finished expanding our "@" references in the auxiliary schema. shall we chat about the next step for auxiliary builder in terms if or how the expanded auxiliary should be processed before being handed to uio builder

[09:21:34 CDT(-0500)] <Justin_o> cindyli: sure we can chat

[09:26:08 CDT(-0500)] <anastasiac> Justin_o, what's your thinking on adding the new low-contrast theme to UIO?

[09:26:39 CDT(-0500)] <Justin_o> anastasiac: you mean to the new demo or to the existing one

[09:26:56 CDT(-0500)] <anastasiac> I mean to UIO itself, as one of the colour-contrast options

[09:27:39 CDT(-0500)] <heidiv> anastasiac i'm thinking the theme might not be production-ready until we figure out how to deal with theme images…. font icon vs. creating pngs for button borders etc

[09:28:06 CDT(-0500)] <heidiv> we also have "more" "close" "gripper" images in there

[09:28:11 CDT(-0500)] <anastasiac> what do the existing themes do now?

[09:28:31 CDT(-0500)] <heidiv> existing themes have their own images

[09:30:10 CDT(-0500)] <heidiv> jhung how much work would it be to switch those few icons (maybe not button borders) to font icons? we could adapt/update the FSS button styling perhaps

[09:30:25 CDT(-0500)] <anastasiac> have we not converted the themes to icon fonts yet? Justin_o, michelled seems to remember a pull request?

[09:30:28 CDT(-0500)] <heidiv> relates to the email you just sent out

[09:30:44 CDT(-0500)] <heidiv> anastasiac not yet FSS - just UIO, inline edit, and uploader

[09:31:20 CDT(-0500)] <anastasiac> could we create the necessary images for the low-contrast theme? how much work would that be?

[09:31:42 CDT(-0500)] <jhung> heidiv: It may be complicated because the icon fonts need to go into before or after pseudo elements. So for the button borders this is really not ideal because we'll end up with 2 or 3 icons per button.

[09:31:53 CDT(-0500)] <jhung> I would prefer a non-icon approach if possible.

[09:32:06 CDT(-0500)] <heidiv> jhung - thoughts? i don't really like the idea of creating border images for our buttons. antiquated solution

[09:32:33 CDT(-0500)] <heidiv> and we want to convert images to font icons in FSS soon

[09:32:48 CDT(-0500)] <jhung> heidiv: yeah, but the solution is really ugly.

[09:32:57 CDT(-0500)] <heidiv> yep

[09:33:09 CDT(-0500)] <jhung> Per button we have at least 2 images, right? A start cap and the end cap.

[09:33:35 CDT(-0500)] <jhung> Icons need to be created for those. Then separate containers for those in the markup.

[09:33:46 CDT(-0500)] <heidiv> 4 images per button

[09:34:02 CDT(-0500)] <jhung> So at least 4 elements per button.

[09:34:05 CDT(-0500)] <heidiv> buttons-med-bg.png, buttons-med-cap.png, buttons-titlebar-bg.png, buttons-titlebar-cap.png

[09:34:22 CDT(-0500)] <heidiv> i don't think we should recreate these, but use css instead

[09:34:29 CDT(-0500)] <jhung> yeah agreed.

[09:34:36 CDT(-0500)] <heidiv> and font icons for more/close/gripper

[09:34:46 CDT(-0500)] <jhung> Maybe look into using better semantic markup?

[09:35:23 CDT(-0500)] <jhung> heidiv: those gripper icons (as well as some others) are a different problem.

[09:35:34 CDT(-0500)] <jhung> Icon fonts can't recreate their 3D effect.

[09:35:46 CDT(-0500)] <jhung> So we lose their original visual fidelity.

[09:36:02 CDT(-0500)] <heidiv> jhung we'd have to investigate what changes would be needed to update our theme buttons from images to css

[09:36:15 CDT(-0500)] <heidiv> markup vs just classes? i'm guessing both

[09:36:34 CDT(-0500)] <jhung> yeah probably both heidiv.

[09:36:36 CDT(-0500)] <heidiv> we could prob find a different looking gripper icon

[09:37:09 CDT(-0500)] <heidiv> tho it just looks like a bunch of dots to me

[09:37:24 CDT(-0500)] <jhung> heidiv: re: gripper - true, but i'm a bit wary of changing the visual appearance since we don't know how end users have implemented FSS.

[09:37:50 CDT(-0500)] <jhung> if you look at Coal theme's gripper, it looks inset.

[09:38:01 CDT(-0500)] <heidiv> jhung yeah, i guess i'm thinking new stuff for the new contrast theme only, for now?

[09:38:56 CDT(-0500)] <jhung> heidiv: that is one option heidiv.

[09:40:18 CDT(-0500)] <heidiv> jhung if we can find a simple solution for updating the button styles, would adding font icons to my new theme be straight fwd? for those 3 icons

[09:40:59 CDT(-0500)] <heidiv> a font file, and updating the classes to use icons vs images, right?

[09:44:04 CDT(-0500)] <jhung> heidiv: I would recommend that we try to use CSS and semantic markup solution for the buttons. Then for the other stuff (like gripper, close icon etc) we will use an icon font. This would be only for the new theme and would be predominantly flat in appearance (no 3d).

[09:44:24 CDT(-0500)] <jhung> does that summarize it?

[09:44:56 CDT(-0500)] <heidiv> jhung let's do it… could you make that font for me? Justin_o does jhung's summary look like a good approach? then we could add it to UIO proper.

[09:45:15 CDT(-0500)] <heidiv> and add some feedback to jhung's email to the list about updating fss themes

[09:50:44 CDT(-0500)] <Justin_o> heidiv, jhung: that sounds like a good approach..

[09:53:03 CDT(-0500)] <Justin_o> jhung, heidiv: will this make it incompatible with the other themes, in terms of markup

[09:53:32 CDT(-0500)] <heidiv> Justin_o just looking at the button's markup in our theme tests…. <a class="fl-button-right settings" href="#"><strong class="fl-button-inner">Settings</strong></a>

[09:54:00 CDT(-0500)] <heidiv> for bkwards compatibility, we can ignore "button-inner" class and just set fl-button-right to be a border. even tho that semantically doesn't make sense

[09:54:19 CDT(-0500)] <heidiv> then add another class for styling <button>

[09:54:23 CDT(-0500)] <heidiv> ?

[09:55:40 CDT(-0500)] <Justin_o> heidiv: hmm.. seems like things won't just work for anyone who has already implemented it though, if they would need to add another class for styling buttons

[09:59:09 CDT(-0500)] <heidiv> Justin_o styling fl-button-right would work for old implementations (using <a> as a button) and we would also support styling <button>

[10:00:30 CDT(-0500)] <Justin_o> heidiv: oh i see you mean you would add styling for buttons as well as anchors

[10:00:30 CDT(-0500)] <Justin_o> okay..

[10:00:39 CDT(-0500)] <Justin_o> so the only issue is the non-semantic name of the class

[10:00:52 CDT(-0500)] <heidiv> Justin_o right

[10:05:28 CDT(-0500)] <Justin_o> heidiv: i guess we could alias that with another name..

[10:05:31 CDT(-0500)] <Justin_o> something like

[10:05:46 CDT(-0500)] <Justin_o> fl-button-style, fl-button-right: {}

[10:06:32 CDT(-0500)] <jhung> Justin_o: yeah that's a good compromise.

[10:06:53 CDT(-0500)] <heidiv> yes that's what i was thinking

[10:07:03 CDT(-0500)] <heidiv> fl-button-right wouldn't be used, just for bkwards compat

[10:07:32 CDT(-0500)] <jhung> heidiv: So would that mean we'd still need to have border images?

[10:07:45 CDT(-0500)] <heidiv> jhung no

[10:07:53 CDT(-0500)] <jhung> heidiv: cool.

[10:08:01 CDT(-0500)] <jhung> heidiv: so let's go for it.

[10:08:37 CDT(-0500)] <jhung> heidiv: I'll start looking into converting some of those icons into fonts.

[10:22:50 CDT(-0500)] <michelled> cindyli, Justin_o: are we set on using 'enactors' or 'actions'? we seem to have a mixture in the repo right now

[10:25:05 CDT(-0500)] <Justin_o> michelled: hmm.. i'm not entirely sure.. you are right that we should settle on one though.. cindyli do you know?

[10:25:07 CDT(-0500)] <cindyli> michelled: we set on "enactors" as i understand. "actions" seems only used for "starterActions". Should we replace it with "starterEnactors" too?

[10:25:35 CDT(-0500)] <michelled> yes, let's be consistent

[10:26:01 CDT(-0500)] <cindyli> ok

[10:57:51 CDT(-0500)] <colinclark> Bosmon: So, I hear we need an arsonist!

[10:58:02 CDT(-0500)] <colinclark> Tell me about your experience with the ChangeApplier

[10:58:20 CDT(-0500)] <colinclark> Is it the transactional features, or other parts of it?

[10:58:31 CDT(-0500)] <Bosmon> It is the transactional features

[10:58:44 CDT(-0500)] <Bosmon> Which, as we may recall, were designed specifically for use in the Pager round about 2010

[10:58:50 CDT(-0500)] <Bosmon> And were never used for any other use case since then

[10:59:05 CDT(-0500)] <colinclark> yes, that's right

[10:59:13 CDT(-0500)] <Bosmon> Even for a "White Elephant Generalisation", their fit to their original problem is somewhat poor

[10:59:18 CDT(-0500)] <colinclark> I remember you recently commented that we had all of that infrastructure, but no real use cases

[10:59:35 CDT(-0500)] <michelled> cindyli: I'm not sure if you already say this, but we still have text-sizer in the html templates

[10:59:37 CDT(-0500)] <colinclark> Tell me about the nature of the original problem that drove the development for the Pager

[11:00:17 CDT(-0500)] <Bosmon> The Pager has a very strange kind of model... I guess at the time it seemed we were on the verge of an avalanche of finding components with similar models, but in fact no further examples appeared

[11:00:23 CDT(-0500)] <Bosmon> I guess you could call its model "self-reactive"

[11:00:36 CDT(-0500)] <cindyli> michelled: ah, missed that, will fix it in the new pull request

[11:00:42 CDT(-0500)] <cindyli> thanks

[11:00:44 CDT(-0500)] <Bosmon> Here we are talking about the little model it has, that has fields such as "pageIndex", "pageCount", "totalRange", "pageSize"

[11:00:45 CDT(-0500)] <michelled> np

[11:01:20 CDT(-0500)] <Bosmon> Several of these fields have values which are constrained by several of the others, which is actually quite a complex scenario

[11:01:49 CDT(-0500)] <Bosmon> In the "old pager" this was done by lots of manual code and "if" statements, but as well as being rather messy, this was actually the biggest source of dependency risk in the component

[11:02:18 CDT(-0500)] <Bosmon> So I guess we could say that despite the "failure" of the transactional features of the new ChangeApplier, they have at least met their basis purpose in allowing the component to be refactored

[11:02:23 CDT(-0500)] <Bosmon> basic purpose

[11:02:43 CDT(-0500)] <colinclark> right

[11:02:49 CDT(-0500)] <Bosmon> Since this "little model" gains some extra fields in the "PagedTable" component that are not present in the "Pager" component - in particular the sort direction and sort key

[11:03:01 CDT(-0500)] <colinclark> So what do you envision the next steps for the ChangeApplier to be?

[11:03:13 CDT(-0500)] <Bosmon> In the "old pager", the little method where all of these fields were dealt with at once was the worst point of dependency risk in the entire component, and the last problem to be fixed in the refactoring

[11:03:51 CDT(-0500)] <Bosmon> I think that we need to continue along the lines we currently are, and improve the power of the "ModelRelay" system that cindyli and others are designing for UIO, and improving the ModelTransformations system

[11:04:00 CDT(-0500)] <Bosmon> Neither of which were developments we were really considering in 2010

[11:04:19 CDT(-0500)] <Bosmon> But it's obvious that the system of "guards" that we have drawn up to describe the operation of a "self-reactive changeApplier" is faulty

[11:04:31 CDT(-0500)] <Bosmon> We should be describing directly required transformations and constraints on VALUES

[11:04:50 CDT(-0500)] <Bosmon> Rather than as we do with the "transactional ChangeApplier", expect people to directly write code which operates on streams of CHANGEEVENTS

[11:05:07 CDT(-0500)] <Bosmon> People should write the value filters and constraints as ModelTranformation documents

[11:05:29 CDT(-0500)] <Bosmon> And then the system should infer the required filtration of the ChangeEvent stream from this automatically

[11:05:58 CDT(-0500)] <Bosmon> Similarly to the way that a simple Transformation document allows two ChangeAppliers to be connected together by the ModelRelay systems that we are currently working on

[11:06:34 CDT(-0500)] <Bosmon> I guess this will mean that our current system of things like "guards" and "postGuards" etc. will bite the dust - in fact noone used them since 2010 since their implementation was unstable and incomprehensible

[11:06:54 CDT(-0500)] <kasparnet> Bosmon, colinclark, michelled: arch meeting now

[11:06:59 CDT(-0500)] <Bosmon> There's still a bit of a "cognitive gap" in figuring out how to describe constraints between values that are meant to operate in a particular ORDER

[11:07:21 CDT(-0500)] <Bosmon> For example, in discovering that the "pageIndex" is out of range of the "pageCount", it is the former which has to give way and not the latter

[11:07:50 CDT(-0500)] <Bosmon> Similarly, if the "pageCount" mismatches its value which can be inferred from "pageSize" and "totalRange" it is that one which gives way

[11:08:12 CDT(-0500)] <Bosmon> So there needs to be some kind of "hierarchy of constraints" which it is not possible to describe simply as a ModelTransformation document

[11:09:17 CDT(-0500)] <colinclark> This is very interesting

[11:09:36 CDT(-0500)] <colinclark> I think I need to break down the particular example in the page to understand this clearly

[11:15:32 CDT(-0500)] <michelled> avtar: the branch we are working on is: https://github.com/fluid-project/infusion/tree/discovery-tool-demo

[11:15:42 CDT(-0500)] <michelled> Justin_o: ^

[11:15:57 CDT(-0500)] <colinclark> How come we're going to do the discovery tool in a branch of Infusion?

[11:16:03 CDT(-0500)] <michelled> we haven't put anything interesting in it yet, but an automated build would be awesome

[11:16:30 CDT(-0500)] <Bosmon> michelled - didn't yzen create a new github repository under GPII for work such as this?

[11:16:47 CDT(-0500)] <avtar> michelled: perfect. thanks!

[11:16:51 CDT(-0500)] <michelled> colinclark: we talked about doing it as another integration demo. do you think it should be a separate repo?

[11:17:00 CDT(-0500)] <michelled> hang on avtar - I might have jumped the gun

[11:17:05 CDT(-0500)] <avtar> too late

[11:17:14 CDT(-0500)] <avtar> i'm attached to that repo

[11:17:18 CDT(-0500)] <michelled>

[11:17:49 CDT(-0500)] <Justin_o> avtar: your level of commitment is astonishing

[11:17:55 CDT(-0500)] <michelled> Bosmon: I think this belongs under the fluid space rather than GPII

[11:17:56 CDT(-0500)] <colinclark> Yes, I think it should be a different repository

[11:18:14 CDT(-0500)] <colinclark> Why do you think it belongs there, michelled?

[11:20:02 CDT(-0500)] <michelled> I thought it was Floe/PGA. Am I wrong?

[11:20:41 CDT(-0500)] <colinclark> This is an interesting conversation

[11:20:41 CDT(-0500)] <michelled> yzen: where is your GPII repo?

[11:20:48 CDT(-0500)] <colinclark> We're in the midst of the architecture meeting at the moment

[11:20:57 CDT(-0500)] <colinclark> and I'd like to give it more time that I've got for the next 30 minutes or so

[11:21:24 CDT(-0500)] <yzen> colinclark: are you talking about the prefEditors repo ?

[11:21:29 CDT(-0500)] <colinclark> I can say this much: I feel pretty clear, in my own mind, that it shouldn't be in a branch of Infusion

[11:21:30 CDT(-0500)] <Bosmon> yzen - we are

[11:21:57 CDT(-0500)] <colinclark> I think we can have a discussion clarifying whether it should be part of the GPII prefsEditor repository or not

[11:22:06 CDT(-0500)] <colinclark> I just need a few minutes

[12:05:34 CDT(-0500)] <colinclark> Ok

[12:05:34 CDT(-0500)] <colinclark> repositories

[12:05:34 CDT(-0500)] <colinclark> and where an early prototype of the Discovery Tool preference editor should live

[12:05:52 CDT(-0500)] <colinclark> I can imagine jessm may also have some thoughts on this

[12:06:07 CDT(-0500)] <colinclark> From my perspective, I'd like to see the PGA work as closely aligned with the larger GPII community as possible

[12:06:13 CDT(-0500)] <jessm> jessm? thoughts? keywords!

[12:06:21 CDT(-0500)] <colinclark> lol

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

[12:06:30 CDT(-0500)] <colinclark> in part to remind the project team that this is a piece of a larger effort

[12:06:39 CDT(-0500)] <colinclark> that there are different preferences tools for different users and use cases

[12:07:01 CDT(-0500)] <colinclark> I guess one question is if we think there will be opportunities for harmonization or code sharing with the other two preference editors

[12:07:04 CDT(-0500)] <colinclark> the PCP and PMT

[12:07:19 CDT(-0500)] <colinclark> both of which will live in that prefsEditor repository that yzen created

[12:07:30 CDT(-0500)] <michelled> I had thought of the discovery tool as a flavour of UIO and thought that once it was production worthy it would ship with the component

[12:07:45 CDT(-0500)] <colinclark> So, I guess this points to something big

[12:08:04 CDT(-0500)] <colinclark> I fear we're getting to the end of the usefulness of the name "UI Options component"

[12:08:23 CDT(-0500)] <colinclark> I've started to use the term "UI Options Framework" in the documentation I've been writing

[12:08:42 CDT(-0500)] <colinclark> but have found that it still points people back to "that thing at the top of some websites that lets you make the font bigger or change the contrast"

[12:09:10 CDT(-0500)] <colinclark> michelled: How is your notion of a "flavour of UIO" different from what the PCP and PMT are?

[12:11:26 CDT(-0500)] <michelled> I suppose my notion might be archaic and comes from the concepts of full page, full page with preview and fat panel.

[12:12:04 CDT(-0500)] <michelled> when we moved the full page demos into the manual tests, we said they would eventually be replaced by PCP and/or PMT

[12:12:27 CDT(-0500)] <michelled> I guess I'm not clear on what it is we want in the Infusion repo anymore.

[12:13:38 CDT(-0500)] <Bosmon> Well, we certainly want at least the "framework" itself

[12:13:42 CDT(-0500)] <Bosmon> And its "starter configuration"

[12:13:47 CDT(-0500)] <Bosmon> We may want little else there

[12:14:11 CDT(-0500)] <colinclark> I think that's probably right...

[12:15:22 CDT(-0500)] <colinclark> I expect that the "starter" configuration will look something like joanna's latest wireframes for the "fat panel"

[12:15:44 CDT(-0500)] <colinclark> I'm having trouble finding them at the moment. When I search in the wiki for "UI Options wireframes" I still get Gary's old designs with the vegetables in them

[12:16:26 CDT(-0500)] <colinclark> Ah, here: http://wiki.fluidproject.org/display/fluid/%28Floe%29+UI+Options+Design+High+Fidelity%2C+C.1

[12:16:48 CDT(-0500)] <colinclark> I guess the thing we have to unpack a bit is, "what is UI Options?"

[12:16:49 CDT(-0500)] <colinclark> It

[12:17:08 CDT(-0500)] <colinclark> It's more than "a component" at this state in its evolution

[12:17:30 CDT(-0500)] <colinclark> where "a component" is, in many people's minds, "a specific widget or control you can put in a web page"

[12:17:42 CDT(-0500)] <colinclark> We have, of course, a much more expansive notion of the word "component"

[12:18:03 CDT(-0500)] <colinclark> but the point is that, I think, UI Options is now increasingly a "tool that you use to build preference editors"

[12:18:12 CDT(-0500)] <colinclark> Does that seem about right to you, michelled?

[12:19:59 CDT(-0500)] <michelled> well, I do think that's true colinclark - but I also feel that Infusion might be having an identity crises. I think people will want access to preference editors that they can just use with minimal work. in my mind, Infusion delivers (delivered?) that.

[12:20:23 CDT(-0500)] <michelled> this seems to point to the what the KING was been saying about pulling the framework out from the components

[12:20:47 CDT(-0500)] <michelled> unfortunately, he's at soccer right now

[12:22:03 CDT(-0500)] <colinclark> Okay, so we can unpack some of this

[12:22:17 CDT(-0500)] <colinclark> The identity crisis issue, perhaps you can elaborate on

[12:22:42 CDT(-0500)] <colinclark> The other question is, do we think that the Discovery Tool is the sort of thing that someone would just pop into their application? Or is it broader in scope?

[12:25:08 CDT(-0500)] <michelled> when the tool is integrated with the full workflow that involves setting more fine grained setting of course it is broader. what I'm not sure about is whether it's useful on its own.

[12:29:54 CDT(-0500)] <michelled> vjoanna, danaayotte: where do we expect the discovery tool to be used?

[12:33:24 CDT(-0500)] <colinclark> I wasn't able to attend your scoping meeting about the DT recently

[12:33:32 CDT(-0500)] <colinclark> but I assume this was probably discussed

[12:33:43 CDT(-0500)] <colinclark> The DT is interesting in that it needs to be closely integrated with a "content delivery system"

[12:34:02 CDT(-0500)] <colinclark> Since, ultimately, the user will be explore the range of preferences and settings available to them within particular content

[12:34:31 CDT(-0500)] <colinclark> but it's also notable that the DT will ultimately stretch beyond just a particular kind of content

[12:34:51 CDT(-0500)] <colinclark> also offering users ways to play around with native assistive technology and settings

[12:35:02 CDT(-0500)] <colinclark> such as, say, a screen magnifier

[12:35:07 CDT(-0500)] <colinclark> or tools like Read & Write Gold

[12:35:35 CDT(-0500)] <colinclark> Which means that an aspect of it will be connected to or aware of a local GPII installation

[12:35:57 CDT(-0500)] <colinclark> so that it can send "preference preview" events to a local Flow Manager

[12:39:24 CDT(-0500)] <colinclark> Also, if I remember correctly, the Discovery Tool also had a kind of "preferences summary" view that was something akin to the PMT

[12:39:34 CDT(-0500)] <colinclark> where you could see what actual preferences were stored in your set and tweak them

[12:39:35 CDT(-0500)] <jessm> so, identity crisis indeed

[12:40:44 CDT(-0500)] <colinclark> What is the identity crisis?

[12:40:53 CDT(-0500)] <jessm> colinclark: michelled: just the other day i said (before my ears fell off my head) I can imagine the DT is the same thing as the PCP as the UIO in some implementations. it's a sign of the brilliance of it being a platform, but makes for very confusing conversations

[12:41:21 CDT(-0500)] <jessm> i can say the PMT feels different because of the additional features

[12:41:51 CDT(-0500)] <jessm> but we have a museum PCP mock-up that looks a lot like UIO on a kiosk and doesn't look that different from the DT

[12:43:06 CDT(-0500)] <colinclark> I really love how you've taken on the Infusion philosophy from a design perspective, jessm

[12:43:28 CDT(-0500)] <colinclark> In that it doesn't mean a whole lot, technically, to say "the PMT is different from the PCP"

[12:43:46 CDT(-0500)] <colinclark> in that they are both implementations of the UI Options framework

[12:43:51 CDT(-0500)] <colinclark> different views or configurations of it

[12:44:05 CDT(-0500)] <colinclark> but nonetheless very interrelated

[12:44:19 CDT(-0500)] <jessm> it's intirely danaayotte and jvass' faults

[12:44:45 CDT(-0500)] <colinclark> Yes, I blame vjoanna and danaayotte for being awesome

[12:44:57 CDT(-0500)] <jessm> exactly

[12:45:02 CDT(-0500)] <colinclark> I'm hesitant to call it an identity crisis

[12:45:02 CDT(-0500)] <colinclark> but the point is notable

[12:45:07 CDT(-0500)] <jessm> what i love about all the tools is the top-hat and underpants part

[12:45:17 CDT(-0500)] <colinclark> woah

[12:45:32 CDT(-0500)] <colinclark> And people say Bosmon uses strange references

[12:45:54 CDT(-0500)] <jessm> just like the uploader component you can dress these guys up and take them to the opera, or you can strip them down to underpants and take them to a cookout

[12:45:58 CDT(-0500)] <Bosmon> jessm - is this anything to do with the "underpants gnomes business model"?

[12:46:18 CDT(-0500)] <jessm> colinclark: it goes back to Portland when you showed me the uploader in its underpants!

[12:46:21 CDT(-0500)] <colinclark> so awesome

[12:46:26 CDT(-0500)] <colinclark> is this what happens on the 4th of July?

[12:46:37 CDT(-0500)] <colinclark> y'all bbq in your underpants?

[12:46:43 CDT(-0500)] <jessm> what? it's the 3rd!

[12:46:50 CDT(-0500)] <jessm> oh right

[12:46:51 CDT(-0500)] <Bosmon> I think it is only the 4th July currently in the KIRIBATI ISLANDS

[12:47:01 CDT(-0500)] <colinclark> sorry

[12:47:10 CDT(-0500)] <jessm> tomorrow underpants bbq

[12:47:12 CDT(-0500)] <colinclark> yes

[12:47:14 CDT(-0500)] <colinclark> that's what I meant

[12:47:19 CDT(-0500)] <jessm> maybe!

[12:47:23 CDT(-0500)] <colinclark> Although it is unusual, I do know what day it is today

[12:48:03 CDT(-0500)] <jessm> let me dig up the german museum kiosk sketches

[12:48:19 CDT(-0500)] <Bosmon> jessm - now that could only lead to a Monty Python result

[12:48:28 CDT(-0500)] <Bosmon> "I don't believe you have any DUEHRER IN THIS KIOSK AT ALL!"

[12:48:35 CDT(-0500)] <jessm> lol

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

[12:48:51 CDT(-0500)] <colinclark> Anyway, this fact that the various preference editors aren't strictly delineated...

[12:49:13 CDT(-0500)] <colinclark> The good news is, first, that we've got a common technical framework with which they can all be built and configured

[12:49:30 CDT(-0500)] <colinclark> Secondly, we've got an awesome design team who is tackling their user experience holistically

[12:49:42 CDT(-0500)] <Bosmon> Justin_o - will there happen to be a Community Meeting today?

[12:50:27 CDT(-0500)] <colinclark> So, the name is increasingly insufficient

[12:50:40 CDT(-0500)] <colinclark> but we have "the UI Options framework," which all three tools will be built from

[12:50:55 CDT(-0500)] <colinclark> four if you want to count the "thing we currently know as UI Options"

[12:51:10 CDT(-0500)] <colinclark> You could call it the "web PCP" if you were so inclined

[12:51:40 CDT(-0500)] <colinclark> So the UIO framework should undoubtedly be part of Infusion

[12:51:50 CDT(-0500)] <colinclark> since we want to offer it to anyone doing the work of building a preference editing tool

[12:52:02 CDT(-0500)] <colinclark> and we always like to ship default configurations and useful, high-level components

[12:52:05 CDT(-0500)] <jessm> yes, exactly, web PCP

[12:52:14 CDT(-0500)] <colinclark> so the (sorry for the name) "web PCP" should ship alongside the framework as an exmplar

[12:52:47 CDT(-0500)] <colinclark> From there, the "native PCP" and the PMT are both being built in the context of the GPII Github org

[12:52:59 CDT(-0500)] <colinclark> I think there's a lot of benefit to also building the DT in that context

[12:53:11 CDT(-0500)] <colinclark> good to remind everyone working on the project that there's a big picture

[12:53:23 CDT(-0500)] <colinclark> beyond any single content authoring or delivery system

[12:55:18 CDT(-0500)] <michelled> ok. what do you think we should do with the code we currently have for the full page versions of "web PCP"

[12:55:39 CDT(-0500)] <colinclark> We don't really see those as a "product"

[12:55:43 CDT(-0500)] <colinclark> sorry for the word, jessm

[12:56:13 CDT(-0500)] <colinclark> So they really just serve as exemplars for how you can build different types of preference editors with the UI Options Framework

[12:56:14 CDT(-0500)] <colinclark> I think

[12:56:20 CDT(-0500)] <colinclark> is that what others think, too?

[12:57:04 CDT(-0500)] <jessm> so, remind me of the details – yzen had a thread onlist about naming the "basic" or "starter" configuration

[12:57:09 CDT(-0500)] <michelled> I'm a little uncomfortable with having code in the main repo that we aren't using for something that we are expecting to be in production

[12:57:37 CDT(-0500)] <michelled> it's too easy for us to forget it and have it break without our knowledge

[12:57:38 CDT(-0500)] <jessm> i think that hinted at where we are now — deciding what are unique instances or exemplars

[12:57:57 CDT(-0500)] <colinclark> I'm pretty sure vjoanna said months ago that those full-page views weren't ever intended to be real

[12:58:38 CDT(-0500)] <michelled> yes, my understanding was that we were temporarily keeping it in the repo until we replaced it with PCP/PMT - but I must have misunderstood that.

[12:58:59 CDT(-0500)] <colinclark> jessm: Yes, we have a "starter" configuration that represents, or should represent, roughly those C.1 wireframes

[12:59:24 CDT(-0500)] <Bosmon> michelled - hopefully we rely on more than "expecting it to be used in production" for our ability to keep code working

[12:59:36 CDT(-0500)] <colinclark> so what's wrong with that idea, michelled?

[12:59:40 CDT(-0500)] <colinclark> why did you misunderstand?

[13:00:24 CDT(-0500)] <michelled> and I guess I'd like to make the distinction between the code https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uiOptions/js/FullPreviewUIOptions.js and the demo https://github.com/fluid-project/infusion/blob/master/src/webapp/tests/manual-tests/html/uiOptionsFullWithPreview.html

[13:00:31 CDT(-0500)] <colinclark> the idea of eventually replacing those with pointers to the PMT or PCP or discover tool or any number of other things, i mean

[13:00:43 CDT(-0500)] <colinclark> what kind of distinction?

[13:02:22 CDT(-0500)] <michelled> well, having a demo that shows ways of using the framework is great - the first link I sent could be considered part of the framework

[13:02:31 CDT(-0500)] <michelled> but it sounds like we wouldn't actually be using it anywhere

[13:02:41 CDT(-0500)] <michelled> that was what I was concerned about leaving in the repo

[13:02:47 CDT(-0500)] <michelled> or at least, leaving it where it is

[13:03:31 CDT(-0500)] <Bosmon> michelled - what's behind this?

[13:03:34 CDT(-0500)] <Bosmon> What real risks do you see?

[13:03:35 CDT(-0500)] <michelled> my misunderstanding was that I thought the PCP and PMT core code would eventually be in the infusion repo rather than the infusion repo having pointers out to it.

[13:04:09 CDT(-0500)] <michelled> Bosmon: the same risk we just finally got rid of by removing our ancient portal integration demo

[13:04:14 CDT(-0500)] <Bosmon> Perhaps we should remove the Uploader, the Reorderer, and the Pager from the framework too

[13:04:19 CDT(-0500)] <Bosmon> Since they are not "actually used anywhere"

[13:04:20 CDT(-0500)] <michelled> the one that spent more of it's time broken in the repo than working

[13:04:30 CDT(-0500)] <colinclark> Justin might agree to that

[13:04:53 CDT(-0500)] <michelled> that's what I was hinting at before - the KING has been suggesting that for some time now

[13:05:02 CDT(-0500)] <colinclark> But it's a good point...

[13:05:07 CDT(-0500)] <colinclark> He's been suggesting it for some time,

[13:05:11 CDT(-0500)] <colinclark> and I was quite against it

[13:05:32 CDT(-0500)] <colinclark> until he proposed a very awesome and time-intensive (to build) cross-repository Builder

[13:05:48 CDT(-0500)] <colinclark> Until we're ready to tackle that, I can't see any real benefit to removing components from the framework

[13:06:02 CDT(-0500)] <colinclark> and in fact I think it risks the thing you're most concerned about

[13:06:11 CDT(-0500)] <colinclark> which is inadvertent and unnoticed breakage

[13:06:43 CDT(-0500)] <colinclark> I mean, from a very big picture perspective, I'd love to decouple the components from the framework

[13:06:56 CDT(-0500)] <colinclark> since i think people are often confused by the idea that the components ARE Infusion

[13:07:08 CDT(-0500)] <colinclark> but honesty I think that has much to do with our documentation and demos as anything else

[13:07:35 CDT(-0500)] <colinclark> And having these "exemplars" of how our framework can be used in a variety of ways to create very different types of user interfaces

[13:07:47 CDT(-0500)] <colinclark> from a shared base of code and configuration

[13:07:52 CDT(-0500)] <colinclark> that goes a long way to explaining the dynamic

[13:08:22 CDT(-0500)] <colinclark> There's an interesting question about how we keep things working and up-to-date

[13:08:36 CDT(-0500)] <colinclark> why is it that the Uploader didn't break, but the uPortal demo often did?

[13:08:42 CDT(-0500)] <colinclark> what's different about these two things

[13:08:43 CDT(-0500)] <colinclark> ?

[13:08:55 CDT(-0500)] <anastasiac> so I'm a little confused. The things we currently have in our 'components' folder: are those actual widgets we expect people to use in their sites/apps, or are they exemplars of how to use the framework to build their own widgets, or both, or something else?

[13:08:59 CDT(-0500)] <Bosmon> Actually the Uploader did break : P

[13:09:04 CDT(-0500)] <colinclark> Bosmon: in the end, it looks like we're having our community meeting right now

[13:09:12 CDT(-0500)] <Bosmon> "if a component breaks in the forest and nobody hears it....>"

[13:09:45 CDT(-0500)] <Bosmon> And what is the topic of the meeting?

[13:09:49 CDT(-0500)] <Bosmon> "What, in fact, are we up to?" : P

[13:10:09 CDT(-0500)] <colinclark>

[13:10:26 CDT(-0500)] <colinclark> anastasiac: They are undoubtedly both

[13:10:43 CDT(-0500)] <colinclark> this speaks my earlier point about how we have a different notion of what a "component" is

[13:11:00 CDT(-0500)] <anastasiac> yes, we need a different name for the "widget" components

[13:11:19 CDT(-0500)] <colinclark> I guess my hope is that we don't really have these things, so much

[13:11:34 CDT(-0500)] <Bosmon> They serve at least a 3rd purpose, and possibly several others...

[13:11:47 CDT(-0500)] <Bosmon> They validate the fact that the framework is useful for building something that someone at at least one time genuinely wanted

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