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:
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.
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! 🙂
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.
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.
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)
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!
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.
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.
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):
<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>
<p>Proin elit arcu, rutrum commodo, vehicula tempus, commodo a, risus.</p>
<p>Morbi tincidunt, dui sit amet facilisis feugiat, odio metus gravida ante, ut pharetra massa metus id nunc.</p>
<p>Mauris eleifend est et turpis. Duis id erat. Suspendisse potenti. </p>
Now, if the jQuery UI were to suddenly disappear, you would end up with something like the following:
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:
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.
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. 🙂
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.