The Student Feedback App

The Student Feeeback App

This page contains user instructions for the Student Feedback App (SFA) of the WE-COLLAB project. Information on the objectives and implementation of the app can be found in the learning path (LA) "Development of a Student Feedback App for the WE-COLLAB project", which however still has to be aligned with the new version of the app.

The multiplatform version

The first version of the app was developed as a native mobile app for the Android devices. The new version (since release 0.10) has been developed with the native web app (NWA) approach; this is also known as progressive web app (PWA); the app is a regular web application optimized for devices with small screen. Currently it has been tested with recent versions of the web browsers FireFox and Chrome on Android, and with Safari on iOS.

Installation

Being accessed with a common web browser, the SFA does not require a real installation. However, for ease of use from a smartphone, we suggest a few preparatory steps. What follows assume that you are a registered user of CommonSpaces and a member of the WE-COLLAB community (the project platform).

First access from the phone

In new release 0.20, steps 2 and 3 below are NOT required.

On the smartphone,

open your browser, access the official home (the cover page) of the WE-COLLAB site, that is www.we-collab.eu. and proceed to the home of the WE-COLLAB top community, using the link below the title;
login with your CommonSpaces credentials (email address and password); in doing that, check the box Remember Me; then, close the browser;
re-open the browser and re-access WE-COLLAB; if you are not recognized and need to login again, answer 'yes' when, after you enter your email address, the browser asks if you want to use your saved password;
using the Tools menu, choose the Student feedback item; when you get the cover of the app, using the browser menu (usually a vertical row of 3 dots), choose the function Add to the Home screen to create a new icon acting as a shortcut to the app.

Expected result

The new icon should appear as a big W character or as the We-collab logo on a uniform colour background.

The rest of this section does NOT apply to new release 0.20.

By clicking on it, you should open the SFA as an authenticated user.

In fact, it is difficult to find documentation on the browser behaviour in similar situations; for example, on an Android device,

if not only you exit the browser but also stop all apps running in background, it seems that both Chrome and FireFox keep you logged-in when you access again the SFA, more in general the WE-COLLAB platform;
if you switch the device off and on again, nothing changes on FireFox but, on Chrome, probably you have to repeat step 3. of the above procedure.

Some context

Calendars and Events

The SFA makes reference to calendar events.

The rest of this section is of NO interest for guest users of the SFA in new release 0.20.

In WE-COLLAB, calendars can be created at any level in the hierachy of social spaces (communities and projects). By clicking on the calendar icon in the right of the black user bar, each logged user can open her virtual calendar, an overview of all past and future events associated to the spaces of which she is a member. However, only current and future events are considered by the SFA.

Courses and lectures

An event is an object that can represent anything having a title, a description (optional), a starting time and an ending time, and being associated to a community or a project. For example, a lecture can be represented by an event. A project can represent a course and the project members can match the students enrolled in the course. Lectures belonging to that course should be represented, as far as the SFA is concerned, by events in that project's calendar.

Use of the SFA by an event attendee

Selecting an event

The student following a lecture in presence or at distance is a special case of somebody attending an event. She can really use the interactive SFA tools only while the event is in progress.

Next paragraph is of NO interest for guest users of the SFA in new release 0.20.

Registered users can select the event of interest even before it starts. The function select event in the App menu is just for that. A dropdown list presents, in ascending time order, the events in the virtual calendar of the user whose ending time has not elapsed yet.

When a registered user selects an event from the options list, or a guest user accesses the App using an event code, this becomes the current event and its attributes are shown. If the event hasn't started yet, a warning is provided, otherwise the communication channel with the server is opened.

Next paragraph is of NO interest for guest users of the SFA in new release 0.20.

When the select event screen is visualized, the state of the event is refreshed: you could need to switch between any other screen and the selection screen to update said state.

Sending reaction messages

By choosing the function react in the menu, the user gets a screen with a virtual keyboard whose buttons are labeled with the names of nine reaction types, those in currently available repertoire. Clicking on each of them results in sending to the server a message including that label together with name of the sender. The timestamp is provided by the server, which adds a line in the Reaction log of the Event dashboard, updates the visual presentation in the form of a word cloud and forwards the message as an xAPI statement (an action trace) to the xAPI LRS (learning record store).

Participating in the event chat

By choosing the function chat in the menu, the user gets a screen from which she can send chat messages; the server annotates each message with the sender name and a timestamp and 'broadcasts' it to all users being connected to the event chat by means of a SFA. When the message comes back to the sender, the SFA adds to the Chat log a line including the annotated message.

Users can participate in the chat also from the Event dashboard, preferably from a PC or other device with bigger screen. Even in this case, the server forwards the message as an action trace to the xAPI LRS.

Role of the teacher

Obviously, the lecturer, and perhaps also her assistant, more in general the 'event masters', will use the Event dashboard to follow the 'reactions' and other feedback from the lecture/event attendees, in order to take them into account during the course of the event itself. Possibly they themselves can participate in the chat. And they may analyze, in deferred time, the event-related traces stored in the LRS as xAPI statements.

But, specifically referring to the SFA and to the lecture use case, the role of the teacher is to create a project matching the course or choosing an existing project for that, to create in the project calendar an event for each lecture to be 'SFA-enabled'.

In new release 0.20, the following paragraph is relevant only for attendees that are (registered) members of the project.

Another task of the teacher is to ensure that all expected attendees are members of that project, that they are able to access their virtual calendars or be notified in other way of the lecture date and time, that they have 'installed' the SFA on their smartphones and know how to use it.

To gain experience on the use of the SFA, and to let your students familiarize themselves with it, feel free to create and modify test events; do that in a space (project or sub-project) of which only you and a few other users, being aware of the test, are members. To create the project, the project calendar and the events in it, you need supervisor role; you get it if you are already a supervisor of the parent project or if one of its supervisors creates the sub-project and makes you its supervisor, afterwards or before opening the new project.

Extensions of new release 0.20 of the SFA

Release 0.20 allows the participation of users not registered at CommonSpaces/We-Collab. We will call them guest users. Guest users access the SFA, from a mobile device or a desktop, using a web browser such as FireFox or Chrome or Safari.

Guest users access the SFA in the contest of a specific event (course lesson), which is specified by the user by entering an event code provided to them by the teacher (more in general, by the event organizer).

Technical detail: the event code is a simple numeric string that almost transparently embodies information on both the event and the teacher. Only the event information is used to identify the event (course lesson); the teacher information is redundant but it is used to minimize the possibility that the casual user succeeds in accessing the SFA with a random event code.

Two flavours of guest users

Guest users are supported to allow the access to the SFA with a certain level of anonymity, which solves most of the problems associated to data privacy and the GDPR. As a side effect, the App usability is improved too for casual users of the We-Collab platform.

To interact, through the app, with the other users, guest users take on temporary identities which, as a rule, are not traceable to their true identities. Each user, independently from the others, can choose to get randomly a synthetic identity from the system or to provide herself a fictitious identity.

When an anonymous user, that is a non-registered or non-logged in user, accesses the SFA from a web browser, possibly by clicking on a bookmark of the browser itself or a self-created icon on a smartphone, she lands on the homepage of the SFA, which is a very simple cover. In the upper-right corner of the screen she will find a mobile-style menu (an icon with a few horizontal bars), including only three menu items: Cover, Guest user, About. The second one, before getting access to a specific event, shows a form for getting a guest user identity.

Since the duration of a (temporary) guest user identity can depend on many factors, in particular on the configuration of the web browser in use, a function is provided to release a persisted old identity if a new one is required to attend a new event.

Fully anonymous access

The top section of the form contains a text-box where, in any case, the student must enter a numeric string: the event code provided by the teacher or other event organizer. Said code can have length 4 or 6 or more. Since 4 is it minimum length, when at least 4 numeric characters have been entered a function button labeled Get guest user id is enabled.

The system checks the validity of the event code provided. If it is invalid, an error message is visualized and the user can retry. If the code is valid, the SFA user interface gets reconfigured: the user is taken again to the cover page and the menu gets extended with two more items: React and Chat; these are the same available to registered users.

In the case of successful identification, the user will interact with the React screen and the Chat screen in the exact same way as the registered user. On the other hand, the Guest user screen gets modify to allow to release the guest identity, as mentioned above.

Technical detail: currently, the system assigns as guest identity one picked in pseudo-random way from a small pool of pre-created guest accounts; these can be recycled when no more in use. The probability that the same user gets the same guest identity in different sessions (events, lessons) exists but is low; thus, xAPI statements associated to the same guest account in connection with different events are expected to be very weekly correlated.

Access with a self-chosen fictitious identity

The bigger bottom section of the Guest user identity form includes boxes for 3 data that the user must enter to choose her temporary identity for the event specified by the event code:

email; only a syntactic check is performed by the app screen on the validity of the email address;
first name; the only syntactic check concerns the minimum length of 3 characters;
last name: the only syntactic check concerns the minimum length of 3 characters.

After the Send data function button is enabled, and the user presses it, the system performs a few more validity cheks:

the email cannot be the same as that of a regularly registered user;
if the email was already used as part of the identity of a guest user, first and last name entered must match those already provided; in this case, the same fictitious identity is reused.

In the case of successful identification, with the fictitious identity just specified the user will interact with the React screen and the Chat screen in the exact same way as a registered user. On the other hand, the Guest user screen gets modified to allow to release the guest identity.

Important non-technical note: the case that the user herself chooses her (fictitious) identity is very "flexible"; it adds some options and introduces some problems that the teacher, perhaps together with the students themselves, should carefully consider. But this is not the place to illustrate and discuss them.

Additional advice for the teachers

(The following notes are just practical suggestions for non-technical users willing to set up an initial experimentation of the SFA)

We suggest conducting a test, simulating a lecture, with a small number (4-5 ?) of students who can then assist their colleagues.
In presence it is certainly easier to become familiar with the SFA, also in view of later distance classes. The students themselves can advise each other and possibly help the lecturer too.

ONE-TIME INITIAL STEPS

have all students create the start icon for SFA (the We-Collab app) on the mobile device (smartphone or tablet); instructions are in the help page, but it is necessary to understand them and overcome any difficulties dependent on the type of mobile device, the browser choice, and the browser configuration. This is a relatively simple operation, such as creating a bookmark in a browser, but not everyone is familiar with it; it can be useful in many other cases.
create the project/course, giving it a meaningful Title, recognizable to the student; should be a regular "LP creation" project, not a "Support project";
create the Calendar for the project/course (just click on the dedicated function button);
suggest the students to take a look, on the site, at the help page on the Student Feedback App; this can provide useful context for overcoming any difficulties.

BEFORE EACH CLASS

1. create an event in the project/course calendar
- giving it a meaningful title, for example, one that incorporates or recalls the course title and includes the ordinal number of the lesson,
- specifying start time and end time with a good margin before and after, so that you can interact with the SFA even before the lesson begins and after its nominal end;
2. view the event in the calendar and
- take note of the event code: this is the personal code associated with the teacher, but it is the same code that students will need to specify the event itself in acquiring their temporary identity;
- open the Event Dashboard view related to the event itself, to get a picture of the situation as students interact with the app;
3. communicate to the students the unique event code that they will all need to qualify as guest users;
4. agree with the students what kind of identity to acquire as guest users: totally anonymous or self-defined; probably, at least in the beginning, it will be better to opt for a totally anonymous identity, because it is easier and does not pose privacy problems.

AT THE TIME OF THE LECTURE

The lecturer and/or an assistant lecturer could produce a timeline of the lecture, with mention of highlights and topic changes, if, in addition to using real-time feedback, they want to be able to analyze the data offline and correlate it with the student feedback. This can be done by annotating a previously prepared lecture outline, using the SFA chat, recording and then debriefing the lecture, etc.

It is good, both on the part of the lecturer and the students, to start using the SFA before the nominal start of the lesson. Even in the case of a real, non-simulated lesson, this allows students to verify the connection and take their time to apply as a guest users (the acquisition of temporary identity). All activity traces sent to the LRS (the xAPI statement database), and displayed by the SFA (in the case of chat messages) and by the Event Dashboard, are accompanied by a timestamp and thus can be filtered against them if necessary.

NOTES ON THE CALENDAR

The teacher should also be able to view events/lessons on the Virtual Calendar accessible from the user bar at the top of the page. But the creation of events should be done from the Calendar local to the project/course of interest.

If all students act as guest users, they do not need to access the Calendar. It is the teacher who needs to provide them with the associated event code (his/her personal event code).

Events should be created from the daily view of the Calendar. Events and their detail view are conveniently displayed from the monthly view of the Calendar. If I remember correctly, from the daily view it is possible to edit an event: Title, Description (optional, it is not displayed by the SFA), Start and End date and time of the event. By editing an event, you can also move it by date and extend its duration.