MoodleNet in 2019: a retrospective

Retrospective

Intro

This year, MoodleNet has gone from a Minimum Viable Product (MVP) to a more sophisticated beta, which is now ready to be tested as a federated platform. Along the way, hundreds of people have had the opportunity to test various versions of MoodleNet, to get involved in various ways (such as localisation), and to give their input into its future direction.

We’ve collaborated with a number of organisations and individuals outside Moodle HQ, most notably Eummena, a new Moodle Partner, who have added to the resource and energy available to the MoodleNet project. We’ve also had input from 3ipunt around plugin development, and many conversations with other Moodle Partners who are keen to get involved in 2020.

In last year’s retrospective, we explained that building a federated network like MoodleNet takes time. While ActivityPub-based alternatives to services such as Twitter (Mastodon and Pleroma), Instagram (Pixelfed), YouTube (PeerTube) exist, and more are being developed, MoodleNet is one of the first social networks to reimagine social networking from the ground-up for this particular audience. We want to empower educators by them creating and joining communities to engage in discussions with one another and curate resources.   

Interestingly, Twitter seems to have realised the importance and power of federation, announcing a dedicated team to explore ways in which their platform can become decentralised. As we have often argued, the design of platforms and algorithms, as well as content moderation should happen for and with communities, instead of being controlled by a faceless corporation, potentially headquartered many thousands of miles away. So if Twitter is serious about this initiative we invite them to adopt the ActivityPub web standard and join the Fediverse!

This, then, is the story of MoodleNet in 2019. It’s been quite the adventure.

Q1: Testing the value proposition

We began the year in January with a core team of Doug Belshaw (Product Manager), Mayel de Borniol (Technical Architect), Ivan Minutillo (UX Designer & Front-end Developer), and Alex Castaño (Backend Developer). By the end of January we had begun testing the value proposition of MoodleNet with those who had signed up. Volunteer contributors helped to get MoodleNet translated into a number of languages, which we then tested with English and Spanish speakers.

Gaining feedback from testers, we evolved MoodleNet during the first testing period so that by early February, MoodleNet looked like this:

MoodleNet UI (Feb 2019)

The question representing our value proposition was “Do educators want to join communities to curate collections of resources?”. After several surveys and lots of conversations, it appeared that, even from the initial version we presented to users during the first testing period, yes they did!

We iterated from version 0.3 in late February, to 0.5 in early March, and 0.7 by the end of that month. During that time, the second testing period demonstrated that users wanted a way of being able to distinguish the good from the bad in terms of resources, so we published an in-depth post exploring rating systems. In that post we shared the following diagram, commenting that ‘quality’ is subjective, and how we are interested in providing “the shortest path to the best resources”. 

Educational resources triangle

We learned a lot from testing MoodleNet’s value proposition, and most importantly confirmed we were on the right track. The tagline ‘Share. Curate. Discuss.’ was chosen based on what resonated the most among testers, and we ended up with a very clear list of priorities for future development.

Q2: Iterating and learning

In the second quarter of 2019, our focus was on ensuring that the version of MoodleNet we delivered met and, if possible, exceeded people’s expectations from the beginning. At this point, each MoodleNet installation was a standalone ‘silo’; in other words, it could not federate with other MoodleNet instances. 

While we worked on federation on the backend, we made iterative improvements to the front-end in April and May with versions 0.9 alpha, v0.9.1 alpha, v0.9.2 alpha, and v0.9.3 alpha. At the same time, we thought carefully about how to make search in MoodleNet a useful and delightful experience, as well as the best approach to categorising resources and collections. 

MoodleNet UI (May 2019)

At the UK & Ireland MoodleMoot we ran a workshop where five emergent groups looked at MoodleNet from various perspectives. Our wiki page for the event captures the feedback we received from the ‘Online course design’, ‘Institutional use’, ‘Learning and teaching’, ‘Technology’, and ‘UX’ groups. Although this was very positive, we noticed some concerns around telling the difference between Communities and Collections, as well as the way discussion threads were organised.

In May we attended the Creative Commons Summit in Lisbon, Portugal. We did not run a session this time, instead networking with other projects, including OER World Map, Wikidata, and CC Search. In fact, our conversations with the OER World Map project directly benefited our approach to categorisation.

Towards the end of Q2 we said goodbye to Alex, and hello to Karen and James. We were delighted to have been able to attract and employ two such high-quality candidates, particularly to help with the challenges we faced around implementing federation.

We had a new page about MoodleNet arriving on moodle.com, but wanted to re-use the moodle.net domain for the main project website, so it was important that we set about sunsetting the existing service. In June, we worked with the Moodle Community team to formulate a plan which they then carried out perfectly over the following months. 

New moodle.com/moodlenet

We finished work on the first draft of MoodleNet’s Data Protection Impact Assessment (DPIA) and made it available for community consultation. This process, which we went through with Carlo Polizzi, Moodle’s Privacy Officer (as well as Simon McGarr, Moodle’s external Data Protection Officer and Legal Counsel), really helped us clarify the data workflows using a ‘privacy by design’ approach.

Q3: Rewriting all the things

While James and Karen got up-to-speed in June, Mayel prototyped a plugin for Moodle LMS, and Ivan took some time to redesign the front-end user experience. By the end of the month we had mock-ups ready of the new, much more conversational interface that makes the relationship between Communities and Collections much clearer. In July we did the additional work necessary to turn this into a clickable prototype, which we tested out with users.

It was around this time that we realised that we were going to have to change the database structure and rewrite much of the backend code in order for MoodleNet to be able federate while also providing a snappy UX on the front-end. This was not a small undertaking, but we were nevertheless optimistic about the amount of time this would take. Eummena, a new Moodle Partner, decided to support the MoodleNet team by hiring a full-time backend developer in the form of Antonis Kalou. He’s been working very closely with our team ever since. 

Somewhat implausibly, looking back, we announced that the federation testing programme would start in August! Of course, making predictions around these kinds of things is hard.

MoodleNet Discover page

Given the backend developers would be busy with the rewrite, we decided to turn the new conversational UI into code. The first version of this was ready by the end of August.

In preparation for the federation testing programme, and because of wider problems in the Fediverse around decentralised moderation, we created a draft user agreement and covenant for instance administrators. We also clarified our position around the licenses users would be able to select when uploading resources to MoodleNet. 

In September, based on some feedback from the community, we reasserted the project’s stance on ‘free speech’ issues in the context of wider debates about and across social networks. We also revisited considerations around metadata and the way ‘likes’ and ‘boosts’ would work across federated instances.

Q4: Crunch time

By the time we got to October, whilst the backend refactor was in full swing, the MoodleNet servers were still running the new front-end with an old (unfederated) backend. That needed to change as soon as possible given the upcoming Global MoodleMoot, where we wanted to start federation testing and give people the ability to sign-up and start using an instance run by Moodle HQ.

At this point, Alessandro Giansanti joined us for a few weeks as a front-end developer to help us during crunch time. As a member of ZO (a cooperative he’s formed with existing team members Ivan and Mayel), he’s now also part of our team and we’ve really benefited from his energy and experience. Eummena also funded a front-end developer who has been helping Ivan and Alessandro. 

MoodleNet sign-in page

MoodleNet sign-in page

As the Moot approached, we asked for some feedback from the community around resource uploading in MoodleNet, and we started to think beyond the beta for our 2020 roadmap. 

At the start of November we were still planning to start federation testing in some form at the Global Moot. However, despite the team working late into the night for several days before demo day, we didn’t manage to have a fully working version ready by the time Doug and Mayel took to the stage, so we simply showed screenshots instead. The main challenge, as we explained in our reflections on what happened, was resolving the small but numerous breaking changes in GraphQL API to get the frontend working correctly with the shiny new backend.

After taking some time off to recover from an intense period of work, the team have regrouped in December and resolved the remaining broken functionality in MoodleNet. There’s many more features and improvements we want to work on, but the core MoodleNet functionality is now ready and hooked up with federation. We’ve even already had an initial external security review done, which showed no major problems. All in all – as we said in our recent ALT Online Winter Conference session – we’re actually in pretty good shape going into 2020.

Final thoughts

Reflecting on mid 2019 in particular, it’s evident that we lost a bit of momentum for a while. Some of that couldn’t be helped because of the nature of the problems we had to solve, but we certainly could do a better job of estimating (or avoid trying to estimate altogether) how long it would take. We’ve fed these realisation into our thinking and planning for next year.

The team is particularly looking forward to users getting their hands on the new, federated, version of MoodleNet. We’re excited about the amount of power and flexibility we’re putting into the hands of educators, and can’t wait to see what individuals and organisations do with MoodleNet in 2020!

Welcome Alessandro, new MoodleNet front-end developer!

The MoodleNet team is delighted to welcome Alessandro Giansanti who will be working on front-end development. Ale’s based in Italy and will be working between two and four days on MoodleNet!

Alessandro and family
Alessandro and family

We would love to hear a bit about your work history?

My life followed roughly a square wave path between coding and music/entertainment:

  • from 8 years old hacking on C64 basic
  • from 15 rock guitar and recording studio
  • from 23 Java consultant
  • from 26 projectionist in cinemas, audio technician in national tv broadcasting, and photographer
  • from 34 steadily restarded coding, firstly as freelancer on e-commerce and websites
  • then, from 2011, I got totally passionate with Javascript.

Early adopter of the MEAN stack, I worked full-stack on different projects: geographic map based applications for automotive businesses, online sport gaming, and blockchain based authentication applications.

What do you love about what you do?

“I love it when a plan comes together” (John “Hannibal” Smith)

I love aiming at the realization of ideally crystal-shaped architectures and implementations and then, back down-to-earth, understanding which is the most efficient compromise to adopt. A well implemented system (and not one of “just make it work”) means happier coders – current and future – happy to work and expand it, and therefore happier and satisfied users. Furthermore, software is a means to implement human activities, so I, as a coder and a human, am happy when I can participate in the realization of some positive ones.

What are your interests outside of work?

Playing noisy improvised funk-rock with my band and with whoever wants to join the jam!

Where is your favourite place in the world, and why?

The whole our World is fantastic. If you look closely, you will see your home is fantastic too, take care of it.

Recording of ALT Online Winter Conference session

It was our pleasure to present in a session entitled MoodleNet: federated, resource-centric social networking for educators at the ALT Online Winter Conference yesterday. The presentation was similar to the one from the Global Moot, with Doug Belshaw, Mayel de Borniol, and Alessandro Giansanti explaining to participants the research behind MoodleNet, the benefits it provides, and how they can get involved.

There were a number of interesting questions on a range of topics including interoperability, privacy, and accessibility. Many thanks to all who came along!

If you have any questions as a result of watching the recording, please do add them to the comments section below.

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!