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.

Voodoo categorisation and dynamic ontologies in the world of OER

Voodoo masks

Introduction

In a previous post on this blog, I described how we’re planning for search to work in MoodleNet. In this post, I want to dig into tagging and categorisation – which, it turns out, is an unexpectedly philosophical subject. Fundamentally, it comes down to whether you think that subjects such as ‘History’ and ‘Biology’ are real things that exist out there in the world, or whether you think that these are just labels that humans use to make sense of our experiences.

What follows is an attempt to explain why Open Educational Resources (OER) repositories are often under-used, how some forms of categorisation are essentially an attempt at witchcraft, and why assuming user intent can be problematic. Let’s start, however, with everyone’s favourite video streaming service.

Netflix

If you asked me what films and documentaries I like, I’d be able to use broad brushstrokes to paint you a picture. I know what I like and what I don’t like. Despite this, I’ve never intentionally sat down to watch ‘Critically-acclaimed Cerebral Independent Movies’ (Netflix code: 89), nor ‘Understated Social & Cultural Documentaries’ (Netflix code: 2428) nor even ‘Witty Independent Movies based on Books’ (Netflix code: 4913). These overlapping categories belong to a classification system developed by Netflix that now stretches into the tens of thousands of categories.

Netflix screenshot
Screenshot of Netflix user interface

Netflix is popular because the content it provides is constantly updating, but mainly because it gets to know you over time. So instead of presenting the user with a list of 27,000 categories and asking them to choose, Netflix starts from a basis of the user picking three movies they like, and then making recommendations based on what they actually watch.

There aren’t a lot of actions that users can perform in the main Netflix interface: it’s essentially ‘browse’, ‘add to list’ and ‘play’. In addition, users don’t get to categorise what they watch. That categorisation is instead performed through a combination of Netflix’s algorithm and their employees, which work to create a personalised recommendation ‘layer’ on top of all of the content available.

In other words, Netflix’s categorisation is done to the user rather than by the user. Netflix may have thousands of categories and update them regularly, but the only way users can influence these is passively through consuming content, rather than actively – for example through tagging. More formally, we might say that Netflix is in complete control of the ontology of its ecosystem.

Voodoo categorisation

In a talk given back in 2005, media theorist Clay Shirky railed against what he called ‘voodoo categorisation’. This, he explained, is an attempt to create a model that perfectly describes the world. The ‘voodoo’ comes when you then try to act on that model and expect things to change that world.

Voodoo dolls
Image CC BY Siaron James

Shirky explains that, when organisations try to force ‘voodoo categorisation’ (or any form of top-down ontology) onto large user bases, two significant problems occur:

  1. Signal loss – this happens when organisations assume that two things are the same (e.g. ‘Bolshevik revolution’ and ‘Russian revolution’) and therefore should be grouped together. After all, they don’t want users to miss out on potentially-relevant content. However, by grouping them together, they are over-estimating the signal loss in the expansion (i.e. by treating them as different) and under-estimating the signal loss in the collapse (i.e. by treating them as the same).
  2. Unstable categories – organisations assume that the categories within their ontology will persist over time. However, if we expand our timescale, every category is unstable. For example, ‘country’ might be seen as a useful category, but it’s been almost thirty years since we’ve recognised East Germany or Yugoslavia.

The ontologies we use to understand the world are coloured by our language, politics, and assumptions. For example, if we are creating a category of every country, do we include Palestine? What about Taiwan? These aren’t neutral choices and there is not necessarily a ‘correct’ answer now and for all time. As Shirky points out, it follows that someone tagging an item ‘to_read’ is no better in any objective way than conforming to a pre-defined categorisation scheme.

This is all well and good theoretically, but let’s bring things back down to earth and talk very practically about MoodleNet. How are we going to ensure that users can find things relevant to what they are teaching? Let’s have a look at OER repositories and the type of categories they use to organise content.

OER repositories

The Open Education Consortium points prospective users of OER to the website of the Community College Consortium for Open Educational Resources. They have a list of useful repositories, from which I’ve chosen three popular examples, highlighting their categories:

This slideshow requires JavaScript.

These repositories act a lot like libraries. There are a small number of pre-determined subject areas into which resources can be placed. In many ways, it’s as if there’s limited ‘shelf space’. What would Netflix do in this situation? After all, if they can come up with 27,000 categories for films and TV, how many more would there be for educational resources?

Ultimately, there are at least three problems with OER repositories organised by pre-determined subject areas:

  • Users have to fit in with an imposed ontology
  • Users have to know what they are looking for in advance
  • Users aren’t provided with any context in which the resource may be used

We are trying to rectify these problems in MoodleNet, by tying together individual motivation with group value. Teachers look for resources which have been explicitly categorised as relevant to the curriculum they are teaching. Given the chance, great teachers also look for ideas in a wide range of places, some of which may be seen as coming from other disciplines. MoodleNet then allows them to provide the context in which they would use the resource when sharing their findings with the community.

Dynamic ontologies in MoodleNet

Our research has shown that, as you would expect, educators exhibit differences in the way they approach finding educational resources. While there are those that go straight to the appropriate category and browse from there, equally there are many who prefer a ‘search first and filter later’ approach. We want to accommodate the needs of both.

The solution we are proposing to use with MoodleNet includes both taxonomy and folksonomy. That is to say, it involves both top-down categorisation and bottom-up tagging. Instead of coming up with a bespoke taxonomy we are thinking of using UNESCO’s International Standard Classification of Education (ISCED) fields of education and training which provides a three-level hierarchy, complete with relevant codes:

UNESCO ISCED codes
Example of some of the UNESCO ISCED fields of education and training

MoodleNet will require three types of taxonomic data to be added to communities, collections, and user profiles:

  • Subject area (ISCED broad, narrow, or detailed)
  • Grade level (broadly defined – e.g. ‘primary’ or ‘undergraduate’)
  • Language(s)

In addition, users may choose to add folksonomic data (i.e. free-text tagging) to further contextualise communities, collections, and profiles. That would mean a collection of resources might look something like this:

Mockup of what tags could look like in a MoodleNet collection
Mockup of taxonomic and folksonomic tagging system in a MoodleNet collection

The way Clay Shirky explains this approach is that “the semantics are in the users, not in the system”. In other words, the system doesn’t have to understand that the Bolshevik Revolution is a subset of 20th century Russian history. It just needs to point out that people who often tag things with ‘Lenin’ also tag things with ‘Bolshevik’. It’s up to the teacher to make the professional judgement as to the value of a resource.

We envisage that this combination of taxonomic and folksonomic tagging will lead to a dynamic ontology in MoodleNet, powered by its users. It should allow a range of uses, by different types of educators, who have varying beliefs about the world.

Conclusion

What we’re describing here is not an easy problem to solve. The MoodleNet team does not profess to have fixed issues that have beset those organising educational for the past few decades. What we do recognise, however, is the power of the web and the value of context. As a result, MoodleNet should be useful to teachers who are looking to find resources directly relevant to the curriculum they are teaching. It should also be useful to those teachers looking to cast the net more widely

In closing, we are trying to keep MoodleNet as flexible as possible. Just as Moodle Core can be used in a wide variety of situations and pedagogical purposes, so we envisage MoodleNet to be used for equally diverse purposes.

Making search a delightful experience in MoodleNet

MoodleNet is a new open social media platform for educators, focussed on professional development and open content. It is an integral part of the Moodle ecosystem and the wider landscape of Open Educational Resources (OERs). The purpose of this post is to explain how our approach to search will help with this.

Our research shows that educators discover resources in two key ways, which we’re bringing together with MoodleNet.

Proactive/Reactive

In order to be proactive and search for something specific, you have to know what you are looking for. That’s why it’s common for educators to also be reactive, discovering resources and other useful information as a result of their social and professional networks.

From its inception, we’ve designed MoodleNet as a place that works like the web. In other words, it harnesses the collective power of networks while at the same time allowing the intimacy of human relationships. However, search tends to be a transactional experience. How do we make it more ‘social’?

Seung (persona)At this point, let’s re-introduce Seung, the 26 year-old Learning Technologist from Australia who we first met in a white paper from early 2018. She’s looking to help her colleagues use Moodle more effectively, and to connect with other Learning Technologists to discover promising practices.

Seung comes across many potentially-useful resources on her travels around the web, which she curates using services such as Pocket, Evernote, and the ‘favourite/like’ functionality on social networks such as Twitter and Facebook. When Seung uses MoodleNet, she joins relevant communities, follows interesting collections and people, and ‘likes’ resources that either she or her colleagues could use.

One of the problems Seung has is re-discovering resources that she’s previously found. Although she considers herself an advanced user of search engines such as Google and DuckDuckGo, Seung is sometimes frustrated that it can take a while to unearth a resource that she had meant to come back to later.

MoodleNet search overview (Bryan Mathers)MoodleNet’s powerful search functionality will allow Seung to both find interesting communities, collections, and profiles, and quickly rediscover resources on MoodleNet that she has marked as potentially-useful. In addition, because MoodleNet is focused on open content, Seung can extend her search to OER repositories and the open web.

The same search functionality will be available through a Moodle Core plugin that allows any user, whether or not they have an account on MoodleNet, to search for resources they would like to pull into their Moodle course. This plugin will also automatically add metadata about the original source location, the MoodleNet collection of which it was part, as well as any licensing information.

We’ve already started conversations with Europeana and Creative Commons about allowing MoodleNet users to directly search the resources they both index. We would also like to explore relationships with other OER repositories who would welcome MoodleNet communities curating and using their openly-licensed resources.  

In closing, we should mention that we have big plans for tags across MoodleNet, involving both taxonomic and folksonomic tagging, and provided by both users and machine learning. More details on that soon.

For now, the MoodleNet team would be interested in any questions or suggestions you have about this approach to search. What do you think? What else would you like to see?


Illustrations CC BY-ND Bryan Mathers