salvetore

The blog of Michael de Raadt


Leave a comment

How electronic forms are changing the business of schools

When I was a student, the only way of requesting information from student families was by using paper notes. In many schools today, that is still the case and the number of forms is ever increasing as the demands on schools to capture information grows.

At Canberra Grammar School, an ongoing project is transforming paper forms into electronic forms, and making quite a difference to the way the school operates. The School uses a proprietary form system called Infiniti from Intelledox, an Australian company based in Canberra, but the benefits could be seen using any forms system, even HTML forms.

The forms system is being used to collect information from families and staff. Coupled with an electronic announcements system, this has changed the way the School requests and collects information.

The Figures

Infographic.png

 

Advantages of an Electronic Forms System

There are a number of advantages to using an electronic forms system.

  • Less frequent information requests
    Forms feed directly into the Student Information System (SIS), in our case a system called Synergetic, but again that’s not critical. Once stored securely in the SIS, information can be accessed on demand or used to create reports, so information only needs to be provided by families once or when updates are needed. As the forms system knows the user, there is no need to duplicate what they have provided before. When an excursion is undertaken the information is already available, so there are no paper forms to be passed back-and-forth at the bottom of student’s school bags.
  • Reduced manual handling
    Because form data is added directly into the SIS, no paper handling is involved. Time saved receiving and handling forms could be estimated to be equivalent to a full time employee; that time is offset by the time taken to developing the form in the first place. However, time spent filling forms and submitting is greatly reduced for both staff and families.
  • Reduced printing and postage costs
    If time is money, reduced handling and filling times are saving money, but these are hard to convert into objective figures. It is possible to estimate a few more tangible items, such as printing and postage. In the last 12 months, based on forms completed, relative to past printing and postage practices, we can estimate significant cost savings as shown above.
  • Facilitating processes
    It is possible to use electronic forms as part of a process, passing through a number of people before being finalised. This is has proven to be very useful and simplifies process handling, particularly for staff. We are now discovering processes where there was previously no paper form, or a paper form followed by manual processing, and establishing new processes using electronic forms.

Of course, a forms system does not come instantly. We have spent more than two years improving the way we create forms. Several forms have been created over a number of weeks and never used, so there is now an emphasis on involving stakeholders, defining needs and testing. A number of database-integration hurdles have been overcome to get to the point we are now.

Uses for Forms

The forms are used to collect a range of different kinds of information.

  • Student data and choices
  • Student enrolment
  • Absence reporting
  • Policy agreement for staff and students
  • Staff data
  • HR data collection including applications
  • Event registration

Form Fragment

As well as data collection, the forms system has become another interface to other systems, such as the SIS. Where the SIS has a cumbersome and complicated user interface we can provide an alternative interface that is streamlined for our own context. Coupling this with the ability to drive processes, the forms system is becoming more than just a data collection system. In terms of the SAMR model, we are going beyond substitution (paper for Web) and higher levels of transformation.

In conclusion, the forms system is proving itself to be beneficial for the wider School community and we are discovering new uses for the system over time.

Advertisements


Leave a comment

Advice to IT Job Applicants

I recently posted about my experience organising recruiting for IT positions. I though I would follow this up with advice for those on the other end of the interview panel, based on my experience as someone involved in and responsible for hiring staff at a number of organisations. Much of this advice is relevant to any job applicant, but some is specific to IT positions.

CV and Covering Letter

If you are applying for a position, avoid applying for numerous positions with the same CV. This is something that is obvious when panel members read applications. Look for the positions that you are seriously interested in, research the organisation and take the time to customise your CV for the position.

If you are applying for a position above an entry level position, a covering letter that addresses the selection criteria is expected. You should be able to show that you are capable of covering each criterion.

As an IT professional, when writing your CV and covering letter, you should be able to demonstrate capable word-processing skills. Many people think they know how to use a word processor, but if your skills are not more advanced than when using a typewriter, you’re going to meet sticklers like myself who will judge you on your document writing skills. Think about document writing as you would when writing source code. Your document should be structured with headings that use heading styles. Formatting should avoid unnecessary white-space and include proper formatting mechanisms, such as tabs and tables. Unless it is required, submit a PDF, not the word processed document.

  • Length
    For most positions, two pages should be your CV length limit. Exceptions are positions in higher education where research background may be expected. Keep your text brief and use points. An easy-to-skim CV will quickly get you to the next round.
  • Logos
    Consider adding company logos in your experience list. It quickly shows where you’ve been and is eye catching.
  • Diagrams
    A quick way to show something relative is with quick diagram, such as years of experience in past positions as a graph or timeline. Some of the most intriguing CVs I’ve seen include such simple diagrams.
  • Personal Photo
    Should you add a photo of yourself? Some people are against this. In some parts of the world it is expected. I think that if you have a vibrant, friendly smile, I would add a good photo of yourself next to your name. If you are a female applying for an IT position, I would definitely recommend this.
  • Spelling and Grammar
    If you think spelling and grammar isn’t important for an IT position, think again. Day-to-day communication in IT is written, such as documentation, reports and even bug tickets. If you’re not a native speaker of the language you’re applying in, find a friend who is and ask them to check your writing.

Before the Interview

So you got the call and you’re heading for the interview. Don’t waste your time waiting anxiously; get prepared.

  • Research
    Do more research about the organisation. See if you can determine what technologies the organisation is using that may be relevant to the position. Look for information about history, corporate structure and current newsworthy events. If you are given the names of the interview panel members, look for information about them and their roles; this may help you answer interview questions from them in the most appropriate way.
  • Write questions
    At the end of an interview, you’re often given the opportunity to ‘reverse the tables’ and ask questions yourself. This is a chance to demonstrate the research you’ve done and leave a good impression. Being ready to ask questions shows you have envisioned yourself in the position and are enthusiastic about working in it. Have a few more questions that you will ask so you can pull them out selectively. It’s OK to ask about salary expectations for the position if that hasn’t been covered.
  • Anticipate answers
    Many interviewers will ask similar sorts of questions. See my guide for some examples.  Think about occasions where things have worked in past positions and where they have failed. Think about relationships you’ve had with fellow workers, where that was successful, where you had conflict and how you dealt with that. Write some of these cases down. Be prepared to be honest; answering dumbly that you “can’t think of an occasion where something has gone wrong” can be viewed as dishonesty.
  • Schedule yourself
    When presented with a set of items to remember, people tend to remember the first and the last items better. When marking assignments, markers will often fall into patterns over time, biasing submissions they see early or late in the process. Interview panels will be more open to the first interviewee, critical of following candidates as they hope for someone ‘just right’, but the last applicant has the best chance to swoop in and prove that the whole depressing series of interviews was worth it after all. If you have any opportunity to nominate your time-slot, see if you can get in last or, if not, then first.

The Interview

You’ve made it in the door. You looked good enough on paper, but now you have to prove you’re ready for the job. As well as probing you about your skills and experience, much of an interview is about picturing how well you will work with the people within the organisation. An interview can draw you from the bottom of the list to the top, but a single answer can drop you out of contention.

  • Consider your attire
    As much as we may be casual about attire in IT on a daily basis, avoiding fashion trends and false pretences, what you wear to an interview should be a step-up from the norm. In some cases, that may mean full business suit for ladies and men. See what people are wearing there and go a notch higher. If you’re not sure, it’s OK to ask what to wear to an interview.
  • Don’t show up early
    You may be eager and definitely want to give yourself buffers so as not to be late, but showing up early is a bit annoying for interview panels who are trying to keep to a schedule. Showing up early sets in motion a series of actions that eventually interrupts someone who may subconsciously judge you. Be there on time or a couple of minutes early; if that means lurking in the carpark until your time, do that.
  • Be ingratiating
    Your opportunity to warm up and share what a great person you are comes at the beginning. Don’t skip straight to the skills and experience, however keen you are to demonstrate these. Imagine the interview panel are your best friends; even if they appear weary after a series of interviews, you need to be smiling and respectful of the panel and their process.
  • Be specific
    When answering questions, be as specific as you can. Listen to the questions as they are asked and, even if you have to take a few seconds before answer, consider how you will answer. Giving general answers may cover the question, but it won’t make you a standout applicant. If you can use specific examples from your experience, this is a plus: you’ve been there and done that. Avoid waffling; a concise answer is good. Look at the expression of the person asking the question to see if they are satisfied with your answer to the question, otherwise ask for clarification. Consider the role of the person asking and what perspective (technical, managerial, end-user) they are asking the question from. Be confident about technical skill questions; if asked about something you haven’t worked with previously, answer honestly but show an interest in learning new skills.
  • Be wary of scenarios
    Almost all interviews will include a scenario; expect some verbal role-play, written response, coding task or a combination of these. Your answer to a scenario is not as important as how you answer it. The scenario may test how you might interact with clients. When faced with a conundrum, it’s more likely that you’re being tested on whether you can come up with a workaround, rather than following corporate rules or passing decision-making responsibility upwards.

Afterwards

If you’re waiting for a long period after an interview without hearing any news, it’s probably not a good thing. It doesn’t hurt to call up and ask how the process is going. Put your efforts into other positions after a week or so, if you haven’t already.

If you were unsuccessful, do ask for feedback. As well as helping you with future applications, it shows you’re a mature person and keeps you in mind should the chosen application not work out.


6 Comments

Learning Analytics – Where’s my data?

A while ago I wrote a blog about learning analytics from different perspectives giving examples of different analytics based tools that could benefit different users. Since then I’ve had discussions with numerous people, many of whom have great ideas for analytics tools, but I’ve discovered there is a disconnect between the analytics people want and their understanding of where to find the data.

To get from question to answer there needs to be an understanding of where the data are located and how they can be brought together. My intention with this blog is to show you where to find data for analytics in Moodle.

Source 1: Database tables

Database tables - fadedThe database tables are used by Moodle and its plugins for data storage. They are able to be queried for information about users, and their involvement, as well as course and site information. I would estimate that more than half of the data needed for analytics are stored in these database tables.

The limitation of these data is that they are not historical – they represent the current state of the system. There is some historical data, for example Forum posts and Chat sessions, but for historical information generally you need logs or observers. One advantage of drawing from database tables rather than logs is that such data can be gathered in real-time, all the time, which is not advisable for log data (more on that later).

Here is a summary of the data in Moodle database tables. I’ve categorised the data by the perspectives relevant to analytics.

User information
  • name and profile fields
  • site access (last login)
  • course access (last access)
Activity involvement
  • Assignment submissions
  • Blog entries
  • Chat involvement
  • Database activity entries
  • Feedback responses
  • Forum posts
  • Glossary entries
  • Lesson activity progress and answers
  • Quiz answers
  • Scorm progress and answers
  • Survey answers
  • Wiki writing contributions
  • Workshop submissions and reviews
  • involvement in add-on activities
Grades and achievements
  • course grades
  • badges
  • outcomes
  • activity and course completion
Course information
  • organisation within course and sections
  • number and mix of activities and resources
  • Question bank questions and types
  • configuration and content of activities and resources
  • course enrolments (roles)
  • groups and groupings
Site information
  • organisation of courses and categories
  • file information
  • messages
  • “My home” page customisation

Examples of using database data

Here are some examples of how data in Moodle’s database tables could be used for learning analytics. It’s not a comprehensive list, but perhaps there are ideas here that could inspire some great analytics tools.

  • Student involvement and achievement
    • Accesses to enrolled courses
    • Progress through course
    • Relative success or risk of failure
    • Opportunities for students to undertake activities or interact
  • Teacher involvement
    • Regularity of access to courses
    • Timely interaction with students
    • Timely grading
    • Success of students in teacher’s courses
    • Potential to assist students at risk or commend success
  • Course quality
    • Richness of content and activities
    • Use of assessment
    • Student-teacher ratios

Source 2: Logs, Events and Observers

Currently the logging of events in Moodle is undergoing change. Rather than referring to past implementations of logging, I’ll be more forward looking, referring to events and logging as used to some extent in Moodle 2.6 and used fully in Moodle 2.7. The new logs are richer and more focussed on educational activities.

Live logs

From logs it is possible to extract information about events that have taken place. Here are some relevant aspects of events that are captured.

Component The part of Moodle (module, block, core) in which the event took place
Action What took place, based on a pre-defined list of verbs
CRUD Whether the action was to create, read, update or delete
Educational level Whether the action was teaching, participating or other (eg. administering)
User IDs Who was responsible for the action and who they might have been affecting (eg. a teacher grading a student)
Course and context Where it happened
Timestamp When it happened

Here is a list of verbs (action words) that are used with events currently. This set may grown.

accepted, added, answered, assessed, attempted, awarded, backedup, called, commented, completed, created, deleted, duplicated, evaluated, failed, graded, imported, loggedin/loggedout, loggedinas, locked, moved, passed, previewed, reassessed, reevaluated, submitted, suspended, switched, viewed, registered, removed, restored, reset, revealed, unlocked, upgraded, updated

One of the problems with logs is that they grow very large. This makes efficient searching and processing of log information almost impossible, particularly on larger sites. With richer event information being captured, there are also events being recorded from more places in Moodle. There is the potential to direct log information to log stores outside of the Moodle database. The intention of this change is to allow searching and processing of logs without impacting the performance of the Moodle server itself. There is also the potential to export log data to files for filtering and analysis outside Moodle. So it is possible to get detailed log information, but this cannot be used in real-time, say for a block or a report that combines logs with other information.

One way to capture event information so that it can be used in real-time is with observers. As each action takes place an event is “triggered” within Moodle and observers can “observe” events based on certain criteria. The new logging system is an event observer that consumes all events that are triggered and stores them (to one or more log storage plugins). It’s possible to create new observers that can focus on a subset of events, store relevant information so that it can later be presented efficiently. If you were interested in, say, creating a report that focussed on enrolment actions, you could allow the report to observe enrolment events, store records in its own table and then present the results to users appropriately, any time it was needed. The report could even make use of messages to send out alerts when necessary.

Examples using events and log data

  • Monitoring site activity and focal points
  • Number of user accesses, which could be used to infer time online
  • Repeated exposure to resources and activities within courses
  • Students accessing teacher feedback on activities
  • Student retention in courses (based on enrolments and unenrolments)

Source 3: Click tracking by external monitors

Google Analytics for moodle.org

Google Analytics for moodle.org

The term “analytics” has been popularised by Google who offer a service that allows you to track users as they move through the pages of your website and then report information about the users back to you. It is possible to use Google Analytics with a Moodle site. After registering your site you need to slip some JavaScript into the pages of your site (Site administration > Appearance > Additional HTML or in your theme’s footer.html file). Google will then collect and present information about your users including…

  • their environment (browser, OS, device),
  • where in the world they are coming from and
  • the paths they are following through your site.

This information is useful to administrators wanting to ensure their Moodle site is catering to users’ needs. To discover learning analytics from Google Analytics, it is possible to drill down into usage information, This will not yield the same sort of information as the Moodle database or logs, instead showing patterns of behaviour. This information could potentially be fed back into Moodle as Google provides an API to query analytics data, which could be presented in a Moodle report or block.

Another relevant click-tracking tool is the Moodle Activity Viewer or MAV. This is a system in two parts: a server-side component that collects course activity usage statistics and a browser plugin that takes the page delivered from Moodle to your browser and overlays the page with colour to turn the course page into a heatmap. This shows teachers where the focus of activity in a course is taking place.

Could this understanding be built-in?

Unfortunately, at this stage, there are no simple generic mechanisms built into Moodle that allow you to freely gather and combine information without writing code. There are some exceptions attempting to allow generic report writing, but I don’t think these are simple enough for ordinary users yet. Currently, if you have specific questions that can’t be answered using standard Moodle reports, the best way to get the answers you want is by writing (or get a developer to write) a plugin (report or block). Hopefully this guide so far will provide an understanding of what data are available and where to find them.

Is there a possibility to create the reports without coding them from scratch?

One potential future step would be to allow plugins (and Moodle itself) to be able to describe the data they store. With this meta information, it could be possible to use a generic tool to  gather and combine specified information on-the-fly and tweak the criteria as needed. This would allow access to the rich data in the Moodle database (with appropriate security constraints, of course).

It could also be possible to create a generic observer that can be configured on-the-fly to consume events of interest and record them. The current logging and events system APIs allow such alternative logging. Providing a sense of what events could be observed would be the challenge here, but at least events are now somewhat “self describing” meaning meta information is recorded with the coded description of the event objects.

For administrators interested in the sort of user information that Google Analytics reveals, it is possible in Moodle to determine a user’s browser, OS and device type. Moodle already does this to allow page customisation for different combinations of these factors. It would not be a great step to capture and present this information in a report. Google could probably do this better, but perhaps you’re not too keen to allow Google to snoop on your students and their learning activities. Moodle logs could be used to infer the paths and behaviour of students, but this would be a very costly exercise, requiring a great deal of computing power, preferably away from the Moodle server.

What to do with this data?

The final challenge then is to go beyond data gathering and analysis to provide tools that can use this information to support teaching; tools that help students learn, teachers teach and administrators to cover their butts. Only then will we see the LMS take education beyond what could be achieved in the classroom.


2 Comments

What makes a good research paper?

Committee Header

The submission deadline for the Moodle Research Conference (MRC2014) is approaching fast. I imagine many people around the world are feverishly preparing their submissions. Unlike most conferences, the MRC draws together people with different experience from many fields who happen to be conducting research in and around Moodle. Being one of the co-chairs for this year’s MRC, I thought I’d put together a guide to help authors.

Links to past research

Links to past researchAs a researcher, you are never working alone. Basing your research on work that has come before gives you a solid foundation and increases the credibility of your work. Reviewers are not only judging your paper, they are looking at your knowledge of the field. Citing appropriate past research demonstrates your understanding and places your work within your research area. References should be formatted according to the prescribed standard and should provide enough detail to allow a reviewer to find the cited work. Cited works should be primarily from peer-reviewed sources. Ideally, you should be able to demonstrate a need for your current work based on past research.

Research questions

After setting the paper within past research, you should then define the aim of your research and this is done with research questions. Such questions could be phrased as hypotheses, but this is not essential for an MRC paper. Your research questions can be used to define the structure of the remaining paper including the conclusions at the end of the paper, where the answers to these questions should be presented.

Evidence

Without evidence a paper is simply opinion. evidenceIn order to answer your research questions, you need to gather and analyse evidence. The evidence should answer the research questions, proving or disproving something – either outcome is valuable to report. The evidence you present could come from one (or more) of many sources such as experimental results, user data gathered in Moodle, surveys, case studies, etc. You should be able to show how the evidence you have gathered builds on the past research you have written about earlier in the paper. Even if your paper is focussed on the the development of a new tool (such as a Moodle add-on), you should go beyond a simple description, showing evidence that the tool works in practice and can have benefits.

A few more tips

Writing quality and flow
MRC papers must be written in English. Poor writing distracts reviewers from the important research work you are reporting. If English is not your first language (or even if it is) get someone else to proof read your paper before you submit it. Also consider the flow of your paper: each paragraph should follow on from the last and each section should lead into the next. You are arguing the value of your work and your argument should seem logical.
Follow the template and use its styles
The MRC, like most conferences, provides a template to demonstrate the expected paper format. Rather than copying the styles shown, use the template as the starting point for your submitted paper. Use the styles in the template rather than manipulating text to look like the styles. Doing this is easier and is something all word processor users should be able to do. It also ensures all papers in the final proceedings are consistent. If your paper appears different, reviewers will feel responsible to point this out and that will detract from the review. Look through the Moodle Research Library for examples of accepted papers from past MRC conferences.
Anonymise your work properly
The MRC uses double-blind peer review, so authors don’t know who is reviewing their work and reviewers don’t know who has authored the paper they are reviewing. If the reviewer sees you’ve done a poor job anonymising your paper, that may impact their review. See the guide to submitting papers for things to check when anonymising your document.
Present data visually
A picture is worth a thousand words. Presenting data as a table or chart makes it easier for readers to understand. Screen captures are a great way to show tools in use. All tables and figures should be labelled and there should be a reference to these items within the text to include them at appropriate points in the flow of the document.

References

  • MRC2014 site
  • MRC2014 Call for Papers
  • Moodle Research site
  • Guide to submitting papers
  • Moodle Research Library
  • Simon, Carbone, A., de Raadt, M., Lister, R., Hamilton, M., & Sheard, J. (2008): Classifying Computing Education Papers: Process and Results. Proceedings of the International Computing Education Research Conference (ICER2008), Sydney, Australia, 6-7 September, 2008. 161 – 171. PDF Web Web
  • Simon, Sheard, J., Carbone, A., de Raadt, M., Hamilton, M., Lister, R., et al. (2008): Eight years of computing education papers at NACCQ. Proceedings of the 21st Annual Conference of the National Advisory Committee on Computing Qualifications (NACCQ 2008), Auckland, New Zealand, 4-7 July 2008. 101 – 107. PDF Web


3 Comments

Agile development and Scrum in an open source project

I was asked by a teacher of software development if I could give an overview of how we use the Scrum Framework in a real-world, open source project, here at Moodle. Being a former development teacher myself, I could not refuse.

The video below outlines the Agile software development processes followed at Moodle HQ. If you’re a developer or someone training to be a developer, this will be relevant to you.

Forgive my ums and ahs. It’s been a while since I was in teacher-mode.


Leave a comment

A New Battleground

From the static Web to dynamic mobile browsing

Moodle 1.9

Moodle 1.9

In the beginning, when Learning Management Systems (LMSs) were young battlers, Moodle came about as a combatant that succeeded through its stubborn simplicity. Other LMSs attempted to overload interfaces with Java to achieve an edge. Moodle, on the other hand, stuck to standard Web interfaces to achieve the same result. The result was that Moodle was considered simpler and more user-friendly. If you knew how to use a Web browser, you could use Moodle; you didn’t have to have any additional browser plugins installed. Moodle’s usage grew rapidly, overtaking its competition, because people could understand it.

With the advent of AJAX and JavaScript libraries, the Web has started to move beyond being a place to present content and has become a place where applications (once bound to the desktop) now live. JavaScript, having existed for many years, is finally being used to its fullest potential, allowing greater interactivity on Web pages. AJAX is a means of communicating between a browser and a server without a page reload, in other words, things are happening in the background without the user needing to leave the current page. The Web is now truly dynamic; this new Web is the place LMSs were meant to be. The challenge LMSs face, is to achieve simplicity, while adding dynamic elements in an intuitive and unobtrusive way, always maintaining usability and accessibility.

LMSs are also being used beyond the desktop. Now that we are finally seeing consistency among desktop browsers,  developers are faced with a new challenge in the form of mobile devices. The standards set for the Web are still followed (although I think a mobile browser war is just getting started), but the physical interface to the browser is different on mobile devices. No longer can we rely on users with a mouse, keyboard and monitor; the Web has to work with touch interfaces also. We aren’t even afforded the luxury to assume a reasonable minimum screen size.

A new battleground

I have been involved in the bureaucratic effort to select a new LMS for a university. Battle was fought by lining up each LMS candidate side-by-side against a set of features. The LMS with the most checkmarks next to its name was the victor. Moodle won this battle many times because it was well featured. If the feature didn’t exist in the standard distribution, there were add-ons to supplement it, and if that wasn’t enough, you could always customise. The other thing Moodle had going for it was its underdog status, which I’ve talked about before.

About two years ago, at the 2011 Australian Moot, I sensed a new set if biases creeping into the public consciousness. No longer were people asking for more features, instead they were wanting style and speed. Does this mean Moodle is feature-complete? Probably not, but at least most people seem satisfied with the current feature set and seem to have shifted priorities. A new battleground has been forming in my mind in the last couple of years.

So what is Moodle doing to arm itself for this new battleground? Here are some newish additions to Moodle’s arsenal.

Simpler Editor

People spend a lot of time in Moodle using the editor. The WYSIWYG editor has been around from very early in Moodle’s history, but now it’s is being simplified. We’re still using TinyMCE for now, but keep your eyes open in future for a brand new, home-grown editor alternative that will be slicker still.

New editor look

Drag-and-drop

The most obvious use of AJAX and JavaScript is drag-and-drop and Moodle now uses this in a number of places. You don’t have to leave the course page to add a file resource (“dump-and-pump” is so much easier). If you want to rearrange the placement of activities, resources or blocks, no page reloading is needed. In a similar way, if you want to rename something, you don’t have to edit a whole page of settings. Where ever a file is needed, if you can drag it into the file picker, that will get the file uploaded quickly.

Drag-and-drop

Access to the world’s data

Repositories are sources of files. They could be files on your computer, files on the institution’s server, files from the Web or files from “the cloud”. This concept seemed to stump some people at first, but it is now starting to make sense. At the advent of Moodle 2.0, there were a few teething problems with repositories, but this part of Moodle has settled down into something smooth and reliable.

Repositories

An interface that works on anything

Apparently students and teachers have new-fangled mobile devices now, and they want to access their Moodle sites on these devices. Responsive themes allow a single Web interface to react to different screen sizes. On a large screen, the view is not too different from the standard theme, with a few rounded edges. On a small screen, things are rearranged: menus collapse into icons, blocks shift to below content and pop-ups fill the screen. There are a number of other changes that the use of touch devices have promoted as well. Not only is the interface becoming more usable on different devices, it’s also becoming more accessible to users with disabilities.

Moodle on a small screen

Is it working?

Well, none of the things I’ve mentioned above appeared on the feature list a few years back, so are they needed now? There are a large number of registered sites still on 1.9 – why? Is it a case of “If it ain’t broke, don’t fix it”, or is the simplicity of older Moodle versions still more attractive to some users? Change, it seems, happens slowly in the world of education. Change can be dramatic for people.

When Mary Cooch conducted some training for existing Moodle users at Our Lady’s Catholic High School, the new interface was different enough that they did not recognise they were still using Moodle. One participant’s response was that the new system was “Unbelievably simpler than Moodle!” Others had similar comments, and even though it’s a small sample size, I think we can see that as evidence that Moodle is getting simpler.

The battleground of the future

The battle goes on.

The question now is where the battles of the future will be fought. Predicting the future is precarious, and I’m undoubtedly going to be proven wrong, but I have to speak at a conference next week, so I’d better come up with some ideas that sound slightly visionary.

Scale

learn.moodle.netMassive Open Online Courses (MOOCs) are a hot topic at the moment, with large courses being offered online to anyone willing to participate. Many are anticipating that MOOCs will have an impact on the future of higher education. Moodle has recently conducted what could be seen as an experimental step into the MOOC world. Check out learn.moodle.net.

Massive is big, but is there something bigger. Moodle and other LMSs have traditionally focussed on tertiary education and corporate training. There is a smattering of use in primary and secondary education, but it is limited to a relatively small number of classrooms. However when you compare the student numbers and budgets of these sectors side-by-side, primary and secondary education dwarf the other sectors. So why are LMSs not being used widely in primary and secondary education. I believe the answer is that primary and secondary teachers are not well supported and have less time to attempt such ventures than their colleagues in higher levels of education. Where LMSs could start to become useful is through large-scale integration at state or federal levels. If an LMS is set up where the curriculum is defined, teachers would be freed of the laborious tasks of gathering resources, establishing assessment and conducting grading. Instead they would be free to focus on what they do best: teaching.

End of one-size-fits-all education

At almost any level of education, once the class grows beyond a handful of students, necessity prevents teachers from implementing individual learning plans. The burden of assessing students regularly enough, measuring their performance and adjusting the curriculum to suit them becomes nearly impossible. But that is where LMSs can help. At the moment providing an individual path through a curriculum that automatically adjusts for a student is possible, but it is cumbersome. Hopefully we can improve on that in the future.


3 Comments

Incentives for Developers

How do you encourage developers to be more productive?

A few months ago, I was intrigued by a presentation by Dan Pink, an American public speaker. Here is a version of that presentation (and there are a few similar presentations around, including a TED talk).

In the presentation, Pink claims that extrinsic motivators, specifically financial incentives (bonuses, raises, promotions, stocks,…), can be counter-productive to the goal of encouraging workers in certain circumstances. In the presentation, Pink refers to studies at MIT, so I went searching for publications for these studies and found Ariely (2005) and Awasthi & Pratt (1990).

While people can be motivated by financial incentives, the studies found that financial incentives can reduce performance for tasks involving a cognitive component. Software development certainly involves cognitive tasks, in fact programming is about as cerebral as you can get.

So if money doesn’t work, what does? Pink’s thesis is that employees will be more productive when they have a sense of:

  • autonomy,
  • mastery and
  • purpose.

Pink refers to cases at Atlassian and Google, where employees are reported (in the media) to receive many perks. I’ve been to Google, and while I did enjoy the free food, the work environment was certainly not anarchistic, in fact it seemed quite ordinary on the inside. What Pink emphasises is that these companies offer a degree of autonomy to their workers, that employees have the potential to develop professional masteries for their current job and for future jobs, and that employees are able to see a sense of purpose in what they do day-to-day.

Developer Incentives at Moodle?

Some aspects suggested by Dan Pink were already in place at Moodle, but some have been added or enhanced in recent months. I will describe how we offer a sense of autonomy, master and purpose to members of the STABLE team at Moodle (the devs who work on the existing releases of Moodle).

Autonomy

Apart from being a relatively relaxed working environment, there are some specific differences that may set Moodle apart from other development offices.

  • Devs choose, set-up and maintain their own development environments. Code meets at the repository, but how it gets there is up to the developer.
  • Using the Scrum framework, devs choose issues they will resolve from a prioritised backlog of issues. This ensures that the highest priority work gets done, but devs have a sense of ownership over, and responsibility for, the issues they choose.
  • After every two sprints (sprints are typically three weeks long), devs have a week to work on a project of their own choosing. The projects have to benefit the Moodle community, but is open to interpretation by the developer. This means that one week out of every seven, the developer is completely autonomous.

Mastery

Mastery is an area we could be working more on, but there are a few initiatives in place at Moodle.

  • Devs can nominate external training courses and are supported to attend.
  • Devs nominate areas of interest in Moodle and are allowed to specialise in those areas.
  • Devs receive in-house productivity training . There are also irregular presentations on development related topics related to the current focus of work (for example, in-code documentation writing, Web services, etc.)

Purpose

Purpose is something that Moodle has a lot of. Moodle allows many people to access education, some of whom would not be able to do so otherwise.

In saying that, it is easy to lose sight of that purpose when devs are focussed on lines of code while reading the grumbles of users on bug reports.

It is important t0 regularly remind developers that there is a community out there and they really appreciate the work devs are doing. We have, in the past, dragged devs to a Moodle Moot, where there is a lot of back-patting. We are hoping to do that again this year.

If you are a member of the community and wish to express your gratitude, please do so. Send me an email or post a message on the Moodle forums. It will really help.

Do these incentives work?

From my perspective, I would have to say “yes” – encouraging a sense of autonomy, mastery and purpose does help developers, their progress, as well as the general working environment. It’s hard to quantify the effect of making these aspects more obvious to developers, but I have noted some improvements since we have.

  • Our turn-over of staff is low. The devs seem are content and passionate about their work, particularly when they have a chance to work on what they are interested in. This really helps avoid slacking off when it comes to doing “more of the same”; with sufficient variety, developers are quite happy to switch to unstructured work and then back to structured sprints again.
  • General productivity is higher and being maintained. The number of issues being led through our process has increased and that is a good sign.
  • The STABLE team is producing some significant contributions to Moodle, and not always in the same way. We had a very colourful show-and-tell session last Friday with some very excited developers (including devs from outside the STABLE team). Here are some examples of what was put on show…

An optimised view for the Gradebook (Rajesh Taneja)

There are a number of issues relating to the usability of the Moodle Gradebook, which can become unwieldy. With some simple modifications, the Gradebook becomes a much more usable space.

Optimsed Grader Report

Previews for Database activity uploads (Adrian Greeve)

Currently, uploading data into a Database Activity provides little feedback or control. Adding in a preview, with field matching, allows easier uploading.

DB Activity Upload Preview

A Moodle development kit (MDK) (Frédéric Massart)

The MDK automates many regular dev tasks including Git operations, adding information to issues on the Moodle Tracker and automation of site instantiation and population with dummy data.

Moodle Development kit

This project has been quite a collaborative effort and is still growing.

  • Documentation is available on the Moodle Dev docs.
  • The MDK can be accessed from Github.