We are happy to present another featured plugin, the Collapsed Topics format,
maintained by Gareth Barnard
. This plugin is a 'must-have' for many Moodlers because it solves the 'Scroll of death' issue when courses have large numbers of sections and activities.
Collapsed topics was in the Top Ten Downloads last year. At the time of this post, it is being used on over 3370 sites. I asked Gareth in an interview about his background, his plans for the plugin and any recommendations he could give to other plugin developers. Here’s what he had to say:
Hi Gareth. Can you briefly tell us something about yourself and your background?
I am a software engineer and educator, with a Masters in Computing, a teaching qualification in Secondary Education (ICT) and am a member of the British Computer Society. I started my career as a software engineer, went into education and have now returned to software engineering.
I write software because I get great satisfaction from doing so. Before PHP and modern web technologies, I have coded in C++, Java, ADA, C, Modula-2, Pascal, COBOL and Basic.
I enjoy walking, cycling, archery, landscape photography and filming steam engines/railways.
Can you briefly describe the Collapsed Topics plugin and its main features? Who is it primarily intended for?
Collapsed Topics has the ability to:
- 'Toggle' sections open and closed.
- Remember the state of each toggle on a per course per user basis.
- Display the sections as weeks, topics, days, current week first or current topic first.
- Organise the sections into columns.
It is aimed at educators who have medium to large courses where the content can be broken down into self-contained sections.
How did you get into Moodle and Moodle development?
Whilst teaching ICT, the UK government brought in a requirement that all secondary schools should have an 'eLearning Co-ordinator' to manage online learning within their institution. I was appointed, and instructed to look at various LMS solutions by my boss. I looked at one solution and then Moodle. I discovered that I could do with Moodle in five minutes something that took thirty minutes with the other solution. We were already running our own servers so went for Moodle.
My development work started with Collapsed Topics. I was teaching an ICT examination course that had many modules. At any one time a student would only be working on one module and thus did not need to know about the others. I read an article in .Net Magazine Issue 186, entitled Collapsed Tables by Craig Grannell; this seemed to be a good way of hiding the topics. So I contacted him and received permission to use the work and started to create Collapsed Topics.
What software and IDE do you use when developing for Moodle, and what does your typical screen look like?
I do most of my Moodle development using browser development tools, Notepad++, MySQL administrator, Node.js command prompt, TortoiseGit and the Git bash, although very recently I have been looking at the Netbeans IDE (as I have used it in the past for Java development). I use both a WAMP and a LAMP stack with the latter being a virtual Ubuntu machine. I also have a Raspberry Pi operating as a Git server as well as publishing on GitHub.
I hate doing anything twice, so regularly backup all my code to GitHub, the Pi and four other hard drives and a memory stick. This does not include when the zip files are published in the plugins database. Ok, not quite software, but I consider that backup and configuration management are essential things for any developer.
Another 'DE' I use is pen and paper; this helps me to sketch out ideas and keep track of things.
What is your common plugin development workflow and how do you organise the code in terms of branching, tags etc?
I stick to having a 'Git' branch for each version of Moodle that the plugin supports (even if there are no code changes between the versions) which keeps things contained and clear. The current one supported is the 'master' branch. Previously this was not the case with 'master' only being used for the next version of Moodle; however over time, this proved to be more administration, thus evolving to better practices as new information comes to light.
As there is only me for the most part working on the code, I develop within the branches. Occasionally if I want to try out an idea I create a separate development branch. All releases are tagged and marked as 'beta' / 'pre-release' or 'stable'. Anything in between is considered development and subject to change.
Many Moodle plugin developers are looking for a business model that would, at least partly, cover the time spent on their plugin development and support. Can you give some recommendations based on personal experience?
Very good question!
With Collapsed Topics I developed it because I wanted to. It solved a problem for me at the time in a work situation and even more gave me satisfaction that it benefited my students. Developing the format has also improved my PHP skills which were none at the start. I continue with the format so that I can maintain my skills and learn new ones. Over time the API for course formats has changed and this has lead me in different directions that I did not expect.
Developing any plugin will give you experience and help to develop your skills. When you publish your work you will then gain further experience technically and by supporting users. This facilitates the building of a reputation. That reputation will help you stand out and attract clients who come to you asking for bespoke modifications and new work based upon what you have done.
Do you have any particular plans for further development of the Collapsed Topics plugin?
I have a firm belief at the moment that Collapsed Topics has all the functionality it needs to do the job wanted of it. How long is a piece of string? As long as it needs to be to do the job. Collapsed Topics is the correct length.
The user interface is just right in terms of complexity. Any more complexity would lead to confusion. I do not want this to happen, a tool should be almost self explanatory and intuitive in its day to day use. However, I will continue to improve the underlying functional code in order to keep up with technical developments. Following recent feedback from Michael de Raadt, there might be some minor cosmetic changes to improve the overall look and feel. The main plan is ensuring it works on each upcoming version.
Thanks Gareth, and thanks again for all your contributions.