Designing E-Learning 3.0 in gRSShopper - 1

---

E-Learning 3.0 - Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6 - Part 7 - Part 8 - Part 9 - Part 10 - Part 11 - Part 12 - Part 13

---

One of the fun things about working with software I wrote myself is that I get to try new things. For example, instead of creating a course simply by filling in boxes in predefined forms, I can think about the structure and format ahead of time and design it exactly how I want.

It would help if gRSShopper were a finished application. But it isn't, so from time to time I have to stop and code the right bits. This is a process that will probably never end. But it's far enough along now I can have some fun doing it.

Installing gRSShopper

gRSShopper is a web application that can be big and complex and difficult to learn. On the other hand, the completed version of the application with all the course elements created will be very easy to use and to learn. But I need to build all this. That's what these posts will address, as well as showing you how I'll design and create my course.

Until now, installing gRSShopper has been the hardest part of the process. But now it's pretty straightforward. I've created a one-hour video that shows me in real time installing gRSShopper at Reclaim Hosting.

Here's the video: https://www.youtube.com/watch?v=T8PFEEQJ8kw

Below, we'll begin by talking about the overall design, then we'll look at how to start creating that in gRSShopper. If you want more background before we get started, here's the gRSShopper website with instruction on some of the major elements.

The Overall Course Structure

I've decided to be really conservative here and set up the course as a ten-week (or so) course covering a series of topics. I've also decided that I want it to be able to export the course if I need to, so it needs to be reasonably consistent with other courses.

Ah, but what to call the pieces. I did a bit of searching around and determined that the overall structure is pretty common:

- course
      - modules - an array of individual units of instruction
      - sections - an array of individual offerings of the course

Like this:

Figure 1. From the University of Sussex - yes I know it's from 2012 but we can manage with that. I've looked at some more recent schemas and there isn't much difference between then and now.

So that's what I'll do. We'll only have one section for now (and if I offer it again in 2019 we'll have two sections, etc.). I already have a 'course' table in gRSShopper from previous experiments, so I'll make a 'module' table and a 'section' table.

In gRSShopper you make a table by selecting Admin window (the gear icon, blue arrow), selecting the database tab (circled in blue) and then entering the name of the table in the field (highlighted in yellow). I'm making a module table so I typed 'module' in the form.

Figure 2. Add a table in gRSShopper.

This creates the table and gives me an option to edit the table, which I click. This take me to the Form Editor. It's just a big empty field, though, and I realize I haven't created any instructions for it. Um, OK then. First things first, I'll create a new page and create some instructions.

(Pause) OK, done that. Here are the instructions.

(Pause) Then I decided to make this a generalized help system for gRSShopper. Skip over this part if you're not interested. This is what I did:
- first, using the Form Editor, I created a new field for forms, called 'form_help', and then I added a 'form_help' field in the Form itself (read the documentation on the form editor for this (heh, recursion is recursive).
- then in grsshopper.pl, in main_window(), I added a default tab 'Help' if a value for 'form_help' exists for the form being displayed in the window.
- then I created a function called tab_Help() that looks for a page in the database with the same page_location as defined in form_help.
- the I added some script that would try to fetch the page from grsshopper.downes.ca if it's not available locally (I should change this to an API in the future so you don't get the header and index, but it works for now)

OK, back to building a module table. Let's define what I want in a module. This XML schema is a good starting point (remember, I can always add or change elements later if I want).

Figure 3. Sorry about the image of text; Blogger insisted on interpreting it as HTML.

You might wonder why so many of these are 'int' fields (or 'integers'). This has to do with database normal form (DNF). The idea here is that you don't want to type the same information into a database in two different locations. So, eg., you wouldn't put the name of a 'groupmode' into the module, you would create a separate 'groupmode' table, put the names in there, and point to the index of the groupmode you want to use. This make a lot of sense, but it also results in long convoluted queries, so while I agree with the idea of DNF, I went a different way, associating everything with everything else using a graph.

Many of these tables are things that I don't deal with (like 'groupmode' so I'll ignore them. But the others are keys from important tables. For example, at the top of the table are fields for 'course' and 'instance'.Any time we have a field like that, we'll call it a 'keylist', and then in our form, we can easily link to the other table using a 'keylist' input (I do the same thing when I list the 'author' of a post).

We're looking at something like this:

Figure 4. Module Definition. From Moodle.org - and yes I know it's out of date; it's just an example.

Note: I'm using a lot of stuff from Moodle here, but we need to keep in mind that a lot of stuff in Moodle is presented very differently, so for example you can have different course 'formats' such as weeks or topics' or whatever. A lot of this is over-engineering, in my view. We'll use 'Modules', we'll think of them as course components, and not worry about plug-ins or any such thing.

I think I can reduce all of this to its essence:

     name="id" type="int"
     name="course" type="int"
     name="section" type="int"
     name="added" type="int"
     name="score" type="int"
     name="visible" type="int"

Translating that to the gRSShopper forms format (I don't need to include ID because everything is given an id, creation date, and creator ID by default):

     tab:Edit;
     title,varchar,256;
     author,keylist;
     course,keylist;
     description,wysihtml5,40x20;
     tab:Upload;
     file,file;

I decided I didn't really need 'score' or 'visible', but I might add them later. I decided every module should have a description. I also allowed files to be uploaded and associated with the module. What's missing?

Minimally, each module should have one or more event. So I'll add that. I'll also associate the guests (as 'authors') with the module. And for external resources, I'll associate link posts with it. There might be more, but that's a start.

        tab:Edit;
        title,varchar,256;
        author,keylist;
        course,keylist;
        description,wysihtml5,40x20; 
        event,keylist; 
        author,keylist;  
        tab:Upload;
        file,file;
        tab: Resources;
        post,keylist;

Here it is in the form editor:

Figure 5. Defining the module in the form editor.

Now I need to add these to the database (ideally they'd be added automatically when I edited the form in the Form Editor, but that proved to be way too sketchy, so I do it this way). So I click on the 'Table' tab in the Form Editor and add the items. Notice that this time I use the full name of the variables. Also notice that I don't add the names of the external tables (ie., the 'keylist' variables) in the form.

Figure 6. Defining the module table.

Notice how much simpler this table is. I'm not saying it's better - maybe we really do need all that other stuff. But this works for me. Also notice that I decided to add a module_number field, to make it easier to sort modules. (Couple of bugs: the 'delete' icon is broken, also, when I add a new field it's supposed to reload the table, but the command is not recognized by api.cgi so I'm having to open the Form Editor each time. Annoying. On the list to be fixed.)

Now to make a module. (I notice that 'Module' didn't show up in the 'Make' tab on the left hand pane. That's a bug; the pane should have reloaded when I added a new thing to list. Reloading gRSShopper fixed it, but it's annoying).

Here we are in the module editor.

Figure 7. Module editor.

This is the form I just finished defining. Notice that there tabs for Edit, Resources and Upload, just as defined in the Form Editor.

Now I'll go back to the Course Editor (I'll just click on 'Edit' next to the name of the course):

Figure 8. Course Editor

I'll add the rest of my new modules by typing their names in the 'Add Module' field. Then I'll list the modules in the lest hand pane by clicking on 'Make' and then 'List' Mocules (really, the left hand pane should reload automatically as I enter new modules; that's in the to-do list). gRSShopper will create the new modules automatically as I add them to the course; I can edit them one by one to fill in the details.

Figure 9. All Modules

And that's where I'll finish this article. But, one note first.

You might think that this is a lot of work just to set up a course with some modules. But my point here isn't to show that you have to do this, it's to show that you can do this. You're not locked in to the way an LMS defines a course. You define it yourself.

Also, now that I've created this course and these modules, they're done. You don't need to do all this. Anyone with their own gRSShopper instance can import them and use this as a template to create their own course. I'll show more about this in a future post.