WAY2WEB: Web Design & business...

Building a Course Management System: Where to Start?

My latest undertaking on the web development front is a web-based eLearning (or Course Management) system, designed specifically for high schools. In essence, it provides a place where teachers can add lessons, and quizzes, and then the students can access them and use appropriately. And it's all through a web browser.

Of course, it does many other things, and the feature list is growing, but I'll focus on this aspect a bit later on. Today's article is about why I decided to make such a system, and how I first went about it. This isn't about code - it's about processes and decisions.

Existing Solutions

Let's go right back to the start, way back in September, when the project first started. It all started when I was talking to one of the technology teachers at my school about eLearning, and specifically a system called Moodle. We were discussing rolling out this system through the school, and in fact they had been planning to roll it out for some years, but for some reason no one quite felt it was right.

Moodle was open source, highly customisable, and widely used around the globe. It had most of the features we wanted, but it lacked one key component - a easy to use interface. For some reason, the interface seemed clunky, and not very smooth. So, instead of using Moodle, I suggested something different: we develop our own system.

This decision didn't come lightly. I'd developed some pretty comprehensive systems before, so I knew the work involved in getting it right. Instead of going straight home, loading my code editor and getting started, I researched some existing alternatives. There's plenty of such systems available, but none seemed quite right. Just like Moodle, they didn't seem to be easy enough to use.

After a week of this searching, I concluded that we needed to roll our own solution.

No Nonsense

So, once we had decided that I was to develop our own system, we made up a features list. We didn't go through fifty sheets of paper in specs, diagrams, flow charts, and Gantt charts. No, we made a simple features list, on a scrap sheet of paper. Simple.

As you can see, this no nonsense approach got us through the planning stage really easily, and it took minimal time to complete. Throughout the process of development, this tradition continued. Plenty of decisions were made, but they were made in an informal way, which meant that they took as little time as possible.

Another factor which got the project off the ground so quickly was the minimal amount of people involved. At the initial stage in the project, there were just the two people involved. By the time the first demo was ready, we had five people "in the know" about this system, but only three people actually contributing ideas. This has continued until the present point, with three people actively working on the development and implementation of this system. This allows us to move as quickly as possible.

Further Reading

Hopefully you can apply some of the tactics used in this project to your own endeavours, to speed them up. For further reading, I suggest the book "Getting Real" by 37signals - I have found quite a few of the ideas in this small book to be useful, and so practical that I can use them myself!

Our next article will be about how we defined a common denominator for managing users of the system, and used that as the cornerstone of our code.