fluid-work IRC Logs-2009-01-22

Owned by Fluid IRC Log Bot
Last updated: Jan 22, 2009Version comment
13 min read

[04:11:24 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[07:01:23 EST(-0500)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[07:01:52 EST(-0500)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has left #fluid-work
[07:02:01 EST(-0500)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[08:06:51 EST(-0500)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[08:49:35 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[09:51:42 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:51:50 EST(-0500)] * anastasiac (n=stasia@142.150.154.235) has joined #fluid-work
[09:54:54 EST(-0500)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:59:55 EST(-0500)] <anastasiac> Justin_o, I have a question about JIRA filters
[10:00:06 EST(-0500)] <anastasiac> on the release status page (in today's topic)
[10:00:42 EST(-0500)] <anastasiac> what is the difference between the "Remaining Tasks before Release" and the "Known Issues" filters?
[10:00:55 EST(-0500)] <anastasiac> justin_o ^^
[10:02:30 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176131918.dsl.bell.ca) has joined #fluid-work
[10:04:43 EST(-0500)] <justin_o> just going to check the page to refresh my memory
[10:05:57 EST(-0500)] <anastasiac> thanks
[10:07:02 EST(-0500)] <justin_o> this is something that i was going over with michelled and we were both confusing them at first for a bit too, now i am having trouble remembering what the difference is again (sad)
[10:07:08 EST(-0500)] <justin_o> i'll think about it some more
[10:07:18 EST(-0500)] <anastasiac> can you tell what the filter criteria are?
[10:07:35 EST(-0500)] <anastasiac> the 'remaining tasks' doesn't seem to refer to a saved filter
[10:08:02 EST(-0500)] <justin_o> oh okay... i think i remember now... i think the remaining tasks are the ones that are marked for fix 0.8
[10:08:32 EST(-0500)] <justin_o> known issues are the ones issues that affect 0.8 so they may not be getting fixed for 0.8
[10:08:39 EST(-0500)] <anastasiac> ah, ok - that makes sense
[10:10:06 EST(-0500)] <justin_o> the remaining task one runs off of the 0.8 versions link from the browse project page
[10:49:08 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[11:11:44 EST(-0500)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[11:12:51 EST(-0500)] * anastasiac (n=team@142.150.154.235) has joined #fluid-work
[11:22:06 EST(-0500)] <justin_o> colinclark: I'm just going through the test plans right now and am wondering if we are planning on keeping both versions of paper
[11:22:33 EST(-0500)] <colinclark> pager?
[11:22:59 EST(-0500)] <justin_o> yes... pager... sorry... type-o
[11:26:32 EST(-0500)] <colinclark> no worries
[11:26:41 EST(-0500)] <colinclark> i think it's good to have lots of different kinds of paper, too
[11:26:49 EST(-0500)] <colinclark> two different types of pager
[11:26:56 EST(-0500)] <colinclark> let me take a look at the code for a second
[11:27:12 EST(-0500)] <colinclark> i'm really just getting back into things after all this travel and illness
[11:28:09 EST(-0500)] <justin_o> no problem... i understand... there's no rush
[11:30:55 EST(-0500)] <colinclark> justin_o: So there's only one kind of Pager from the code perspective.
[11:31:00 EST(-0500)] <colinclark> What are the two types you're thinking of?
[11:31:12 EST(-0500)] <justin_o> oh the basic and the renderer version's of the page
[11:31:15 EST(-0500)] <colinclark> aha
[11:31:32 EST(-0500)] <colinclark> let me take a look at the two different versions of the markup
[11:31:39 EST(-0500)] <justin_o> okay... thanks
[11:34:29 EST(-0500)] <colinclark> justin_o: Okay
[11:34:52 EST(-0500)] <colinclark> It seems to me that the Renderer version is probably the ordinary configuration for a Pager.
[11:35:14 EST(-0500)] <colinclark> I certainly can't imagine a user wanting to build up all that markup themselves... it begs the question of why they'd bother to use the Pager.
[11:35:40 EST(-0500)] <colinclark> That said, we've found it useful in the past to have examples that show the markup agnosticism of a particular component.
[11:35:47 EST(-0500)] <colinclark> That's effectively what the basic sample does.
[11:36:02 EST(-0500)] <colinclark> However this is probably better achieved with a springboard in the long run.
[11:36:35 EST(-0500)] <colinclark> I forget who the co-leads of the component are... michelled and Boz?
[11:37:11 EST(-0500)] <justin_o> oh okay... so i should talk to them too i guess... i was just wondering if we could drop it, but it sounds like we need to keep it until a springboard is developed
[11:37:30 EST(-0500)] <colinclark> justin_o: I think we can probably drop it from active testing.
[11:37:40 EST(-0500)] <colinclark> And in fact we could simply move it into the manual tests folder.
[11:37:54 EST(-0500)] <colinclark> The Renderer really is the future for this component.
[11:37:58 EST(-0500)] <justin_o> that sounds like a good idea
[11:39:14 EST(-0500)] <colinclark> justin_o: So Jess just responded with a +1 to the 0.8/0.9 timeline.
[11:39:30 EST(-0500)] <colinclark> Can you give some thoughts to the dates you'd like for bug parade and code freeze?
[11:39:39 EST(-0500)] <colinclark> And I agree with your point about some targeted bug squashing.
[11:40:23 EST(-0500)] * mtheoryx83 (n=mtheoryx@c-68-58-86-205.hsd1.in.comcast.net) has joined #fluid-work
[11:41:46 EST(-0500)] <justin_o> sure... i guess i should first check to see what you would like to go into the 0.8/0.9 release... i'm assuming it's going to be a bunch of stuff for uploader, ui options, maybe continued work on pager, and rich text inline edit... any thing else? or any major changes within any of these components?
[11:42:12 EST(-0500)] <colinclark> justin_o: Here's the wish list Daphne and Jess and I put together:
[11:42:12 EST(-0500)] <colinclark> http://wiki.fluidproject.org/display/fluid/Infusion+0.8+Roadmap
[11:42:49 EST(-0500)] <colinclark> I'm not optimistic about moving forward with any date picker development within this time frame, so we may revise that section.
[11:43:07 EST(-0500)] <colinclark> Otherwise, we'll move Pager forward in the hopes that it will ultimately be useful within the new Sakai.
[11:43:29 EST(-0500)] <colinclark> We'll sync Inline Edit up with the latest design considerations for both dropdown and rich text.
[11:43:50 EST(-0500)] <colinclark> We'll address all the core browser compatibility issues in Uploader and pick of as many of the a11y issues as we can.
[11:43:57 EST(-0500)] <colinclark> With Gears perhaps taking the lead on that front.
[11:44:07 EST(-0500)] <colinclark> UI Options will continue to grow based on Gary's wireframes.
[11:44:30 EST(-0500)] <colinclark> I expect the Renderer to grow somewhat as well
[11:44:58 EST(-0500)] <colinclark> I'd like to get the framework in a spot where we've made any last crucial API changes.
[11:45:14 EST(-0500)] <colinclark> Ideally, 0.8/0.9 will be the point at which our core API is frozen for 1.0.
[11:45:44 EST(-0500)] <colinclark> justin_o: How does that sound? Ambitious? Realistic?
[11:46:09 EST(-0500)] <colinclark> The good news is that it's largely just the evolution of products we've already established.
[11:47:04 EST(-0500)] <michelled> it sounds a bit ambitions but not ridiculously so
[11:47:15 EST(-0500)] <anastasiac> ambitious (smile)
[11:47:21 EST(-0500)] <colinclark> That's why we called it a "wish list." (wink)
[11:47:23 EST(-0500)] <justin_o> i like michelled's wording
[11:47:26 EST(-0500)] <colinclark> We knew we'd be pushing the team a bit.
[11:47:46 EST(-0500)] <colinclark> I'll tell you my own personal priorities...
[11:47:52 EST(-0500)] <colinclark> which I hope are realistic. (smile)
[11:47:58 EST(-0500)] <michelled> I was wondering if we'd want to cut 0.8 a week before the end of Feb since we'll have a lot of loose ends to tie up for 1.0
[11:48:05 EST(-0500)] <colinclark> 1. Steady growth for UI Options.
[11:48:15 EST(-0500)] <colinclark> 2. Stability and awesomeness for Uploader
[11:48:30 EST(-0500)] <colinclark> 3. Pager growing and helping to drive changes to the Renderer.
[11:48:48 EST(-0500)] <colinclark> michelled: I think that probably makes sense.
[11:49:03 EST(-0500)] <colinclark> Many of us will continue to work on Fluid 1.0 deliverables past April, I expect.
[11:49:43 EST(-0500)] <michelled> do you mean 1.x deliverables?
[11:49:57 EST(-0500)] <michelled> or are you suggesting that 1.0 may not be cut at the end of March?
[11:50:16 EST(-0500)] <colinclark> michelled: Yes, sorry.
[11:50:25 EST(-0500)] <colinclark> I mean "Fluid Educate" deliverables.
[11:50:31 EST(-0500)] <colinclark> As opposed to Fluid Engage.
[11:50:41 EST(-0500)] <colinclark> We'll definitely cut 1.0 at the end of March.
[11:50:46 EST(-0500)] <michelled> docs/workshops etc?
[11:50:56 EST(-0500)] <colinclark> No, sorry.
[11:51:17 EST(-0500)] <colinclark> "Fluid Educate" is the name Jess and I have retroactively been using to describe the first round of the Fluid Project.
[11:51:18 EST(-0500)] * michelled thinks colinclark has been living in the grant cave for too long
[11:51:22 EST(-0500)] <colinclark> (tongue)
[11:51:36 EST(-0500)] <fj4000> you mean the bathroom
[11:51:43 EST(-0500)] <colinclark> (tongue)
[11:51:57 EST(-0500)] <colinclark> michelled: Am I making sense, re: Fluid Educate?
[11:51:59 EST(-0500)] <michelled> ya, that makes sense.
[11:52:26 EST(-0500)] <michelled> and of course Infusion will continue to move forward throughout the Engage timeframe
[11:52:26 EST(-0500)] <colinclark> We wanted to make a distinction between our work with the user experience of higher education software vs. museum visitor experience.
[11:52:34 EST(-0500)] <colinclark> Yep, exactly.
[11:52:48 EST(-0500)] <colinclark> Infusion is the medium we're all swimming in for these projects.
[11:53:28 EST(-0500)] <anastasiac> hmm... there's an interesting mental image :-/
[11:53:58 EST(-0500)] <michelled> going back to pushing the renderer forward - what do people think of UI Options depending on it for table of contents?
[11:54:16 EST(-0500)] <colinclark> michelled: +1
[11:54:18 EST(-0500)] <anastasiac> I think any use of the renderer is good
[11:54:30 EST(-0500)] <colinclark> I think it's a nice gentle introduction of the renderer.
[11:54:42 EST(-0500)] <colinclark> Otherwise, how else would you generate the markup for the ToC?
[11:55:26 EST(-0500)] <michelled> I suppose it could be pluggable. and of course there is transformable code that does this already. but I wanted to use the renderer
[11:55:37 EST(-0500)] <michelled> I just wasn't sure if it was ok to create that dependency
[11:56:19 EST(-0500)] <colinclark> michelled: I can't think of any reason. It seems to me that it's a good dependency.
[11:56:32 EST(-0500)] * michelled is happy
[11:56:44 EST(-0500)] <colinclark> The TransformAble code to generate the ToC is quite well-written, but it will seem like "old fashioned" JavaScript to us now.
[11:57:00 EST(-0500)] <colinclark> And it has some fundamental issues in it that will need to be addressed early.
[11:57:06 EST(-0500)] <justin_o> michelled: thinking about yesterdays meeting with gary could the renderer be used to make the ui options dialog as well... that way if a page doesn't fully support a contract they will only see options supported or is this something totally different
[11:57:24 EST(-0500)] <colinclark> By the way, I was interested to read the channel logs last night and see you guys talking about "defaults" for UI Options. Reminds me of the TransformAble days.
[11:57:32 EST(-0500)] <colinclark> And ultimately of the funniest thing we ever built...
[11:57:37 EST(-0500)] <colinclark> The "default defaults."
[11:58:10 EST(-0500)] <anastasiac> ah, yes, default defaults
[11:58:30 EST(-0500)] <anastasiac> justin_o, what you're describing sounds like something we were talking about for collection space
[11:58:35 EST(-0500)] <michelled> justin_o: yes, the plan is that the renderer can be used to generate the UI depending on what's supported
[11:59:03 EST(-0500)] <michelled> but of course we will always support other people creating markup for us as long as they use our contract
[11:59:22 EST(-0500)] <justin_o> i see... thanks
[12:00:27 EST(-0500)] <michelled> just to give others some context - in the conversation with Gary it became clear that 'no preference' was a confusing concept. Gary asked that we enforce a contract with integrators that specify their default for each of the settings in UI Options.
[12:00:53 EST(-0500)] <michelled> We decided that we would implement with this contract and then try out an edge case of someone not conforming.
[12:01:30 EST(-0500)] <colinclark> michelled: How will this contract be expressed?
[12:02:05 EST(-0500)] <michelled> there would still be the defaults in the UI Options component - like all our other components. But what that defaults to is the use of FSS in our template.
[12:02:17 EST(-0500)] <michelled> the contract would be expressed through options
[12:02:22 EST(-0500)] <michelled> in the component
[12:03:06 EST(-0500)] <michelled> so if an integrator used our template out of the box, they would not need to configure the defaults in UI Options.
[12:03:17 EST(-0500)] <michelled> am I making sense?
[12:03:28 EST(-0500)] <colinclark> yep, totally
[12:03:44 EST(-0500)] <colinclark> This sounds identical to the issue we faced back in the PreferAble days which forced us to define a properties file containing the default settings when No Preference was chosen.
[12:03:59 EST(-0500)] <colinclark> Am I correct?
[12:04:26 EST(-0500)] <fj4000> sounds like the exact same thing
[12:04:32 EST(-0500)] <michelled> yes, I think so.
[12:04:38 EST(-0500)] <michelled> default defaults?
[12:05:02 EST(-0500)] <colinclark> Default defaults were the settings to fall back on if the implementer failed to give us any defaults.
[12:05:51 EST(-0500)] <colinclark> I guess in your case you'll have something similar set in the component's defaults?
[12:07:13 EST(-0500)] <michelled> yes, the difference being that I have a template which co-relates to the defaults in the component
[12:08:34 EST(-0500)] <colinclark> co-relates
[12:09:02 EST(-0500)] <michelled> (tongue)
[12:09:07 EST(-0500)] <colinclark> (wink)
[12:09:13 EST(-0500)] <colinclark> It sounded very mathematical.
[12:09:18 EST(-0500)] <colinclark> co-efficient
[12:09:38 EST(-0500)] <michelled> MATH is GOOD like CATTTS
[12:09:44 EST(-0500)] <colinclark> lol
[12:10:41 EST(-0500)] <colinclark> ok, back to the grant cave
[12:10:58 EST(-0500)] <colinclark> justin_o: Let me know your thoughts on dates for the next release whenever you get a chance. No rush.
[12:12:40 EST(-0500)] <justin_o> colinclark: sure... if we release a week before the end of february did you still want to have that focused bug fix time in february or push it to march as part of tying up lose ends
[12:13:19 EST(-0500)] <colinclark> justin_o: I think we should try for some this release, and some more next release.
[12:13:25 EST(-0500)] <colinclark> bugs tend to beget other bugs
[12:13:33 EST(-0500)] <colinclark> or at least the squashing of them reveals new ones
[12:13:39 EST(-0500)] <justin_o> that is very true
[12:13:53 EST(-0500)] <justin_o> so maybe we can do half a week in February
[12:14:04 EST(-0500)] <colinclark> makes sense
[12:14:16 EST(-0500)] <colinclark> i'd suggest assembling your parade list earlier in the cycle
[12:14:21 EST(-0500)] <colinclark> and checking in with devs about it regularly
[12:14:29 EST(-0500)] <colinclark> reminding of the current issues as they're digging around in the code
[12:14:38 EST(-0500)] <colinclark> and giving them a chance to assess which ones might be easy or hard
[12:14:45 EST(-0500)] <colinclark> even before the parade actually starts
[12:14:57 EST(-0500)] <justin_o> makes sense... i'd also like the devs to go through and determine which bugs should be "Escalated"
[12:15:09 EST(-0500)] <justin_o> then we can set those aside
[12:16:11 EST(-0500)] <colinclark> that makes sense
[12:16:21 EST(-0500)] <colinclark> you'll have to ping everyone about that
[12:16:33 EST(-0500)] <colinclark> some of us are notorious for forgetting to do those sorts of things
[12:16:38 EST(-0500)] <colinclark> umm... not me, of course (tongue)
[12:16:42 EST(-0500)] <justin_o> yah... i figured that... (smile)
[12:16:54 EST(-0500)] <justin_o> is there somewhere i can find out who is the lead on each component
[12:17:12 EST(-0500)] <colinclark> on the top of the whiteboard behind you
[12:17:26 EST(-0500)] <colinclark> We should create a wiki page with that information.
[12:17:35 EST(-0500)] <justin_o> okay... thanks.... i'm working at home today but i get the idea
[12:17:43 EST(-0500)] <colinclark> oh, yes, sorry
[12:17:51 EST(-0500)] <colinclark> I don't know what to call it, because I don't want to put too fine a point on being a component co-lead.
[12:17:58 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[12:18:06 EST(-0500)] <colinclark> it's sort of "the person to talk to about component x"
[12:18:18 EST(-0500)] <colinclark> the leads seem to change organically based on who is busy with what
[12:18:18 EST(-0500)] <justin_o> maybe like a contact person
[12:18:21 EST(-0500)] <colinclark> yeah
[12:18:25 EST(-0500)] <colinclark> there are design co-leads as well
[12:18:33 EST(-0500)] <colinclark> we'll make a wiki page
[12:18:52 EST(-0500)] <justin_o> did you want to have a directory page for it or should they be listed on the component landing pages
[12:21:03 EST(-0500)] <colinclark> justin_o: Good question.
[12:21:06 EST(-0500)] <colinclark> I dunno.
[12:22:08 EST(-0500)] <justin_o> maybe i'll make a simple directory page to start and it can be refined later
[12:22:42 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[12:28:48 EST(-0500)] <michelled> from the top left corner of the whiteboard:
[12:28:59 EST(-0500)] <michelled> UIOptions: Michelle & Jacob
[12:29:12 EST(-0500)] <michelled> Uploader: Eli & Colin [Michelle]
[12:29:22 EST(-0500)] <michelled> Pager: Boz & Michelle
[12:29:32 EST(-0500)] <michelled> Inline Edit: Colin & Boz
[12:29:43 EST(-0500)] <michelled> Reorderer: Boz & Michelle
[12:30:07 EST(-0500)] <michelled> that's my name a lot but I don't know that I can speak to many of the components yet
[12:30:27 EST(-0500)] <justin_o> michelled: thanks... I was just going to say that it seems like you have to look after most of them
[12:30:53 EST(-0500)] <justin_o> did you not want me to put your name next to some of them.. i.e. uploader
[12:31:24 EST(-0500)] <michelled> ya, I think the square brackets must have meant 'eventually'
[12:31:28 EST(-0500)] <michelled> (wink)
[12:31:50 EST(-0500)] <justin_o> okay... well it can be changed when eventually happens (smile)
[12:31:58 EST(-0500)] <michelled> yes
[12:31:58 EST(-0500)] <justin_o> i'll leave it off for now
[12:32:52 EST(-0500)] <michelled> fj4000 is giving a CSS class right now
[12:33:27 EST(-0500)] <justin_o> in the fluid room or with Jutta
[12:37:26 EST(-0500)] <michelled> in the fluid room
[12:38:47 EST(-0500)] <anastasiac> so michelled, you're a 'contact person' for pager
[12:39:00 EST(-0500)] <anastasiac> do you know the status of the 'sakai-site-setting' sample code?
[12:39:11 EST(-0500)] <anastasiac> should it work?
[12:40:28 EST(-0500)] <colinclark> anastasiac: sakai-site-setting is Antranig's progressive attempt at supporting the first use case from Sakai 3 for a pager.
[12:40:36 EST(-0500)] <colinclark> They're currently using the YUI data grid, I believe.
[12:40:48 EST(-0500)] <colinclark> So he set up that sample as a way to track progress on that use case.
[12:40:53 EST(-0500)] <anastasiac> ok, I suspected something like that
[12:40:58 EST(-0500)] <colinclark> If it's shipped in the sample code directory, it should work.
[12:41:05 EST(-0500)] <anastasiac> it doesn't work, so I figured it was a work in progress
[12:41:30 EST(-0500)] <colinclark> That's a bug.
[12:41:36 EST(-0500)] <michelled> we should probably move it to the manual tests
[12:42:11 EST(-0500)] <colinclark> It's missing a Sakai dependency or two.
[12:42:34 EST(-0500)] <colinclark> Yep, it should move until it's working as a reasonable piece of something we might or might not call "sample code."
[12:45:45 EST(-0500)] <michelled> justin_o: when you set up the QA for a release, do you ensure all the samples in the sample-code folder work? This may be something we should add if not. They don't all need to be tested on all platforms but we should probably check them all on some supported platform
[12:46:17 EST(-0500)] <justin_o> you mean for the release package
[12:55:08 EST(-0500)] <michelled> well, I just meant so samples don't sneak in
[12:55:45 EST(-0500)] <michelled> developer should be careful with what they put into sample-code
[12:55:53 EST(-0500)] <michelled> but I guess I wanted a safety net
[13:22:10 EST(-0500)] <justin_o> michelled: do you mean that you just want to test to make sure they load without errors?
[13:24:44 EST(-0500)] <colinclark> That was fun with the cats and dogs at standup today.
[13:26:48 EST(-0500)] * everettz (n=chatzill@fctnnbsc16w-156034212126.pppoe-dynamic.nb.aliant.net) has joined #fluid-work
[13:27:23 EST(-0500)] <everettz> Good afternoon, can anyone point me to a browser agnostic copy to clipboard script? Really needs to only work in FF3 and IE7+
[13:27:49 EST(-0500)] <colinclark> everettz: Can you tell us more about what you're looking for?
[13:28:20 EST(-0500)] <everettz> colinclark: Yes, on the Credibility 2.0 site I need a script to copy text from a textarea to the clients clipboard.
[13:28:49 EST(-0500)] <colinclark> everettz: You want to do this programatically, without requiring the user to hit Ctrl/Cmd-C, then?
[13:29:14 EST(-0500)] <everettz> colinclark: We have a bookmarklet for the site and there does not appear to be a keyboard only method of adding it to the Bookmarks menu. So I had to write manual instructions, including copying the javascript code for the bookmarklet.
[13:29:39 EST(-0500)] <everettz> colinclark: yes, by clicking on a "copy to clipboard" button.
[13:29:40 EST(-0500)] <colinclark> Hmmm.
[13:30:17 EST(-0500)] <colinclark> everettz: What does the bookmarklet do?
[13:33:21 EST(-0500)] <everettz> colinclark: If a user is on another page. google.ca for example, and activates the bookmarklet, it takes them to our site and prepopulates some fields to create a post about the site they were just on, prepopulates title, url and any selected text in the browser goes into the Comments field.
[13:33:57 EST(-0500)] <colinclark> everettz: Cool.
[13:34:30 EST(-0500)] <colinclark> Unfortunately I haven't found any copy to clipboard scripts that are truly cross-platform.
[13:34:41 EST(-0500)] <colinclark> The only one I've encountered that apparently succeeds at is uses Flash.
[13:34:49 EST(-0500)] <everettz> colinclark: I did just find a keyboard method, but it won't work for all AT. if you tab to the bookmarklet on our site and press applications / property key you can choose to add link to bookmarks. But, not all ATs will likely know that the link has been selected, proper context for the properties menu. And, most aT users don't tab navigate.
[13:35:14 EST(-0500)] <everettz> colinclark: I knwo that opy to clipboard is possible, just never had to do it before. I thought someone in here may have used the function, if not I can google it.
[13:35:56 EST(-0500)] <colinclark> everettz: I've been googling while we talked, and it looks like all the scripts that do it in a truly cross-platform way end up resorting to Flash.
[13:36:13 EST(-0500)] <colinclark> http://ajaxian.com/archives/auto-copy-to-clipboard
[13:36:33 EST(-0500)] <everettz> colinclark: Does the user have to interact with the flash, or can it be done using an xhtml button and a call to the flash object?
[13:36:51 EST(-0500)] <colinclark> everettz: It looks like the user interface doesn't have to be Flash-based.
[13:37:19 EST(-0500)] <colinclark> But you'd have to do some careful testing; Flash 10 has introduced a number of restrictions with this sort of things do to "security" reasons.
[13:37:22 EST(-0500)] <colinclark> It's immensely frustrating.
[13:37:23 EST(-0500)] <everettz> colinclark: Ok, I'll look that up, it's a bit of a low priority now that I've found the tab navigation method.
[13:37:31 EST(-0500)] <everettz> colinclark: Thanks for your help.
[13:37:49 EST(-0500)] <colinclark> everettz: Any time.
[13:41:24 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[13:48:50 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[13:49:46 EST(-0500)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:49:56 EST(-0500)] <Bosmon> Hello there
[14:15:16 EST(-0500)] * lessthanzero (n=lessthan@wcpbarri501bryne.grokspots.com) has joined #fluid-work
[14:17:06 EST(-0500)] * lessthanzero (n=lessthan@wcpbarri501bryne.grokspots.com) has joined #fluid-work
[14:17:41 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[14:55:05 EST(-0500)] * lessthanzero (n=lessthan@wcpbarri501bryne.grokspots.com) has joined #fluid-work
[15:02:50 EST(-0500)] * lessthanzero_ (n=lessthan@wcpbarri501bryne.grokspots.com) has joined #fluid-work
[15:07:51 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[15:08:15 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[15:22:25 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[15:35:48 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[16:10:43 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[16:48:25 EST(-0500)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[17:48:30 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[18:28:03 EST(-0500)] * lessthanzero (n=lessthan@74.13.33.37) has joined #fluid-work
[20:12:21 EST(-0500)] * lessthanzero (n=lessthan@74.13.33.37) has joined #fluid-work