League Pass on Chromebook

I have been having an absolutely horrible time trying to watch NBA games online this year. I’ve been a League Pass subscriber for three years now, and have had no trouble with the digital access, but this year has been a nightmare. It took Verizon 6 weeks to let the NBA know that I had in fact paid to watch the games. Now I have access, but it only works correctly on my tablet, not my Chromebook nor my Chromebit. I do have a laptop it works on, but since the Chromebit is already connected to my TV, and will be connected to the TV in our rental house in Florida, I really, really want to be able to get the games in the Chrome OS.

After talking to NBA support, who basically told me, “too bad, we aren’t supporting the Chrome OS this year,” I decided to tackle this with my browser inspector. Turns out, there is actually nothing wrong with the games, only the links to the games. Once you know what the game link is supposed to be, you can hand enter the URL and click enter. Once I figured that out, I also figured out that from www.nba/games, you can basically reload the default URL that you redirect to, and the player will appear. Seems like reloading should have been the first thing I tried, but I’m too happy to be embarrassed. So far, I’ve only done this on my Chromebook, and only watched recorded games, but I will be trying a live game on the Chromebit tonight.

For those who are technically inclined, I will recount just a bit of my efforts along the way. One thing I did early on with the inspector was to change the html of the page, basically by locating a div with a long class name that included the string “no-league-pass”. I deleted that portion of the class, which helped not at all until I also constructed a link following the pattern I saw in the URL field to match the game I actually wanted. Neither the calendar links nor the game buttons were working. However, after I had successfully browsed to a different game, and then checked again to see whether I would need to edit the class every time I want to watch a game, I discovered the merely reloading the page that /games redirects to, I can remove the no-leaguepass class and everything magically starts to work. I think there is just a problem with the way the redirect is working that somehow fails to detect the fact that a subscriber is logged in. I’m going to try to help the NBA fix this bug, or at least let other users know the work-around.

Here’s how a game link looks: http://www.nba.com/games/20161102/CHIBOS?left=true#/video. Edit the date and the city codes, and you can browse directly to the game you desire.

hidden gems?

I occasionally add features to the Canvas UI by taking advantage of the custom css and custom js files that can be added to all pages in an account or sub-account. This is a really powerful thing, and needs to be done with some discretion. One of my recent additions is a tool that allows you to hide all non-essential screen elements from a Canvas page, including both side bars, and the top bar containing breadcrumbs,etc. In fact, it hides everything EXCEPT the main content area and the global navigation bar. This is especially helpful when you need to project content from a Canvas page onto a screen, so I’ve  made the button look like a little projector, and I’ve put it into the global navigation bar, so that you can toggle back to the normal page when you are done projecting.

I’ve implemented this in the sub-account i use for all my test courses, so at this point, no one teaching a real course in any of the academic sub-accounts can use it. This post is to teach you the secret handshake that will allow you to call the toggleChrome function from within any UD course. It’s a bit technical, so not for the faint of heart.

Here it is, step-by-step. The first step is the hardest.

  1. Open your browser console. If you don’t know how to do this, you will need to visit follow the instructions for your browser OR, just right click inside your browser window, and choose whatever most closely resembles the word “Inspect”. From there, you can probably guess your way though. If the instructions in the page linked above don’t work for you, try a Google search on [your browser] launch console. Or just give up. If you aren’t comfortable searching Google, this page is not for you.
  2. In the console, enter one of the following:
    1. udatsToggleChrome() //this one will toggle between the normal and the stripped-down view. Will work for any UD course
    2. $.getScript(“https://apps.ats.udel.edu/canvas/subaccount_ats.js”);//this one will add the projector button to your global nav, and then you can click it to toggle the views. This one should work for any Canvas course.

No matter which method you choose, you need to do it again each time you load a new Canvas page.

For a more permanent solution, you can visit your course settings and move your course into the IT->ATS sub-account. Doing so will disable any customizations that exist in your current sub-account, however, there are only a few sub-accounts that have any customizations, so you are probably OK to go ahead and make that change. You can always change it back later.

Threadz

I’ve fallen woefully behind in my blogging. Several new LTI apps have gone undocumented here. The most recent of these is Threadz, which has been added to a collection of tools already installed in every Canvas course. The collection is called Utilities, and currently provides a way to do three things that Instructure has not yet enabled via the Canvas user interface.

  1. Download a spreadsheet containing rubric scores awarded for a Canvas assignment.
  2. Create a Group Set with sub-groups based on roster: one group per roster.
  3. Visualize Discussion data.

So, I don’t really have much to say about Threadz that hasn’t already been said better elsewhere. We adopted Threadz from GitHub, so I didn’t write it, although I did modify it a bit. For more information, visit any of the following links:

Utilities Help

The Threadz Mothership

Recording from the Summer Faculty Institute 5 minutes of fame

Canvas Video (alt-F9)

The purpose of this post is to document  6 easy ways to add video to Canvas. Usually when I list things like this, I go from the easiest to the most complicated, but this time I’m going to do something a little bit different. I’m going to take my best shot at listing these from the least well-advertised to the most.

Starting right out with a method I myself did not know about until today. Canvas has quite a few unadvertised features, and each time I find out about one, I do my best to help others discover it more easily than I did. I also like to record things here in case I myself need a reminder about the details.

  1. Reveal the hidden Editor Menu Bar using the keyboard shortcut ALT + F9. On some keyboards, you may need to hold down the Fn key as well as the ALT key.
    1. A new set of Editor controls should appear above the original ones. Pull down the Insert menu to find the video option. You will need to know the url of the video file (mp4, mov, ogg or webm) you wish to embed. The file should NOT be in the Canvas file system. If it is, use method 3.
  2. Use the UDCapture Web Editor button.
  3. Upload video to the Canvas file system and then use the Files link to embed it in your page.
    1. There may be a delay of several minutes before your uploaded video will be viewable. This is because Instructure compresses, and possibly reformats uploaded video.
    2. After compression, you may find the quality of your video unacceptable. If so, you will have to find another place to host your video, such as UDCapture, DropBox, or Google.
  4. Upload video using the appropriate tab in the Video button interface.
    1. Same caveats as above.
  5. Record webcam video using the ‘Record/Upload’ button in the Canvas web editor.
  6. Use the YouTube Web Editor button to search for and embed YouTube video.

OMG

I just learned about an awesome tool that has apparently been around for at least 3 years! It’s another undocumented Canvas gem. Provides super-easy access to anything (?) you can do with the Canvas API. I mean, ridiculous.

This tool is similar to the /undelete link I blogged about on June 9th. To use it, you have to know the url. In this case, the secret sauce is to add /doc/api/live to the end of your canvas domain, so in my case https://udel.instructure.com/doc/api/live. Go there, and you can read all about the api endpoints. Better yet, go there with an access token in your clipboard, and you can use them!

I’m assuming this works for anyone, but with the understanding that the API won’t give you anything that doesn’t belong to you. A lot of those endpoints aren’t going to work for an instructor, much less a student. Still, even students would have plenty to choose from.

LTI App sharing schemes

I’m trying to wrap my head around various app sharing scenarios that I hope to deploy before I retire. The more I can bullet-proof the processes, the better. To help me think about this clearly, I’m going to list the scenarios here, starting with the easiest and working my way up to the muddle currently swirling in my brain.

Level 0: Don’t share, don’t use the API, anonymous.

I’m pretty comfortable with this one. It only requires the blti library I adopted from Dr. Chuck, and I don’t need to distribute key : secrets. I’ve used this to create editor buttons and assignments. I was surprised to learn that even an LTI assignment can be launched anonymously and still pass a grade back to Canvas. I don’t fully understand how that works, but it does. I always require a key and secret when using grade passback, but I’m not sure whether or not that is necessary.

Level 1: Don’t use the API, anonymous, shared

I’ve only done this with one app so far, but it seems to be working out. The app sends a score back from one of the very first simulations I ever created, the UD Virtual Compound Microscope. Since grade passback does not require the API, all I need to store in my database is the key : secret pairs I give to people who want to use it. I have a google form I use to collect and respond to requests. There is a script in the form that composes the sql statement needed to populate the database, and send reply email, but I don’t run it automatically. I like to check first to make sure that all uses are non-commercial. Still, turn around on requests has been pretty fast so far.

Level 3: Use the API, don’t share.

Using the API is a huge step up. It’s a lot harder. It’s a lot scarier. It’s a lot more powerful. I find myself reaching for the API more and more, but also dreading the consequences more and more. However, as long as you don’t have any intention of sharing your code, using the API is pretty straightforward. All I need to do is include my CanvasAPI library, grab an existing admin-level auth token from my database, and I’m good to go. Currently I have several apps that COULD be following this workflow, but only one that actually uses it. Peer Evaluation.

Level 4: Use the API, prepare to share, but don’t.

The rest of my API dependent tools are hooked into a structure I put in place for deploying my developer super-power: requesting tokens on-the-fly. This may have been a mistake, but as long as a valid access key is properly located in the database, the whole token request sequence is never triggered, and the app behaves like a level 3 app. The only difference is that I worry about database corruption if something were to go wrong. There are provisions is there for deleting tokens, replacing exisiting database entries, and of course, writing to the database at all is far scarier than just reading from it. I should probably push everything that is actually in use at UD back to level 3, and maybe I will.

Level 5a : Use the API, don’t share, issue single-use tokens on the fly

This is where I am right now. I have an app that I’m playing with on our campus that requests a temporary token each time it is launched. It has a delete token button you can use to automatically delete, but even if you don’t do that, there is little danger of token abuse, because the token does not get stored. I’ve had a devil of a time getting this to work, but I THINK it is working now. I wish I knew of a way to delete the token even if people exit Canvas without using my button. If anyone knows of a way to do that, please comment!

Level 5b : Use the API, share, and issue/store tokens on the fly

I have one app that I think is doing this successfully, storing instructor level courses for each context in which it is launched. Users should only be asked to authenticate once, since the token is stored. In theory, if an admin authenticates, no one else in that domain should need to. One of the problems with working on this particular branch is that I don’t have access to any other domains I can test on.

Level 5c: Use the API, prepare to share, issue/store tokens on the fly

I have a version of one of my level 4 apps that does this.  The big difference between issuing on the fly and using a dedicated token is that when you have an instructor-level token, your API access is constrained…mostly in a good way. So, for example, when pushing grades into the gradebook via the API using an admin token, you have to masquerade as an instructor in order to have them show up as the grader. In most cases, you won’t even succeed in getting the grades posted unless you masquerade, since admins don’t seem to have the authority to grade assignments. When using an instructor token, you don’t need to masquerade. Your grades will show up as though they had been submitted by the token holder. This is not quite the same thing as showing up as the logged in user, since some courses have more than one instructor, and the same tokens are issued per course, not per instructor. Since instructors don’t have the power to masquerade as each other, it’s a fly in the ointment.

The other big difference is that there are just so many more places for things to go wrong. Also, it is way, way harder to test.

Level 6: The holy grail

Ideally, you’d want to have a single set of files that handles all of the above scenarios on demand. I am still hoping to get to this level some day. So far, even the baby steps I’ve attempted have been a struggle.

At the bar

It’s Friday morning, and I’m at the Faculty Commons welcome bar. I have my Chromebook on my lap, because I am unable to position myself comfortably for typing here. All-in-all, getting anything done during my bar time has turned out to be as near to impossible as makes no never mind. Apart from physical discomfort based on the height of the bar and the lack of footrests on the bar stools, I just really miss my dual monitors and effortless access to my desktop file system and installed applications. So, I’ve resigned myself to tasks I can perform wholly online, like writing blog posts. I’ll be posting pretty much every Friday, and probably never at any other time.

Two hours is a long time to spend composing one blog post, but of course I am also responsible for answering the phone and helping people walk in during my shift. Time drags when you’re not getting anything done, but at least I only have one two hour shift per week. My next post in this  category will be about my efforts to actually be productive while using my Chromebook. Who knows how many post I’ll end up making this morning. It’s only 9:00, and I’m here until 10:30. Yikes.

reThinQ

blog post updated June 30, 2015.

I’m currently working on a new Canvas extension we’re calling reThink (renamed from FATT). The basic scheme is to craft a multiple choice quiz that students take in teams during class time. Each time they select an answer option, they get immediate feedback. Each time students select an answer, they can immediately see whatever feedback message the quiz creator associated withut. The earned score for each question drops each time an incorrect choice is revealed, and teams compete with one another for the top total score.

ReThinQ takes advantage of the existing Canvas Quiz engine, as well as the interface Canvas provides for creating and managing groups. A reThinQ exercise returns grades and comments to the gradebook, so that instructors can review student performance item by item, and option by option. Fundamentally, though, the power of reThinQ is in the discussions it inspires among students in each group.

The reThinQ tool is currently still in beta. i have one brave soul trying it out in her Spanish summer course. Interested UD faculty can contribute to reThinQ development and testing by contacting Becky Kinney, or adding a comment to this post. For those who want to install and use the tool as is, documentation is available at https://apps.ats.udel.edu/canvas/rethinq/help.html.

 

Khaki

On March 20, 2015, Instructure hosted 40 hand-picked Canvas administrators and instructors from both K12 and Higher Education in an effort to improve their user outreach efforts. The new initiative was named Khaki, and was the first of it’s kind at Instructure. All participant travel expenses were paid by Instructure.

Although I was in the midst of a long-planned vacation on March 20th, I decided to attend this invitation-only event. It was well worth my time. The meeting was inspired by user discontent around a single issue: Canvas’s feature request system was perceived as unresponsive to many of it’s most active contributors. Long-standing, highly popular requests were receiving little or no attention from Instructure employees, and the anger and frustration were starting to boil over.

During the Khaki meeting, we were presented with two lists. One contained unfulfilled feature requests, and the other, unfixed bugs. We were given an opportunity to vote on 3 issues. First, what percentage of developer hours should be devoted to bugs vs. features. Second, which features? Third, which bugs? We were given 10 votes to expend on each question, with the caveat that we use no more than 5 votes for any given bug or feature. The results were startling, not so much in terms of which issues won out, but in terms of the immediate impact on Instructure’s roadmap for 2015.

The first, and perhaps most meaningful outcome was that Instructure shifted the balance between bug fixes and feature development from their existing 1:2 ratio to a 50-50 split. This immediately caused ALL the bugs identified on the list provided to Khaki participants to be scheduled for resolution by the end of 2015, regardless of the votes they garnered.

The second outcome was more controversial. There was only enough developer time to complete the top three vote getters among the feature requests. This was largely due to the fact that the most popular features turned out to be quite costly in terms of the estimated number of developer weeks required :

  1. Selective Release (60)
    Instructors are able to give an assignment to one or more individual students in a single course section.  Conditional release without modules.
  2. Improved performance of Gradebook when loading large rosters (72)
  3. Speed Grader 2.0 (64)
    Improve the overall SpeedGrader experience, including better user flows, reusable comments, and the ability to grade one question at a time. This series of improvements may also be impacted by other Canvas enhancements, including Late Assignment Submissions, Anonymous Discussions, and Anonymous Peer Review.
    prerequisite: Gradebook performance update.

Once the results were in, we were given the opportunity to re-cast our votes in light of the fact that we could easily pick up 3 or 4 quick-and-easy features for the price of one of the favorites, but in the end, we stuck with the original winners. This seemed to take the Instructure CEO by surprise. I got the sense that they were expecting that, once we realized how difficult these trade-offs could be, we would make choices closer to the ones that Instructure has been making all along. Indeed, that could easily have been the outcome, but instead, we ended up with choices that Instructure would clearly not have made in the absence of this meeting.  The influence that 40 people were given over the course of one 6 hour meeting was nothing short of startling. In essence, we were handed total control over 20% of the Canvas development budget for the second half of this year, with precious little background knowledge, and no awareness prior to the vote of how meaningful it was going to be.

I have very mixed feelings about the level of empowerment our little cadre was allotted. From my perspective, all Instructure really needed to do was hop onto their own forums and provide some honest feedback to those of us who subscribe to feature request threads. To actually hand the reins over to a small group of vocal participants seems like a rather drastic response. Talk about greasing the squeaky wheel. Wow.

On the other hand, I am thrilled that Canvas is now destined to be significantly less buggy than it has been up until now, and that the pace of new feature roll-outs will be slowed. It won’t mean that every long-awaited feature will appear in the foreseeable future, but for me, that wasn’t really the point. I’m hopeful that Instructure’s priorities will be globally shifted in two important ways: first, make the features you already provide bug free rather than heap on new features every 3 weeks, and second, don’t assume that more is always better when it comes to adding features. As a developer myself, I well understand the temptation to churn out easy features rather than tackle the ones that will require a lot of work, and have far-reaching consequences in terms of other features that will need to be touched. But just because something is easy doesn’t make it right. If we are lucky, Instructure is starting to understand that.

Instructure has promised to keep Khaki alive, although nothing was said about who would foot the bill for next year’s participants, nor how they will be chosen. Are the 40 of us lifetime members? One thing we do know is that there will soon be a new site for the Canvas forums, and a new process for collecting feature requests. The new site will have many of social networking capabilities of Facebook or LinkedIn. Khaki will have a group presence there, as will other groups to be announced. Let’s hope the new site provides a better platform for Canvas users to communicate with Instructure.

 

Microscope LTI

At long last I have implemented a version of the Virtual Microscope that can be hooked into an LMS in a meaningful way. When deployed within Canvas, the new simulation will post a grade back to an LTI (Learning Tool Interoperability) Consumer. So far, I’ve only tested it in Canvas, because the Sakai instance I have access to doesn’t support LTI Outcomes Services properly, but it should work for Moodle, Desire-to-Learn, and any other LTI enabled LMS.

As an added bonus, when used in Canvas, I have taken advantage of an extension that allows me to return a url along with the grade. The url links directly back to the simulation with all data required to focus the scope on the specimen in view at the time that the student chose to post his/her grade back to the LMS. Following the link lets you have an immediate view of whatever the student could see at the moment the grade was posted.

I’m trying to get Google Analytics to merge the hits from the LTI version with the tracking I already have established. So far, I’m not seeing any new hits, but I’m hoping that is because GA doesn’t harvest the hits in real time? I’ll know better tomorrow.