Termipankki
  1. A
    1. Admin Site
  2. C
    1. Cache
    2. Checking Daemon
      System Exercises
    3. Celery Worker →
      Checking Daemon
    4. Checker Backend →
      Checking Daemon
    5. Content Graph
      Courses Content
    6. Content Page
      Content
    7. Context Node
      Concept
    8. Course
      Courses
    9. Course Completion
    10. Course Instance
      Courses
    11. Course Prefix
      Courses System
  3. E
    1. Embedded Content
      Content Exercises
    2. Enrollment
      Courses System
  4. F
    1. Feedback
      Content Feedback
    2. File
      Media
    3. File Upload Exercise
      Exercises
    4. Front Page
      Courses Content
  5. H
    1. Hint
      Exercises
  6. I
    1. Instance →
      Course Instance
    2. Image
      Media
  7. L
    1. Lecture Page
      Content
    2. Legacy Checker
  8. M
    1. Media File →
      File
    2. Markup
      Content
    3. Media
      Media
  9. P
    1. Primary Instance
    2. PySenpai
  10. R
    1. Regex
    2. Repeated Exercise Generator
    3. Responsible Teacher
      Courses System
    4. Revision
      System
  11. S
    1. Scoring Group
    2. Slug
      System
    3. Staff
      Courses System
    4. Staff Mode
    5. Statistics
      Exercises
    6. Student Group
  12. T
    1. Teacher Toolbox
      System
    2. Term
      Content
    3. Textfield Exercise
    4. Triggerable Highlight
      Exercises
Ratkaistu: / tehtävää

Managing Your Course Instance

Course instance
is the primary unit of teaching in Lovelace. In typical use cases, a single course instance corresponds to a single time span the course is run (e.g. semester). Course instance management includes the following topics:
The last part is a wider topic that will be handled in more detail later in this document. Before that, we will go through the various fields in the course instance settings form.
In order to see the various staff controls, you must first enable staff mode from the top navigation bar, next to the language selector. This mode stays on until you either click on it again to disable it, or close the browser tab.

Course Instance Settings Form

This is the primary form where most of the general course setting information can be added and/or modified. Some fields are translated, and in the current version of Lovelace you will be editing the field that matches your current site language. This will likely change in a future version to use forms that have fields for all enabled languages.
Instance settings form. Fields will be explained below in numbered order.

1. Instance Name

This is the displayed name of your course instance. It is typically course name + some context information, e.g. "My Awesome Course Spring 2023". Course instance names are unique across the entire system. Furthemore, the URL of your course instance is based on the slugified form of this name. Unlike content pages that never change their slug once created, course instance slug will be updated every time the name is changed. In other words, care must be taken if changing the name while it is in active use. However, it is worth noting that if this is the
primary instance
then the system will prioritize using primary URLs where your course instance name is not part of the URL.

2. Instance Tags

The primary use of instance tags is to display extra context information on the system front page about this particular course instance. Their main intended use case is to help students pick the correct instance for courses that have multiple parellel instances, but they can also provide some additional hints about the level of the material etc.
Example showing two parallel instances with different tags
This field is a text field that is split from commas into individual tags for display. This field is also translated.

3. Email

This field should have the contact email for the course instance. This should be either the email address of the main responsible teacher of the course, or an email list address that reaches the entire staff. Lovelace will send error reports to this email address when there are crashes in
backend checkers
. While not mandatory, this field is highly recommended for any course that uses the checking backend in any form.

4. Start and End Dates

These two fields take ISO datetime values (YYYY-MM-DD HH:MM:SS) and they will determine the window during which this course instance is active. When an instance is active, it will be displayed in the system front page, and students can enroll to it. Note that it does not control submitting answers to the course, so it is more akin to registration period. Students who have enrolled to the course instance can still access it after the end date.

5. Primary Instance

Checking this box will make the course instance the
primary instance
of this course. The main purpose of this feature is to give you a permanent URL that is not dependent on the course instance name, and will instead always lead to the primary instance. Such an URL can be distributed easily without worrying about its expiration. This checkbox controls which instance this permanent URL will lead to. If there are no parallel course instances, simply check this box for the latest version. This check will automatically be cleared from other instances when it is set in one of them.

6. Max Group Size

This field determines the maximum size of
student groups
in the course. If empty, groups cannot be formed by students. If set to a number, students are able to form groups up to that size. The life-time of a student group is intended to be the entire course duration. If your implementation has a need for ad hoc groups, it is not currently supported by the system and you will have to manage them elsewhere.

7. Manual Acceptance

When students enroll to a course in Lovelace, they will either be automatically accepted, or they will have to apply to enroll. If this field is checked, enrollments need to be approved by the teacher from the enrollments manager (see: -- WARNING: BROKEN LINK --managing enrollments guide).

8. Welcome Email

If this field has content, the system will automatically send it as an email to a student's registered email address when they enroll to the course (or when their enrollment is accepted). The email will be sent with [your-course]-notices@[lovelace-server] as the sender address, and your course instance's contact email as the reply-to address. The main use of this field is to give students additional information, and links that you might not want to show publicly on the site.
This field is translated, and the content to be sent is determined by the student's selected language when they enroll.

9. License Information

These fields can be filled to display license information about the course instance contents at the bottom of the page. The first field is the license name (e.g. CC-BY-SA), and the second field is the URL that contains the license text. This will be displayed as a link at the bottom of the page.
Example license displayed at the bottom of the page
The current implementation assumes that all of your content is under the same license. If there are exceptions, you should notify about them on the page itself. We encourage the use of Creative Commons licenses to keep education readily available for everyone.

10. Front Page

This allows you to select a front page for your course, from existing pages that you have access to. The selected page's contents will be displayed underneath the table of contents on your course's front page. The frontt page should contain mostly generic information about the course. We have discovered that students do not always scroll down to it, and information there might be go unread by them. Putting really important information like course completion rules into a separate, accurately named page in the table of contents has been more successful.

Grade Thresholds Form

This form allows you to specify point thresholds for automatic grading. It is a relatively simple system where you can add grades and the minimum score for each. Grades can be any short strings to account for different grading systems. When using
course completion
to calculate grades, each student's line will display the highest grade they can achieve with their current points total.
In addition, you can display the grade thresholds in content pages. This allows you to let students know what the thresholds are without worrying about remembering to update pages if you change the thresholds. It is however worth noting that these references are not tracked, so the system cannot currently refresh cache automatically for pages that display the thresholds. Remember to
refresh cache
on your grading information page after changing these thresholds. Refer to the -- WARNING: BROKEN LINK --markup guide on how to include grade thresholds in pages.

Table of Contents Editing

The staff controls in the table of contents allow you to add content pages to your course, and organize them into a clean table of contents where pages can have sub-pages. It also allows you to configure the
context node
for each page. The context node determines rules for displaying the content, and answering tasks in that content.
Context node control buttons, from left to right: move, edit settings, unlink, add new after this

Adding Content

The green plus button adds a new page. The page's placement depends on which button you press. If you press the button from the controls of an existing page, the new page will be added either after that page on the same level, or as its sub-page. The button on top of the table of contents adds a new page to the beginning. Please refer to -- WARNING: BROKEN LINK --the content settings section of this document for information about what different fields in the form mean.

Unlinking Content

You can unlink content from the course by pressing the unlink button. This is not a delete. It will simply unassociate the content from this course instance. The page can no longer be viewed as part of this course instance, but if it was linked to a past instance, it can still be accessed that way. Deletion of pages is only possible from the
admin site
and is generally discouraged. If a page is not referred to from any course instance, it will not be viewable, and is effectively soft-deleted.

Moving Content

You can reorganize course contents by moving. To initiate a move, click and hold the left mouse button on the move button of the page you want to move. Doing this will display landing markers on other pages. Drag the move button into the landing marker of your choice to move the content. These markers will place the content either above or below the target content, or as its sub-page.
Example of move landing markers. From left to right: above, as sub-page, after

Content Settings

Content settings allow you to specify rules about displaying content, and answering tasks contained within it. These settings are saved on the
context node
that associate the content with the course instance. This means that different course instances can have different settings for the same content. There are two version of the form with small enough differences that they are represented here with only one example. When adding new content, the form has two extra fields that are not present when editing settings later.
Content settings form when adding content. Fields will be explaned below in numbered order

1. Viewing Settings

The first checkbox determines whether the content is shown in the course table of contents for students. When viewing the table of contents as a staff member, any pages that are not visible to students will have purple background. While in this state, content can only be viewed by course staff members.
The second checkbox allows you to make pages that cannot be viewed unless the viewer is enrolled to the course (or a staff member). Generally keeping study materials open to the public is encouraged, but the option to lock pages behind enrollment exists for pages that have content you do not want to expose publicly. When viewing the table of contents as a staff member, a black lock icon will be displayed in front of pages that have been locked behind enrollment. For viewers who are not enrolled, these pages will not be visible in the table of contents.

2. Scoring Settings

This group of settings affects scoring of tasks on the page. The first field determines whether any tasks on the page contribute to course grade or not. It is largely useful for pages that contain surveys you want students to answer, but do not want them to show up in grading results. Pages that are not included in scoring do not affect students' total points regardless of whether tasks on the page have point values or not, and they also are not displayed in the summary page when viewing course completion or a single student's completion records.
Weight multiplier is used to do more or less what you'd expect from the name. It is a weight that is applied to the raw scores of tasks on the page when calculating the students' total points for grading. This field supports up to two decimal spaces.
Pages can be grouped together into
scoring groups
to create mutually alternative assignments. This is achieved by giving the same group identifier to all pages that are supposed to be alternatives to each other. For instance, if your course has three chances to take an online exam, and only highest result is used, you can group the exam pages together by using e.g. my-course-exam as the value of this field.

3. Deadline Settings

These settings allow you to set a deadline for tasks on the page, and also configure how students are penalized for submitting tasks late. The deadline field takes an ISO datetime string (YYYY-MM-DD HH:MMS:SS). The second field takes a mathematical formula written as a Python format string with the following variables available as placeholders.
Practical examples values:

4. Freeze Prevention

This checkbox setting is mostly for very specific use cases. When you archive the course instance, any pages that have been configured to not be frozen will remain in the most recent version. This means any edits done to those pages after the archiving will be visible in the archived course instance. This is mostly relevant if you need to make something like a meeting calendar available for students who are completing a past course instance late. For most scenarios it's best to leave this unset.

5. New Page Settings

These two settings are only present when adding a new page. The first field makes the page a sub-page of the page where the add page button was clicked. If not set, the new page will be placed after that page on the same level; if set it will be placed as its child with an extra level of indetation. The second field allows you to specify a name when adding a new empty page. The name is provided in the default language, and the page's
slug
will be generated from it. When choosing a name, keep in mind that page names are unique across the system.

6. Page Selector

This select field allows you to select what content to show in the page. It allows you to choose any page that you can access (see access model for more details). There aren't a lot of situations where you would want to change this value, but it can be relevant when making parallel instances.
?
Django Admin Site is Django's default method for managing content. Teachers in Lovelace have access to the admin site where they can see all pages etc. that they have access to, and they can be edited from there. Compared to Lovelace's own editing tools, the admin site is a more direct mapping to values stored in the database. As Lovelace development progresses, the need to use the admin site diminishes.
In the context of using Lovelace as a teacher, the term Cache refers to the cache that holds pre-rendered HTML of your content pages. When you edit a page, this cache will be refreshed. This is the only time when the markup of a page is actually read and rendered - when users access the page, it will simply show the already rendered content that is stored in cache. In most scnearios the caching is invisible to users. However, there are still some edge cases where a change does not automatically trigger a cache refresh. For these scenarios teachers have access to the cache regeneration tools that can be executed on individual pages, or the whole course. If you know what page is affected, please use the page specific tool.
The checking daemon is a separate multi-threaded program that is invoked whenever Lovelace needs to execute code on the command line. The most common use case is to evaluate student programs by running checking programs. When a task is sent to the checker daemon, copies of all required files are put into a temporary directory where the test will then run. The daemon also does necessary security operations to prevent malicious code from doing any actual harm.
Content graphs are objects that connect content pages to a course instance's table of contents. Content graphs have several context attributes which define how the content is linked to this particular course instance. A content graph's ordinal number and parent node affect how it is displayed in the table of contents. You can also set a deadline which will be applied to all exercises contained within the linked content page. Content graphs also define which revision of the content to show - this is used when courses are archived.
In Lovelace, content page refers to learning objects that have text content written using a markup language. All types of content pages are treated similarly inside the system and they are interchangeable. Content pages include lecture pages, and all exercise types.
Context nodes are used for connecting various pieces of content to course instances in Lovelace. In addition to defining what content to include, they also define context information that can change how the content is treated. The most notable context nodes are index nodes that form the table of contents of a course instance, and embed nodes that are generated from embed markups on pages. Terms, media files, images etc. also have their own context nodes.
  1. Kuvaus
  2. Relations
In Lovelace, course refers to an abstract root course, not any specific instance of instruction. Courses are used for tying together actual instance of instruction (called course instances in Lovelace). In that sense they are like courses in the study guide, while course instances are like courses in WebOodi. The most important attrbutes of a course are its responsible teacher and its staff group - these define which users have access to edit content that is linked to the course.
Course Completion is a teacher tool for viewing students' progress, scores, and grades. It is accessed from the top right menu. By default the view only shows a table with student names and a button to view their individual progress. Calculation of scores and grades can be performed by pressing the button above the table. Note this operation can take some time if the course has a lot of students, which is also the main reason why the scores are not shown initially.
  1. Kuvaus
  2. Relations
  3. Cloning and Archiving
In Lovelace, a course instance refers to an actual instace of instruction of a course. It's comparable to a course in WebOodi. Students can enroll to a course instance. Almost everything is managed by instance - student enrollments, learning objects, student answers, feedback etc. This way teachers can easily treat each instance of instruction separately. Course instances can also be archived through a process called freezing.
Course prefixes are recommended because content page and media names in Lovelace are unique across all courses. You should decide a prefix for each course and use that for all learning objects that are not included in the course table of contents. The prefix will also make it easier to manage learning objects of multiple courses - especially for your friendly superuser who sees everyhing in the admin interface...
  1. Kuvaus
  2. Examples
Embedded content refers to learning objects that have been embedded to other learning objects through links written in the content of the parent object. Embedded content can be other content pages or media. When saving a content page, all embedded objects that are linked must exist. A link to embedded content is a reference that ties together course instance, embedded content and the parent content.
Enrollment is the method which connects students to course instances. All students taking a course should enroll to it. Enrollment is used for course scoring and (once implemented) access to course content. Enrollments are either automatically accepted, or need to be accepted through the enrollment management interface.
Lovelace has a built-in feedback system. You can attach any number of feedback questions to any content page, allowing you to get either targeted feedback about single exercises, or more general feedback about entire lecture pages. Unlike almost everything else, feedback questions are currently not owned by any particular course. However, feedback answers are always tied to the page the feedback is for, and also to the course instance where the feedback was given.
  1. Kuvaus
  2. Archiving
  3. Embedding
In Lovelace file normally refers to a media file, managed under Files in the admin site. A file has a handle, actual file contents (in both languages) and a download name. The file handle is how the file is referened throughout the system. If a media file is modified by uploading a new version of the file, all references will by default fetch the latest version. The download name is the name that is displayed as the file header when it's embedded, and also as the default name in the download dialog. Files are linked to content through reference objects - one reference per course instance.
Media files are currently stored in the public media folder along with images - they can be addressed directly via URL.
  1. Kuvaus
  2. Legacy Checkers
File upload exercises are at the heart of Lovelace. They are exercises where students return one or more code files that are then evaluated by a checking program. File upload exercises can be evaluated with anything that can be run from the Linux command line, but usually a bit more sophisticated tools should be used (e.g. PySenpai). File upload exercises have a JSON format for evaluations returned by checking programs. This evaluation can include messages, hints and highlight triggers - these will ideally help the student figure out problems with their code.
Front page of a course instance is shown at the instance's index page, below the course table of contents. Front page is linked to a course instance just like any other page, but it uses the special ordinar number of 0 which excludes it from the table of contents. Any page can act as the course front page.
Hints are messages that are displayed to students in various cases of answering incorrectly. Hints can be given upon making incorrect choices in choice-type exercises, and they can also be given after a certain number of attempts. In textfield exercises you can define any number of catches for incorrect answers, and attach hints to each. Hints are shown in a hint box in the exercise layout - this box will become visible if there is at least one hint to show.
  1. Kuvaus
  2. Archiving
  3. Embedding
Images in Lovelace are managed as media objects similar to files. They have a handle that is used for referencing, and the file itself separately. Images should be always included by using reference. This way if the image is updated, all references to it always show the latest version.
Images stored on disc are accessible directly through URL.
Lecture pages are content pages that do not have any exercise capabilities attached to them. A course instance's table of contents usually consists entirely of lecture pages. Other types of content pages (i.e. exercises) are usually embedded within lecture pages.
Legacy checker is a name for checkers that were used in previous versions of Lovelace and its predecessor Raippa. They test the student submission against a reference, comparing their outputs. If the outputs match (exactly), the submission passes. Otherwise differences in output are highlighted. It is possible to use wrapper programs to alter the outputs, or output different things (e.g. testing return values of individual functions). Legacy checkers should generally be avoided because they are very limiting and often frustrating for students. Legacy checking is still occasionally useful for comparing compiler outputs etc.
Lovelace uses its own wiki style markup for writing content. Beyond basic formatting features, the markup is also used to embed content pages and media, mark highlightable sections in text and create hover-activated term definition popups.
In Lovelace, media refers to embeddable files etc. These come in there categories: images, files and video links. Like content pages, media objects are managed by reference using handles. Unlike other types of files, media files are publicly accessible to anyone who can guess the URL.
The Primary Instance of a course is a special nomination that can be given to one instance of each course at a time. It gives the instance a special URL that has the course name slug twice instead of having the course name slug followed by the instance name slug. The main use case is to be able to get a shareable link that will always point to the most recent course instance. This way links to Lovelace courses from other sites will not become obsolete whenever a new course instance is created.
PySenpai is a library/framework for creating file upload exercise checking programs. It uses a callback-based architecture to create a consistent and highly customizable testing process. On the one hand it provides reasonable defaults for basic checking programs making them relatively straightforward to implement. On the other hand it also supports much more complex checking programs. Currently PySenpai supports Python, C, Y86 Assembly and Matlab.
Regular expression's are a necessary evil in creating textfield and repeated template exercises. Lovelace uses Python regular expressions in single line mode.
A generator acts as a backend for repeated template exercises, and provides the random values and their corresponding answers to the frontend. Generators can be written in any programming language that can be executed on the Lovelace server. Generators need to return a JSON document by printing it to stdout.
Responsible teacher is the primary teacher in charge of a course. Certain actions are available only to responsible teachers. These actions include managing enrollments and course instances.
Lovelace uses Django Reversion to keep track of version history for all learning objects. This can be sometimes useful if you need to restore a previous version after mucking something up. However the primary purpose is to have access to historical copies of learning objects for archiving purposes. When a course instance is archived, it uses the revision attribute of all its references to set which historical version should be fetched when the learning object is shown. Student answers also include the revision number of the exercise that was active at the time of saving the answer.
Scoring Group is a mechanism related to exercises in Lovelace. It allows the creation of mutually exclusive tasks where a student chooses one task from a set of tasks, and only completes that one. These groups come in two flavors:
  1. task group inside a single page (one task from the group is scored)
  2. group of pages (one page's total score is counted)
In both cases the group is formed by giving each task/page the same tag (any string) in their settings. I.e. if two pages have "my-final-exam" as their scoring group, only one of the two pages will contribute to the student's total score.
Slug is the lingo word for names used in urls. Slugs are automatically generated for courses, course instances and content pages. Slugs are all-lowercase with all non-alphanumeric characters replaced with dashes. Similar naming scheme is recommended for other types of learning objects as well although they do not use generated slugs.
Staff members are basically your TAs. Staff members can see pages hidden from normal users and they can edit and create content (within the confines of the courses they have been assigned to). They can also view answer statistics and evaluate student answers in manually evaluated exercises. Staff members are assigned to courses via staff group.
Staff Mode is an on-site editing mode that can be enabled from the secondary top bar, next to the language select. When in staff mode, various editing buttons are added to editable objects on the page. Pressing these buttons usually brings up an editing form. Staff mode remains enabled until you close the browser tab. Other staff tools that do not interfere with viewing content are always visible regardless of staff mode.
Lovelace has answer statistics for all exercises. Statistics are collected per instance, and allow you to review how many times an exercise has been answered, what's the success rate etc. All of this can be helpful in identifying where students either have difficulties, or the exercise itself is badly designed. For some types of exercises, there's also more detailed information about answers that have been given. Statistics can be accessed from the left hand toolbox for each exercise.
Student Group is a logical group of students that they can form in courses that allow it. Groups can be enabled by setting the max group size setting of an instance to a number (if it is left empty, group related features will not be visible at all). Group submissions can be controlled on a per task basis by checking or unchecking the group submission attribute. When a group member submits an answer to a task that has group submission enabled, their answer and evaluation is automatically copied to all group members. Currently this does not include submitted files, so the file can only be viewed from the original submitters answers. Please note that once answers are copied, they are owned by the students and will be kept even if they are removed from the group. In the current design, the lifetime of a group is the entire course instance.
Teacher toolbox is located on the left hand side of each exercise. It has options to view statistcs, view feedback about the exercise and edit the exercise. For file upload exercises there is also an option to download all answers as a zip file. Do note that this takes some time.
  1. Kuvaus
  2. Examples
Terms are keywords that are linked to descriptions within your course. They will be collected into the course term bank, and the keyword can also be used to make term definition popups on any content page. Terms can include multiple tabs and links to pages that are relevant to the term. For instance, this term has a tab for examples, and a link to the page about terms.
Textfield exercises are exercises where the student gives their answer by writing into a text box. This answer is evaluated against predefined answers that can be either correct (accepting the exercise) or incorrect (giving a related hint). Almost always these answers are defined as regular expressions - exact matching is simply far too strict.
  1. Kuvaus
  2. Markup
  3. Triggering
Triggerable highlights can be used in content pages to mark passages that can be highlighted by triggers from file upload exercise evaluation responses. When a highlight is triggered the passage will be highlighted. This feature is useful for drawing student attention to things they may have missed. Exercises can trigger highlights in their own description, or in their parent page. It is usually a good idea to use exercise specific prefixes for highlight trigger names.