fluid-work IRC Logs-2010-10-04

[08:54:29 CDT(-0500)] <jameswy> golam, greggy, harriswong, heidi_, jamon, jessm, jhung, Justin_o, yura_, zafar: welcome JenC to the channel, (smile)
[08:54:49 CDT(-0500)] <heidi_> welcome JenC !!!!
[08:54:51 CDT(-0500)] <Justin_o> JenC: Welcome
[08:54:56 CDT(-0500)] <golam> welcome JenC
[08:55:02 CDT(-0500)] <harriswong> welcome JenC!!!!!!!!!!!!!!!!!!
[08:55:03 CDT(-0500)] <heidi_> ocad student?
[08:55:03 CDT(-0500)] <jhung> Hi JenC! (smile)
[08:55:11 CDT(-0500)] <jessm> hiya JenC
[08:55:18 CDT(-0500)] <jessm> that's a lot of welcomes!
[08:56:19 CDT(-0500)] <greggy> JenC: welcome JenC
[08:56:50 CDT(-0500)] <JenC> thanks and hi, heidi_, justin_o, golam, harriswong, jhung, jessm, and yep, I'm an OCAD grad student (smile)
[08:57:59 CDT(-0500)] <jessm> JenC: glad to have you aboard! I'm looking forward to your contributions to our many design deliverables!
[09:14:08 CDT(-0500)] <jhung> does the Uploader demo work for anyone? http://build.fluidproject.org/infusion/demos/uploader/demo.html
[09:15:49 CDT(-0500)] <Justin_o> jhung: doesn't seem to be... colin is doing some major refactoring on uploader at the moment...
[09:15:57 CDT(-0500)] <jhung> okay.
[09:16:38 CDT(-0500)] <Justin_o> jhung: if you need to see it in action, you can check out the 1.2.1 demos http://fluidproject.org/releases/1.2.1/demos/uploader/demo.html
[09:17:21 CDT(-0500)] <jhung> justin_o: thanks.
[09:17:27 CDT(-0500)] <Justin_o> np
[09:43:58 CDT(-0500)] <mlam> jhung: you have a minute?
[09:44:13 CDT(-0500)] <jhung> mlam: sure
[09:44:54 CDT(-0500)] <mlam> for the inline edit option of adding a tooltip instead of describedby text...would we ever want to display the tooltip?
[09:45:32 CDT(-0500)] <mlam> or would we want to toggle the display depending on what mode we're in? or would it be best to always display the tooltip offscreen?
[09:45:37 CDT(-0500)] <jhung> mlam: Yes because for a novice sighted user, it may not be obvious how to end their editing.
[09:45:56 CDT(-0500)] <mlam> ok, so always display it?
[09:46:56 CDT(-0500)] <jhung> mlam: Yes, default is always display the tooltip it, but make it configurable (enable/disable, reveal delay). jameswy, this sound about right to you?
[09:47:48 CDT(-0500)] <jameswy> mlam, jhung: What do you mean by "always"? On-hover always, or always-always?
[09:47:58 CDT(-0500)] <mlam> always-always
[09:48:40 CDT(-0500)] <mlam> jhung, jameswy: is the optimal location for the tooltip immediately after the inline edit component?
[09:48:47 CDT(-0500)] <jameswy> mlam, jhung: I'm inclined to say no to always-always, and yes to on-hover always.
[09:49:16 CDT(-0500)] <Justin_o> jameswy: i do you mean on focus always?
[09:50:19 CDT(-0500)] <jameswy> mlam: Immediately after the component unless it ends flush to the right side of the screen; immediately below in the case it's flush against the right; and immediately above if it's flush against the right and bottom.
[09:50:42 CDT(-0500)] <jameswy> mlam: But, if we're strapped for time, immediately to the right, (smile)
[09:51:14 CDT(-0500)] <mlam> jameswy: and what about on focus?
[09:51:20 CDT(-0500)] <mlam> display the tooltip as well?
[09:52:55 CDT(-0500)] <jhung> mlam: good question. On focus would mean it would display always, no?
[09:53:24 CDT(-0500)] <mlam> jhung : on focus meaning its' in edit mode
[09:53:37 CDT(-0500)] <jameswy> Justin_o: on focus and on hover both.
[09:53:44 CDT(-0500)] <jameswy> mlam: ^
[09:54:13 CDT(-0500)] <jameswy> mlam: Wait. Now I'm confused.
[09:54:29 CDT(-0500)] <jameswy> mlam, Justin_o, jhung: can we hop on Skype for a minute to deconfuse me?
[09:54:36 CDT(-0500)] <Justin_o> jameswy: well on focus in this case would be equivalent to always while in edit mode
[09:54:48 CDT(-0500)] <Justin_o> sure
[09:54:50 CDT(-0500)] <mlam> sure
[09:54:58 CDT(-0500)] <jhung> k
[10:56:22 CDT(-0500)] <colinclark> jhung: So, how much do you think we need a new Uploader demo?
[10:57:10 CDT(-0500)] <jhung> colinclark: That question crossed my mind.
[10:57:48 CDT(-0500)] <colinclark> There are certainly some things we could play around with in HTML 5 to preview uploaded files even when they haven't really been uploaded to a real server
[10:57:58 CDT(-0500)] <colinclark> But it wouldn't work in all our A-Grade browsers, unfortunately
[10:58:23 CDT(-0500)] <jhung> colinclark: Yeah.
[10:58:27 CDT(-0500)] <colinclark> Certainly we know the file names and sizes, so we could probably imagine some kind of summary page after the upload is finished, even when we can't quite preview the actual contents
[10:58:29 CDT(-0500)] <mlam> colinclark: we have a question about the tooltip for inline edit. do we want to give the user an option to provide their own tooltip ?
[10:58:47 CDT(-0500)] <colinclark> But I don't mind the Uploader demo so much as it stands. It could perhaps use some tweaks and improvements, but it's relatively clear what it does
[10:58:53 CDT(-0500)] <colinclark> Some instructions, among other things, might help.
[10:59:12 CDT(-0500)] <jhung> colinclark: thinking the same thing.
[10:59:30 CDT(-0500)] <colinclark> mlam: When you say "provide their own tooltip," do you mean, their own text for the tooltip? Their own markup? A different tooltip plugin than the one we use?
[11:00:21 CDT(-0500)] <jhung> colinclark: I think whatever improvements are done will just be on the existing demo (ie. not a new demo design).
[11:00:23 CDT(-0500)] <mlam> colinclark: as in provide their own selector to represent the tooltip within the component
[11:01:52 CDT(-0500)] <colinclark> Well, I guess maybe there's a larger question here? What's the relationship between this new tooltip and the one the component already has?
[11:02:52 CDT(-0500)] <colinclark> jhung: Makes sense to me
[11:03:28 CDT(-0500)] <mlam> the original tooltip was created by using the jQuery plugin which is likely not to be accessible. our injected tooltip is.
[11:13:06 CDT(-0500)] <colinclark> mlam: So you guys have made your own tooltip component or something?
[11:15:48 CDT(-0500)] <mlam> no, we haven't, but that's what we're trying to decide. is it necessary to create our own component for tooltips?
[11:16:17 CDT(-0500)] <colinclark> What does your thing actually do?
[11:16:38 CDT(-0500)] <mlam> we found this: http://flowplayer.org/tools/tooltip/index.html
[11:16:38 CDT(-0500)] <mlam> but it's not accessible. we're looking into ways of making this accessible.
[11:18:27 CDT(-0500)] <mlam> colinclark: the tooltip is just aria markup for the inline edit. we had a quick meeting with Justin_o, jhung, and jameswy...and it was decided that the tooltip be toggled on and off the screen based on whether or not we are in edit mode.
[11:19:03 CDT(-0500)] <mlam> from this, we ran into the question of whether or not the tooltip should be a selector or not.
[11:19:13 CDT(-0500)] <colinclark> mlam: I just fired Justin_o the new Filament Group book about progressive enhancement
[11:20:10 CDT(-0500)] <colinclark> They've got a tooltip widget, I don't know if it's any good
[11:20:20 CDT(-0500)] <colinclark> but they're much more likely than anyone else in the jQuery world to bother with things like ARIA
[11:40:37 CDT(-0500)] <golam> colinclark: just added the FLUID-3751.patch to the jira FLUID-3751
[11:40:46 CDT(-0500)] <colinclark> golam: Awesome, thanks
[11:44:00 CDT(-0500)] <colinclark> golam: I'm just chatting with Justin_o here...
[11:44:25 CDT(-0500)] <colinclark> It seems to me that if no one objects to this new demo for Progress replacing the old one, we can probably merge the contents of your branch into trunk sooner rather than later
[11:44:32 CDT(-0500)] <colinclark> No point in sitting on things if we're happy with it
[11:44:44 CDT(-0500)] <golam> ok
[11:44:48 CDT(-0500)] <colinclark> Are there any other outstanding tasks or bugs related to Progress itself or its demo?
[11:45:59 CDT(-0500)] <golam> no bugs
[11:46:20 CDT(-0500)] <golam> there isn't any event handler for the progress component
[11:47:05 CDT(-0500)] <golam> the progress component doesn't through any events when the progress is complete
[11:50:40 CDT(-0500)] <colinclark> right
[11:50:52 CDT(-0500)] <colinclark> That is a bug, and one we should contemplate fixing
[11:51:05 CDT(-0500)] <colinclark> I don't know if the King will want us to add it to the bug parade, but it's worth asking him
[11:51:28 CDT(-0500)] <colinclark> Can you check to see if there is already a bug about the fact that, using progress.hide(), there's no way to know when it's finished hiding?
[11:51:33 CDT(-0500)] <colinclark> And if not, go ahead and file one
[11:54:03 CDT(-0500)] <golam> colinclark: I did a search with progress.hide() and nothing came up
[11:54:08 CDT(-0500)] <colinclark> ok
[11:55:17 CDT(-0500)] <golam> colinclark: is that a bug or improvement
[11:55:26 CDT(-0500)] <colinclark> I'd call it a bug, myself
[11:55:31 CDT(-0500)] <golam> ok cool
[11:55:45 CDT(-0500)] <colinclark> The fact that Progress has this hide() method, but users have no way of knowing when it's done--that's a bug rather than a new feature (smile)
[11:57:55 CDT(-0500)] <colinclark> Justin_o: This is, I think, the tooltip we currently use http://bassistance.de/jquery-plugins/jquery-plugin-tooltip/
[11:58:06 CDT(-0500)] <Justin_o> colinclark: thanks
[11:58:21 CDT(-0500)] <colinclark> Yep, that's the one
[11:58:49 CDT(-0500)] <colinclark> I think we should probably just patch it directly and share our contributions back with Jörn
[11:58:53 CDT(-0500)] <colinclark> He's quite nice
[12:29:41 CDT(-0500)] <jhung> colinclark, justin_o, mlam, golam: I'm going to take this afternoon off sick. Anything urgent I should look at before I go?
[12:29:55 CDT(-0500)] <colinclark> Not that I know of, jhung
[12:30:01 CDT(-0500)] <mlam> jhung: I think we're good, thanks
[12:30:03 CDT(-0500)] <golam> same here
[12:30:05 CDT(-0500)] <mlam> hope you feel better soon
[12:30:17 CDT(-0500)] <jhung> thanks. See y'all tomorrow
[12:54:25 CDT(-0500)] <greggy> jamon:osu is working fine
[12:57:03 CDT(-0500)] <jamon> greggy: great, mail time
[13:33:45 CDT(-0500)] <justin_o> anastasiac, colinclark: I'm in the process of updating bug parade, I should be adding the jiras you both mentioned to the parade on the next update
[13:33:57 CDT(-0500)] <anastasiac> thanks!
[13:34:03 CDT(-0500)] <colinclark> great
[13:34:28 CDT(-0500)] <colinclark> So, anastasiac, was I making any sense with the idea of a task specifically to create a document that lists new sneak peek sutff?
[13:34:50 CDT(-0500)] <colinclark> As opposed to feeling pressure to actually finish all the documentation itself, what we most need is just a comprehensive list of what fits into that category
[13:37:26 CDT(-0500)] <anastasiac> colinclark, sure - that makes sense. I've actually almost finished that task, but having a specific JIRA is probably a good idea
[13:37:33 CDT(-0500)] <colinclark> awesome
[13:38:08 CDT(-0500)] <colinclark> I just want to make sure it doesn't get forgotten for the release. We should probably do one last comb-through of the source code after code freeze to make sure that document is up to date
[13:43:37 CDT(-0500)] <anastasiac> colinclark, definitely! I've also got a watch on many of the bug-parade issues, so that if I see fixes that are changing APIs, I can keep on top of it
[13:43:44 CDT(-0500)] <colinclark> awesome
[14:02:05 CDT(-0500)] <mlam> colinclark: we tried running two tooltip instances using the tooltip plugin and we found that only 1 instance can run at a time.
[14:02:31 CDT(-0500)] <colinclark> you're kidding
[14:03:04 CDT(-0500)] <mlam> yah, whichever instance is run first, dominates the 2nd instance...the second instance just gets ignored
[14:04:03 CDT(-0500)] <colinclark> Sounds like that plugin is fatally broken
[14:04:14 CDT(-0500)] <mlam> a tooltip component is sounding pretty good? (smile)
[14:04:30 CDT(-0500)] <colinclark> I'm not sure good is quite the right word, but it might be our best option (smile)
[14:05:06 CDT(-0500)] <mlam> yah, i looked through the plugin code and it doesn't look very malleable.
[14:06:36 CDT(-0500)] <mlam> what do you think? should we continue looking for a tooltip solution ?
[14:09:22 CDT(-0500)] <colinclark> Take a quick look to see if there's anything better
[14:09:37 CDT(-0500)] <colinclark> but I'm leaning towards using the Filament Group's plugin as a model for something a little more robust
[14:10:21 CDT(-0500)] <colinclark> What are you guys leaning towards?
[14:13:21 CDT(-0500)] <mlam> we're not sure. because tooltips are so inter-linked with aria-describedby text, it almost seems that we only have 1 solution.
[14:13:46 CDT(-0500)] <mlam> so perhaps we already have our solution with describedby?
[14:15:46 CDT(-0500)] <colinclark> I don't quite understand
[14:18:58 CDT(-0500)] <mlam> we can't have aria tooltips without the presence of describedby text, because the html element containing the tooltip role has to have an "id" attribute that references the aria-describedby attribute value
[14:19:42 CDT(-0500)] <mlam> so in order to have an accessible tooltip, describedby text has to be present which is already in the first solution that we have.
[14:20:31 CDT(-0500)] <justin_o> colinclark: http://www.w3.org/TR/wai-aria/roles#tooltip
[14:20:46 CDT(-0500)] <mlam> and i guess since the aria tooltip is so dependant on the describedby, it seems that we don't have 2 full solutions to our accessibility issues.
[14:22:23 CDT(-0500)] <colinclark> I think I must be particularly dense today, I'm sorry
[14:30:05 CDT(-0500)] <mlam> colinclark: i put the 2nd tooltip on the button and it still doesn't work (smile)
[14:30:13 CDT(-0500)] <colinclark> yearg
[14:30:18 CDT(-0500)] <colinclark> I wonder why?
[14:30:40 CDT(-0500)] <colinclark> For sanity's sake, I might be tempted to create a simple test page with a few elements and a few tooltips and see if it all works
[14:31:29 CDT(-0500)] <mlam> let us do some more research before we waste any more of your time
[14:35:18 CDT(-0500)] <colinclark> You're not wasting my time at all!
[15:49:45 CDT(-0500)] <mlam> colinclark: the tooltip plugin looks for the title attribute of any element . so if the title attribute value is different, the tooltip will adjust accordingly
[16:11:03 CDT(-0500)] <justin_o> jamon: the wiki and jira are running slow again
[16:11:38 CDT(-0500)] <anastasiac> jamon, yes: the wiki is extremely slow