3 ms·

Moodle is awful in many ways, but it's well known, has a decent ecosystem, and I've yet to interact with something I didn't find substantially more awful. I su

by mst 3y ago

Moodle is awful in many ways, but it's well known, has a decent ecosystem, and I've yet to interact with something I didn't find substantially more awful. I suspect, much like ticketing and project management systems, LMS software is always going to be awful -somehow- because of competing desires from different users, and that as such "the least amount of awful amongst the ones I've dealt with" should probably be considered a (qualified) endorsement.

pacifika 3y ago
What’s awful?
- TuringTest 3y ago
  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.
- sombragris 3y ago
  I'll talk about how it's implemented in my university. YMMV of course. 1. There's no common area for teachers. I cannot have common resources. For example, I like to have some ground rules for all my courses; cannot have them stored in a common space to import them to any course opened. 2. So many steps are repetitive and cumbersome without any possibility of automating them. For example, I can devise an activity and set up a carefully crafted rubric for grading. There's no way to store that rubric elsewhere so I could reuse it for another, similar activity either in that same course or in another. 3. No possibility of mass uploading files except when in a folder. 4. No possibility of customizing an activity or resource per-teacher. If any, is either school-wide or nothing. 5. I need a custom Web font (for some language I teach) but it's extremely difficult to configure that school-wide. Teacher-specific it's just impossible. and the laundry list could go on and on and on. These are little details, but enormous time wasters.
catlifeonmars 3y ago
Ticketing systems are only awful if they try to model everything. … Which is something that ticketing systems tend to evolve towards over time. Maybe it’s some organizational phenomenon vaguely related to Conways law…
- mst 3y ago
  In practice, I tend to find ticketing systems almost invariably exist either in a superposition of modeling too much and modeling too little, or as you say, have tried to model everything to the point where you can't find anything. The 'almost' is because e.g. RT or JIRA -can- be configured such that they provide exactly the details and workflow that each team/queue wants and end up being almost pleasant to work with, but putting in the necessary business analysis time and having somebody learn their configuration and scripting facilities sufficiently to actually achieve that is something I only encounter very occasionally.
catlifeonmars 3y ago
Once, I heavily used an internal ticketing system that wasn’t awful. It only did ticketing and nothing else. There were no sprint views or folders or custom fields. The data model was exceedingly simple: Title, 3-level hierarchy, a priority, an open/closed/pending status, a summary, and a correspondence log (comments). There was a separate system that would handle paging on user defined rules based on priority and aforementioned hierarchy.
deleted 3y ago
[deleted]

by mst 3y ago

pacifika 3y ago

What’s awful?

TuringTest 3y ago
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.
sombragris 3y ago
I'll talk about how it's implemented in my university. YMMV of course. 1. There's no common area for teachers. I cannot have common resources. For example, I like to have some ground rules for all my courses; cannot have them stored in a common space to import them to any course opened. 2. So many steps are repetitive and cumbersome without any possibility of automating them. For example, I can devise an activity and set up a carefully crafted rubric for grading. There's no way to store that rubric elsewhere so I could reuse it for another, similar activity either in that same course or in another. 3. No possibility of mass uploading files except when in a folder. 4. No possibility of customizing an activity or resource per-teacher. If any, is either school-wide or nothing. 5. I need a custom Web font (for some language I teach) but it's extremely difficult to configure that school-wide. Teacher-specific it's just impossible. and the laundry list could go on and on and on. These are little details, but enormous time wasters.

catlifeonmars 3y ago

Ticketing systems are only awful if they try to model everything. … Which is something that ticketing systems tend to evolve towards over time. Maybe it’s some organizational phenomenon vaguely related to Conways law…

mst 3y ago
In practice, I tend to find ticketing systems almost invariably exist either in a superposition of modeling too much and modeling too little, or as you say, have tried to model everything to the point where you can't find anything. The 'almost' is because e.g. RT or JIRA -can- be configured such that they provide exactly the details and workflow that each team/queue wants and end up being almost pleasant to work with, but putting in the necessary business analysis time and having somebody learn their configuration and scripting facilities sufficiently to actually achieve that is something I only encounter very occasionally.

catlifeonmars 3y ago

Once, I heavily used an internal ticketing system that wasn’t awful. It only did ticketing and nothing else. There were no sprint views or folders or custom fields. The data model was exceedingly simple: Title, 3-level hierarchy, a priority, an open/closed/pending status, a summary, and a correspondence log (comments). There was a separate system that would handle paging on user defined rules based on priority and aforementioned hierarchy.

deleted 3y ago

[deleted]