Moodle Wishlist

Warning! This page is highly speculative.

It is basically a dumping ground for random ideas from anyone who wants to write something here. It is not in any way an official Moodle roadmap or policy. Some of the good ideas here may be adopted, but most of the ideas are pretty crazy, and will never work. Basically, it is a place to brainstorm. Please add your own crazy ideas! They don't need to be consistent yet, just make sure your ideas are here to be boiled down later on.

Think Big!

One type of plugin

All plugins/modules could be subclassed from one plugin class, making installation easier and simplifying the API a lot.

Look at new framework

Possibly base Moodle 3.0 on new existing frameworks? Ruby on Rails? Drupal? Symfony2? +2

Keypoints Gabriel Mazetto

• MVC is a must (we waste too much time reimplementing "mvc" in every single page, and we lack best practices by doing it again and again and again)
• Better ORM (I understand that in some time of the history, it was a good idea to create our own ORM, but today's lack of modern ORM means bad APIs, ancient unit tests, no "factories" which leads to expensive tests and bazilion fixtures)
• Object Orientation done right (doesn't matter if it's php, ruby or whatever, but let's use all the useful features the language has to offer and lets make the code easy hackable, no more useless private/protected that makes impossible to overwrite pieces of code without having to duplicate everything).
• Use more external libraries (let's just not reinvent the well again, there is a lot of good libraries out there that have strong community to maintain, and let's not waste time reimplementing our "perfect" version of them, that soon will be obsolete as no one is willing to maintain... and also let's make an effort to update regularly thous external libraries).

Drupal

There's an interesting discussion in the Language Teaching Course: How can Moodle be more of a social networking site? with some links to the Drupal in Education User Group. --Frank Ralf 14:27, 18 January 2009 (CST)

(I started a section about talk on my User talk page. --Frank Ralf 06:35, 21 January 2009 (CST))

There are some activities in the Drupal community regarding better interoperability and integration of Moodle and Drupal, see Drupal Quiz module - data exchange with other LMSes and Moodle integration with Drupal. --Frank Ralf 08:10, 10 June 2009 (UTC)

Zend Framework

How about ZendFramework? It's open source, of course, runs on PHP, already has a pretty cool API with a well stocked service library, and the coders are working closely with Google, Adobe and Microsoft, among others, to produce some really high quality code. One feature I particularly like is that the main bulk of the PHP code is outside the public HTML directory. Since version 1.7 It also offers pretty good support for Flash Remoting (AMF0 and AMF3) making it especially easy to create integrated RIA frameworks. Check here to see what you get "out of the box". It looks like they've already done most of the hard work for you.

Node.js

Thinking "big", how about ditching PHP entirely and building on top of node.js? You could exploit its real-time-friendly design, and integrate the node.js-based etherpad-lite for synchronous document collaboration. And javascript has some of the same hacker-friendliness that PHP has.

Moodlets

Individual-independent-activities backup/restore + metadata - Eloy

Support for alternate interfaces, mobile interfaces

Optimized for tablet computing: iPad, others Completely flash-based interface? Designed for offline clients?

Integrated category/taxonomy system

Putting together the "course categories", "tags" into a generic taxonomy system.

Save the 1970-2038 limitation

Those UNIX timestamps are pretty limited.

Translation framework

Drupal uses GNU gettext.po files for providing translations which is a very robust and well understood format.

Or XLIFF format (use in Zend Framework, Symfony, Intl extension) with Resource bundle manager

Use PHP 5.3 Native Power

Like : PDO, SPL, Namespace, Intl, Phar... (Zend Framework 2 use it)

Caching with Edge Side Includes (ESI) and a proxy (varnish, squid)

This should provide performance improvements while not having to limit the number of portlets on a page for optimisation. (Symfony2 provides that possibility out of the box, leaving the choice to activate it or not)

Make a replica Moodle

1 Moodle library, 100 Moodle platforms, just adding plugins and themes.

Please Sanitize the PHP code

Don't use : ini_set

Don't use : error_reporting Don't use : @

Don't use : eval

Don't use alias : exemple : die (it's exit)

Don't use depreciates functions : exemple : split (it's explode or preg_split)

A simple way to show all errors : (in php.ini with PHP 5.3) :

disable_functions = ini_set, error_reporting

error_reporting = E_ALL | E_STRICT

display_errors = On

(eval can be disable with Suhosin)

Use the right functions : exemple : it's not ini_set('include_path') it's set_include_path

Use Registry Pattern instead global

Use Docbook everywhere

Moodle is now PHP 5 : clear "var" in class, methods are public/private/protected function (not just function) and __construct for constructor method

Many thanks for your invaluable and expert opinion, we'll be working hard on all those, sincerely! --Eloy Lafuente (stronk7) 01:37, 19 February 2011 (UTC)

Built for Teacher-to-teacher Content Sharing

Drag-and-drop courses and course items from Moodle Hubs

Learn from LAMS and Dokeos

Integrated authoring system Drag-and-drop sequential scenario-building

Invent something crazily new

3-line ideas are welcome here:

• participation reward systems
• Add trashcan and /or undo function
• Make editing of modules WYSIWYG, no more icons that change layout
• Collaborative spreadsheet editing functionality - like Google Docs.

More Agile Development

There are many elements in agile development that could apply to Moodle and benefit the development process tremendously. With proper application of these elements, the Moodle's core code can be more solid and robust. Any programmer can make changes to the source with confidence and not be afraid of breaking any other features.

Test Driven Development

Require unit tests and acceptance tests be written for every change made to the core code. No code should be committed to the core without any test written. A code reviewer should run the tests and expect them to be failed before applying the code changes, and expect they all passed after applying the fix or code changes. S/he should also run the full test suite to make sure the changes did not break any existing features and functionalities.

Code Review

Implement a code review process like the Google Chromium project. Developers can only commit to the trunk with one or more reviewers' approval.

I wonder if the person who added these ideas has any idea how Moodle development actually works. I would guess not. The process is already very agile. All contributions are code-reviewed. There are not enough unit tests yet, but writing unit tests for legacy code is the hardest sort of tests to write (see the book xUnit test patterns) so frankly, it is not worth the effort, except in new code. I can get away with saying that because I have written 2500+ test cases for the latest bit of development I did.--Tim Hunt 15:23, 6 February 2011 (UTC)

Hi Tim, please don't take me wrong. I think the development team at Moodle is already very agile. It is actually one of the few agile projects that I have seen in the open source communities. The effort that you and many diligent individuals have made to coordinate and integrate contributions from all over the world is outstanding. I just made these comments based on the software development environment I came from, where no code change is allowed to commit without any test written and reviewer signs off. Our VCS is actually configured to reject any commit that do not have these two elements present. You are correct that I do not fully know the Moodle development process yet, but the fact that I see codes (particular contributed codes) being checked in without any tests, I just thought it would help bolster Moodle's core code by enforcing this rule in future commits. And implementing something like Google Chromium code review interface allows more eyes on the check-in codes, and hopefully alleviates some of the loads from you and the rest of the core team, who have been doing a wonderful work on peer-reviewing all these time. Again, please don't take this as a criticism but a brian-storming idea if you will. Peace. --Carson

Audio Feedback

• The ability for lecturers to leave audio feedback on students work (student uploaded work could be: text,audio,video...) as opposed to written text feedback. Students can then listen to feedback rather than read text feedback on-line.
• On the (moodle) activity/assignment submissions page, beside each students text input box, have a record, pause & stop button for teachers to record & save the audio feedback.
• It would be for all audio feedback left by lecturers in a particular course for a particular student could be aggregated into one podcast, which could be listened to by students on their mobiles, on the move--Jago Brown

This does not require any major changes to Moodle. It just requires a few plugins, possibly just a 'record audio' repository plugin. And, perhaps, a new assignment type or question type. This is all perfectly possible in Moodle 2.x.--Tim Hunt 16:22, 10 September 2011 (WST)