Teaching Web Applications and Arguing to Let Students Loose

As I mentioned recently, I've come to the end of my latest teaching course: a semester in Web Applications at one of Berlin's universities (see my previous post for more details). As well as theory, there was a practical element to the course, where the students divided into teams to produce their own web apps from scratch. I've done similar things before, but in those cases I was forced by circumstance to assign the students to work on a specific project. What I want to do here is briefly explain how much more a successful strategy it is (IMHO) to allow students to be largely free to determine the course of their work themselves.

The Course

The Web Applications course was eight sessions delivered bi-weekly over a single semester. Each session consisted of a lecture followed by practical work, where the students either worked on an assignment I had given them or developed their web app. By the second session, the students had pretty much settled into their teams of 2 or 3 members. (That was one thing I did enforce by the way. 2-3 students per team works really well, and I would not recommend going above 3.) The university infrastructure was relatively impressive and provided hosting software, databases, project management tools etc. Use of this infrastructure was optiona.

The Choices

When it came to deciding what application the students should develop, I allowed them to choose both their own topic and which technology they would use to implement it. I figured:

  • When you give someone the freedom to choose their own topic, they're much more likely to end up caring strongly for it, invest in it and make a good job of it.  Assigning them something risks sapping their creativity because they may have little or no interest in the topic.
  • Nevertheless, I gave about a half dozen example topics. This gave both a feel for the kind of scope I was looking for and also some ideas to any teams who couldn't come up with their own ideas. Using one of these examples had no effect on the final grade. Students were marked on their ability to understand the course material, put it into practice, write reports and present it to their peers; there were no prizes for originality.
  • Allowing the students to choose their own implementation technologies was also a means to maximise their creativity. Programming languages, frameworks, operating systems... these are all 'religious' issues and every programmer has their own preferences. Enforcing the use of the university-maintained PHP/MySQL servers would have been a good way to create quite a few frustrated students who felt stifled and uninspired by the choice of tools. Of course, I made sure to verify all technology choices, in case a team wanted to use a completely unfamiliar or inappropriate technology.
  • Finally, it was important for students to experience first-hand the consequences of their own choices. There are risks when embarking on a software development project:
    • Have we bitten off more than we can chew by choosing this topic?
    • Are we making a mistake choosing a cool but unfamiliar language?
    • Have we chosen a poor programming framework?
    • Have we picked the right ways of working together?
    • Is the infrastructure we're using sufficient?
  • Getting some of these wrong can lead to a project 'failing'. Now, there's a lot to be said for failure as a learning method. And also, what better time is there to make a mistake than in your formative/educational years? It's a more forgiving time than when you have a career, that's for certain. To be sure, some choices the students made wouldn't work out, and, as long as they subsequently understood why, they serve as valuable lessons.


As it went, the choices made by the students were varied and interesting. PHP was the most popular choice (roughly half the groups chose it), but other technologies like Ruby on Rails, Grails, .NET and JavaScript frameworks were also used. Furthermore, while few groups used the University's hosting services, many elected to arrange their own. Clearly, they knew their own minds.

What I found particularly impressive, even though I wasn't evaluating the students on this, was their originality and imagination. There's clearly still a wealth of ideas for web-based applications out there if my students were a fair sample of the programming population.

I'll leave you with a selection of the ideas to see for yourself (links correct at time of writing):

  • Crowdstory: An application for the community-driven writing of stories. Allows voting and discussion on sections of the story.
  • Div@: A place where you can discuss sites you disapprove of without linking to them (and thus giving them traffic) -- instead, the app samples the target site as screenshots.
  • MoPad: A mobile game controller system. Multiplayer games are hosted in the browser and you use your mobile device (e.g. smartphone, tablet) as the controller.
  • Tourathon: An app which generates a tour of specific types of places between waypoints. For example, you can go on a pub crawl by specifying two points and requesting pubs/bars between them; a route which takes you along the pubs is generated. Integrates with Google Maps and Facebook (so you can share tours with friends).
  • Yum.is: Taking photos of your food is a popular pastime. This app allows you to upload your food photos to the site and link them with places they're served on Google Maps. You can also use GPS positioning to get a selection of photos (or yums as they're known here) in your area.



Leave a Reply

Your email address will not be published. Required fields are marked *