Comparisons and advocacy

"the fact that you worked for "at least 4 Universities in 3 years" tells me that you are in a highly volatile place"

Yes the UK after Brexit

I am a contractor, so work all over the UK and the Europe

Next i'm of to work for the UN in New York

I will list three areas for improvement as examples -  others may want to add to this

1. Lesson - is this still fit for purpose and does it represent a tool that should be found in "a top-tier learning platform"? Compare the look, feel and usability with something like H5P.

2. Survey - A potentially powerful activity that can't be edited or adapted.

3. Currently you can add as many topic sections as you like (no limit!) e.g. 1000 or 10,000 but good luck trying to remove or delete them.

Of course Moodle has to be all things to all users and that is a tough challenge. Greater emphasis on quality control and users (not developers) dictating priorities and usability could steer things back in the right direction. Some popular plugins should become core, some core should be seriously improved or shelved.

It isn't about love it or hate it, for many of us it's a more complex relationship. We have been using Moodle for many years and like any good partnership we have a deep understanding of the strengths and weaknesses within. We also understand how tools like this can be used to support learning and teaching, as long as they are quick and easy to understand, use and edit. We will do our part where we can to be supportive and provide feedback and provide criticism that is hopefully constructive. Perhaps on some occasions we forgive the problems and quirky behaviour and even help to paper over some of the cracks. However at 16 years old maybe now is a good time to help Moodle grow up, tidy it's room and start to think about where it wants to be in a few year's time.

At my university, most of the students in our department didn't even realize there was a dashboard on Moodle because the default landing page was/is set to the news feed with numerous other blocks on. It's not ideal but I'm not in charge of their installation, whereas the course dashboard would be a lot more relevant to students in terms of accessing a course, finding resources, activities, etc.. I even had some instructors e-mail me (as a student) asking questions about Moodle since they knew my job was being a Moodle admin. Ironic!

Where I currently work, part of my job is to conduct orientation to all new students (as well as faculty, but this is not frequent), and ongoing support on campus. It's just another way of being the traffic cop and getting students from "login to learning" as you described it earlier. Like you, I was somewhat surprised that my rather small department actually had/has a dedicated position for this. When I worked in K-12, I tried for several years to get one added (I taught and managed the LMS) as it was extremely difficult to do both time wise. Moreover, I couldn't be available for help when I was teaching a full load of classes. They never had thought about this at all, and to some degree later on, just assumed it was relatively easy to do. I was put in a position where I wanted to either teach full time, or do ed-tech admin full time and the school chose the former over the latter. Turned into complete chaos after that but this thinking (or lack thereof) goes back well into the 1990's  in the academic literature sadly.

One way to add this "traffic cop" function to Moodle is to create a User Tour for each of your user types so they see directions the first time they log in (and whenever they want to review them later). A lot of the things one needs to do on first login are never done again, or are done rarely (depending on how the institution handles things like creating new courses, new user accounts, etc.) User Tours can be customized per site and can directly address the needs of that site.

I think periodically reviewing the most-used plugins is a great idea. When I was hired at Moodle, one of my first tasks was to review third-party plugins currently in the directory and group them by similarity so we could see what feature areas were receiving the most interest from the developer community. It would be great to combine this with installation and usage data on both core and third-party plugins to help focus future priorities. However, the data is currently incomplete and skewed by the fact that many (possibly most) sites never register with Moodle, so we have no idea what they are doing. We have been putting stronger processes in place to encourage site owners to register their Moodles. I think this situation will improve over the next few releases.

There will always be the challenge that Moodle is open-source and not a commercial product, which limits in-house resources. If a third-party plugin is "adopted" to be part of core, Moodle HQ takes on maintenance costs, including increasingly complex testing with each release. Many plugins are also created in a way that meets the needs of the home institution, but would not work as well across a wide variety of sites.

I personally think the way forward is simplifying Moodle to more generic, configurable features (not requiring PHP code to configure), and providing installation profiles for different site types (similar to what was suggested above). These installation profiles should consist of configuration pre-sets that members of the community can create, share, and evaluate. But we would also need to provide migration tools from the existing plugins to a smaller set of new, more general-purpose plugins.

For example, if we develop a new custom reporting tool, we should probably migrate existing reports in Moodle to the new tool, so that anyone can customize the standard reports for their site, (without destroying the default reports provided with core), and we might need to help creators of existing reporting tools to develop conversion tools from their formats to the new tool. Ultimately this would reduce the "technical debt" of future development, lowering maintenance costs and making regression bugs less likely with new releases. But each initiative like this is expensive. Maybe if MUA gets a lot of new members and can help fund it....

Is this random, Marcus? Should it have been elsewhere? Or is it you expressing some frustration at Admins not bothering to actually learn about the systems they are supposed to be admining? 

If someone was to come to me with that question, and I didn't know what Kaltura was, which has happened with another plugin btw, I would go look, then have a look at version numbers, if it fit, I would test it. If the test was successful, I would ask the person who made the request to make a case for using it and then seek permission to use that plugin from the owners of the Moodle. (The only issue I have is in versions. If versions are not maintained, then I am seriously reluctant to do anything.)   

I would think that would be responsive admining. I must admit though, the further I move away from core, the more uncomfortable I get, because it means greater possibility of more things going wrong as a result of an upgrade. I think we learned that lesson in the transitions between v1.9 and v2.2 in just how complicated it could all get if non-core, third-party plugins are not properly maintained. 

As a side line, we have been using Kaltura for about 4 years now and it integrates well and works along the line of a private YouTube site with some bonuses (e.g. the ability to embed quizzes into recordings, add chapters and additional files to videos, etc.). Our faculty are liking it and use it for both course information and student assignments.

Yes, Chris, I agree, and reading my earlier comments I think I am blurring the ideas of "simplified" and "user friendly", sorry about that. 

On one hand, is Moodle really generating a new level of "terror by choice"? We are learning from so many studies now that if we, people, have too much choice, we either don't make a choice or we chose inappropriately. So perhaps are we getting out of hand with the number of plugins and options available? 

For me, on the other hand, the concept of simplified is more about using buttons and drop down menus rather than a cluttered block structure. I understand the docking bay is a step in that direction, but most people are now used to having a menu bar across the top of the screen in their working pages, the landing pages are different, but working pages have very little on them. I suggest this is a continuation of the original text editing process, then word processing. They originally informed people's expectations when writing things, basically a blank screen with toolbars across the top. Yes, technology has changed, screens have gotten better, wider, for sure,  but people's expectations are not moving as rapidly as the technology.  

We expect to see things cluttering up the screen when using Excel, or Photoshop but look at any text editor, and there is not a lot on the screen. I still suggest that Moodle needs to get away from the three column Post-Nuke look. If blocks are to appear onscreen, then why not use the same approach as Adobe and put everything on the right for left-side readers and on the left for right-side readers? The tabbing blocks of Photoshop or dockable, nested menus of Acrobat are a neat, tidy solution, which Moodle is actually using, why not formalise it and make it a Moodle Standard? The only thing is that this would be a long term theme project which would take many versions to get right, I would think. 

I have a wide screen monitor, and I set this forum up using the "flat replies and oldest first" option and I can read it in a 2 column approach, just as described above. OK, blocks scroll with the page, but I know enough about HTML5 to know this is only because the right hand column is set to the top of the page, not the screen. Why can't all Moodle's pages, even the landing page be set like that? And right now, I am wishing I had been more creative and really tried to learn how to write themes years ago instead of giving it away when I changed jobs, so I could show you what I really mean.  Crystal ball really failed me here....   

Hi Joost, and I mostly agree, but...

" it pays to make choices at the beginning of the implementation (what's enabled, what's disabled)" 

The assumption here is that the people making decisions know what they want, know what's available and understand the technologies involved. Far too often, none of these pre-conditions are true. Most of my time in the last three years has been battling the ignorance of the people who are making decisions. They don't know what they don't know and far too often I get "Can we talk about this later, I have a meeting." or similar excuse, and of course, "later" doesn't happen. They remain unaware of the impact of their decisions so people get frustrated, not at the nitwits making decisions years ago, but at how the tools they are using don't work, or are not fit for purpose, or complicated, or whatever. I wear that, so I'm the bad guy... but I struggle on, "Non illegitimi carborundum."