fluid-work IRC Logs-2010-02-02

[00:10:50 EST(-0500)] * jamon (jamon@mantis.openject.com) has joined #fluid-work
[05:35:59 EST(-0500)] * sveto (~sveto@62.44.108.2) has joined #fluid-work
[08:28:49 EST(-0500)] * boyan (~boyan@62.44.108.2) has joined #fluid-work
[08:31:01 EST(-0500)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[09:07:40 EST(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[09:57:24 EST(-0500)] * clown (~clown@142.150.154.101) has joined #fluid-work
[10:04:37 EST(-0500)] * sveto (~sveto@62.44.108.2) has left #fluid-work
[10:11:21 EST(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[10:24:28 EST(-0500)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[11:03:29 EST(-0500)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[11:06:47 EST(-0500)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[11:13:45 EST(-0500)] * EverettZ (~chatzilla@bas4-toronto06-1279277146.dsl.bell.ca) has joined #fluid-work
[11:14:15 EST(-0500)] <EverettZ> colinclark: Is there anything that I could do to help out the team with a couple of free hours today?
[11:14:34 EST(-0500)] <colinclark> EverettZ: Wow! For sure!
[11:15:06 EST(-0500)] <colinclark> EverettZ: We've been working hard to put together our mobile application for museum visitors to the McCord museum.
[11:15:24 EST(-0500)] <colinclark> EverettZ: It's still very, very raw, but now would be a great time to get your thoughts on it so far.
[11:15:41 EST(-0500)] <colinclark> EverettZ: Especially if you've got some time to actually try it out on your iPhone.
[11:16:49 EST(-0500)] <EverettZ> colinclark: sure, can I have the URL?
[11:17:03 EST(-0500)] <colinclark> EverettZ: Yep, just let me grab it.
[11:18:01 EST(-0500)] <colinclark> EverettZ: So at the moment, it's really only the Exhibitions link on the home screen that is properly working. A number of artifacts are missing from the database, so you're like to encounter raw stack traces in a few cases.
[11:18:07 EST(-0500)] <colinclark> EverettZ: Here's the URL: http://build.fluidproject.org:8095/engage/home/home.html
[11:18:44 EST(-0500)] <EverettZ> colinclark: cool, I'll take a look and send my finding to the mailing list
[11:18:53 EST(-0500)] <colinclark> EverettZ: Thanks so much. I really appreciate it.
[11:19:20 EST(-0500)] <EverettZ> colinclark: np, this is what I do to relax. Far more relaxing when you don't have a deadline
[11:19:42 EST(-0500)] <colinclark> EverettZ: No kidding. Still, it's awesome.
[11:20:44 EST(-0500)] <EverettZ> colinclark: Is this app intended to ever be used outside of the iPhone?
[11:21:10 EST(-0500)] <colinclark> EverettZ: We already have it running on Android phones as well, but the first release will only be QA tested on the iPhone.
[11:21:38 EST(-0500)] <colinclark> EverettZ: Ultimately, I expect that many of the underlying components will be repurposed for use on desktop Web browsers, too, but that'll be down the road a few months.
[11:22:58 EST(-0500)] <EverettZ> colinclark: alright, talk to you later.
[11:33:36 EST(-0500)] <jessm> standup Toronto
[11:34:19 EST(-0500)] <colinclark> on our way
[11:52:03 EST(-0500)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[12:07:25 EST(-0500)] * elicochran (~elicochra@dhcp-169-229-212-4.LIPS.Berkeley.EDU) has joined #fluid-work
[12:15:11 EST(-0500)] * EricDalquist1 (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[12:41:00 EST(-0500)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[13:08:26 EST(-0500)] * elicochran (~elicochra@2607:f140:400:144:21b:63ff:fec8:1179) has joined #fluid-work
[13:32:19 EST(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[13:49:11 EST(-0500)] * EverettZ (~chatzilla@bas4-toronto06-1279277146.dsl.bell.ca) has joined #fluid-work
[13:49:36 EST(-0500)] <EverettZ> colinclark: anything else that would benefit from my taking a look at it?
[13:56:12 EST(-0500)] <colinclark> EverettZ: Sorry, I missed your question.
[13:56:19 EST(-0500)] <colinclark> EverettZ: Thanks for your email, that was great.
[13:56:52 EST(-0500)] <colinclark> EverettZ: Alison and Armin have been working on some ideas for checking WCAG 2 compliance in Infusion...
[13:57:02 EST(-0500)] <colinclark> EverettZ: You might be curious about that... Let me dig up the information
[14:00:15 EST(-0500)] <EverettZ> colinclark: sounds good
[14:00:19 EST(-0500)] <colinclark> EverettZ: I can't find it. I'm assuming they're not quite ready for it yet, so don't sweat it.
[14:00:32 EST(-0500)] <colinclark> EverettZ: I'll get Alison to ping you whenever she's ready to share it.
[14:00:39 EST(-0500)] <EverettZ> colinclark: what is the accessibility situation with kiosk?
[14:01:08 EST(-0500)] <colinclark> EverettZ: At the moment, the kiosk is still very early in the design phase...
[14:01:28 EST(-0500)] * jameswy (~jameswy@142.150.154.196) has joined #fluid-work
[14:01:31 EST(-0500)] <colinclark> EverettZ: jameswy is on his way, he's one of the designers.
[14:02:28 EST(-0500)] <jameswy> Hi EverettZ! We're doing a bunch of research on how to make our kiosks accessible.
[14:02:39 EST(-0500)] <jameswy> I can point you to some of the stuff that's already on the wiki about it.
[14:02:47 EST(-0500)] <EverettZ> jameswy: not an easy task I'm sure.
[14:02:49 EST(-0500)] <jameswy> And we'd certainly love your input on the matter!
[14:02:53 EST(-0500)] <jameswy> Indeed!
[14:03:05 EST(-0500)] <EverettZ> jameswy: Can you point me to a page with a project description?
[14:03:57 EST(-0500)] <jameswy> EverettZ: We have some details about the project on this page here: http://wiki.fluidproject.org/display/fluid/Kiosk+design+overview
[14:04:31 EST(-0500)] <jameswy> And some research we've been doing on kiosk accessibility here: http://wiki.fluidproject.org/display/fluid/Accessibility+Guidelines+for+UI+and+Physical+Kiosk+Design
[14:04:34 EST(-0500)] <jameswy> And here: http://wiki.fluidproject.org/display/fluid/Notes+from+chat+with+blind+user+about+museum+experience+%28January+13%2C+2010%29
[14:04:50 EST(-0500)] <jameswy> And here: http://wiki.fluidproject.org/display/fluid/Accessibility+requirements+to+address%2C+iteration+5
[14:07:24 EST(-0500)] <EverettZ> jameswy: thanks, I'll take a look
[14:14:06 EST(-0500)] <EverettZ> jameswy: Not to be to critical, but "Some direct questions from us are indicated in purple" not particularly useful to blind content consumers and violates wcag
[14:15:13 EST(-0500)] <jameswy> EverettZ: Aha, good point. Would using underline, bold, or italics be better?
[14:16:09 EST(-0500)] <EverettZ> jameswy: nope.
[14:16:52 EST(-0500)] <EverettZ> jameswy: annotation or categorization of content so that questions are logically perceivable as "direct questions" would work.
[14:17:13 EST(-0500)] <EverettZ> jameswy: not an issue to me, just something to be aware of when producing content.
[14:19:40 EST(-0500)] <jameswy> EverettZ: Duly noted. Thanks!
[14:23:37 EST(-0500)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[14:24:39 EST(-0500)] * EverettZ (~chatzilla@bas4-toronto06-1279277146.dsl.bell.ca) has joined #fluid-work
[14:24:53 EST(-0500)] <EverettZ> jameswy: "We could adapt a commercial screen reader (e.g. JAWS or Voice Over"
[14:25:08 EST(-0500)] <EverettZ> jameswy: Or open source such as NVDA or Orca
[14:27:06 EST(-0500)] <EverettZ> jameswy: They have aweful voices, but different tts voices can be commercially purchased that are low cost and sound good. See http://www.cepstral.com/
[14:31:46 EST(-0500)] <jameswy> EverettZ: We'll take a look at them. Also, I've replied back to your excellent review of our Exhibitions screen. Thanks again for your notes there!
[14:39:40 EST(-0500)] <EverettZ> jameswy: responded to your message on the fluid work list. Let me know if I can be of further assistance.
[14:49:34 EST(-0500)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[15:07:23 EST(-0500)] * yura (~yura@142.150.154.101) has joined #fluid-work
[15:07:34 EST(-0500)] <yura> Bosmon:
[15:07:53 EST(-0500)] <Bosmon> hi
[15:08:09 EST(-0500)] <yura> hi
[15:08:16 EST(-0500)] <Bosmon> yura, michelled - I was just wanting to post a link of interest
[15:08:18 EST(-0500)] <Bosmon> https://bug509678.bugzilla.mozilla.org/attachment.cgi?id=399062
[15:08:36 EST(-0500)] <Bosmon> So, it seems that this infuriating behaviour of failing on parsing JSON with whitespace in it is highly deliberate
[15:08:55 EST(-0500)] <Bosmon> In September, the parser was patched to solve this "regression"
[15:09:01 EST(-0500)] <Bosmon> https://bugzilla.mozilla.org/show_bug.cgi?id=509678
[15:09:10 EST(-0500)] <Bosmon> But other than this, I can see no reason why our UTF-8 should fail to parse
[15:09:22 EST(-0500)] <Bosmon> I am trying to find the code in services-sketches where you run the McCord import but I can't find it
[15:09:39 EST(-0500)] <yura> i think it's in patch right now
[15:09:48 EST(-0500)] <yura> one sec, ill find the jira
[15:10:09 EST(-0500)] <yura> http://issues.fluidproject.org/browse/ENGAGE-290
[15:10:11 EST(-0500)] <yura> right here
[15:10:53 EST(-0500)] <Bosmon> OK
[15:10:56 EST(-0500)] <Bosmon> Your problem is here on this line
[15:10:57 EST(-0500)] <Bosmon> + BufferedReader in =
[15:10:58 EST(-0500)] <Bosmon> + new BufferedReader(new InputStreamReader(url.openStream()));
[15:11:02 EST(-0500)] <Bosmon> You have already corrupted the stream at this point
[15:11:08 EST(-0500)] <Bosmon> Also, why are you reconverting the data twice?
[15:13:50 EST(-0500)] <Bosmon> If you want to do it by hand, I suggest using a ByteArrayOutputStream to pen up the data, which will pass it along directly
[15:15:32 EST(-0500)] <Bosmon> Since you have included PonderUtilCore there is a useful utility StreamCopyUtil.inputToOutput that will do it in one step
[15:16:16 EST(-0500)] <yura> oh, I wasn't aware of inputtooutput
[15:46:35 EST(-0500)] <Bosmon> yura - while you are at it, could you arrange for the ISO standard language codes to be applied to the URLs rather than the original numbers?
[15:46:37 EST(-0500)] <Bosmon> Cheers
[15:59:37 EST(-0500)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[16:00:03 EST(-0500)] <colinclark> Hey Bosmon
[16:00:21 EST(-0500)] <colinclark> justin_o and I hit an interesting issue
[16:01:46 EST(-0500)] <colinclark> Renderer component decorators don't tend to go through any kind of IoC
[16:02:07 EST(-0500)] <colinclark> They're generally attached by concrete type
[16:02:45 EST(-0500)] <Bosmon> Yes
[16:02:45 EST(-0500)] <colinclark> Anyway, the issue we encountered was that we have a component that may or may not set up a subcomponent based on options passed in.
[16:03:04 EST(-0500)] <colinclark> We had a unit test that was verifying that the subcomponent was getting setup correctly
[16:03:15 EST(-0500)] <colinclark> It was subsequently refactored to be added as a component decorator
[16:03:19 EST(-0500)] <colinclark> So the end result seems to be a net loss
[16:03:26 EST(-0500)] <colinclark> Now the component isn't going through any IoC
[16:03:36 EST(-0500)] <Bosmon> Well
[16:03:37 EST(-0500)] <colinclark> And it's harder to test, since it's just a ghost floating in the DOM
[16:03:49 EST(-0500)] <Bosmon> That will be partially resolved, once we have some IoC
[16:04:27 EST(-0500)] <Bosmon> But I am interested in the details...
[16:05:11 EST(-0500)] <Bosmon> When you say, "added as a component decorator"
[16:05:21 EST(-0500)] <Bosmon> You mean, using the "fluid" decorator in the renderer?
[16:05:26 EST(-0500)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[16:06:22 EST(-0500)] <colinclark> Bosmon: Yes, exactly
[16:07:37 EST(-0500)] <Bosmon> I was aware that the method of "finding" these components is not ideal... although it is at least possible once you only apply shallow copies to the component tree
[16:07:50 EST(-0500)] <Bosmon> But I was planning to have a better method for that, perhaps along the lines of the "identify" decorator...
[16:08:02 EST(-0500)] <Bosmon> Assuming they were easy to find again, how much of the problem would that solve?
[16:08:27 EST(-0500)] <Bosmon> What IoC in particular is the component lacking in its "standalone" form?
[16:09:13 EST(-0500)] <colinclark> Bosmon: That would certainly solve part of the problem, yes
[16:09:33 EST(-0500)] <colinclark> The concrete use case here regarding IoC isn't particularly enlightening, but I think you can imagine the problem
[16:09:49 EST(-0500)] <colinclark> If something is a subcomponent, being managed by IoC ensures that someone from the outside can change its type
[16:10:22 EST(-0500)] <colinclark> Whereas, it appears that naively, we have in several cases moved subcomponent instantiation into the component tree, causing us to loose that indirection.
[16:12:33 EST(-0500)] <Bosmon> I'm a bit puzzled how it is possible to substitute one type of thing for the other... I guess this is more properly attached to some "smaller" part of the DOM than its parent?
[16:12:50 EST(-0500)] <Bosmon> If it has a sensible kind of "subcomponent" role it would be preferable to keep it that way
[16:13:18 EST(-0500)] <Bosmon> Since even with "new IoC" the "Fluid component instantiation" time is special, and there are several things you can do during this time that you can't do afterwards
[16:13:36 EST(-0500)] <Bosmon> What might happen if you returned this thing to being instantiated as a subcomponent?
[16:14:02 EST(-0500)] <colinclark> Bosmon: The code will be substantially improved
[16:14:15 EST(-0500)] <colinclark> And that is exactly what I just recommended. I just wanted to ensure that I wasn't missing anything obvious.
[16:14:30 EST(-0500)] <colinclark> And to use this as an opportunity to remind all of us that we need to think about how we design our components.
[16:14:59 EST(-0500)] <colinclark> Subcomponents exist for a reason--to allow external clients of our code to swap out default behaviour for their own custom designs.
[16:15:11 EST(-0500)] <colinclark> That's why creating them via IoC is so important.
[16:15:49 EST(-0500)] <colinclark> Use Renderer decorators where they are appropriate--for decorating the DOM with fairly granular behaviour that is unlikely to need to be altered by our users.
[16:16:01 EST(-0500)] <Bosmon> ok, that is cool
[16:16:12 EST(-0500)] <colinclark> Thanks, Bosmon
[16:16:38 EST(-0500)] <Bosmon> Yes, it is strongly recommended to instantiate as many things as possible using a "Fluid component tree"
[16:17:04 EST(-0500)] <Bosmon> In fact, I imagine we are moving gradually over to a model whereby EVERYTHING is instantiated as one giant tree of this kind
[16:17:22 EST(-0500)] <Bosmon> "Renderer components" should gradually more and more become hidden from view
[16:26:43 EST(-0500)] <colinclark> Bosmon: One other quick question
[16:27:15 EST(-0500)] <colinclark> justin_o and I have changes to the Exhibition Browse "spout" to improve localization
[16:27:28 EST(-0500)] <colinclark> I guess we'll just hold on to patch until your big commit goes in?
[16:28:55 EST(-0500)] <Bosmon> That could help - can you describe what it does?
[16:30:18 EST(-0500)] <justin_o> Bosmon: basically we are making changes around i18n so a change to some string related code and some other options passed back to the component
[16:31:15 EST(-0500)] <Bosmon> ?
[16:31:38 EST(-0500)] <justin_o> all of the changes take place in handler.registerProducer
[16:32:17 EST(-0500)] <justin_o> Bosmon: this is because of a refactoring to the Browse component
[16:33:04 EST(-0500)] <colinclark> Bosmon: I can be more concrete
[16:33:45 EST(-0500)] <colinclark> We literally changed only a couple of lines
[16:34:10 EST(-0500)] <colinclark> We added an option, which is passed to the Browse component from the markup "spout"
[16:34:50 EST(-0500)] <colinclark> And we changed the way the localized strings are resolved for Exhibition Browse.
[16:35:06 EST(-0500)] <colinclark> Which, actually, brings me to the other thing I wanted to talk about with you sometime today...
[16:35:25 EST(-0500)] <Bosmon> ok
[16:35:33 EST(-0500)] <Bosmon> About "the way the localized strings are resolved"?
[16:35:36 EST(-0500)] <colinclark> indeed
[16:35:42 EST(-0500)] <colinclark> The ultimate problem justin_o and I encountered repeatedly today was that Browse is just incorrectly factored.
[16:36:10 EST(-0500)] <colinclark> It's too big to be a thing, and needs to be fractured out into smaller things that can be composed to capture the variety of browse-ish behaviour we have
[16:36:30 EST(-0500)] <colinclark> But we're not gonna get that done before Hugues' pilot, so we find ourselves working around things here or there.
[16:36:41 EST(-0500)] <Bosmon> ok
[16:36:51 EST(-0500)] <colinclark> Anyway, it's interesting to me that, by default, strings are resolved relative to a template
[16:37:18 EST(-0500)] <colinclark> More specifically, one would typically pass the render handler config to a call to kettle.getData() in order to look up the message bundle
[16:38:22 EST(-0500)] <colinclark> It seems quite possible, though, that one might want to reuse the same template with different message bundles in some cases.
[16:38:43 EST(-0500)] <colinclark> Justin and I were able to this in a somewhat less-than-awesome way today without much trouble
[16:39:29 EST(-0500)] <colinclark> But in the end message bundles always end up getting resolved relative to "source"
[16:39:49 EST(-0500)] <colinclark> hard-coded to ../messages/messages_[locale].json
[16:40:24 EST(-0500)] <colinclark> Bosmon: Are you following at all?
[16:43:35 EST(-0500)] <Bosmon> Yes, I am, sorry
[16:44:26 EST(-0500)] <Bosmon> Yes, I realised that the bundle resolution policy might not be best for all...
[16:44:30 EST(-0500)] <Bosmon> Where were you wanting to keep them?
[16:45:34 EST(-0500)] <colinclark> Bosmon: Well, for now we've just worked around the issue
[16:46:10 EST(-0500)] <colinclark> Exactly where we might want to keep them is a good question. I guess in this case they represent a kind of alternate configuration for Browse
[16:46:19 EST(-0500)] <colinclark> So they might go alongside browse
[16:46:32 EST(-0500)] <colinclark> I guess ideally they could go wherever we wanted them
[16:46:49 EST(-0500)] <colinclark> And we'd have some directive to tell the framework where the messages are relative to
[16:47:38 EST(-0500)] <colinclark> So if you look at justin_o's recent commit, you'd actually see that we've created new directories within engage-core and stuck the messages in there, which turned out just fine.
[16:47:50 EST(-0500)] <colinclark> Except that we had to supply an empty "html" directory to make it all work.
[16:47:56 EST(-0500)] <colinclark> None of this is a showstopper, but it's interesting.
[16:47:59 EST(-0500)] <Bosmon> I see
[16:48:30 EST(-0500)] <Bosmon> Well, in the "new deal" this code is still also left out in the open
[16:48:32 EST(-0500)] <Bosmon> So it should be fine
[16:48:34 EST(-0500)] <colinclark> Ok, great
[16:48:43 EST(-0500)] <colinclark> The workaround was quite straightforward to implement
[16:48:53 EST(-0500)] <colinclark> We'll add it to the queue of things to address for 0.5
[16:48:57 EST(-0500)] <Bosmon> I am just getting the test for the "markupSpout" working now...
[16:49:04 EST(-0500)] <colinclark> In the meantime, it's awesome that you were able to get it working
[16:49:08 EST(-0500)] <colinclark> Bosmon: Cool. How is it going?
[16:50:50 EST(-0500)] <Bosmon> Pretty good
[16:50:58 EST(-0500)] <Bosmon> Just getting it to try to load the templates from the filesystem now....
[16:51:15 EST(-0500)] <Bosmon> This represents yet a FOURTH bozotic configuration for the path resolution machinery
[16:57:48 EST(-0500)] * elicochran (~elicochra@dhcp-169-229-212-4.LIPS.Berkeley.EDU) has joined #fluid-work
[17:01:54 EST(-0500)] <Bosmon> HAH!
[17:02:01 EST(-0500)] <Bosmon> Fetch of templates is asynchronous again....
[17:08:33 EST(-0500)] <Bosmon> It works!!
[17:18:56 EST(-0500)] <clown> Bosmon: They're coming... http://www.theonion.com/content/video/final_season_of_lost_promises_to
[17:19:04 EST(-0500)] <Bosmon> Yes
[17:19:13 EST(-0500)] <Bosmon> I am making a trip to Houston just for the purpose
[17:20:28 EST(-0500)] <clown> okay. have a good trip. don't crash on any islands.
[17:21:03 EST(-0500)] <colinclark> lol
[17:21:21 EST(-0500)] <Bosmon> hahahah
[17:26:02 EST(-0500)] * clown (~clown@142.150.154.101) has left #fluid-work
[17:52:00 EST(-0500)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[23:17:55 EST(-0500)] * elicochran (~elicochra@adsl-70-137-137-123.dsl.snfc21.sbcglobal.net) has joined #fluid-work