If you use Plone for your school's public web presence or intranet, it might also make sense to use it for your courses:
Courses can interact naturally with other Plone content. For example, an event listing can combine exams and athletics.
Plone is more customizable than commercial offerings like WebCT or Blackboard, and there's no worry about another company swallowing it.
Plone can save hundreds of thousands of dollars per year over a commercial course management system.
Consistent navigation and one-stop search come for free, avoiding the need to cobble together disparate systems with arcane web server rewrite rules.
Plone brings flexible access control and workflow, freedom from the webmaster bottleneck, and the other general advantages listed in the Preface.
There isn't a lot of support specifically for doing course management in Plone. However, there is plenty of overlap between course management and the more general content management at which Plone excels. With creative application of content types, Plone can make a respectable showing against some of the most popular course management packages: you get events, discussion forums, custom forms for online testing, assignment submission, and a flexible permission system for enabling collaboration, along with the integration and consistency advantages of a single system.
This chapter suggests a flexible strategy for representing courses using Plone's built-in content types — news items, collections, and events — all without a single line of code. We'll put course materials online, publish assignments and announcements, and lay the groundwork for add-ons like blogs, forums, and other third-party products covered in later chapters. Following the iterative philosophy of beginning with the simplest approach that adds value, we'll keep away from markup and stylesheet tweaks for now; what we build will be functional and reasonably attractive, so you can put the basics into production fast, returning later to sand off the rough edges with a third-party theme or a bit of custom coding.
Finally, while the following strategies are one set of working practices, don't be afraid to mold them to your school's needs. Customization is Plone's strong suit!
Our first order of business is deciding where to store courses. Instructors using Plone on their own sometimes create an entire Plone site for each course. While this lets them choose add-on products on a per-course basis and offers some isolation should a catastrophe occur, it carries two important disadvantages:
A maintenance burden. Unless you are adept at writing scripts to automate it, upgrading and editing redundant settings on several Plone sites takes time and invites error.
An integration challenge. Sharing information among Plone sites is tricky. By using a single site, you get integrated navigation and search without having to cobble together bridging solutions using XML—RPC or RSS.
Thus, we recommend keeping all your courses (and whatever else you can get away with politically) in a single Plone site. We will keep the courses in a special kind of folder called a large folder.
Note
Folders versus Large Folders
In Plone 3, there are two main types of folders— folders and large folders— each with its own advantages.
Folders are best for holding less than about fifty items. Their contents can be manually ordered through drag-and-drop and appear beneath their enclosing folder in Navigation portlets. However, whenever a folder is loaded into memory (unpickled, in Python parlance), all its contents are loaded as well. This takes up a lot of RAM and causes slowdowns if folders are overpopulated. In addition, since folders store all their contents in a single Python "tuple", they are a prime source of conflict errors in Zope's database: temporary errors which happen whenever two transactions try to write to the same object at once. In addition to adding noise to your error logs, these hurt performance, since they require the entire transaction — everything done in response to the HTTP request — to be redone.
Large folders, on the other hand, are optimized to hold thousands of items, storing their contents in a B-tree, a data structure that supports incremental loading and therefore needs less RAM and disk access. B-trees also provide finer-grained locking, making for fewer conflict errors. The downside is that their contents cannot be manually ordered. Also, for cosmetic reasons, their contents aren't listed in Navigation portlets (though this can be changed in the portal_types
tool in the ZMI).
A note about the future
In Plone 4, both folder types will be subsumed by a hybrid that combines the best attributes of each. Called plone.folder
, this package is, as of October 2009, available separately for Plone 3 at beta quality. If you choose to use it now, migration to the Plone 4 version will likely be smooth.
Large folders are not available from the Add new menu (addable) out of the box. To enable them...
1. Go to Site Setup → Zope Management Interface, colloquially known as "the ZMI." This is an under-the-hood view for tweaking infrequently used settings and performing advanced tasks.
2. Go to portal_types → Large Plone Folder, where you can control the behavior of the Large Folder type within the Plone site.
3. Turn on Implicitly addable, and save. Large folders are can now be added throughout the site.
Once you are finished adding large folders, it's a good idea to revoke their addability to prevent user confusion. Otherwise, users will see them in their Add menus.
Next, create a top-level large folder for holding courses:
1. Navigate back to the top level of your Plone site (no longer in the ZMI), and choose Add new → Large Folder. Title it "Courses," and save. (Now is a great time to return to
portal_types
and turn off large folder addability.)Although large folders are supposedly designed to hold thousands of items,their views are unpaginated: they are happy to display all those thousands of items on one gigantic page. Improving this behavior is on the docket for a future version of Plone: http://dev.plone.org/plone/ticket/9544. In the meantime, we can take advantage of a little trick using collections to add pagination to the folder:
2. Inside the Courses folder, choose Add new → Collection. Title it "Courses" like its surrounding folder, so the name of the folder and the title on its default page are consistent. Save it.
3. On the collection's Criteria tab, add a relative Location criterion, and leave.. (the default) as its Relative path. Search Sub-Folders should remain unchecked; we want to pull in only the direct contents of the Courses folder.
4. Under Set Sort Order, select Title to make courses appear in alphabetical order.
5. Go back to the collection's View tab, and choose Display → Summary view. This keeps users from seeing distracting author information and modification dates.
6. On the collection's Edit → Dates tab, set the Publishing Date far in the future. This ugly but effective trick keeps the collection from showing up in the folder listing for students. You will still see it, however, since you created it.
7. Finally, navigate back to the Courses folder, and set the collection as its default view: choose Display → Select a content item as default view, and choose the Courses collection.
Congratulations! Perhaps that seemed a lot of work for an empty folder, but pagination and efficient storage are insurance against being woken in the middle of the night when your server chokes trying to render too many 1,000-course pages. (It also means fewer servers to buy, a significant monetary saving for your institution.)
Incidentally, you can feel free to add additional levels of organization within your Courses folder at this point: for example, grouping courses by subject or level. Just remember to revoke large folder addability when you're done.