what's going to happen to deprecated jQueryUI?

[laurakgibbs]

I'm reposting questions from another page here, hoping to carry on the discussion as a discussion (instead of a question that is not an easy one to answer). So, start here if you are not familiar with the problem:

Deprecated use of magic jQueryUI widget 

Thanks to  @jnickerson1 ‌for the info in the other discussion, and to awilliams‌ for suggesting a separate discussion based on what we learned there:

Basically, I've got four separate but inter-related questions about Canvas support for jQueryUI (as used for tabs, accordions, other display effects):

1. When will Canvas no longer support the deprecated jQueryUI options?

2. Is someone going to go through the Community space alerting people not to the end of Canvas support for these jQueryUI options? I've seen jQueryUI mentioned and highly recommended by multiple users in multiple places; that was what finally persuaded me to give it a try last weekend.

3. What exactly would be required for jQueryUI to be supported by local Canvas administrators? Will Canvas prepare documentation so that it will be easy for local administrators to provide that support if they agree?

4. Is there some kind of way for individual faculty to run a report that would identity deprecated jQueryUI instances in their course spaces and/or for system administrators to do so across their system?

I was excited by the results I had experimenting with jQueryUI over the weekend (my experiment here), but I'm definitely going to hold off on using these features in the current uncertainty. My concern is more for people who are heavily invested in this design feature whose Pages are going to become very unattractive and perhaps even unusable when support for the jQueryUI comes to an end.

[themidiman]

I wonder if  @kenneth_larsen  might have some insight as his KennethWare used to be a community resource that seems to have turned into a full on enterprise for his group. Having tried to do what they did for our institution a year ago, I had to resort to telling folks to use the built in styles instead because it became too problematic.

[laurakgibbs]

I really like how this Community space allows discussion to happen not just across schools, but also across different types of users, with non-tech-faculty like me, and then people who have insight into Canvas administratively, institutionally, etc.

Getting different perspectives is surely a big part of finding a good solution. 🙂

[kenneth_larsen]

I can't answer too many of the questions above, but I am happy to chime in on the conversation.

When I started developing tools to extend Canvas, I took advantage of quite a few of the different features that are built into the Canvas style guide. However, as time moved on, I realized that such behaviors left that content at the mercy of Canvas. What I now develop, I take the approach that if Canvas were to take away everything that I rely on to make this content, what would it look like?

With that approach in mind, the tools I make create content as basic html and then I use jQuery to turn it into jQuery UI elements.

Let's use tabs as an example. If you were to write the HTML for jQuery UI tabs, it would look something like this (exact implementation in Canvas probably varies):

<div id="tabs">
  <ul>
    <li><a href="#tabs-1">Nunc tincidunt</a></li>
    <li><a href="#tabs-2">Proin dolor</a></li>
    <li><a href="#tabs-3">Aenean lacinia</a></li>
  </ul>
  <div id="tabs-1">
    <p>Proin elit arcu, rutrum commodo, vehicula tempus, commodo a, risus.</p>
  </div>
  <div id="tabs-2">
    <p>Morbi tincidunt, dui sit amet facilisis feugiat, odio metus gravida ante, ut pharetra massa metus id nunc.</p>
  </div>
  <div id="tabs-3">
    <p>Mauris eleifend est et turpis. Duis id erat. Suspendisse potenti. </p>
  </div>
</div>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Now, if the jQuery UI were to suddenly disappear, you would end up with something like the following:

• Nunc tincidunt
• Proin dolor
• Aenean lacinia

Proin elit arcu, rutrum commodo, vehicula tempus, commodo a, risus.

Morbi tincidunt, dui sit amet facilisis feugiat, odio metus gravida ante, ut pharetra massa metus id nunc.

Mauris eleifend est et turpis. Duis id erat. Suspendisse potenti.

You have a list of links that don't really do much and groups of content the run into each other.

The approach I take is to create content using headings and divs more like this:

Nunc tincidunt

Proin elit arcu, rutrum commodo, vehicula tempus, commodo a, risus.

Proin dolor

Morbi tincidunt, dui sit amet facilisis feugiat, odio metus gravida ante, ut pharetra massa metus id nunc.

Aenean lacinia

Mauris eleifend est et turpis. Duis id erat. Suspendisse potenti.

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍These headings and divs have different classes that I can target using jQuery to rebuild that and turn it into the HTML necessary for tabs. If the JavaScript were to go away, the content is still accessible and makes sense.The other fun thing that I can do with this arrangement is easily change my mind and turn the code from a tab to an accordion.

When Canvas does do away with jQuery UI widgets, an institution that still wanted to use those widgets would need to add the code they want to use back into Canvas. There are some crazy little nuances that you have to work through to make sure all of the timing works out but it is possible using your account global JavaScript file. 

Now, don't get me wrong, I still use aspects of the Canvas style guide like button and table styles, but these are all things that are relatively easy to recreate should Canvas remove those styles from their own code. This ability to extend and add onto Canvas is one of the things I like most about Canvas.

Anyway, those are my ramblings for the moment.

[dwillmore]

As always, thank you sir.   If you built a 16 week course on tweeking Canvas through code with best business practices, I would pay a lot to take it.

[d_ellis]

Great questions, and a great summary - thank you laurakgibbs. This back-end change has a huge amount of front-end impact - and a timeline, change process, and institutional plan will save a lot of grief (and support calls!) further down the road.

[ryan]

I added this comment to the original forum post but I wanted to add it here too in case someone came here without reading the other:

Hey everybody, this is Ryan Shaw, from the canvas engineering team. I see a lot of great questions here and some worry so I wanted to chime in to provide some guidance and assurance.

A little background: Canvas has, for a long time, used jqueryUI for our own widgets. So when you see a modal dialog pop up or an accordion or a group of tabs, they were probably using jQueryUI. One day, after talking with some awesome customers at instructurecon that were creating their own content, we decided to add this little piece of code: https://github.com/instructure/canvas-lms/blob/stable/public/javascripts/instructure.js#L66-L101 so that if you added class names like .tabs, or .accordion to your content it would automatically turn that element into that kind of jqueryUI widget for you without having to write any code yourself.

The problem:

First, sometimes the markup that gets created from people doing this in their content is not accessible. So, for example, users using a screenreader would not be able to use that content. That’s a huge bummer for them so we wanted to make sure we weren’t contributing to that.

Second, we are starting to rely on React.JS more and more in our front-end code, and we have even written our own UI library (http://instructure.github.io/instructure-ui/) that is built on React and is much more modern, has better UX, fixes a ton of bugs that would pop up with jqueryUI widgets and, has some of the best accessibility support of any UI lib I’ve ever seen. So we have started replacing places we were using jQueryUI widgets to use instructure-ui widgets and using the latter exclusively for new code.

So eventually, we hope to get to a point where there is nothing that canvas is doing that is using jqueryUI and loading it will make canvas slower for everyone. jQueryUI is a big javascript library, and loading all of it's code on every page has a real cost in terms of time it takes to download and view every page. We don’t want to slow down all of canvas for everyone even if they are not using this.

That's why we put that warning message in there. And in general, it will be safer and less brittle for your custom interaction code to not be dependent on canvas’ code. So us making a change doesn’t break your code and vise-versa. That’s why we recommend loading your own widget library in your custom ThemeEditor JavaScript file if you want to add custom widgets to your content.

As far as when will canvas stop using jqueryUI anywhere, I’ll be the first to tell you that it will take a long while...like measured in years, not months. And as long as we are loading jQueryUI widgets for something we need on the page, there’s no reason not to expose it like this for you to use too.

So the “official” future-proof, encouraged way of adding your own widgets is to include your own UI library in your custom JS file so it is not dependent on anything from canvas’ code. (On a side note, if you are going to do that, make sure that you are using a library that has good accessibility support, there are a lot out there that look nice but are unusable by screenreaders)

But, if you have a bunch of content relying on this and you are willing to stay on top of things, and check the release notes and react if canvas does stop using jqueryUI, you are free to do so, however it is now considered “unsupported”. But we will say something in the release notes if we ever do remove this feature, and in the worst case scenario you could just add jqueryUI to your custom ThemeEditor JavaScript file and a similar snippet to what we did for this and not have to change any of your content even after we stop supporting this.

I hope that helps clear up some of the what, why, and when behind this question. I love reading these forums, you guys are so innovative, so helpful to each other and your passion to create great educational content shows!

[laurakgibbs]

Thank you SO MUCH, Deactivated user !!! That is extremely helpful, and insofar as I can understand the technical details, it's clear that this is something that will have to be addressed at an admin level; it's not something an individual faculty user like myself can do anything about. So I will pass this along to the Canvas admin people at my school; we just started using Canvas this year, and I don't imagine there are many (any?) people at my school who had started using these jQuery UI features. That means I don't imagine they will feel a need to provide ongoing support for the jQuery UI, but at least they will be forewarned in case it does come up.

I really appreciate the detailed reply here (and at the other post too).

And I am glad I found the warning about this before I started using lots of tabs and accordions! 🙂

[awilliams]

Deactivated user Thank Youfor the information. You definitely helped shed some light on the nature of the deprecation and the more information we have the better!