Collaboration Platform for Students

A desktop application for organising events, communicating with professors and students, and sharing documents.

Bootstrap
Node.js
Electron

13/03/2020

Description

Copsi is a desktop application that is used for communication and document exchange between professors, assistants and students of the Kaiserslautern University of Applied Sciences. The current exchange of information, news or relevant data on the respective modules means that students have to use variousplatforms such as the OLAT system, Google Drive, student emails or even instant messaging services such as WhatsApp in order t o get a reasonable overview. Information is quickly overlooked and direct communication with fellow students is often not possible, as students have to search for specific fellow students in the list of people on the campus board, assuming there is any contact at all.

Due to this dissatisfaction with the various services that have to be used in everyday student life, the idea arose to create software that would simplify communication and dataexchange. This should take place via a central server in connection with a database.

Objective

The aim of this study project is a Minimum Viable Product (MVP) that can read and display the structure of courses, channels and messages from a database. Additional functions would be, for example, the uploading and downloading of files and user rights.

Environment

The project was commissioned by Prof. Dr. Dieter Wallach as a lecturer at Kaiserslautern University of Applied Sciences. Our project team, consisting of Caroline Miller, Sebastian Schuler and Philipp Spandl, accepted this assignment as a student project team at Kaiserslautern University of Applied Sciences. The interest groups were lecturers and Students of the University of Kaiserslautern.

Planning phase

As-is analysis

The OLAT learning platform is a web application that, with a few exceptions, is used by professors at Kaiserslautern University of Applied Sciences to manage and organize their courses. Among other things, it is possible to create a new course, search for courses in the directory, invite students, upload and download files, even the possibility for a course chat and discussion forum is given. The functions offered by OLAT are not accepted by the students, as the use of OLAT is too complicated for daily use. An unsuccessful interface makes orientation difficult; for example, it is not immediately apparent that the system even has a search function. There is no general start page where the user can be sure that he will return to a point of orientation

Target analysis

The target groups can be defined from proto personas and interviews and the results derived for the requirements.

Interviews

The stakeholder interviews were needed to clearly define objectives. It was important to find out the weaknesses and flaws of the competitor's product in order to improve it.

Interviews with five stakeholders (professors and students) confirmed the assumptions made by the proto personas. Four of them were very many complaints about OLAT, the biggest common one being the lack of clarity. In addition, it is overloaded with functions and in some places it is more complicated than it should be, for example uploading and downloading files - a double-click leads directly to downloading the file instead of getting a preview first.

Requirements

The target group to be filtered out for this application is quite obvious. The application is to be developed specifically for students and lecturers. This raises the question of what wishes the target group might have for interacting with the system.

Scenarios

Functional

Non-functional

Planning

In the design phase, the architecture and the preliminary design of the client are defined, based on the following methods of the design phase. The client allowed a free design option, with the condition that the design should be oriented as closely as possible to the corporate identity of Kaiserslautern University of Applied Sciences.

Scribbles and Mockups

In order to get an overview of how the individual pages of the client should look and which functions should be offered to ensure that the user can use the system as easily and intuitively as possible, rough pencil drawings were made. These are easy to correct and with Post- Its it is possible to run through a scenario and eliminate ambiguities in advance or not create them in the first place.

With help of scribbles, it was possible to define the basic structure and agree on which recurring UI elements would be used.

Scribbles

The scribbles could then be roughly visualized as mockups using Balsamiq.

Mockups

Wireframes and Prototype

Adobe XD was used to create the wireframes, which were then connected by interaction options to serve as a prototype. There were two versions of each wireframe: an "empty" and a filled screen, i.e. how the screen would look if professors and assistants regularly wrote news and uploaded files and how screens could look when participants chat with each other.

Usability Tests

Formative usability tests were used to find out where there was potential for optimization in the design of the wireframes; the wireframes were changed after each run. Five test subjects were interviewed, who were given a short briefing at the beginning about what the application is about and asked to share their thoughts on the design. Each test subject underwent two tests, one prototype was not filled with messages or files, the next gave the impression that the application had been extensively maintained and kept up to date throughout the semester. For each screen of the prototype, they were first given the opportunity to express all their thoughts on any points that caught their attention, after which they were given simple instructions on what to do with the application. In the second run, the scenarios from chapter 4.3 were run through. Finally, they had the opportunity to give their feedback again, address points of criticism and make suggestions.

Preliminary Design

The login screen shows a color gradient of two CI colors of the university in the background, blue for computer science and green for business administration - so far it has not been possible to bring all colors of the study areas into a harmonious color gradient. In the middle there is a simple login form, each user logs in with their university e-mail and the corresponding password. If the user has forgotten their password, there is a link to Kaiserslautern University of Applied Sciences and an article on passwords and university accounts.

Colors of the university:

The preliminary design of the application is primarily in white with a dark gray font, the font is Rubik. It is a sans-serif font, which does not create a hard contrast due to slightly rounded corners and is easy to read.

The structure is designed to keep all important information in view at all times, which means that information on which module and channel the user is currently in, as well as the participants in the module, is always displayed.

The design consists of four columns, the first column from the left shows all available modules, the next column refers to the selected module, which is highlighted in the accent color blue. The accent color blue corresponds to the CI blue of the Faculty of Computer Science and Microsystems Engineering at the university Kaiserslautern.

In the second column there is a list of so-called channels, the active channel is also highlighted in the accent color. The respective Channels are also displayed with an associable icon, for example, the "News" channel has a paper page as an icon, which could be associated with a page from a newspaper for news and the "Anonymous" channel has a ghost:

Anonymous user

The third column shows the main content, of which there are three types for the time being: News, Tables and Chats. All types have in common that the respective title is displayed in the header, at the same height there is also a text element that displays the current semester data. News and tables have an additional Common feature: two cards, each with an important date, are displayed directly below the title. The left card shows the exam date, the right column can show any important date, for example the deadline for a submission:

Deadline

The news content consists mainly of white "cards", based on the cards from Material Design, which have a picture of the author of the news on the left-hand side. Show news, for the time being images of sheep and lambs have been used as placeholders, these have no deeper meaning. The name of the author, the role, a time and the text are displayed on the right-hand side of the card:

Message

The text input is located in the lower part of this column. Messages can be sent by entering text normally and pressing the Enter key.

Documents can be uploaded and downloaded in the table content. Here you can see a classic table. The name, size and date are shown in the header, with a list of the individual files below. For each file, some details such as name, size, date and a download button to the right are displayed. In the At the bottom is a button in the accent color with which the files can be uploaded.

The chat content is only available anonymously for the time being, the messages are displayed in colored "boxes", there is no display of names, only a time indication:

Anonymous Message

As in the news content, there is also a text area at the bottom where you can write your messages.

The fourth column shows the list of members of the module. Starting with the professor, followed by the assistants and then the students. A hover button suggests that it may be possible to send a private message to these people.

The design was implemented using HTML and CSS, and the Bulma framework was used for the simple structure and the UI elements such as the cards and boxes. It is a simple CSS framework, which is used for the layout and many UI elements and still gives the possibility to create and design every single element individually.

Screenshot of the application:

User interface

Implementation Phase

First, the class objects User, Server (or course for the user), Channel, Role and Message were created. The required combination classes, which only contain IDs and are used to connect n:n relationships, were also created. The extra classes UserAbility and RoleAbility contain arrays for each function, e.g. reading and writing in a specific channel. Role IDs are used in the RoleAbility arrays, and the respective user IDs are used in UserAbility (e.g. the professor's ID could be assigned to Admin assistant moderator, etc). However, this is only the structure for the application; a different, more effective structure is used on the database.

Structure of the application

The database model created from this looks slightly different to facilitate access from the server. The database contains only two real tables, two combination tables and two file tables. It was realized with MongoDB, which we chose due to its high compatibility with Node.js.

Structure of the database

In contrast to classic database systems, MongoDB supports objects as they exist in Javascript. This means that arrays are permitted (marked above with Arr). The Server and User tables are the most important and are loaded first by the DB. Sur (short for server-user-role) indicates which user is in which server and channel-messages is a collection of all messages of a certain channel in a certain server. The two extra tables fs.files and fs.chunks are used to store files, files contain the metadata and chunks contain the file split into chunks whose size can be changed in the DB settings.

Server

The server is based on Node.JS and Express. It connects to the database and loads all available objects so that they are ready as soon as a user connects. If an object is changed or newly created, this only needs to be sent to the DB and can be adopted locally on the server. Sensitive data such as passwords are encrypted with the help of BCrypt.js, stored on the DB and only decrypted again by the server. A large part of the program logic is located on the server, e.g. message distribution, rights queries, loading/saving files from the DB and much more. This means that the client remains unloaded and only has to take care of the display and communication with the server. After a new client logs in, all relevant information is sent to it in one package. This includes the user's server / course list and personal data (passwords are removed from objects before they are sent). In addition, the server manages the server, user, sur and message lists as variables. At the same time, changes are always saved in the DB.

Client

The client is based on Electron, which provides a stable and fast basis for a desktop application. The actual user interface was created and customized with the help of Bulma. The exchange between client and server is event-based, i.e. something is only sent when, for example, a message is sent or received.

Conclusion

The goal of this application was to develop an MVP of a collaboration application between students and professors. As a minimum, this should offer a chat function and the possibility to upload and download files.

To achieve this goal, the first step in the analysis phase was to analyze existing platforms and target groups and to define the corresponding requirements and scenarios for this application.

Methods were then used in the design phase to define the basic architecture and design of the application, which would later serve as a basic aid in the implementation phase.

In the implementation phase, the final application was implemented using various means and finally tested.

The first priority here is scheduling; instead of a mature and clear schedule, only individual deadlines were adhered to and then it was determined what should be approximately ready by the next deadline. Although this is somewhat similar to the agile approach, it was not defined in advance.

The analysis phase could have been a little more detailed; although requirements were drawn up from analyses, everything was usually formulated somewhat vaguely. There could also have been more communication with the target group.

The design phase, which is actually intended to serve as a basic support for the implementation, was completed somewhat late, which meant that the implementation was already partly started before the actual design was ready. There should also have been more communication with the target groups during this phase.

Outlook

In the future, the application should run on a central server throughout the university, and professors should be able to create their courses dynamically in order to provide students with a wide variety of documents. It should also be possible to form learning groups and it should be possible to organize yourself in these groups.

The system should also receive quality of life improvements, such as a drag and drop function for files, templates for creating courses and general improvements to user- friendliness.

In future, the Campusboard account or the university account should be used for login.

Share of project implementation

According to the module handbook, the study project is entitled to approx. 210 hours of work, which was achieved in this project and exceeded with an approximate actual workload of 270 hours.