Web Application Design Class and Meteor

The first semester of my web design and programming course was an overview of HTML, CSS, Javascript, and jQuery. The end goal is to get students piecing together their own web applications using the Meteor framework. I don’t know how sophisticated these will be. The prototypes they are putting together, however, as well as the questions they are asking, show that they are ready for Meteor.

Given that few of my students have programmed before this class, there are some gaps in knowledge that I’ll need to think through. The one thing I didn’t want to do in this class was declare that students need to go through a full CS course before being able to touch this material. The value of a framework like Meteor is the ease with which anyone can piece together an application. The most consistent theme in this course has been that getting students working with code and troubleshooting upfront is much more productive than a lecture on for-loops. My model has been to have students take a piece of code, figure out what it does, and then hack or tweak it to do something different. As students get more experience, they become more comfortable writing code from scratch to complete a task.

Despite knowing this about my group, I almost didn’t do continue the model in exactly this way after the winter break. I was going to do a unit on classes and methods, but in my brainstorming how to do this, I realized that the better approach would be to look at database queries and MongoDB. The concepts of properties would be obvious in the way Mongo stores information, so it would then be easy to talk about the concept of objects once students were interacting with the database. Again, this became more ‘Application first, theory second.’

This also meant I had another opportunity to bring up fundamentals of computational thinking. I opened up the lesson by having students look at a screen sized list of all of the ninth grade students and some of the information stored by the school. I asked them questions like this:

• How many students in Mr. S’s advisory are girls?
• How many students in the red or blue house are in Mrs. M’s advisory?
• Do any students share the same birthday?

They didn’t mind this too much, but there were some different answers to the questions that came from counting by hand. It was fairly mindless work and none of them were too bothered by my requests to do it with this data set. Then I told them that we were going to do the same with the list of 160 students in the entire upper school.

Groans.

They didn’t ask it because they know me at this point, so I told them that there was, of course, a better way. I taught them some Mongo queries using a sandboxed collection consisting of student information from the school. I then set them loose with a list of questions about a fictional database of people that I generated and posted at http://citizens.meteor.com. (The names for the collection came from the cast list for the most recent Hobbit movie. A fun side project, by the way.) A subsequent lesson was about sorting, limiting, and interacting with an array of returned documents, and students handled it well. We did some quick demonstrations of dot notation, but I didn’t make a big deal out of it.

In the next class, I gave students the following prompt:

Mr. Weinberg wants to survey students on their favorite ice cream flavor. He wants to be able to sort the results by grade, gender, and house. Sketch the layout of a web form he could use to collect this information.

Their sketches were good fun:

I asked them to then work backwards from their database experience: What would a single document in the database containing the results of this survey look like? They were coming up with sample properties and values. I then showed them how these values could be captured from the form elements using jQuery.

Then came the Meteor magic.

I took the web form and pasted it into a template. I took the jQuery calls and put them in an event handler for the template. I added a line to create a collection, made another quick template to show results, and then made a helper to fill that template with the entries in the database. One last thing I put in to prevent rapid submissions – calls to clear out all of the form elements after the database insert.

I typed meteor in the terminal, fixed one error, and then the app was live. I had students go to my IP address and the form popped up. The page started filling with survey results as students realized they could interact with the page. These were initially full submissions, but soon after, lines with empty values showed up as students realized that they could add garbage data and submit them really quickly. I told some of the students that were doing this that people would be doing that with their apps soon, so there would need to be a way to handle it in their apps.

I then set students off in groups to do this same process with different web applications along the lines of the one I used to start class. It was incredibly fun hearing them talk about how they were going to move forward, including a number of new web page sketches. I gave them more concepts to work from, including an after school activities form and a web portal through which students could tell school administration that they were going to be late to school. I asked them to write down potential database queries to help find important information quickly. The really impressive part came when they had ideas for what they wanted to program. One student suggested a database of sports scores. Another, an online store.

The class was abuzz with ideas for what was possible. I knew that I had to show students how to get these into Meteor the next class, in the easiest way possible.

Enter Meteorpad. I made a streamlined form with instructions on how to take the web forms they had designed and get them into a template with as few steps as possible. The students don’t currently have terminal access on their Macbooks, so I can’t get them to run Meteor locally.

You can check out the MeteorPad template I gave them here:
here…

…and the full set of instructions for adapting their code to it here.

They followed the instructions, and by the end of the class, most had their own versions working. The students then started tweaking them to see what they could do to make it work as they wanted.

Today, my students were going from an idea concept to coding their own apps to getting these prototypes online. Yes, they were primitive, lacked error handling, styling, and had typos. No, the students didn’t have much understanding of the differences between helpers and event handlers. That is just fine. It’s only January! I originally thought we’d get to this point by the end of the year, so this is a great point to be at right now.

I’m can now help students take their ideas and turn them into working prototypes. These students know how to look up code to do what they want to do. They’ve happened upon W3Schools web pages and StackOverflow, and while they are generally overwhelmed by what they find there, they know how to ask me the right questions about what they see. This was a great way to end a busy week.

Have a great weekend, everyone!