I personally like certain kind of Moodle plugins. Those with a simple idea behind yet with wide range of usage scenarios and pedagogical situations they effectively support. Such plugins typically do not enforce the teacher to use them in "the only right" way. Instead, they give the teacher freedom to use the tool in many creative ways to facilitate students' learning. Today's featured plugin - Dataform activity module by Itamar Tzadok - is a perfect example of such activity. Started its life as a fork of the standard Database activity module, it evolved into a rich set of related plugins and subplugins with lot of features.
Interview with the maintainer
Hi Itamar. Can you shortly tell us something about yourself and your background?
Hi! I certainly can. I live in Kingston ON, Canada. I started my professional career as a software developer, then IT manager and consultant. At some point I went back to school to pursue MA in Philosophy and discovered online learning. I stayed in the university for the next 10 years or so, facilitating and/or delivering hybrid courses and online activities, as well as pursuing a PHD in the history and philosophy of early modern (17th Century) science. Throughout I have continued to provide professional services as a consultant mainly for Learning Management Systems and Instructional Design, and that is what I still do today.
How did you get into Moodle and Moodle development?
What did make you to start with it?
Towards the end of 2013 I started a major revision of the Dataform for Moodle 2.6 onward. The main objectives were to improve stability and performance, remove unnecessary components and adjust the code to the latest Moodle infrastructure. A lot of effort was put in adding automated tests, unit and acceptance. The plugin docs also went through substantial revision. This effort continues to date.
Dataform 2.6 was released in April 2014, Dataform 2.7 in July, and with Dataform 2.8 the plugin caught up with Moodle’s release schedule and will continue according to that schedule.
What software and IDE do you use when developing for Moodle and how does your typical screen look like?
For Moodle development I use mainly WAMP on Windows. I also have MAMP on iMac which I use for instructional design projects. I used to have also LAMP on Debian Linux but have no need for it at the moment. For coding I use NPP (Notepad++). It's minimal but so far does the trick. Early in my career, some 20 years ago, I was fortunate to have excellent mentors who encouraged the team to write code with the ridiculously minimal vi editor. The rationale was that a minimal editor would force you to write minimal (not to be confused with simple) and in this respect more efficient code. And we were developing C3I and AI applications. You may or may not agree with this rationale and either way is fine. I can at least say this. If for some reason you can only use a simple tool, it doesn't mean that you cannot do complex things with it. And it definitely shouldn't be an excuse for not trying. What NPP can’t do is generate PHP docs. And so for this purpose I use the somewhat less minimal NetBeans IDE. It’s a strange mix, for sure.
As can be seen in the illustrations, my typical development screen behind the windows is green. Then I typically have 3 command prompt windows in the corners. The bottom-left is for phpunit cli, the bottom-right is for behat cli, and the top right is for the selenium driver. The top-left corner is reserved for the Acceptance Test Site browser window that the behat cli (from the bottom-right corner) opens. These are now the most important tools in my Moodle development. In particular the phpunit tests serve as a compiler and will alert me to coding errors or debugging messages, and so I run the plugin tests every so often during coding. In the middle is the NPP editor to write the code and a browser to check things via the UI, and I switch from one to the other as required. There are also occasional Git Gui and Git Bash windows which I manage from the taskbar. Github, Moodle Tracker and Moodle docs are open on a different computer which also has a fair amount of green on the desktop background.
What is your common plugin development workflow and how do you organise the code in terms of branching, tags etc?
I work on the Dataform whenever I can between projects. The best of all worlds are of course Dataform related projects which allow me to rest a bit between projects.
Since 2.6 Dataform releases follow Moodle releases. I try to release major versions as soon as possible after the respective Moodle version release. Dataform 2.8, for instance, was released the same day as Moodle 2.8. Minor versions are released as needed. There are currently 7 plugins in the Dataform set and I support at least 2 major versions, and so the last release, in early November, was actually 14 releases.
The code is organized in branches similar to Moodle's, that is, MOODLE_26_STABLE, MOODLE_27_STABLE, MOODLE_28_STABLE and so on. The same holds for tags. Minor versions consists of mainly fixes and improvements but may also include new features. The Dataform auxiliary plugins such as the Dataform view block, Dataform view mod, and the rule blocks typically do not require minor versions.
Do you have some particular plans for further development of the Dataform module?
More than enough for one lifetime.
The Dataform standard release currently consists of a total of 32 plugins. This includes 25 sub-plugins that are packaged under the main mod_dataform plugin and are seamlessly installed/uninstalled with the main plugin, and 6 auxiliary plugins that are released and installed separately. My development environment contains at least 12 more sub-plugins and auxiliary plugins in different stages of development or experimentation. These include new and to-be-released field types, view types, text filters, rule types. Then there is a wish list of improvements and new features.
Probably the most important item in the list, in my view, is a major conceptual and structural refactoring of the Dataform fields. You see, the initial structure of the Dataform was inherited from the Database module, and while some aspects of the Dataform as well as most of its code are by now considerably different from the Database's, certain others remained the same or similar with the same or similar limitations. The concept of the fields is a case in point. In the Database module the fields have been conceived as place holders and input elements for entry content. But that is already a specialization. Essentially and more generally they are widgets. And we need widgets not only in the entry level but also in the view level. Or even some entry level widgets may have relevant behaviour and presentation in the view level. One simple example is a dropdown quick filter that filters the list of entries by distinct content of a menu field. This can be part of the menu field but should be displayed in the view level rather than the entry level.
Not sure where and how it ends, so just moving forward and taking it 5-6 features at a time.
Thanks a lot Itamar. Good luck with Dataform and all other contributions!
Thanks for having me and for making these contributions possible!
I admit I am very impressed by the features the module provides and the way how Itamar makes use of subplugins to implement them. To highlight just some of them:
The in-built support for entries workflow. This is something I missed in the standard Database module. Each entry in the Dataform can be in a particular state (such as "Draft", "In review" and "Published"). These states are defined by the user to fit the given activity context. Also defined are transition rules, that is who can change the entry from one state to another. So you can, for example, set it that students submit entries for review but it's only teacher who make them public. See the module docs for more details.
Planned support for advanced grading methods so that entries can be evaluated and graded using rubrics, marking guides and other forms eventually. Currently the module supports automatic grade calculation based on the number of submitted entries - more in docs.
Ability to display selected view directly at the course page. This little yet very powerful trick allows to integrate the selected dataform contents and UI directly into the course main page. This feature itself has big potential - from displaying list of course references (citations) to turning the course page into an activity stream known from social media portals.
The presence of unit tests and behat tests.
The plugin documentation hosted at Moodle docs wiki. If you like and use the module, I am pretty sure Itamar will appreciate your help with finishing and improving the module docs pages.
There are some things that could be improved, naturally. I reported those spotted during the review into the plugin's bugs tracker. Having seen how Itamar is responsive and supportive in forums, the tracker and the plugin page comments, I rest assured they will be addressed soon.
Said that, I am happy to give the Featured Moodle plugin award to the Dataform module and I am looking forward to opportunity to use this plugin in production. Well done!