Follow up 15 messages Adrian Fish Thu, Dec 8, 2016 at 5:14 PM To: Neal Caidin , Matthew Jones , Earle Nietzel , Mitch Golden Hi all, I thought I'd just drop you all a mail to try and clarify a few of the points raised during the meeting. I was picking up a bit of a 'why are you reinventing the wheel' kind of vibe that's what I wanted to talk about. I realise I have form with producing versions of tools that exist already (YAFT, although I feel no guilt writing something to replace Forums here at Lancaster), so I don't blame people for perhaps thinking that. On the other hand, I may have totally misread things :) I looked at the Dashboard and saw three downsides to it. 1. It doesn't follow you if something happens in it you don't get to know until you click on the tool. This really detracts from it. 2. It doesn't cover certain things assignments being graded being one. 3. It has effectively been deprecated so it just seemed a worrying prospect trying to revitalise it, even if 1. wasn't a requirement. Your concerns about the bullhorns falling foul of the same performance problems are well heeded. Perhaps treating the bullhorns as a Facebook style alert system, as Mitch suggested, would avoid most of the pitfalls here. Real time clickable alerts, that kind of thing. I'll take a look at the critical and blockers, though. Polls I looked at that and couldn't work out a way of being to show polls based on Lesson page views. We didn't talk about this in the meeting, but that's how we show the poll. It's based on lesson pages and we have an algorithm around viewed pages, time since last show, stuff like that. In the timeframe we couldn't really see how we could refactor the Polls tool to do what we needed. Anyway, onwards. The big step for pushing the bullhorns into master is to squash all those SAK30461 commits and then pick it across, fixing the inevitable messy bits. That's something I should probably do as long as Mitch is okay with me doing that. I'll do it on a clean master so I can see how much of it works out of the box from that point. Cheers and nice talking to you all. Adrian. Matthew Jones Thu, Dec 8, 2016 at 6:27 PM To: Adrian Fish , Neal Caidin , Earle Nietzel , Mitch Golden Hey Adrian, On Thu, Dec 8, 2016 at 3:14 PM Adrian Fish wrote: Hi all, I thought I'd just drop you all a mail to try and clarify a few of the points raised during the meeting. I was picking up a bit of a 'why are you reinventing the wheel' kind of vibe that's what I wanted to talk about. I realise I have form with producing versions of tools that exist already (YAFT, although I feel no guilt writing something to replace Forums here at Lancaster), so I don't blame people for perhaps thinking that. On the other hand, I may have totally misread things :) I don't know enough about YAFT to make a comment about that (we have nobody running it) but the community has a long history of Build a tool to replace a core tool that maybe only gets to be 50% feature parity with the core tool (Assignment 2, Gradebook 2) taking away development effort on core tool Stop working replacement on it after a few years since only one person or institution is really supporting it
We see the same pattern again and again. Sometimes a better tool does come out (Lessons replacing Melete [and hopefully soon Syllabus], GradebookNG replacing Gradebook [and Gradebook 2]) but most of the time it seems like we end up with a Mneme (something a lot of schools still hang onto as superior even though it hasn't gotten any significant commits for over 3 years) But anyway you've been around and seen this tool, some developers just love to develop something new verses fixing something existing. Longsight is strongly in the camp of fixing existing since that's what we do all the time, so maybe we're biased. I looked at the Dashboard and saw three downsides to it. 1. It doesn't follow you if something happens in it you don't get to know until you click on the tool. This really detracts from it. I think everyone agrees on this point, it should be in a popup widget. It's written in Wicket and has a simple UI so this seems like it could be easier to have done than other tools. You have to take mobile into consideration though and how popups should work there. A lot of the time we're seeing they actually work better if they get their own full screen (but are still accessible everywhere) 2. It doesn't cover certain things assignments being graded being one. If something didn't work it was probably just because the provider wasn't written to catch that. You wrote the capability for Dashboard into YAFT right? Each tool needed to implement some code. Though this was only the beginning of the touch problems dashboard faced. 3. It has effectively been deprecated so it just seemed a worrying prospect trying to revitalise it, even if 1. wasn't a requirement. Yeah it was deprecated mainly because after 5 years Michigan stopped development on it (when they moved to Canvas) after Zhen took over from Jim in 2013 if kind of slowed down a little too. I worry because any new "dashboard like replacement" seems like it will have the same long term maintenance issues. We could have fixed up dashboard but nobody really even saw it as a priority at the moment. I think it could have raised money to get in though if this new project from you guys wasn't in the pipeline though, that REALLY was the reason for abandoning it (though it is still currently in the 12 code) Your concerns about the bullhorns falling foul of the same performance problems are well heeded. Perhaps treating the bullhorns as a Facebook style alert system, as Mitch suggested, would avoid most of the pitfalls here. Real time clickable alerts, that kind of thing. I'll take a look at the critical and blockers, though. I don't think it really had performance problems though. The way dashboard worked was similar to sitestats where it would process the events (either live or in a quartz job) and generate individual dashboards for the user. The problems looking through the jiras are mostly around https://jira.sakaiproject.org/issues/?jql=project%20%3D%20DASH%20and%20status%20%3D% 20open%20ORDER%20BY%20priority%2C%20updated%20desc Some interface issues that we couldn't figure out (because they seemed to be odd Wicket behavior) Edge cases related to any changes in the external items for instance DASH351 dashboard doesn't listen for group changes. I think another ticket couldn't tell when an item was changed from hidden to viewable. Dashboard handled creation events really well but not so much update or delete, often because there may not have been events for those or just nothing written to process it. And the issue when you add a new user to a site, or a user to a group, it only pushed forward. There actually was some work Zhen did on this right before the end https://jira.sakaiproject.org/browse/DASH326 Students added to a roster should see retroactive activity in that course. This was another quartz job that actually did period cleanup of the data and compared every students record in every class with other students to try to "sync" them up. I don't know 100% of the details but it looked like a decent amount of work. Anyway, aside from the database model not being able to be automatically migrated, I thought the backend was pretty good and the frontend was fixable. I haven't looked at your implementation at all (I know at lot about dashboard because as I said I worked on it back when I was at Michigan a little) but I feel like it's a hard problem to get everything right. Polls I looked at that and couldn't work out a way of being to show polls based on Lesson page views. We didn't talk about this in the meeting, but that's how we show the poll. It's based on lesson pages and we have an algorithm around viewed pages, time since last show, stuff like that. In the timeframe we couldn't really see how we could refactor the Polls tool to do what we needed.
Yeah with this I don't think anyone will be sad to see the polls go. But since it's so simple the ideal is that we just have one polls tool that could be used anywhere. If you have a better UI maybe we can get some type of conversion to use that one and make it into a tool too? Or just drop the tool. I like all of Earle's ideas about what polls could do. The UI for a lot of these old tools we'd love to go the way of GBNG though the services are in most cases pretty good and well tested. Nice talking to you too! Mitch Golden Thu, Dec 8, 2016 at 6:49 PM To: Adrian Fish Cc: Neal Caidin , Matthew Jones , Earle Nietzel To amplify the point: I don't think the snappolls tool is something that should be added to Sakai, and I am not sure who else would use it anyway. What we built is a very particular thing to solve a very particular problem, and a fair amount of the code implements our specific algorithm for deciding when to pop the poll. As we noted, building a simple poll is not very hard. What I think *is* hard is to do what we did right the right way instead of as a hack. That is, to do the poll right requires building hooks into the various places in the system that might be tasked with showing a poll, and allowing those hooks to call out to see if they should show a poll. The polling engine itself must be sufficiently flexible to allow the poll to be shown when it's needed (which in our case was a rather unusual set of conditions). We also needed emails to be sent under certain conditions. The bullhorn is a different matter. The problem with the Dashboard is that it raises a set of expectations that it doesn't meet. The bullhorn system does not. No one expects to get an alert for things that have already happened in a course after the course has started. My point would be that right now Sakai has no facility to allow users to know that they need to look somewhere to find something that happened since the last time they logged in (got a friend request, an announcement in a course, etc). Keeping the bullhorn out because it doesn't *also* show alerts for things in the past would be making the perfect the enemy of the good. Furthermore, I would point out that the bullhorn functionality is actually a comparatively simple set of code. It is just triggered by the firing of events. It isn't a large amount of code, so I think that maintenance would be less of an issue than feared. Mitch Golden CTO Noodle Partners, Inc. 59 Chelsea Piers, Suite 200, New York, NY, 10011 +1 646 289 7834 | [email protected] | noodlepartners.com [Quoted text hidden]
Mitch Golden Thu, Dec 8, 2016 at 6:54 PM To: Matthew Jones Cc: Adrian Fish , Neal Caidin , Earle Nietzel I just replied directly to Adrian, but I would point out one other thing: The way Adrian has written the bullhorns it is actually rather simple to add alerts for different sorts of events that we might not have considered. In fact, over time we have asked Adrian to do this several times already. The Dashboard as I saw it was much more complex and was more or less an announcement management tool. The bullhorn only links to something else somewhere, so expanding its domain doesn't require changing the user interface at all and doesn't usually mean much code either. Mitch Golden CTO Noodle Partners, Inc. 59 Chelsea Piers, Suite 200, New York, NY, 10011 +1 646 289 7834 | [email protected] | noodlepartners.com [Quoted text hidden]
Mitch Golden To: Adrian Fish , Neal Caidin
Thu, Dec 8, 2016 at 7:05 PM
P.S. There were actually four (!) people named Sakai in the Olympics this summer. The one I recalled (and the only one to win a medal) was the male swimmer Masato. https://www.rio2016.com/en/search?q=sakai Mitch Golden CTO Noodle Partners, Inc. 59 Chelsea Piers, Suite 200, New York, NY, 10011 +1 646 289 7834 | [email protected] | noodlepartners.com [Quoted text hidden]
Matthew Jones Thu, Dec 8, 2016 at 7:25 PM To: Mitch Golden Cc: Adrian Fish , Neal Caidin , Earle Nietzel I feel like dashboard at it's basically level was the same, and nobody *had* those expectations at the design or brought them up back in 2011. They were just issues Chuck Hedrick raised why Dashboard wouldn't work at Rutgers. Like this one https://jira.sakaiproject.org/browse/DASH351 He talked many times on the calls how it would be more of a support issue to not show a new person the appropriate thing than to show them. It's also somewhat of a security issue if you removed a user from the group that previously had access to an item but the item still appeared on their dashboard. Anyway, Michigan ran it in production since 2013 even knowing these issues and probably was okay with it, these *known issues* were built into their documentation around the tool. And the way it works can be as little as just processing events or as much as processing and getting more detail *on* the events. As Adrian knows if a tool implemented the interface DashboardEntityInfo it could be used by dashboard to return a TON of metadata on the events and the tool. Maybe some of this was overload and not necessary and it sounds like the bullhorns really don't deal with this. When TinCan support was written it feels like they didn't want to deal with anything simpler than basic events either, however the majority of tools needed custom methods to return a LOT more metadata on the events. This was done (in 10) using manual statement generation. I changed it a little in 12 so you can attach a LRS_Statement directly to the event. To get around this would seem to have been the same as dashboard does now. You either generate it and send it along *with* the event, or call in to the tool to get more details about the event. In any case, I feel like there will be desire for more and that probably what happened here. Like for instance I was on a call this week and some school wanted an API change to announcements so they could see what tool posted the external announcement into that tool. (LIke with gradebook) Probably a good idea to know but just more stuff! ;) I feel like maybe dashboard tried to do too much but some of what it had to do with availability checks and updates seems like something any tool like this will need to do? Many of entities actually implemented *some* of that for the EntityContentProducer in search making creating some redundancies . . . Maybe that would have been the better way to build off of? [Quoted text hidden]
Adrian Fish Fri, Dec 9, 2016 at 2:40 AM To: Matthew Jones Cc: Mitch Golden , Neal Caidin , Earle Nietzel Mitch made a good point when he spoke of the bullhorns needing minimal mods to tools for their events to be consumed. All they need is an event and a way of linking in the trigger of said event. One of the problems with interface based approaches in Sakai has always been patchy adoption the way I've done this is to minimise the risk of tool maintainers just not being bothered. Even if 30 percent of the tools can be hooked on events and urls that's an advantage, IMO.
From the discussions on the list it sounded like Dashboard was pretty much dead in the water before the bullhorns were discussed, so it seems a bit unfair to in part blame its demise on our work. The Dashboard has been like Hawking radiation from the start sometimes in and the best things since sliced bread, sometimes out due to some problem in production. I see from your notes Matt that there maybe was a lot of scope creep and that it was a tough tool to write, so that's no surprise. If the Dashboard still has a valid reason to be, then it should maybe be revitalised as it provides other functionality to the bulhorns (I'd write it client side and dump Wicket, though, TBH). If somebody is removed from a group of site and losed access to an event trigger, then that does need cleaning out of the bullhorn alerts that is a very good point and hasn't been done. In theory any link should not work as long as authz is working okay, but still ... I'm glad we're talking about this. [Quoted text hidden]
Neal Caidin Fri, Dec 9, 2016 at 7:28 AM To: Adrian Fish Cc: Matthew Jones , Mitch Golden , Earle Nietzel Accessibility. If we need to , as we add new features, let's include the Accessibility group for testing. We are going for WCAG2 certification , and beyond that we simply want Sakai to be as accessible as possible.
[Quoted text hidden]
Neal Caidin Fri, Dec 9, 2016 at 7:50 AM To: Adrian Fish Cc: Matthew Jones , Mitch Golden , Earle Nietzel And , of course, what's the best way to bring this conversation to the larger group. It was great seeing you Adrian, since that is pretty rare. Possibly the first time we've met face to face virtually? Great discussion! [Quoted text hidden]
Neal Caidin Mon, Dec 12, 2016 at 9:40 AM To: Adrian Fish Cc: Matthew Jones , Mitch Golden , Earle Nietzel Is there any harm in posting the recording to the Sakai Youtube channel, or I could just send links to the recording on request? Thanks, Neal [Quoted text hidden]
Neal Caidin Mon, Dec 12, 2016 at 9:50 AM To: Adrian Fish Cc: Matthew Jones , Mitch Golden , Earle Nietzel Also is it okay to summarize Dashboard vs Bullhorn onlist? I think it needs discussion. neal
[Quoted text hidden]
Mitch Golden Mon, Dec 12, 2016 at 9:55 AM To: Neal Caidin Cc: Adrian Fish , Matthew Jones , Earle Nietzel All fine with me... The more people involved in the discussion the better. Mitch Golden CTO Noodle Partners, Inc. 59 Chelsea Piers, Suite 200, New York, NY, 10011 +1 646 289 7834 | [email protected] | noodlepartners.com [Quoted text hidden]
Adrian Fish Mon, Dec 12, 2016 at 10:18 AM To: Mitch Golden Cc: Neal Caidin , Matthew Jones , Earle Nietzel I'm cool with it. [Quoted text hidden]
Matthew Jones Mon, Dec 12, 2016 at 11:34 AM To: Adrian Fish Cc: Mitch Golden , Neal Caidin , Earle Nietzel That's great if it's low maintenance. I felt like dashboard had moderate maintenance requirements, even more than sitestats which needs some things added whenever new events need to be tracked (sometimes more work than others). We all understand the problem of getting direct links into tools and I feel like Lessons has either figured or hacked around a lot of that, and it might be better with Morpheus but that's probably a problem that will continue. Yeah, well Dashboard has been indefinitely frozen because I feel that to actually get it working again and ready for release could be weeks (or months) of effort and nobody stepped forward with money or time to do that. I feel like we would have pushed more for getting it done IF this new project wasn't on the pipeline. Maybe both projects will coexist in the future and dashboard will need to get picked up again, this is why it hasn't been completely removed from the main source tree. Redoing the UI is entirely possible since there isn't much there now and the database layer would be better off converted to an ORM but those aren't much work compared to what already exists with the service and event processing that still seems good. In any case, I feel like the community could raise enough money to get dashboard out by at least Sakai 13 if there still was desire after the bullhorns, but I'm mostly hoping that what this provides is enough and/or maybe the good ideas of dashboard can just be repurposed into this instead eventually in a future release while dumping the rest. I'm looking forward to seeing more about these projects though and I appreciate the demos! [Quoted text hidden]
Neal Caidin Mon, Dec 12, 2016 at 3:12 PM To: Matthew Jones Cc: Adrian Fish , Mitch Golden , Earle Nietzel I think I'm going to just print this out as a PDF and enclose it in an email to the lists. It would be really hard for me to summarize. I'll also include a link to the Youtube video, which I've now posted. neal
Dec 8, 2016 - bullhorns as a Facebook style alert system, as Mitch suggested, would avoid most ..... call this week and some school wanted an API change to ...
Sign in. Page. 1. /. 1. Loading⦠... Cancellations: All cancellations must be in writing and reach the Office of Career Services by close of business on. Monday ...
Dec 15, 2014 - Inc. (âHoldingsâ) as of December 12, 2014, has been established at $40.75 CDN per share. Hence, the new deliverable per THI1 contract is as ...
voicemail messages with the WWU Equal Opportunity Office on Nov. 23, 2015, and said no. I asked. if he emailed a white supremacist letter to WWU Faculty ...
Dec 15, 2014 - Inc. (âHoldingsâ) as of December 12, 2014, has been established at $40.75 CDN per share. Hence, the new deliverable per THI1 contract is as ...
There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. 2015 Follow Up ...
Tues, September 13, 5:30-7:30 pm, River Bridge Regional Center, Glenwood Springs. Mon, November 7, 5:30-7:30 pm, Grand River Health, Colorado River Room, Rifle. Join Meghan Hurley, LCSW, for these FREE parent prevention classes. Meghan has been the.
a cross sectional descriptive one. Clinical data .... The objectives of this report were to analyze the clinical ... observations, clinical data, and laboratory changes.
At approximately 14:10 hours CAMPBELL was taken to the conference room and asked to wait with Ofc. Derek Jones while I collected my paperwork and waited ...
Nov 7, 2016 - CDCC AND THE BOURSE ACCEPT NO ... CDCC Notice to Members No. ... Exercised options will continue to settle in three business days. ... information, please contact Market Operations Department at (514) 871-7877.
The small size of a. bathroom and shape of a bathtub concentrate vapors and present significant safety hazards. For this reason, we recently added both a ...
and laboratory technician. It is an âepidemic ... Department of Public Health, School of Health, .... center of the city, the chief organization of veterinary department of the ... approved the existence of antiâFasciola hepatica antibodies by me
Whoops! There was a problem loading this page. 10-5-15 Western Demographic follow-up letter.pdf. 10-5-15 Western Demographic follow-up letter.pdf. Open.
Jun 8, 2016 - There is large head cut downstream where the spillway drops into the natural drainage. The cut is about 8 feet deep. The bottom of the channel ...
Oct 5, 2015 - Page 1 of 2. October 5, 2015. Dr. Brad Meeks, Superintendent. Steamboat Springs School District RE-2. 325 7th Street. Steamboat Springs, CO 80487. Dear Dr. Meeks: I have re-examined the School Enrollment Forecast and Demographic Observa
Nov 7, 2016 - 2016-133 published on November 1st 2016, all series of Pacific Exploration & Production Corporation. (âPacific Explorationâ) ... Exercised options will continue to settle in three business days. ... Technology. Back-office â ...
Method: Thirty children monosensitized to house dust mite ... design (Yukselen A et al., Int Arch Allergy ... Asian Pac J Allergy Immunol 2013;31:233-41. 234.
Dec 16, 2016 - Telephone: (514) 871-2424. Toll-free ... CANADIAN DERIVATIVES CLEARING CORPORATION (CDCC) ... IN THIS CORPORATE ACTION. ... entered into the Montreal Automated System (SAM) by the approved participants.
There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. Come Follow ...
