fluid-work IRC Logs-2012-10-01

[07:24:39 CDT(-0500)] <Bosmon> Justin_o - Rewriting the framework has revealed some interesting bugs in TableOfContents.js : P

[07:24:46 CDT(-0500)] <Bosmon> In particular this section at line 97:

[07:24:52 CDT(-0500)] <Bosmon> model: {

[07:24:52 CDT(-0500)]

[07:24:52 CDT(-0500)] <Bosmon> },

[07:24:59 CDT(-0500)] <Bosmon> As written, this codes for a misaligned model, and should really read

[07:25:05 CDT(-0500)] <Bosmon> model: {

[07:25:05 CDT(-0500)]

[07:25:05 CDT(-0500)] <Bosmon> },

[07:25:11 CDT(-0500)]

[07:26:48 CDT(-0500)] <Justin_o> Bosmon: is that because it's taking the parents model and making it a portion of the childs model instead of the other way around

[07:27:06 CDT(-0500)] <Bosmon> Justin_o - it is because it refers to that part of the model under the wrong name

[07:29:21 CDT(-0500)] <Justin_o> Bosmon: hmm.. not sure i'm following what you mean by wrong name

[07:29:53 CDT(-0500)] <Justin_o> Bosmon: Do you think you might have time to write up some docs, if none exist already, about the proper way to do these things

[07:31:44 CDT(-0500)] <Bosmon> Let me see if I haven't been confusing myself....

[07:32:35 CDT(-0500)] <Justin_o> Bosmon: okay… thanks

[07:33:02 CDT(-0500)] <Bosmon> Ok yes, actually it is a combination of issues

[07:33:30 CDT(-0500)] <Bosmon> https://github.com/fluid-project/infusion/blob/master/src/webapp/components/tableOfContents/js/TableOfContents.js#L82

[07:33:41 CDT(-0500)] <Bosmon> The code on this line used to rebind the model reference in the finalInitFunction for the component

[07:34:01 CDT(-0500)] <Bosmon> But this must never happen - otherwise different components in the tree may get hold of different model references

[07:34:34 CDT(-0500)] <Bosmon> As it happens, the model for this component "never really changes over time" so the fact that in one test case it had ONE instance of [] and at a later time referred to a DIFFERENT instance of [] made the case pass

[07:35:02 CDT(-0500)] <Bosmon> But really this line should actually read something like this: that.applier.requestChange("", headingsModel);

[07:35:10 CDT(-0500)] <Bosmon> That is, you should only use the applier to change the component's model

[07:35:17 CDT(-0500)] <Bosmon> And never rebind the model reference after the component has been created

[07:35:28 CDT(-0500)] <Bosmon> But this exposes the issue that the default value for this overall model is {}, not []

[07:35:49 CDT(-0500)] <Bosmon> So this makes the "no headings test case" fail when it finds that it has a model with no length field

[07:36:24 CDT(-0500)] <Bosmon> This is why I suggested it may just be simpler to harmonise the overall model between the top level TOC and the "levels" subcomponent so that they have the same arrangement

[07:36:36 CDT(-0500)] <Bosmon> Certainly it is odd to have models getting BIGGER as you go further down the tree, rather than getting SMALLER....

[07:36:46 CDT(-0500)] <Bosmon> So in that case the line should read as follows: that.applier.requestChange("headings", headingsModel);

[07:37:19 CDT(-0500)] <Bosmon> In both cases, with var headingsModel = that.modelBuilder.assembleModel(headings, that.anchorInfo);

[07:37:31 CDT(-0500)] <Bosmon> (lines 82-84 of TableOfContents.js)

[07:38:59 CDT(-0500)] <Justin_o> Bosmon: that makes sense

[07:40:27 CDT(-0500)] <Bosmon> There's no need to do anything, these fixes will be in the "new framework" when it gets pushed... but I thought it would be useful to report the issue since it is important to "model discipline" in general

[07:40:54 CDT(-0500)] <Bosmon> Dealing with models properly has been a big stumbling block in the reimplementation

[07:43:18 CDT(-0500)] <Justin_o> Bosmon: yes.. good to bring these things up.. so two general principals from this are 1) don't change the model directly, always go through the change applier 2) best practice for models to not grow on the way down through the tree

[07:47:05 CDT(-0500)] <Bosmon> I'm not sure 2) is really a general principle rather than an observation : P

[07:47:24 CDT(-0500)] <Bosmon> If there is a general principle, it might be that it is better to try to stick to models which can tolerate a default value of {}

[07:47:46 CDT(-0500)] <Bosmon> Since it might be difficult in general to override it properly if you want a different one

[07:49:56 CDT(-0500)] <Justin_o> Bosmon: okay.. so models should generally always be objects

[07:50:07 CDT(-0500)] <Justin_o> and not other containers like arrays

[07:50:38 CDT(-0500)] <Bosmon> I think the use of array models might lead to problems, yes

[07:52:20 CDT(-0500)] <Justin_o> Bosmon: that's good to be aware of.. i figure typically models align themselves to being objects anyways.. so probably not something that's too hard to follow

[07:52:56 CDT(-0500)] <Bosmon> At least in this case it did...

[07:53:14 CDT(-0500)] <Bosmon> It's possible it might have worked out if the default value were set to [] explicitly in the defaults...

[07:54:34 CDT(-0500)] <Bosmon> Yes, it looks like that does work

[07:54:47 CDT(-0500)] <Bosmon> So yes, perhaps models of [] aren't completely evil

[07:55:01 CDT(-0500)] <Bosmon> But the fact there was an ambiguity here was eventually problematic

[08:02:57 CDT(-0500)] <Justin_o> Bosmon: i see

[09:35:46 CDT(-0500)] <colinclark> alexn: In terms of your question last week, I'm wondering if you can do an hour or two's worth of research to see if you can find some advice about doing responsive design with layers like this.

[09:35:59 CDT(-0500)] <colinclark> I'm sure we're not the first people who have run into an issue like this

[09:36:29 CDT(-0500)] <alexn> colinclark: will sure do.

[09:37:02 CDT(-0500)] <colinclark> thanks!

[09:58:09 CDT(-0500)] <Justin_o> cindyli: i've created a utility for zipping and made use of it in conventional.py

[09:58:46 CDT(-0500)] <cindyli> thanks, Justin_o

[09:59:22 CDT(-0500)] <Justin_o> i'll move on to those functions for finding the images and deleting them

[10:10:17 CDT(-0500)] <jhung> justin_o, cindyli: I was thinking some more about the UI behaviour of the Export and Restart accordions. I think it would be better to hide the accordion when it loses focus. Otherwise, it's possible to have the Restart accordion open all the time, which I think may cause some user concerns.

[10:12:07 CDT(-0500)] <Justin_o> jhung: how would that look

[10:12:18 CDT(-0500)] <Justin_o> jhung: i'm trying to remember what our concern was

[11:26:49 CDT(-0500)] <alexn> colinclark: ayt?

[11:29:16 CDT(-0500)] <colinclark> i'm in a call at the moment

[11:31:34 CDT(-0500)] <alexn> colinclark: ok. ping me whenever you have few free minutes. it is about oer-795 floating dialog

[11:32:16 CDT(-0500)] <jhung> cindyli, let's meet tomorrow morning to take a second look at the Decapod 0.7 roadmap.

[11:36:31 CDT(-0500)] <colinclark> alexn: My call just ended. I'm free now.

[11:37:17 CDT(-0500)] <alexn> colinclark: great. Basically I tried to find anything similar to the problem I'm experiencing in OER Commons with the floating dialog.

[11:38:18 CDT(-0500)] <alexn> But unfortunately I only could find solutions and issues when html elements would be the part of the same div or a specific markup.

[11:39:56 CDT(-0500)] <colinclark> Can you point me to any of the solutions you found?

[11:41:03 CDT(-0500)] <alexn> I need to search through again since there is nothing similar to our issue and those solutions just require some css manipulation for an element be attached to its sibling

[11:41:44 CDT(-0500)] <alexn> I did not kept those pages open since they were still far from out initial problem. Do you want me to find them again ?

[11:42:40 CDT(-0500)] <colinclark> If you don't have any links handy, I suppose not

[11:44:21 CDT(-0500)] <colinclark> So, can you summarize again what the core of the issue is? I looked at the Assembla ticket for OER-795 but it looks unrelated and has already been merged in.

[11:44:30 CDT(-0500)] <colinclark> You had links to screenshots, too, I remember.

[11:45:17 CDT(-0500)] <alexn> colinclark: yes. I just need a minute for all those links

[11:45:34 CDT(-0500)] <alexn> so basically here is the ticket and it is still open and not merged in https://www.assembla.com/spaces/iskme/tickets/795#/activity/ticket:795

[11:46:00 CDT(-0500)] <alexn> here is my branch with the code I have https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-795 currently

[11:46:11 CDT(-0500)] <colinclark> Aha!

[11:46:15 CDT(-0500)] <colinclark> Assembla's URLs suck

[11:46:35 CDT(-0500)] <colinclark> I changed the ticket:794 part to 795, but it's still showing me 794.

[11:46:41 CDT(-0500)] <alexn> unfortunately Assembla lack lots of great JIRA funcationality

[11:48:43 CDT(-0500)] <alexn> here are the links for that issue I'm having

[11:48:44 CDT(-0500)] <alexn> https://dl.dropbox.com/u/14022781/Screen%20Shot%202012-09-28%20at%202.15.39%20PM.png

[11:48:50 CDT(-0500)] <alexn> https://dl.dropbox.com/u/14022781/Screen%20Shot%202012-09-28%20at%202.16.04%20PM.png

[11:49:18 CDT(-0500)] <alexn> when the dialog do not appear to be at the proper location when user start modifying TextSize/Line Spacing or Slide/Unslide the UIO panel

[11:50:09 CDT(-0500)] <colinclark> Can you attach your screen shots to the Assembla ticket? Does it support that?

[11:50:10 CDT(-0500)] <alexn> the dialog looks readable and scales well which works great with our UIO integration but its location is not exact when shown initially

[11:50:26 CDT(-0500)] <colinclark> As well as a link to your branch and a description of the issue?

[11:50:27 CDT(-0500)] <alexn> colinclark: I think it supports that. Will do

[11:50:44 CDT(-0500)] <colinclark> Then you won't have to dig up those links again

[11:51:01 CDT(-0500)] <alexn> colinclark: good point

[11:51:08 CDT(-0500)] <colinclark> Just so, I understand...

[11:51:16 CDT(-0500)] <colinclark> This dialog is a kind of tooltip...

[11:51:25 CDT(-0500)] <colinclark> but one that is "pinned" open, once you click the little icon?

[11:51:48 CDT(-0500)] <alexn> yes and the one which would not update its absolute positioning on any website changes

[11:52:04 CDT(-0500)] <colinclark> So, how does one dismiss the dialog?

[11:52:14 CDT(-0500)] <alexn> There is a cancel button in it

[11:52:17 CDT(-0500)] <colinclark> Presumably one way is to actually type in your first and last names

[11:52:31 CDT(-0500)] <colinclark> So the two buttons are the only way to dismiss it--Save and Cancel?

[11:52:50 CDT(-0500)] <alexn> Submit and Cancel and they both will remove the dialog from the screen

[11:53:25 CDT(-0500)] <colinclark> So if you were to dismiss the dialog, then change sizes with UIO, and then open it again, it would be correctly positioned and look okay?

[11:53:36 CDT(-0500)] <alexn> yes

[11:53:41 CDT(-0500)] <alexn> it would look normally fine

[11:53:43 CDT(-0500)] <colinclark> That's good

[11:53:55 CDT(-0500)] <colinclark> jameswy: Was this an interaction we specified, or one that came from ISKME?

[11:53:55 CDT(-0500)] <alexn> it is only when it is present on the screen and some changes are being applied

[11:54:07 CDT(-0500)] <colinclark> The "pinned" tooltip with Save/Cancel buttons, I mean, jameswy

[11:55:33 CDT(-0500)] <jameswy> colinclark: That doesn't look like our work.

[11:55:49 CDT(-0500)] <colinclark> Do you think it's a very good interaction?

[11:55:58 CDT(-0500)] <jameswy> At least, not the one place alexn pointed to.

[11:56:17 CDT(-0500)] <colinclark> I was imagining that focus outside the tooltip would likely make it disappear as well, but that doesn't sound like the case from alexn's report.

[11:56:18 CDT(-0500)] <jameswy> In the one alexn showed, an inline edit would've been preferable.

[11:56:21 CDT(-0500)] <alexn> colinclark: even more. If I want to use em for initial positioning I have to find the fontSize of the element where dialog appears and then use it to calculate ems. Please see submit.js in my branch.

[11:57:57 CDT(-0500)] <colinclark> jameswy: You're suggesting an inline edit for the names, directly in the page, rather than a tooltippy dialog?

[11:58:19 CDT(-0500)] <jameswy> colinclark: That's right.

[11:58:27 CDT(-0500)] <colinclark> It makes sense to me, yes

[11:59:00 CDT(-0500)] <colinclark> alexn: Can you try to carefully explain in this ticket the issue you're facing? And then perhaps we can file a separate issue suggesting that this interaction would be better served by an inline edit?

[11:59:06 CDT(-0500)] <colinclark> In the meantime, let's get speculative for a second...

[11:59:14 CDT(-0500)] <colinclark> How might we solve the issue?

[11:59:21 CDT(-0500)] <colinclark> Any ideas, alexn, or are you stuck at this point?

[12:00:03 CDT(-0500)] <alexn> colinclark: I have only 2 ideas in my head

[12:00:14 CDT(-0500)] <colinclark> fire away

[12:01:17 CDT(-0500)] <alexn> 1 is the one which I come to when was looking for the similar issues online. It is the same as you and jameswy are proposing. Somehow manage to make the dialog to be part of the markup so that it will scale gracefully with the rest of the page.

[12:01:46 CDT(-0500)] <colinclark> yeah, in other words: don't make it a dialog

[12:01:48 CDT(-0500)] <colinclark> I agree

[12:02:11 CDT(-0500)] <colinclark> What's the other idea?

[12:02:57 CDT(-0500)] <alexn> 2 was to make a component which would be listening to the UIO panel changes and then reposition the dialog. But that one is a bit hacky since first of all it would be css styling changes with different events which is not as clean as having a markup. Also there might be other instances of this dialog usage in OER Commons which means it can take some time to isolate those and create a proper component.

[12:03:32 CDT(-0500)] <colinclark> Can you elaborate a bit more on #2?

[12:03:43 CDT(-0500)] <alexn> colinclark: sure

[12:05:39 CDT(-0500)] <alexn> colinclark: the main interaction which causes the dialog positioning issues is UIO Panel. In order to listen to its events there should be an Infusion component only. So the dialog should be converted into an Infusion component which would listen to the UIO Panel changes as sliding or Text Size changes…

[12:06:03 CDT(-0500)] <colinclark> What events would you listen for, specifically, from UI Options?

[12:06:35 CDT(-0500)] <alexn> Text Size Change, Line Spacing change and Showing/Hiding of the panel

[12:06:45 CDT(-0500)] <alexn> at this point I assume that those events are present in UIO panel

[12:06:56 CDT(-0500)] <colinclark> How would you listen for these?

[12:06:56 CDT(-0500)] <alexn> I do not know for a fact if they are present there

[12:08:03 CDT(-0500)] <colinclark> What kind of events would you be looking for?

[12:08:03 CDT(-0500)] <alexn> Again at this point I would assume that I would be able to create listeners for the dialog component with events attached. Events which I listed above.

[12:08:48 CDT(-0500)] <alexn> I have to mention that those 2 ideas I listed are not the final working solutions. These were ideas which could possibly lead to the problem resolution

[12:09:00 CDT(-0500)] <alexn> *These are

[12:10:15 CDT(-0500)] <alexn> to continue on the idea #2 even if such listener-event linking would be possible for the dialog component there would be dialog.css() function call at its core to change its positioning

[12:10:57 CDT(-0500)] <colinclark> Okay, so I think you might be on to a possible solution...

[12:11:13 CDT(-0500)] <colinclark> I'm just trying to get a sense of whether or not you know how to pursue it

[12:11:17 CDT(-0500)] <colinclark> So I can elaborate a few thoughts

[12:11:28 CDT(-0500)] <colinclark> First, it sounds like what you'll be interested in is ChangeApplier events for UI Options

[12:11:43 CDT(-0500)] <colinclark> You might know that the ChangeApplier allows you to listen for changes in the model of a component

[12:11:53 CDT(-0500)] <colinclark> and you can filter your listener based on certain paths within the model

[12:12:34 CDT(-0500)] <colinclark> So, for example, your listener will only get called if the "textSize" path changed, or whatever.

[12:13:04 CDT(-0500)] <colinclark> So another question: you mentioned something about it being "an Infusion component only." Can you elaborate on what you mean?

[12:14:08 CDT(-0500)] <alexn> I mean that I cannot think of any other way of listening to the ChangeApplier events except of using an Infusion component

[12:14:19 CDT(-0500)] <colinclark> Why not?

[12:16:28 CDT(-0500)] <alexn> I guess I just have not seen such code yet

[12:16:56 CDT(-0500)] <colinclark> Let's unpack this a bit and see if I can understand your point

[12:17:04 CDT(-0500)] <alexn> colinclark: sure

[12:17:22 CDT(-0500)] <colinclark> What's actually involved in listening for ChangeApplier events? What might be complex or interesting about it?

[12:18:53 CDT(-0500)] <alexn> colinclark: I'm not sure what exactly are you asking. But as for me interesting and complex part is when multiple components could listen to the same ChangeApplier events

[12:19:04 CDT(-0500)] <colinclark> Ok

[12:19:16 CDT(-0500)] <colinclark> So, actually listening for the event is quite straightforward

[12:20:06 CDT(-0500)] <colinclark> Here's the relevant documentation: http://wiki.fluidproject.org/display/fluid/ChangeApplier+API#ChangeApplierAPI-modelChangedlisteners

[12:20:40 CDT(-0500)] <colinclark> In short, given a reference to the component, you just call addListener(), passing it a function pointer to your listener

[12:21:04 CDT(-0500)] <colinclark> Any particular reason, alexn, that you'd need to be an Infusion component to do this, do you think?

[12:22:40 CDT(-0500)] <alexn> colinclark: I was reading through. I guess there is no need in a component

[12:22:56 CDT(-0500)] <colinclark> I think you're probably right, yes

[12:22:59 CDT(-0500)] <alexn> colinclark: thanks for clearing it out for me.

[12:23:03 CDT(-0500)] <colinclark> Except there's some complexity, still.

[12:23:26 CDT(-0500)] <alexn> colinclark: anything I should be aware of ?

[12:23:31 CDT(-0500)] <colinclark> These questions start to get at the heart of code factoring...

[12:23:47 CDT(-0500)] <colinclark> 1. How would you get a reference to the UI Options instance?

[12:24:38 CDT(-0500)] <alexn> I'm not quiet sure. As I mentioned earlier the #1 and #2 ideas for solving dialog issue are still ideas and require some research

[12:24:48 CDT(-0500)] <colinclark> 2. How would you manage the hard-coded dependency on UI Options? What if you wanted to use this tooltip on a page that doesn't have UIO on it?

[12:25:03 CDT(-0500)] <colinclark> These two questions, alexn, don't have easy answers

[12:25:29 CDT(-0500)] <colinclark> Usually, you just "get a reference, however you can" and then you make a tight coupling between your tooltip and UI Options.

[12:25:35 CDT(-0500)] <colinclark> That's how most programmers solve the problem

[12:25:53 CDT(-0500)] <colinclark> And it may well be, in this environment, the way you have to solve the problem, alexn

[12:26:16 CDT(-0500)] <colinclark> But these two problems are related to dependency management, and part of the reason we created Infusion to help application developers

[12:26:56 CDT(-0500)] <colinclark> So that the answer to #1 is "You don't. You specify configuration instead, and the framework takes care of wiring up components and events."

[12:26:58 CDT(-0500)] <colinclark> And the answer to #2 is the same.

[12:30:38 CDT(-0500)] <alexn> colinclark: so would be the call for this issue ? Which solution (1 - embedded dialog markup in the page which scales with other elements, 2 - create listeners for UIO ChangeApplier which would change dialog css position attributes )?

[12:31:10 CDT(-0500)] <colinclark> What solution do you recommend, alexn?

[12:33:08 CDT(-0500)] <alexn> To be honest I'm not sure. I'm usually fond of the html markup instead of dynamic css position changes but for this particular problem I cannot say for sure what would be the best.

[12:36:20 CDT(-0500)] <colinclark> Option #1 isn't fully in our control, since it's actually a design change

[12:36:24 CDT(-0500)] <colinclark> It's probably the better one.

[12:36:37 CDT(-0500)] <colinclark> I'm curious to learn from michelled_ how she typically raises these kinds of issues

[12:37:05 CDT(-0500)] <colinclark> Option #2 seems relatively straightforward, with the key question, "How will you get yourself a reference to UI Options?"

[12:37:30 CDT(-0500)] <colinclark> Which, until you can answer that question, it's unclear how long it will take.

[12:38:01 CDT(-0500)] <michelled_> colinclark: I missed most of the conversation - are you wondering whether we have some control over design on OERC?

[12:39:12 CDT(-0500)] <colinclark> Well, less so that question

[12:39:35 CDT(-0500)] <colinclark> and more, "if we think we have a suggestion for a design improvement, how do we surface it with ISKME?"

[12:40:20 CDT(-0500)] <colinclark> The short summary is that alexn has fixed a bug that causes other bugs. And the whole problem would go away if they went with a simpler design. Which, unrelated, is probably a more usable design, too

[12:40:28 CDT(-0500)] <colinclark> People love their dialogs and popups

[12:40:56 CDT(-0500)] <michelled_> colinclark: thankfully ISKME is a dream to work with

[12:41:02 CDT(-0500)] <colinclark> they are indeed

[12:41:37 CDT(-0500)] <michelled_> colinclark: what we usually do is articulate our suggestion in an Assembla message or on a specific ticket

[12:42:01 CDT(-0500)] <michelled_> colinclark: sometimes we will have a quick Skype call to talk a detail through, although generally, if we are clear enough, it's not needed

[12:42:53 CDT(-0500)] <michelled_> colinclark: since ISKME is still in the midst of hiring an interaction designer, the question should be posed to Lisa and Robin

[12:43:28 CDT(-0500)] <colinclark> ok

[12:43:56 CDT(-0500)] <colinclark> So it sounds like perhaps the best approach is to leave the bug in place, and then work with ISKME to suggest design alternatives that will be less brittle in face of responsive designs

[12:44:14 CDT(-0500)] <colinclark> The short summary of the bug is that there is a tooltip which is "pinned" to a little icon on the page

[12:44:32 CDT(-0500)] <colinclark> and that tooltip contains "first name" and "last name" entry fields

[12:44:40 CDT(-0500)] <colinclark> And a pair of buttons--Save and Cancel

[12:44:53 CDT(-0500)] <colinclark> Once the tooltip has been opened, the only way to dismiss it is to save or cancel

[12:45:06 CDT(-0500)] <colinclark> So, a user is free to open it up, and then start playing around with UIO

[12:45:24 CDT(-0500)] <colinclark> which will cause the tooltip, since it's floating in a layer above, to no longer be anchored to its icon

[12:47:10 CDT(-0500)] <colinclark> jameswy: Is it easy for me to follow the history of UI Options design ideas, visually?

[12:47:26 CDT(-0500)] <colinclark> Ideally, I'd like to assemble a series of "screen shots" that show the evolution of UIO over time

[12:47:43 CDT(-0500)] <colinclark> jameswy: Where would I go to do this?

[12:48:06 CDT(-0500)] <jameswy> Reasonably so, I think, colinclark

[12:48:14 CDT(-0500)] <jameswy> http://wiki.fluidproject.org/display/fluid/User+Interface+%28and+Learner%29+Options+research%2C+design%2C+and+testing --> under "Design"

[12:48:55 CDT(-0500)] <jameswy> Version A (Gary Thompson and pre Infusion 1.4), B (Infusion 1.4), and C (current designs).

[12:52:45 CDT(-0500)] <colinclark> cool, ok

[12:52:50 CDT(-0500)] <colinclark> that'll be great

[12:52:53 CDT(-0500)] <colinclark> thanks!

[12:53:09 CDT(-0500)] <colinclark> michelled_: Did you see my earlier comments?

[12:53:51 CDT(-0500)] <michelled_> yes colinclark

[12:54:38 CDT(-0500)] <michelled_> colinclark: do you think the tooltip should be dismissed if the user changes focus?

[12:54:45 CDT(-0500)] <colinclark> I guess that's one option

[12:55:03 CDT(-0500)] <colinclark> jameswy made the point that having the name fields inline editable is probably the most elegant solution

[12:56:11 CDT(-0500)] <colinclark> I think ultimately, michelled_ and alexn, that this issue is enough of an edge case that we can move on with our bug fixing

[12:56:12 CDT(-0500)] <michelled_> ah, that does sound better

[12:56:22 CDT(-0500)] <colinclark> It is always nice to offer design suggestion back to ISKME

[12:56:31 CDT(-0500)] <michelled_> and it should be really easy to implement now that our inline edit component is available

[12:56:49 CDT(-0500)] <michelled_> since we are using it for the title of an OER

[12:57:41 CDT(-0500)] <colinclark> And alexn, for your own edification, I'd be curious to have you spend a few minutes contemplating how you would actually implement your scenario #2. I don't it's necessary to actually do, but I imagine it would be helpful for you to explore a few of the details.

[12:58:02 CDT(-0500)] <colinclark> cool, michelled_

[12:59:02 CDT(-0500)] <colinclark> michelled_: Can I distract you long enough to help alexn file that ticket in Assembla, based on jameswy's advice?

[12:59:14 CDT(-0500)] <colinclark> I know you're deep in the thick of code, too, so I apologize for the intrusion

[12:59:34 CDT(-0500)] <alexn> colinclark michelled_: Correct me If I understood our final plan correctly. We are going to leave ticket as it is but write down summary on what is current issue is and what would be a preferable solution.

[13:00:16 CDT(-0500)] <colinclark> alexn: that's a little ambiguous

[13:00:19 CDT(-0500)] <colinclark> We're going to:

[13:00:22 CDT(-0500)] <alexn> colinclark michelled_: Already found an answer. I missed your last 2 points colinclark while typing

[13:00:34 CDT(-0500)] <colinclark> 1. Do a pull request for your OER-795 fix

[13:00:48 CDT(-0500)] <colinclark> 2. You and michelled_ will file a ticket to suggest an improved user experience

[13:01:19 CDT(-0500)] <colinclark> 3. We'll leave with the bug that, when the tooltip is open, it doesn't stay pinned to its target if the user starts playing around with UIO, under the assumption that it's not something they'll typically do.

[13:01:30 CDT(-0500)] <colinclark> "live with the bug," that is

[13:02:08 CDT(-0500)] <michelled_> colinclark: sure - I can help file the ticket

[13:03:15 CDT(-0500)] <colinclark> cool, alexn?

[13:03:17 CDT(-0500)] <alexn> colinclark: thanks for clearing things for me. And I will think about scenario #2 and ping you when I have an idea

[13:03:26 CDT(-0500)] <colinclark> thanks

[13:03:44 CDT(-0500)] <colinclark> I'm going to disappear for a few hours--this cold is still hanging on

[13:03:49 CDT(-0500)] <colinclark> see you all soon

[13:03:55 CDT(-0500)] <alexn> colinclark: thanks for your time

[13:04:03 CDT(-0500)] <alexn> colinclark: hopefully you will feel better

[13:04:07 CDT(-0500)] <colinclark> thanks

[13:42:19 CDT(-0500)] <Justin_o> fluid-everyone: for decapod when we test the cameras, there could be several reasons why they are unusable for the various types of captures. The HTTP response codes don't really have the detail we'd need for this. What we're thinking of doing is to return along an object that has an error code, message, and some more info about what went wrong so that it can be used to generate a specific message on the client. Are there any conventions

[13:42:20 CDT(-0500)] <Justin_o> around something like this?

[14:24:19 CDT(-0500)] <jessm> anastasiac: so, Iris just clarified the IDI list info… the idi main website should join ppl. to the Idi-community list – can you tell if that's what happens now?

[14:24:59 CDT(-0500)] <anastasiac> jessm, this is not what was happening before, but I got the clarification also, so as of this morning, the email signup now signs people up to the community list

[14:25:18 CDT(-0500)] <anastasiac> iris and i discussed the possibility of avtar moving any current discuss list subscribers over to community when he gets back

[14:25:48 CDT(-0500)] <anastasiac> if you think it's more urgent than next week, jessm, I could look into trying to move them over this week

[14:25:52 CDT(-0500)] <jessm> ah, gotcha

[14:26:09 CDT(-0500)] <jessm> anastasiac: no, i think it can wait as long as it does happen upon Avtar's return

[14:26:25 CDT(-0500)] <anastasiac> ok, cool. I'll make sure it does

[15:03:09 CDT(-0500)] <michelled_> colinclark: alexn and I chatted with jameswy and Lisa - we found out that the feature of being able to edit your name in the context of an OER is actually to fix a legacy issue where a bunch of users didn't fill out their full names so author names are being displayed as a generated number

[15:03:22 CDT(-0500)] <colinclark> aha

[15:03:23 CDT(-0500)] <colinclark> interesting

[15:03:36 CDT(-0500)] <michelled_> colinclark: Lisa agreed with changing to an inline edit experience to mirror the editing of an OER title

[15:03:44 CDT(-0500)] <colinclark> nice

[15:03:54 CDT(-0500)] <michelled_> alexn has filed the assembla ticket and will work on it

[15:04:05 CDT(-0500)] <michelled_> it's actually interesting because it will be a new case for our inline edit

[15:04:31 CDT(-0500)] <alexn> michelled_ colinclark: here is the ticket https://www.assembla.com/spaces/iskme/tickets/820#/activity/ticket:820

[15:04:54 CDT(-0500)] <michelled_> it involves two fields that work in concert. meaning that clicking the pencil will show the two fields and it's only when neither field has focus that we switch back to view mode