search

wombats-writing-code / fbw-components

Fly-by-Wire components for building user interfaces
http://fbw.mit.edu
MIT License
0 stars 1 forks source link

Newly published learning outcomes don't automatically show up in authoring tool #9

Closed chadlieberman closed 8 years ago

chadlieberman commented 8 years ago

The FBW_ALGEBRA collection is working for me now in that I can add outcomes and link them in the authoring tool. However, if I add a new outcome, I have to reload the authoring tool for it to show up.

I think we had this issue before, see Feedback for Cole on Item Authoring Tool, but I'm not sure we ever resolved it.

It would be very helpful for us to be able to move back and forth between the two without having to write chunks of outcomes at a time.

chadlieberman commented 8 years ago

I think I am organizing things the way I should be now, but the new outcomes still don't seem to show up without refreshing. Sorry if you are still thinking on this, it wasn't clear if so.

coleshaw commented 8 years ago

Hm….yes, there are probably some performance tradeoffs around this, which is why we typically cache data.

So I’ve made the Outcomes dropdown fetch each time, but you might notice a lag each time you open that dropdown menu, which you don’t see now, especially with a small number of outcomes (UX / performance tradeoff). In the past (and depending on your bandwidth), that type of lag has been worse for some users, which is why we started caching on component / page load…but the lag shouldn’t be too noticeable, as long as the outcomes list isn’t too long (i.e. hundreds / over a thousand). If that happens and you get annoyed, we can always switch back. In the long-term, I think there is more “linking” activity vs. “create / edit outcome” activity, so there may be more overall time savings by optimizing for “linking” by caching.

Test and let me know if that’s okay.

El may 31, 2016, a las 3:13 PM, Chad Lieberman notifications@github.com escribió:

The FBW_ALGEBRA collection is working for me now in that I can add outcomes and link them in the authoring tool. However, if I add a new outcome, I have to reload the authoring tool for it to show up.

I think we had this issue before, see Feedback for Cole on Item Authoring Tool https://docs.google.com/document/d/1AbTdSCPbBH4eiblYyIRIhny0IfcwY0Pvh1numxdz_H4/edit, but I'm not sure we ever resolved it.

It would be very helpful for us to be able to move back and forth between the two without having to write chunks of outcomes at a time.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wombats-writing-code/fbw-components/issues/9, or mute the thread https://github.com/notifications/unsubscribe/AEs6UUvVKDbCxowA7MRPvb8mjv9ooORBks5qHIhdgaJpZM4Iq3EC.

chadlieberman commented 8 years ago

This does work, and is much better than having to reload the page.

Let me know what you think of this other possible solution:

Assuming there is a one-to-one correspondence between MC3 collections and classes in the authoring tool*, asynchronously load all of the outcomes into the store when the user selects the class in the authoring tool. Then, either (a) set up a poll to fetch new outcomes every 10?/20? seconds or (b) connect via websocket to the API and push changes to the client on CRUD. Unless I am missing something, it should be feasible to cache all of the outcomes for a class, right?

coleshaw commented 8 years ago

So I think solution a) is more overhead than what we’re doing now (fetch when the dropdown menu opens) and therefore I think it’s less ideal…not sure what the performance impacts of constant polling would be. I’m not entirely clear on what you mean by b), but my interpretation of it is for the authoring tool to connect directly to MC3 via web sockets, so MC3 can push changes live? I don’t think that is possible without additional work on MC3 to support web sockets / push notifications, so that’s a question of 1) funding, and 2) timing, plus additional changes to the authoring tool. It may not be worth the added cost or time.

Multiple authors with outcomes is a different issue, because we’re talking about the outcome authoring tool, right? Unless the authors are entering the same data at the same time, there shouldn’t be a conflict…for example, if you split up algebra topics with someone else, that should be fine (you just may not see the other person’s updates until you reload the authoring tool). Obviously if you try to edit the same topics / outcomes at the exact same time, there will be issues. So planning and dividing tasks may be one non-technical approach.

El jun 1, 2016, a las 8:13 AM, Chad Lieberman notifications@github.com escribió:

This does work, and is much better than having to reload the page.

Let me know what you think of this other possible solution:

Assuming there is a one-to-one correspondence between MC3 collections and classes in the authoring tool*, asynchronously load all of the outcomes into the store when the user selects the class in the authoring tool. Then, either (a) set up a poll to fetch new outcomes every 10?/20? seconds or (b) connect via websocket to the API and push changes to the client on CRUD. Unless I am missing something, it should be feasible to cache all of the outcomes for a class, right?

I think this assumption is pretty good for now, until at least we resolve how multiple authors can collaboratively work on outcomes without conflict. — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wombats-writing-code/fbw-components/issues/9#issuecomment-222974066, or mute the thread https://github.com/notifications/unsubscribe/AEs6URc0DK3dMuPt4AttaudAGWL-1zX9ks5qHXdhgaJpZM4Iq3EC.

chadlieberman commented 8 years ago

Yes, that's what I meant on the web sockets. I think it would be a great enhancement for MC3, but I understand there is a cost of course.

Solution (a) definitely has more overhead, and if it is too much on the server side, then that's a non-starter. The client-side overhead wouldn't be a problem if it's all async. It's not much of an improvement over the current implementation except that it will reduce the lag in loading the outcomes dropdown almost all of the time.

I only mention the assumption above as a way of not loading all of the collections into the store, using the assumption that we won't have any/many intersecting outcomes between CAD, Algebra, Accounting.

Closing the issue now.

coleshaw commented 8 years ago

Apologies, I misread your assumption. Yes, I’m making the same assumption (one MC3 collection per xoces domain)...

El jun 1, 2016, a las 8:49 AM, Chad Lieberman notifications@github.com escribió:

Yes, that's what I meant on the web sockets. I think it would be a great enhancement for MC3, but I understand there is a cost of course.

Solution (a) definitely has more overhead, and if it is too much on the server side, then that's a non-starter. The client-side overhead wouldn't be a problem if it's all async. It's not much of an improvement over the current implementation except that it will reduce the lag in loading the outcomes dropdown almost all of the time.

I only mention the assumption above as a way of not loading all of the collections into the store, using the assumption that we won't have any/many intersecting outcomes between CAD, Algebra, Accounting.

Closing the issue now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wombats-writing-code/fbw-components/issues/9#issuecomment-222982095, or mute the thread https://github.com/notifications/unsubscribe/AEs6UQzQ1G-0DNlHxzV_RpLeOFcgpivPks5qHX_igaJpZM4Iq3EC.