Reflections on MoodleNet at the Global Moot 2019

(MoodleNet presentation begins about the 1h00m mark)

Last week was the first-ever Global MoodleMoot in Barcelona, followed by the inaugural Open EdTech Global conference. Both events were attended by the MoodleNet team, with Doug Belshaw (Product Manager) there all week, and Mayel de Borniol (Technical Architect) around for the Moot.

We had chosen the Moot as a self-imposed deadline to demo the latest iteration (version 0.10 beta) of MoodleNet at the Moot, and (in the subsequent workshop) invite people to get their hands on a MoodleNet account. Unfortunately, things didn’t pan out that way.

It was a close-run thing, but on the night before we were due to present, it was clear that we would only be ready to show 80% of the MoodleNet functionality we wanted to demonstrate. Unfortunately, the remaining 20% included functionality around the timeline, which, for a social network, is critical. We decided, therefore, to hold off issuing accounts and doing a live demo.

The team have had a retrospective about what happened. Without diving too much into the technical details, here’s the order of events:

  1. Over the last few months, we re-wrote the backend of MoodleNet entirely, as well as creating a new front-end user interface
  2. While most of the core functionality was ready on the backend and front-end for the Moot, we had issues with breaking changes relating to the GraphQL API (which provides queries from the front-end to the backend) which meant the whole team had to coordinate to make sure the different parts worked well together
  3. Despite the team working overtime and staying up hacking on it until 3am (while the MoodleMoot attendees were at the Moodle Party), we just needed more time to fix things before providing a proper look at the MoodleNet user experience

As a result, in the Moot presentation and workshop we were only able to show screenshots of MoodleNet’s functionality. Neverthless, as an open source project, we have already had developers setting up their own test instances of MoodleNet, as they are happy to live with incompleteness of features while they dive into the code.

We’re going to learn our lesson and not give any hard-and-fast promises, but we’re feeling confident that we will fix the remaining issues soon and should be able to start federation testing next month, though we may wait until January 2020 to open up registrations on instances run by Moodle HQ.

Despite our disappointment around not being able to show all of the amazing work the team has done over the last few weeks and months, there is a lot of excitement around MoodleNet. We’ve had Moodle Partners offering to work with us around integration with Moodle LMS, organisations wanting to set up an instance as soon as they can, and many, many end users eager to get an account.

The MoodleNet team is small and part-time. Our apologies for this setback, we’ll continue to work tirelessly to deliver this solution to you as best we can. We’ve certainly learned a lot from the experience!

Update on federation testing

Orange notebook

The MoodleNet team have received a few emails recently asking when federation testing will begin. This short post aims to clarify a few things.

First, it’s worth saying that you can still sign up to test MoodleNet as an instance administrator via the form linked to in this blog post. Upon completing that, we’ll add you to our federation testing mailing list, either as an individual or organisation.

Second, we’re a small team, so to avoid putting undue pressure on ourselves right before the Global Moot, we’ve made the decision to begin the federation testing period in Barcelona. That means the timeline looks something like this:

  • 19th November — Presentation at Global Moot and start of federation testing programme
  • 2nd December — Start of support period for the federation testing programme

As you can see, there’s a two-week gap from the start of the programme to the beginning of the support period. This will ensure that new admins have a chance to set up and configure their instance, and that the MoodleNet team have a chance to take some time off right after an intense period of work. During this time we will make a best-effort help to assist via our forum, but ticket-based support won’t be available until the start of December.

Finally, it’s worth re-iterating that the MoodleNet team will assume a working knowledge of Linux server administration with Docker containers. If you need some help in getting up-to-speed, check out the official guide to getting started with Docker.

Statement on GitLab

The MoodleNet team use products and services from GitLab Inc. to develop the MoodleNet code base. We were therefore disappointed to learn of a recent decision by GitLab Inc. to change their policies around who they will and will not do business with.

"Deciding not to turn down customers on "moral/value" grounds is still a "moral/value" choice. It's just the wrong one. I hope that GitLab employees are furious."
Tweet from Eva Galperin, Director of Cybersecurity for the Electronic Frontier Foundation

As reported in The Register, GitLab Inc. first updated their policies to declare that they “won’t ban potential customers on “moral/value grounds,” and that employees should not discuss politics at work”. However, after a substantial backlash from current and potential customers, they have modified their position to “get rid of the problematic passages put forth in [the] handbook change”.

The internal policies of other companies might seem irrelevant to the work we are doing at Moodle, but it is important that, as a purpose-driven organisation, we use the influence we have to make our world a better place. Our values include integrity (“we employ the highest ethical standards, demonstrating honesty and fairness in every action that we take”) and openness (“we strive to be open in our goals, our tools, our processes and our results, as much as is practical”).

We believe that in order to live up to our values of integrity and openness, we should make decisions of which our community can be proud. While it would appear that GitLab Inc. have partly reversed their decisions based on the firestorm of criticism they have received, we have nevertheless decided to remove the MoodleNet repositories from gitlab.com and move them to a self-hosted solution. We will provide a further update on this after the Global Moot in Barcelona next month.


Note: the MoodleNet project is set up differently to the Moodle LMS and Workplace projects. Last year, we made the pragmatic decision to use gitlab.com (an instance of the GitLab open source software operated by GitLab, Inc.) to ensure that our project was as open to contributors as possible. 

Our intention was always to move the project’s repositories to an even more open and decentralised solution at an appropriate time. Now that time has come, we are evaluating a variety of options, including the ForgeFed project. Although we may decide to mirror our repositories on centralised services such as GitHub, we believe it is important for the canonical location of our code to be under our control.

Getting feedback on resource uploading in MoodleNet

Upload

Over the past week, we’ve taken the opportunity to talk with 10 community members about uploading resources into MoodleNet. These range from an expert in metadata standards to an educator who is less technical — with the majority being somewhere on the spectrum somewhere inbetween.

What we have been attempting to establish is the simplest and most straightforward way for users to add resources to MoodleNet, while capturing an appropriate level of metadata. We don’t want users to feel that adding appropriately-licensed resources to MoodleNet (and making them easily-discoverable) is a laborious process.

Context

As we explained in a previous post, we plan to restrict users uploading resources to three ‘Free Culture’ licenses:

If a user adds a resource via a link, then they don’t need to indicate within MoodleNet which license that resource is made available under. That’s because after the user clicks through, the external site should provide this information along with the resource. It also saves us from having to display a long and unwieldy list of licenses.

MoodleNet - add resource

Another thing by way of context is that, as we outlined in our post about MoodleNet metadata, resources will ‘inherit’ tags from their collection. At the moment, we’re thinking of implementing this in such a way that the interface automatically starts to complete tags for the resource — language(s), grade level(s), and subject area(s). That’s not actually shown on the screen below, but you can imagine ‘English’, ‘Postgraduate’ and ‘Education Science’ before ‘IDmodel’.

Tagging resources in collections

What we discovered

Here were the top 10 things that were on the mind of those we spoke with about resource uploading in MoodleNet:

  1. Drag-and-drop – extremely important for ease-of-use, rather than having to navigate a computer’s file system.
  2. Resource type – this is perhaps not strictly necessary as a field, but it was certainly felt that MIME types (e.g. PDF) aren’t particularly useful. Instead, we could simply differentiate, as Moodle LMS does, between an ‘activity’ and a ‘resource’. Alternatively, we could consider a free text approach (with autocomplete) using the generic name of ‘assets’.
  3. Metadata fields – some interviewees weren’t sure whether they were just used to certain fields or whether they were genuinely useful. One example of this was an indication of the time it would take to complete a learning activity.
  4. Accepted filetypes – should zip files of resources be allowed?
  5. Previews – a preview feature would be useful within MoodleNet to have a quick peek at potentially-relevant resources.
  6. Accessibility – perhaps we could add a field which referenced the IMS AccessForAll metadata standard? Or make it available as an option?
  7. Illegal resources – as Open Source software, MoodleNet could be used to facilitate the sharing and discussion of extremely problematic content. We should implement some safeguards around that, for example with a NSFW filter applied to search results by default, as well of course as the revocation of a MoodleNet ‘mothership’ API key.
  8. Maximum filesize – this should be configurable by administrators, with perhaps users having an overall amount of storage space.
  9. Tagging – private tagging of uploaded resources would allow users to tag resources in ways they may not want others to see.
  10. Version control – there are some post-launch options here around git, dat, and IPFS.

One interviewee commented that, with other systems: “I always feel like I’m using against what it was meant for”. This is why we’re putting so much thought into what some would consider small details. Another interviewee told us of a system they were forced to use for a resource-sharing project that was so unwieldy that colleagues stopped using it entirely.

Final remarks

During our conversations, interviewees touched on a number of things that were slightly tangential to resource uploading, but were nevertheless interesting:

  • Perhaps you should only be able to see resources that are Moodle activities if they are compatible with your Moodle LMS version?
  • Some people are much more likely to share resources in smaller groups — even if those resources are also publicly available.
  • Tags and license information from resources and collections could/should feed through to Moodle LMS via the MoodleNet plugin.

Many thanks to those who shared their insights with us, they have proved to be very helpful!

Beyond the beta: revisiting the MoodleNet whitepaper and looking to the future

Roadmap

One of the things that we get asked on a regular basis is “when will feature X going be a part of MoodleNet?”

The MoodleNet beta is scheduled to be released at the Global Moot in November and, after that, the team will set our sights on a v1.0 release in Q2 2020.

Let’s revisit the MoodleNet whitepaper to have a look at the original 17 recommendations and what might end up in a v1.0 release next year, and a v2.0 release the year after:

Original recommendations Timescale Comments
#1: MoodleNet should respect copyright law while allowing educators to share their resources as freely and openly as possible. 2019 (beta) MoodleNet will be dedicated to openly-licensed resources, as outlined here.
#2: Open Educational Practices should be supported in MoodleNet by providing educators with tools to find, create, remix, and share each other’s resources. 2019 (beta) The ability to ‘find’ and ‘share’ OER will be available in the beta, and we will re-evaluate the desirability of ‘create’ and ‘remix’ functionality after garnering feedback from users.
#3: MoodleNet should provide educators with powerful functionality that is easy and pleasurable to use. 2019 (beta) After feedback received during value proposition testing process, we have redesigned the user interface of MoodleNet to make it easier to use and more ‘delightful’.
#4: MoodleNet should allow users to create and manage multiple accounts. Serious thought should be given as to the possibility of allowing some interactions to be anonymous, or pseudo-anonymous. 2021 (v2.0) The use of multiple accounts on a single instance (without logging out and then in again) is out of scope for the MoodleNet beta. Creating multiple accounts and being able to switch between them is not a priority feature for the team at the moment, but something we plan to get to eventually.
#5: Although easy to join and use, MoodleNet should be a robust, decentralised, federated system that does not have a single point of failure. 2019 (beta) Federation is something that we are on-track to implement for the MoodleNet beta. Although MoodleNet will have a ‘mothership’ for the purpose of search and discovery, instances do not have to be connected to it to be connected to one another.
#6: MoodleNet should put the user in control of all of their data. All data held about a user should be compliant with the terms of the GDPR and be removable from the system. Users should be given fine-grained controls over who can see personal data and information they have added. 2020 (v1.0) After a great deal of work on a DPIA, MoodleNet will be compliant with the majority of the GDPR. We will prioritise more fine-grained controls for v1.0 in 2020.
#7: MoodleNet should allow for digital credentials to be created, exchanged, and displayed. These should reflect the diverse and wide-ranging interests of users. 2020 (v1.0) We have already begun to issue Open Badges for contributions to the MoodleNet project. We would like to explore much richer functionality, linked to a wider Moodle strategy.
#8: The aim should be for MoodleNet portfolios to become the default place for educators to tell the story of their professional lives. 2020 (v1.0) For MoodleNet to become the default place for educators to tell their professional story, we need to respond to users. The basic functionality for this will be shipped in the beta, but we also plan to add the ability for users to show off digital credentials and list their job history.
#9: MoodleNet should employ end-to-end encryption on all messages sent through the system. It should also be clear to users who will be able to see their communications (e.g. public / group / one-to-one) 2020 (v1.0) For the beta, MoodleNet will be completely open, with no private messaging or groups. As a result, end-to-end encryption is not required until more private / locked-down aspects of MoodleNet functionality are developed in 2020.
#10: To the greatest extent possible, MoodleNet should be interoperable with open standards, including the import and export of data to and from other social networks. It should have an API that allows others to build upon the core functionality it offers. 2020 (v1.0) We are building MoodleNet upon open standards and licensing it in the most permissive way we can. Facilitating the migration of accounts to other social networks and building an API is an important part of our roadmap, and something we plan to get to after the public beta.
#11: MoodleNet should aim at helping educators create Communities of Practice, adding features and taking UX decisions that help with this (e.g through ‘call to action’ buttons). 2019 (beta) The MoodleNet user agreement and covenant for instance administrators outlines ways in which we will insist on certain minimum standards for instances connected to the HQ ‘mothership’. Over and above this, however, we expect MoodleNet communities to differ in their approach to their levels of formality and types of actions they see as acceptable.
#12: The three elements of news, status updates, and messaging should be controlled by users in MoodleNet. They should be separate if the user wishes, and combined if they prefer an approach more like other social networks. 2021 (v2.0) Although we have diverged from the tripartite approach of news, status updates, and messaging in the current MoodleNet UI, we still have in mind different ways in which MoodleNet can be used. We will make the notifications settings increasingly granular so that users can choose how they want to be informed of updates.
#13: MoodleNet should provide a raw, unfiltered feed to users, and make this available via an API that developers can build upon. Any other views or types of feed should be in addition to this. 2020 (v1.0) Every MoodleNet instance has a feed which is shown by default to local users on the ‘Discover’ page. Once we open up MoodleNet, all public posts will be readable by anyone without logging in.
#14: To provide a disincentive for ‘clickbait’ headlines and sensationalist content, MoodleNet should provide mechanisms to collaboratively rate the content shared in the network. 2019 (beta) For the reasons outlined here, we have declined to build a traditional rating system (e.g. with five stars) for resources. It is too subjective. However, we do want to surface quality content, so users will be able to like and boost resources.
#15: MoodleNet should provide a way for educators to be recognised for the contributions they make to the community, including in financial ways. 2021 (v2.0) Given the number of features we need to build out, the MoodleNet team is not prioritising the ability for user-to-user transactions.
#16: To avoid advertising within MoodleNet, members should be able to support the development of new features through membership and/or subscription options. 2020 (v1.0) Options around sustainability for MoodleNet are explored in this document. Our current thinking is that it is organisations, rather than users, who should pay for MoodleNet. By building MoodleNet plugins and adding them to MoodleCloud, we can provide a value-add that enhances the MoodleCloud proposition.
#17: MoodleNet should encourage the development of OER by educators through easy-to-use crowdfunding options. 2021 (v2.0) Crowdfunding is not a priority at the moment and so will be something we get to after, for example, events functionality.

This, of course is EXTREMELY tentative, but that means:

2019 (beta)

  • #1: MoodleNet should respect copyright law while allowing educators to share their resources as freely and openly as possible.
  • #2: Open Educational Practices should be supported in MoodleNet by providing educators with tools to find, create, remix, and share each other’s resources.
  • #3: MoodleNet should provide educators with powerful functionality that is easy and pleasurable to use.
  • #5: Although easy to join and use, MoodleNet should be a robust, decentralised, federated system that does not have a single point of failure.
  • #11: MoodleNet should aim at helping educators create Communities of Practice, adding features and taking UX decisions that help with this (e.g through ‘call to action’ buttons).
  • #14: To provide a disincentive for ‘clickbait’ headlines and sensationalist content, MoodleNet should provide mechanisms to collaboratively rate the content shared in the network.

2020 (v1.0)

  • #6: MoodleNet should put the user in control of all of their data. All data held about a user should be compliant with the terms of the GDPR and be removable from the system. Users should be given fine-grained controls over who can see personal data and information they have added.
  • #7: MoodleNet should allow for digital credentials to be created, exchanged, and displayed. These should reflect the diverse and wide-ranging interests of users.
  • #8: The aim should be for MoodleNet portfolios to become the default place for educators to tell the story of their professional lives.
  • #9: MoodleNet should employ end-to-end encryption on all messages sent through the system. It should also be clear to users who will be able to see their communications (e.g. public / group / one-to-one)
  • #10: To the greatest extent possible, MoodleNet should be interoperable with open standards, including the import and export of data to and from other social networks. It should have an API that allows others to build upon the core functionality it offers.
  • #13: MoodleNet should provide a raw, unfiltered feed to users, and make this available via an API that developers can build upon. Any other views or types of feed should be in addition to this.
  • #16: To avoid advertising within MoodleNet, members should be able to support the development of new features through membership and/or subscription options.

2021 (v2.0)

  • #4: MoodleNet should allow users to create and manage multiple accounts. Serious thought should be given as to the possibility of allowing some interactions to be anonymous, or pseudo-anonymous.
  • #12: The three elements of news, status updates, and messaging should be controlled by users in MoodleNet. They should be separate if the user wishes, and combined if they prefer an approach more like other social networks.
  • #15: MoodleNet should provide a way for educators to be recognised for the contributions they make to the community, including in financial ways.
  • #17: MoodleNet should encourage the development of OER by educators through easy-to-use crowdfunding options.

As well as suggestions from the community (via user testing and Changemap) these feed into the MoodleNet Roadmap

An update on likes and boosts in MoodleNet

Back in March of this year, we published a post entitled What we talk about when we talk about rating systems. While the fundamental approach that we outlined in that post remains unchanged, we’re tweaking the implementation of it for the beta launch in November.

We’re all familiar with the ability to ‘reshare’ and ‘like’ content on social networks. On Twitter it’s called ‘retweeting’ and ‘favouriting’, while on Mastodon (see screenshot below) it’s ‘boosting’ and ‘favouriting’

Boosts and likes

This approach is unproblematic for status updates, but of course with MoodleNet we’re also dealing with resources. As a result, to make things simple, the approach we outlined in our previous post was that there would be a single option (‘likes’) on resources.

Likes on resources

This would serve not only to allow a user to easily re-find something they’d liked via their profile, but it would be a vote for the resource within the collection. Simple, straightforward, and effective!

Likes on profiles

The problem with this, as pointed out by Mayel (our Technical Architect) is that this isn’t in line with Fediverse conventions. We want to be interoperable with other federated social networks, and with those, ‘likes’ don’t show up in feeds, — but ‘boosts’ do.

This led us down somewhat of a rabbithole, as there are several ways we could fix this. One thing to bear in mind is that both ‘likes’ on comments and likes on resources should show up in the relevant section of a user’s profile.


As MDLNET-372 outlines, we initially considered three options:

  1. Users have the option to ‘boost’ or ‘like’ comments, but only ‘like’ resources (which, behind the scenes is actually ‘like+boost’). Likes show up in the timeline on user profiles.
  2. Users can ‘applaud’ (like+boost) both comments and resources. Applause shows up in the timeline on user profiles.
  3. Users can ‘boost’ or ‘like’ comments, and ‘applaud’ (boost+like) resources. Both applause and likes show up in the timeline on user profiles.

Eventually, however, we rejected all of these options, because they would force users into an option where they have to both like and boost something, rather than perform these actions separately.

Finally, there’s terminology to inspect here as well. While Mastodon and Pleroma use stars and call them ‘favourites’, Twitter and Pixelfed use hearts and call them ‘likes’. Given that we want to use stars instead of hearts, we may as well stick with convention and call them ‘favourites’!


The solution to all of this doesn’t sound groundbreaking, but still involved a bit of thought: MoodleNet users will be able to ‘favourite’ and/or ‘boost’ both comments and resources. Favouriting something means it ends up on your profile, while a boost is both a way for users to give a thumbs-up to a resource and share it with their followers.