Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Moodle Wishlist: Difference between revisions

From MoodleDocs
No edit summary
Line 67: Line 67:
* Add trashcan and /or undo function
* Add trashcan and /or undo function
* Make editing of modules WYSIWYG, no more icons that change layout
* Make editing of modules WYSIWYG, no more icons that change layout
* Collaborative spreadsheet editing functionality - like Google Docs.


=== More Agile Development ===
=== More Agile Development ===

Revision as of 11:25, 5 February 2011

This page is a brainstorm about a complete rewrite/refactor for Moodle 3.0.

Please add your 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?

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.

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.

Use PHP 5.3 Native Power

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

Make a replica Moodle

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

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.