fluid-work IRC Logs-2012-09-28

[09:31:21 CDT(-0500)] <Justin_o> cindyli: what do you prefer for the directory that will hold all the pictures. "images" or "captures"

[09:31:36 CDT(-0500)] <cindyli> captures, Justin_o

[09:31:58 CDT(-0500)] <Justin_o> cindyli: okay.. i'll go with that

[09:32:12 CDT(-0500)] <cindyli> cool. thanks, Justin_o

[09:51:18 CDT(-0500)] <Justin_o> cindyli: i committed the directory changes

[09:51:36 CDT(-0500)] <cindyli> thanks, Justin_o, i will merge in

[09:51:51 CDT(-0500)] <Justin_o> cindyli: i'm going to work on export now to add in the feature where it won't reexport if one exists and no changes have been amde

[09:52:37 CDT(-0500)] <cindyli> ok, Justin_o

[10:15:43 CDT(-0500)] <cindyli> Justin_o: I'm thinking if we should have one more URL request for each capture type to return whether the camera status meets all the criteria that are required for that type.

[10:16:18 CDT(-0500)] <Justin_o> cindyli: what would that look like?

[10:17:42 CDT(-0500)] <cindyli> Justin_o: like http://localhost:8081/stereo/canCapture

[10:19:33 CDT(-0500)] <cindyli> Justin_o: the reason we need that is 'cuz when users get to the capture page, we need to know if the capture can be performed. If not, why

[10:19:41 CDT(-0500)] <Justin_o> cindyli: maybe it needs to be in http://localhost:8081/cameras/

[10:20:00 CDT(-0500)] <cindyli> Justin_o: that only returns generic camera infos

[10:20:01 CDT(-0500)] <Justin_o> so as part of the return of what cameras are connected it can also say what types of captures are available

[10:20:55 CDT(-0500)]

[10:20:57 CDT(-0500)] <Justin_o> something like that

[10:21:01 CDT(-0500)] <cindyli> but how do you return different errors for particular captures?

[10:21:39 CDT(-0500)] <Justin_o> cindyli: i suppose some of those errors would have been the result of expection thrown while trying to perform a capture

[10:44:32 CDT(-0500)] <jessm> fluid-everyone: sorry to miss standup

[10:44:59 CDT(-0500)] <jessm> i'm working on the RFP, doing some costing proposal work with Avtar, kicking off the DoE grant for Floe today with ISKME, and talking to Dana about jumping into CMHR

[11:06:59 CDT(-0500)] <Justin_o> cindyli: i pushed my latest changes up

[11:07:14 CDT(-0500)] <cindyli> thanks, Justin_o, will merge

[13:02:27 CDT(-0500)] <alexn1> colinclark: I have been working on https://www.assembla.com/spaces/iskme/tickets/798#/activity/ticket:798. Even though the issue sounds pretty straightforward and simple I had to change almost every single file type possible to fix this: coffeescript, javascript, html markup and django. It took some time and here is my branch https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-798

[13:04:51 CDT(-0500)] <colinclark> thanks, alexn1

[13:04:56 CDT(-0500)] <alexn1> colinclark: even without code refactoring it took me a while to make changes in the context of the existing code base. It seems that some of the widgets in OER Commons look similar and might be refactored into something more simpler. I did not spend time doing it (yet) since it can take good amount of time to do so since it will touch lots of places in the code base

[13:05:13 CDT(-0500)] <colinclark> ok

[13:07:38 CDT(-0500)] <colinclark> Just to save a bit of time-I'm a bit distracted with other work-can you fire me a link to a diff view that shows me all your changes, alexn1?

[13:07:51 CDT(-0500)] <alexn1> let me know what you think about the change whenever you have a minute. I personally think that it is maybe we should push the screen reader changes for the upcoming OER Commons release but then communicate to Andrey about the possibility of the code refactoring or do the code refactoring ourselves ( if we would have more time ti work on OER Commons).

[13:08:03 CDT(-0500)] <alexn1> colinclark: yes sure

[13:08:21 CDT(-0500)] <alexn1> colinclark: let me know if you can view them here https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-798

[13:08:39 CDT(-0500)] <colinclark> yup, thanks

[14:37:09 CDT(-0500)] <alexn1> colinclark: ayt? do you have few minutes? I have a little problem here and I'm not sure how it should be approached.

[14:37:25 CDT(-0500)] <colinclark> sure, fire away

[14:38:00 CDT(-0500)] <alexn1> I was testing one of my branches for OER Commons. Here it is https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-795 for the ticket https://www.assembla.com/spaces/iskme/tickets/795#/activity/ticket:795

[14:38:27 CDT(-0500)] <alexn1> in a nutshell an author name dialog did not scale when user changed UIO Text Size options

[14:38:45 CDT(-0500)] <alexn1> if my branch is applied then the problem goes away

[14:39:14 CDT(-0500)] <alexn1> but I noticed one little thing in UI.

[14:39:51 CDT(-0500)] <alexn1> The thing that position of this dialog is set only once and set depending where a special html element is located https://github.com/ISKME/OER-Commons/blob/master/project/media/javascripts/authoring/submit.js#L104-107

[14:40:25 CDT(-0500)] <alexn1> Hence if you show up the dialog and then start changing Text Size it would look shifted on the screen as on the following 2 screenshots I made

[14:40:36 CDT(-0500)] <alexn1> https://dl.dropbox.com/u/14022781/Screen%20Shot%202012-09-28%20at%202.15.39%20PM.png

[14:40:43 CDT(-0500)] <alexn1> https://dl.dropbox.com/u/14022781/Screen%20Shot%202012-09-28%20at%202.16.04%20PM.png

[14:41:06 CDT(-0500)] <alexn1> I know it is lots of information but my questions are ...

[14:42:03 CDT(-0500)] <alexn1> first one - do I need to take care of this UI layout in the OER Commons floe integration sprint ?

[14:54:11 CDT(-0500)] <alexn1> colinclark: you might have questions about what I just typed. Feel free to ask them if any. And if it looks as it might require more than few minutes we can chat through this issue another time.

[14:54:28 CDT(-0500)] <colinclark> sorry, i was distracted

[14:54:31 CDT(-0500)] <colinclark> i'll try to catch up

[14:55:39 CDT(-0500)] <colinclark> Ah, I see the issue

[14:56:31 CDT(-0500)] <colinclark> You've got a tooltippy, dialoggy thing that is positioned using pixels in some code.

[14:56:50 CDT(-0500)] <colinclark> And so it doesn't move as the overall page grows

[14:57:01 CDT(-0500)] <colinclark> It's a bit of a problem, isn't it?

[14:57:53 CDT(-0500)] <alexn1> colinclark: it is indeed

[14:58:15 CDT(-0500)] <colinclark> Can you modify this code to position the tooltip in a way that will scale relative to the rest of the page?

[14:58:59 CDT(-0500)] <alexn1> colinclark: I was thinking about it but could not come up with a nice solution yet

[15:00:03 CDT(-0500)] <colinclark> Could you convert the dimension of the element it's anchored to into ems, and then position it that way?

[15:00:05 CDT(-0500)] <alexn1> The following 3 things would change dialog position to be a wrong one - Text Size change, Line spacing change and Sliding of the UIO Panel

[15:00:23 CDT(-0500)] <alexn1> colinclark: I tried it the first thing but it did not work

[15:01:01 CDT(-0500)] <alexn1> + even if there was the way, UIO Panel sliding + line spacing change would still break the position

[15:02:18 CDT(-0500)] <colinclark> why is that, specifically, alexn1?

[15:05:32 CDT(-0500)] <alexn1> Well I will take Panel sliding as an example. You showed your dialog at the position lets say 100em, 100em. Then you click to show the panel and it slided. No text sizes or line spacing were changed. But all the HTML elements moved to the bottom of the screen to the size = UIO Panel hieght. Since there is no dynamic position recalculation for the dialog it still would be shown at the position 100em, 100em.

[15:16:16 CDT(-0500)] <colinclark> and the dialog won't slide along with everything else because it's floating in a layer above everything else?

[15:16:33 CDT(-0500)] <alexn1> colinclark: that is correct

[15:40:44 CDT(-0500)] <colinclark> alexn1: The bug is a pretty big one, but it sounds like it's going to take some research.

[15:40:55 CDT(-0500)] <colinclark> There must be responsive design techniques for these sorts of issues

[15:41:22 CDT(-0500)] <colinclark> I think we should check in with michelled to get a sense of the priorities

[15:41:44 CDT(-0500)] <colinclark> but I don't love introducing new bugs while fixing old ones. We'll have to weigh which one has the greater user experience cost

[15:42:05 CDT(-0500)] <alexn1> colinclark: it is a pretty big one for sure that is why I wanted to double check if I need to spend more time looking into it.