Chapter 4. My First Site

There are some brilliant, yet ecologically unsound car advertisements where you can almost breathe the fresh air and feel the water splattering across the side window as you traverse through muddy nature in its full glory. You may get that same feeling of unrestricted freedom and flexibility when you create a site with Sakai for the first time. The original planners have designed site creation for minimum fuss and lots of ad hoc interaction. Tools such as Wiki, Resources, Announcements, and Podcasts are quite intuitive and enable researchers, teaching professionals, and interest groups to get together and do work online with little Sakai-orientated learning effort.

This chapter explains how you can create a project or course site without publishing it immediately. Avoiding publishing until the last minute enables you to experiment with the toolset balance without others seeing your noble failures. It also enables you to place your content and nudge it until perfection strikes.

A big difference between the demo and production-orientated servers is that, in the demo version of Sakai, any user can create sites. For sites in many large enterprise-wide deployments, users need to request their sites through a service desk or automated external page. Another significant difference is that by default, the demo does not have its e-mail subsystem configured and you cannot trigger tools such as the e-mail archive and general e-mail notifications by your actions. This is a good thing; I would not like you to be accidentally involved in mass e-mailing unsuspecting populations. If you are learning within a production server, please remember to not use accounts with real users behind them for testing. Otherwise, expect some interesting feedback and exercises in running and then limping.

There are two types of users in a project site; members, who can gain access and interact with each other via selected tools, and maintainers of the site. Maintainers can configure tools, as well as modify the membership, properties, and content of the newly-created site. If you create a site, then you are by default the site's maintainer. Course sites are the main type of site used for learning in the majority of Sakai deployments. The course site expresses the traditional educational structure found in most universities and higher educational establishments. Course sites differ from project sites in a number of ways. The first is that by default, there are three roles in a course site, each with different permissions. The second difference is that a number of tools, such as Assignments, Test & Quizzes, and Gradebook, interact with each other, and the third is that the administrator can subdivide courses into sections.

The three roles in a course site are instructor, teaching assistant, and student. The student has the fewest powers, but still gets to use most of the tools. The teaching assistant has sufficient permissions to be able to take over some of the regular chores from the instructor; they can moderate forums and send announcements to the site members. The instructor has the most control and sets the structure and atmosphere for the whole site.

Below is a diagram of a simple course. The course has three sections; two are lectures, and one is a lab. Depending on how you wish to manage your site, each section can have an unlimited number of members or a more limited set.

Groups are sets of users. Sections are groups that have extra features and related data, such as the ability to add scheduling information, the name of the section, and whether membership is allowed for the whole course. The definition of sections is difficult to understand, but the extra features of sections, compared to groups, give programmers what they need to build a complex course structure that matches the needs of many universities. For example, sections can be used to help organize labs or lectures.

Unlike groups, each section has a teaching assistant associated with it. Further, the instructor defines the membership of groups, but not always of sections. Depending on how you set the course up, you can specify a limit on the number of students included in each section and whether the students can opt in or out of the section. To add to the complexity, site and section information can be transferred automatically from the students' administration information systems.

Most organizations use student administration data to pre-populate sites with student rosters, course names, and section divisions. As a result, these choices may be narrowed when they create a course site. In a first-time deployment, architects normally hook up Sakai to the local students' administration system, and a direct feed provides course data either on demand or automatically as the academic year progresses. However, the students' administration system may not be able to define all the sections and courses that the teachers expect in a year. In these cases, manually adding the information may be necessary.