4 ms·

The setup processes to build courses, enroll alumns and place contents are slow, complex and involve many repetitive steps. However, that doesn't seem to be an

The setup processes to build courses, enroll alumns and place contents are slow, complex and involve many repetitive steps. However, that doesn't seem to be any better in any other web CMS, and Moodle is extendable with lots of open source plugins for any imaginable purpose, so overall it's a powerful Swiss army knife, and it has all the advantages of a self-hosted, open source project.

mst 3y ago
CMS software definitely also seems to be in the category I was talking about. I suspect the 80/20 rule is in play, wherein each of the 80% of users is using a different 20% of features so your choices are to end up with something nearly feature free (think early github issues for a ticketing example), something specialised to a specific vertical subset of the potential use cases, a complex and usually clunky GUI, or programmatic style configuration that requires a level of time investment that rules out the people whose jobs will be to actually use it being the ones to set it up. Moodle goes the lots-of-features GUI route and does a less annoying job of it than average - like I say, I think the problems are kinda inherent if your goal is to support as many different purposes as it does, and that's a trade-off that's often worth making.
- bafe 3y ago
  I'd add ELN/LIMS in the same category. At first they just look like some CRUD app, but each uses a slightly different data model, different plugin system and (often outdated) scripting language built-in the system.
irq-1 3y ago
> The setup processes to build courses, enroll alumns and place contents are slow, complex and involve many repetitive steps. Thats what SQL is for. You can setup everything using their fairly simple tables, and keep it in sync with whatever registration system you're using. Permissions however were confusing and forget about faculty understanding them.

mst 3y ago

CMS software definitely also seems to be in the category I was talking about. I suspect the 80/20 rule is in play, wherein each of the 80% of users is using a different 20% of features so your choices are to end up with something nearly feature free (think early github issues for a ticketing example), something specialised to a specific vertical subset of the potential use cases, a complex and usually clunky GUI, or programmatic style configuration that requires a level of time investment that rules out the people whose jobs will be to actually use it being the ones to set it up. Moodle goes the lots-of-features GUI route and does a less annoying job of it than average - like I say, I think the problems are kinda inherent if your goal is to support as many different purposes as it does, and that's a trade-off that's often worth making.

bafe 3y ago
I'd add ELN/LIMS in the same category. At first they just look like some CRUD app, but each uses a slightly different data model, different plugin system and (often outdated) scripting language built-in the system.

irq-1 3y ago

> The setup processes to build courses, enroll alumns and place contents are slow, complex and involve many repetitive steps. Thats what SQL is for. You can setup everything using their fairly simple tables, and keep it in sync with whatever registration system you're using. Permissions however were confusing and forget about faculty understanding them.