When you combine the IMS LTI, Deep Linking, and Common Cartridge standards and use them together in a coordinated fashion, you can build and Educational App Store that has smooth integration into the major LMS systems using only IMS standards. Tsugi (www.tsugi.org) is a software framework that reduces the effort required to build IMS standards-compliant applications and integrate them into a learning ecosystem. This presentation will highlight how IMS standards can be used to deploy an educational app store like www.tsugicloud.org and talk about how an App Store lays a foundation towards a Next Generation Digital Learning Ecosystem (NGDLE).
I figured I should reflect on Tsugi as we move into the new year. It has been over six years since I started the code base that would become Tsugi in 2013.
In 2017, we made a lot of progress so Tsugi can be used by by a much broader audience. Some important Tsugi achievements include:
– A place to host open source Tsugi tools at scale for free – www.tsugicloud.org – this required new Amazon features and required improving the “App Store” experience for tools-only servers. There is an app store with metadata and screenshots like any app store.
– Adding support for Google Classroom in addition to LTI for LMS integration. I heard that Google Classroom already owns >60% of the K12 market share. I think that over time Classroom will erode market share in K12 market and in time will begin to make inroads into higher education starting with Community Colleges / FE. So strategically, I want Tsugi to have an early presence in that new emerging market.
– Cleaned up the existing tools in the “tsugitools” repo – like the peer grader with an eye to making the tools more usable by folks other than me :)
– Started to lay the legal groundwork to establish the first Tsugi Commercial affiliate. This is a lower priority activity – once the free/open Tsugi / TsugiCloud is solid – I will progress a commercial offering. If demand emerges for a commercial Tsugi offering, it will be quite easy to replicate the TsugiCloud infrastructure for a commercial offering.
Looking forward to 2018, I have a few goals:
– Begin to document and market tsugicloud.org to build a beta customer base. My first customers will likely be Sakai schools but I will work to get exposure to K12 alpha testers to get a small base of K12 customers. Let me know if you are interested in being an early customer or if you know someone who might want to use TsugiCloud.
– Recruit new open source applications for TsugiTools and host them for free on TsugiCloud
– Focus on cleaning up the developer documentation on tsugi.org to make it easier to develop new applications.
– I will be running an “Tsugi Developer” class on-campus at UMich during Winter semester. This will help improve my documentation and work out the kinks in the developer experience.
– It will be a high priority to build 2-3 new high-quality tools: (1) A threaded discussion tool with grading, (2) A wiki-like tool, perhaps based on HAX from ELMSN, (3) A tool to include H5P content. This fits with the 2018 focus on building tools on the Tsugi infrastructure.
– I am trying to think of something to trigger Tsugi tool development – perhaps a hack-athon or a contest – something to build interest in developing tools.
So it should be an interesting 2018. There is a lot of work to do but a lot of great work to build on.
I have expanded the contract in register.php for the tools to describe themselves and improved the pattern in .htaccess / tsugi.php to better support the App Store. You can see this all in action at:
Play with “Test” and “Tool URLs”. A much smoother flow and richer experience.
You can see the new patterns for developers to take advantage of this in a relatively simple tool like:
Look at .htaccess / tsugi.php / register.php and the store folder which holds screen shots. Some notes:
– The new and expanded register.php is what drives the pretty store view under /tsugi/store
– The new tsugi.php makes it so every tool has a Canvas configuration URL and can dump its own configuration in JSON (more to come here):
– There are new options in tsugi/config.php to include a privacy url and service level agreement url:
$CFG->privacy_url = 'https://www.tsugicloud.org/services/policies/privacy'; $CFG->sla_url = 'https://www.tsugicloud.org/services/policies/service-level-agreement';
These are important when connecting to Google Classroom so you should have them for your sites. Don’t point to mine – make your own and be honest and thorough.
And while I am on the topic – you might want to take a minute and play with Google Classroom. It is easiest to use a non-enterprise Google account. Some enterprises (like umich.edu) do not let their users use Google Classroom. But my @gmail.com account works fine.
Log in to classroom.google.com and make a course. Then go to
And connect to Google Classroom. All of a sudden little green squares show up to let you push tools into Google. Grades flow and everything. Google Classroom flow is pretty nice – but like any proprietary integration – to make it work on the Tool Provider side requires special tooling.
So in summary, if you are a Tsugi tool developer, you might want to up your game in register.php, tsugi.php (adding .htaccess if you don’t already have it) and adding some screen shots in a store folder. The App Store falls back nicely with a simpler view until you upgrade your tool to feed the necessary metadata to expanded store.
Hope you like it and comments welcome.
TL;DR – The Demo
Tsugi and Google Classroom
For the past four years, I have been building software to implement my vision for the new technologies that will enable the Next Generation Digital Learning Environment/Ecosystem.
Tsugi – is software infrastructure, APIs, and code libraries that allow interactive learning tools to be built, hosted and integrated into Learning Management Systems like Sakai, Canvas, Blackboard, Moodle, Desire2Learn, edX, or Coursera. Without requiring the programmer to read and understand the complex documentation that describes the low level details of these integrations.
Koseu is a LMS/Course platform that is aimed at supporting course content on the web. Koseu in a sense is a way for every teacher to build and publish a “MOOC of my Own” while at the same time making that learning content easily integrated into LMS systems. My Python for Everybody web site (www.py4e.com) is a good example of a well developed Koseu-based web site.
Up to this point, Tsugi has focused on the standards like such as IMS Learning Tools Interoperability, IMS Common Cartridge, and IMS Content Item that are used to integrate content and tools into traditional LMS systems.
But increasingly, Google Classroom is being used in K12 and beyond as the “LMS” of choice since so many organizations already use Google Suite for their single sign on, document editing, forms, etc. It is a simple matter to just start using Google Classroom – and Google Classroom is very well connected to the rest of the Google Suite.
So we have added initial support for Google Classroom integration to Tsugi/Koseu. The Google Classroom API patterns are very different than IMS LTI and Content Item Message. Google Classroom uses an OAuth 2.0 and single sign-on (SSO) pattern instead. This pattern requires more initial coordination, but has some nice features that allow the end-user to be involved in their own privacy decisions.
With this support, a Tsugi tool can send grades to the Learning system regardless of where the tool was launched using LTI or with Google Classroom using the exact same lines of code and exact same code libraries.
If we are truly going to make a Next Generation Digital Learning Ecosystem, systems like Tsugi and Koseu need to look beyond the traditional LMS market and to emerging platforms like Google Classroom.
Net Neutrality as Applied to Stop Lights
I was asked for my comments on Net Neutrality by a reporter and so I wrote this.
In general, I think that it is difficult to predict exactly what bad things will happen and in what order. Once Net Neutrality is no longer an underlying value of the Internet, those who control critical core internet resources like fiber links and peering points will look for opportunities to hold traffic “hostage” to make more money.
I believe that in general, “small sites” may not really notice any change except for a general inflation in bandwidth prices as hosting providers like Amazon, Internet2 and DigitalOcean are held hostage. The wholesale cost of bandwidth could easily double in 2-3 years once “Net Discrimination” is officially legal. Large sources of bandwidth like Netflix, Hulu, etc are going to see “death by a thousand cuts” as every little router owner all around the world is going to want their cut. The cost for bandwidth is likely to go up by a factor of 2-3.
It is as if you are driving through a city and every stoplight has a toll booth where you need to stop and take out your credit card to pass. Assume a bunch of different companies you never heard of each “owned” one or two stoplights in downtown Mountain View. When they “bought” the stoplights there was a rule that you could not charge for a green light but instead you got a small fixed amount of money to run your stop lights to move traffic as efficiently as possible. Now with “Stoplight Discrimination” legalized, they can hold car manufacturers “hostage” for green lights. Tesla can pay them so their cars can send a signal to the stoplight so it immediately turns green whenever a Tesla is moving toward the stoplight.
The problem is that sooner or later all the major car manufacturers will have to pay each of the little stoplight companies the “stoplight toll” and then all traffic will be again be treated equally and the companies will be getting very rich.
And the worse part of it is that there is little incentive to improve the roads or generally improve stoplight technology – because the frustration of the drivers and their complaints to car manufacturers leads to more revenue for the stoplight owners. And when things get really bad the stoplight companies can tell car companies they can purchase the “silver level” to once again get differential treatment for their cars. And then everyone buys the “silver” level so they introduce “gold level” traffic discrimination – and so on. Soon, “platinum”, “ruby”, “sapphire”, and “diamond” levels emerge – and then “double diamond”. The worse that traffic gets snarled up because of the byzantine pay-for-play rules – the more money these stoplight companies make.
The revenue potential for doing absolutely nothing more than what you were already doing is immense. No wonder these companies love Net Discrimination.
And our costs of all these services will go up because the “stoplight tax” will ultimately just be passed to the consumers.
This is a story that I tell people over and over when I meet them – so I figured I would make a blog post so I could have it written down somewhere.
I am an accidental Internet historian. It all started in 1995-1999 I hosted a Cable television program with my friend Rich Wiggins that was a talk show about the Internet that ended up with three names over time as the cable TV companies bought one another over that period. Here is a YouTube of those (3) shows:
This led to me having lots of cool early Internet video and for a number of years I wrote a column called Computing Conversations in IEEE Computer Magazine that wrote a short print article with an associated video interview. Here is a Youtube Channel of that work:
You can see my old material and new interviews since 2012 interwoven. I also attach a couple of articles to give you a sample. We even made an NPR-style audio interview for each of the columns:
Then in 2012, I re-did all this material in the form of a Coursera class titled Internet History, Technology, and Security – that is how Niel and I crossed paths. Here is the course and a Youtube channel of the lectures and media:
I even turned this all into a textbook on the basics of the Internet that I wrote for a Khan Academy high school course course on TCP/IP. I finished the book but never built the Khan Academy course.
The latest activity was a live Teach Out – a one week open learning learning activity that I did with Doug Van Houweling called “Internet and You”
This is a story that will keep going as long as I find new folks to interview and add to this collection – I hope folks enjoy this material.
Sakai Virtual Conference 2017
We are Open for Collaboration!
November 14, 2017 – Online
Registration ends November 13th at 5pm ET (your timezone)
Register now! Registration is $50 per person, or $500 for group/institution registration, with all proceeds going toward Sakai feature development.
The Sakai Virtual Conference will take place entirely online on Tues. Nov. 14th, 2017. You’ll attend presentations in concurrent session webinar rooms, ask the presenters live questions, and get the conference experience without the expense of travel. There will be opportunities for networking and informal discussions, as well as a chance to win prizes donated by our sponsors.
Learn about the latest developments in Sakai, exciting new tools, and how faculty are taking advantage of the unique features of Sakai to promote student learning and engagement.
Come and learn more about:
What’s new for Sakai 12?
Innovative uses of Lessons, Syllabus, Tests & Quizzes
What’s all the buzz about Learning analytics?
Join birds of a feather discussions on a Sakai Mobile App, Lessons, NGDLE, Badges, Tsugi, Sakai Skins, and more
The full conference program and session descriptions for the Sakai Virtual Conference are now available online:
The Sakai Virtual Conference is a unique opportunity to network with your peers and share stories and best practices in an online venue.
Reference: This post is from an email written by Neil Caidin and sent to the sakai-all mailing list.
We are just under two weeks out from The Internet and You! Teach-Out with Doug Van Houweling and me. I would like to encourage you to sign up for this event on Coursera, as we look at the past, present, and future of the Internet and how it influences society.
As we move closer to October 30, we’d love to hear your own thoughts and questions about the internet, so they can be addressed within the live sessions. Consider the following questions:
- What questions do YOU have for Doug and I about the past, present, and future of the Internet?
- Do you think the Internet is broken? If so, how should it be fixed?
When you think about the Internet, what puzzles you?
- Do you ever worry that the Internet might be changing for the worse? Why? What concerns you?
- As the Internet continues to become more embedded in our lives, is there anything about it that concerns you?
Once you sign up, there are two ways you can share your responses or questions with us:
- We provide a form to share your YouTube video
- We provide a phone number to leave a recorded voice response
We’re looking forward to seeing you on October 30 for the first live session!
Increasingly faculty need to build educational materials that can be reused and repurposed across a wide range of learning environments. In the “old days”, faculty would dust off last semester’s PowerPoint, fix a few typos, upload it to a campus learning management system like Sakai or Canvas, and walk into lecture. Increasingly, our learning content includes course assignments, specialized software to help with assessments, video materials, formative assessments, supporting materials, etc. And for each course, on each LMS, you needed to upload and format your content and place it into a “course shell”. But now at many campuses, there may be several learning platforms and one or more MOOC platform like Coursera. It is a lot of work to re-author your course content in three or four learning platforms. But with the widespread adoption of LMS interchange standards like IMS Learning Tools Interoperability, IMS Common Cartridge, and IMS Content Item, we should be able to author content once and easily integrate into as many learning platforms as needed. This talk will explore research into developing easy to use learning object repositories and learning application stores that enable this “write once – use anywhere” model of learning content development.
This is mostly my own notes in my attempt to find a quick developer / compile option for Sakai.
TL;DR – An EC2 c4.2xlarge with the right .bashrc settings is a very fast compile box for Sakai.
Check out my Sakai scripts:
Put in all the pre-requisites – make sure to run the qmv.sh script once to get the maven repo cache
warmed up before doing timing.
My baseline is my own MacBook Pro with quad processor i7 2.8 Ghz, with 1TB SSD, and 16GB RAM. I played with the last line in the qmv.sh to change the number of threads in use using the “-T” options.
mvn -T 4 -e -Dmaven.test.skip=true -Dmaven.tomcat.home=$tomcatdir $goals
1 thread - 4:08
2 threads - 2:47
4 threads - 1:52
Testing on Amazon
AWS – c4.2xlarge, 15G RAM, 8 CPUs, 31 “ECU Units”, EBS
Setting the MAVEN and JAVA OPTS to -Xms4096m -Xmx4096m
4 threads 1:25
Setting the MAVEN and JAVA OPTS to -Xms8192m -Xmx8192m
6 threads 1:17
8 threads 1:18
For future testing we might look at less expensive per hour boxes but this certainly is fast enough for Sakai development at $0.40 per hour.