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

Planning for the MoodleNet public beta

In the spirit of working openly, we’d like to share a MoSCoW prioritisation grid for the public beta release of MoodleNet in November 2019. While any project is subject to changing priorities as it progresses, this is where we are in early August.

For those that prefer a more accessible text-based version, please see below.


MUST

Instances:

  • Federation with other instances
  • Connect to HQ ‘mothership’
  • Search across federated instances
  • Discover page
  • My MoodleNet
  • Profiles
  • Flags/reporting
  • Moderation tools
  • Sign-up page (username/password)
  • Open to browse without signing in

Communities:

  • Image upload
  • Join/create/edit/leave a community
  • Every @community is hyperlinked

Collections:

  • Category tags
  • Create/edit a collection
  • Every +mention is hyperlinked

Resources:

  • Like resources
  • Add resource via URL
  • Add hashtags to added resources

Profiles:

  • Bio & links
  • Avatar
  • Header image
  • User timeline
  • Joined communities
  • Followed collections
  • Liked resources

Users:

  • Every @username is hyperlinked
  • Unique usernames

Moodle Core integration:

  • Plugin to pull resources from MoodleNet

Misc.

  • Basic security audit

SHOULD

Instances:

  • Help pages
  • Interoperability with other ActivityPub apps
  • Blocklists

Communities:

  • Share link to community 

Collections:

  • Hashtags 
  • Pinned resources
  • Share link to collection

Resources:

  • Upload resources
  • Add licence to uploaded resources

Profiles:

  • Follow other users

Users:

  • Notifications if mentioned within a community
  • Receive weekly emails about recent activity

COULD

Instances:

  • Analytics
  • Sign-up page (social accounts)

Communities:

  • Related communities

Collections:

  • Related collections
  • Sort/filter listed resources

Resources:

  • Auto-complete hashtags

Profiles:

  • Add other users to a contact list
  • Invite other people to create a MoodleNet profile
  • Add interests (based on hashtags)

Users:

  • Sort/filter ‘My MoodleNet’

Misc.

  • In-depth security audit

WON’T

  • Private communities / collections
  • Request a resource
  • Copy/fork a collection into another community
  • Events functionality
  • Emoji ID
  • Open Badges on profiles
  • Query 3rd-party repositories

MoodleNet 0.3 alpha update

Update: check out this five-minute overview video on YouTube!

This slideshow requires JavaScript.

As MoodleNet progresses and the team get into more of a rhythm, we’ve started working in two-week sprints. For the next few weeks, up to the beta release at the UK & Ireland MoodleMoot, we have plenty to do!

Earlier this week we released MoodleNet v0.3 alpha in preparation for inviting a new cohort of testers. It includes the following new functionality, UI tweaks, and bug fixes:

Functionality added

  • Collection-level discussions
  • ‘Profile & settings’ to update name, description, and avatar
  • Guide to Markdown next to text input boxes

UI tweaks

  • Tweaks to fonts and colours to improve accessibility
  • New approach to discussions, which now act more like threads
  • List of communities indicates number of collections contained by each

Bug fixes

  • No longer have to refresh to see added community/collection
  • Can see all communities again (fixed pagination)

We’ve removed edit functionality from MoodleNet at the moment in preparation for moderation. In future, you’ll be able to edit and delete comments and resources you add, or those in a community you moderate.

Given the amount of time between now and the beta launch at the UK Moot, we’re going to focus on what we consider to be essential to the core value proposition of MoodleNet:

  1. Federation — the ability to have separate instances of MoodleNet that can communicate with one another.
  2. Mobile view — MoodleNet accessible and usable on mobile devices.
  3. Moodle Core integration — add a resource from MoodleNet to a course in a Moodle course.

Thank you to our testers, who are doing a great job of asking questions, reporting bugs, suggesting functionality, and filling in surveys!