The built-in WYSIWYG editor in Moodle uses outdated technology (literally). Going to implement a completely proprietary editor is currently impossible, as is building your own LMS. So we need to improve the existing editor. This project is phased.

1. PHASE I

The first phase of this project is to clean up the editor. Specifically:

• Removing unnecessary plugins
• Adding an “html cleaner + formatter” that formats the content in realtime according to our guidelines. It is important that all components contain the correct classes, so that our CSS can do its job. Also, weird constructions need to be removed/adjusted.
• If necessary, move inserted images to our own file server so that the translation server can do its job.

2. PHASE II

At this point, the editor should already be running good, clean html, but it is therefore not yet usable. In this phase, UX is addressed by transforming the editor into a block-based editor. Concretely, the editor will indicate in real time which components you can add. The only way to add such a component is to press a button and fill in a pop-up.

Prerequisites

• PHP, Javascript

This project is about the share part of Learn Make Share. Specifically, it will be a (stripped down) Mahara instance. It needs to be integrated not only with Moodle, but also with our ID provider and our translation server. The editor should be looked at (may be its own project) to make it as simple as possible to build your own portfolio.

Prerequisites

• PHP, Javascript
• Must be able to work independently based on documentation

Related to Proposal DESIGN4: UI/UX E-Portfolio

In this phase, the backend of the 3DSlicer will be addressed. It will be connected to our API servers as an oauth2 client (just like the SVG editor) such that, for example, the following things become possible:

• Shielding options based on badges
• Listing of available machines
• Immediately make gcode available on the personal drive and machines, provided you are connected to the local network.

Prerequisites

• Javascript, …
• Web development in general

Each Makercart will eventually be equipped with an IoT device to monitor the machines, among other things. Currently, this device continuously synchronizes with a (sort of) public Drive folder and offers the files to our machines. In time, of course, this will not be enough. This could be a large project, so we are working in phases:

1. PHASE I

The first phase will be to connect these devices to our API servers. Specifically, authentication will be done via a machine-to-machine secret. The IoT device can then, for example, keep a websocket open with a specific endpoint or poll every so often.

The IoT device will need to publish the status of the machines and usage to some sort of logging endpoint. Users with the appropriate permissions can then retrieve this information.

Note that the machine does not work with personal information. For that, a simple machine-to-machine secret is not secure enough.

2. PHASE II

After the second phase, it will also be possible to interface directly with the machines, provided that you are allowed to do so (based on badges, for example) and that you are connected to the local network.

For that, the device will have to run a relatively small HTTP server. Now we do deal with personal data, so the external API server will also play an important role here in terms of authentication. Specifically, authentication will be done with a partially automated version of the OpenID Connect device flow. Thus, a custom client-side javascript module will also need to be developed to guide this authentication.

Some examples of things that should be possible after Phase II:

• In the SVG editor, load a scan from laser cutters that include a camera (like the Beambox)
• Immediately send files from the browser (SVG editor, 3DSlicer, …) to the machines.
• Instead of working with a public drive we can now mount a ‘personal drive’. When you generate G-code, that file will automatically end up on that drive.

Prerequisites

• Good handling of Linux related issues
• Javascript, Typescript, …
• Basic knowledge of API design, OpenID Connect (or Oauth2), security, …

NO LONGER AVAILABLE

With the SVG editor, we also want to be able to generate machine code for embroidery machines. Typical file formats are .pes and .dst

The generation of machine code based on a .svg file is handled serverside.

Some of the features we want to implement:

• For each vector (or group of vectors) indicate with which stitch it should be run.
• fill enclosed surfaces (2D fills) with specific fill patterns according to a given orientation.
• Conversion of a bitmap to a cross-stitch pattern (e.g. HaftiX).

Prerequisites

• computational geometry (linear algebra/metrology)
• Python

NO LONGER AVAILABLE

When bitmap images are used for display on physical media through digital fabrication, they must first be converted to a so-called raster pattern. Different raster algorithms exist for this purpose:

• ordered dithering raster
• error diffusion raster (Stucki, Floyd-Steinberg, Jarvis)
• Colour en Black/White

The generation of raster images is handled serverside. Intention is to implement and further optimize different algorithms for laser cutters.

Prerequisites

• image processing (bvb openCV)
• Python