Sj ¨alvst ¨andigt arbete i informationsteknologi
11 juni 2020
QuickBook
Web-based booking system for dinner parties and events
Agnes Abrahamsson,
Carolina Gripsborn,
Anto Juko,
Catya Kemppainen
Institutionen f ¨or informationsteknologi Bes ¨oksadress: ITC, Polacksbacken L ¨agerhyddsv ¨agen 2 Postadress: Box 337 751 05 Uppsala Hemsida: https://www.it.uu.se
QuickBook
Web-based booking system for dinner parties
and events
Agnes Abrahamsson, Carolina Gripsborn, Anto Juko,
Catya Kemppainen
G¨oteborgs Nation is an organisation in Uppsala led by students at Uppsala University. The student nation provide social activities for the university’s students, and they experience certain difficulties with the booking process for their events. There is no standard procedure or single system for this process and a lot of the work has been done manually. When hosting events such as dinner parties with table service, or when renting out their premises to other organisations, there is a large amount of logistical work to compile all the data and to get the different systems to work together. A solution to this problem is QuickBook, which is a web based event booking system with the functionality required to create, market and execute an event, all collected in one place. This system makes the work at G¨oteborgs Nation easier by reducing the extra steps in the processes.
The resulting system has the basic functionality that G¨oteborgs Nation requested. There is a collection page for all current events that users can browse through and register for. Users can also sign up to become mem-bers, log in and see their saved information, registrations and tickets. As an administrator, the staff at G¨oteborgs Nation can easily create events that are all in uniform, see all registration information that comes in, and even provide credentials for rental organisations to use the system. The functionality that is currently not in place is the ability to launch the web application as it is currently only running locally on a computer, as well as some smaller functions that would make the system easier to use. Extern handledare: Ebba Ulfberg, first curator at G¨oteborgs Nation
Handledare: Mats Daniels och Bj¨orn Victor Examinator: Bj¨orn Victor
G¨oteborgs nation ¨ar en organisation i Uppsala som leds av studenter vid Uppsala uni-versitet. Studentnationen erbjuder sociala aktiviteter f¨or studenterna, och de har vissa problem med bokningsprocessen f¨or olika evenemang. Det finns ingen standardprocess eller ett enda system f¨or utf¨orandet av evenemang och mycket jobb har gjorts manuellt. N¨ar G¨oteborgs nation ¨ar v¨ard f¨or ett evenemang som exempelvis middagar med bords-servering, eller n¨ar de hyr ut sina lokaler till andra organisationer, kr¨avs det mycket logistiskt arbete f¨or att sammanst¨alla all data. Mycket tid g˚ar ¨aven ˚at till att f¨ors¨oka f˚a de olika systemen i processen att g˚a ihop. En l¨osning p˚a detta problem ¨ar QuickBook, som ¨ar ett webbaserat evenemangsbokningssystem med den funktionalitet som kr¨avs f¨or att skapa, marknadsf¨ora samt genomf¨ora ett evenemang, samlat i ett system. Detta system underl¨attar arbetet p˚a G¨oteborgs nation genom att minska de extra stegen i pro-cesserna.
Det resulterande systemet har den grundl¨aggande funktionalitet som G¨oteborgs nation efterfr˚agade. Det finns en samlingssida f¨or alla evenemang d¨ar anv¨andare kan g˚a ige-nom all information samt anm¨ala sig till ett evenemang. Anv¨andare kan ocks˚a bli med-lemmar, logga in och se deras sparade information, registreringar och biljetter. Som administrat¨or p˚a websidan kan de anst¨allda p˚a G¨oteborgs nation enkelt skapa olika eve-nemang i ett och samma format, se all information fr˚an anm¨alningar samt kunna ge inloggningsuppgifter till andra organisationer som hyr lokalerna f¨or att de ska kunna anv¨anda systemet. Funktionaliteten som f¨or n¨arvarande saknas ¨ar m¨ojligheten att k¨ora webbapplikationen via andra datorer och n¨atverk, eftersom den f¨or n¨arvarande enbart k¨ors lokalt p˚a en dator, samt n˚agra mindre funktioner som skulle g¨ora systemet mer gynnsamt och l¨attare att anv¨anda.
Contents
1 Introduction 1
2 Background 2
2.1 Student nations . . . 2
2.2 G¨oteborgs nation the Stakeholder . . . 2
2.3 Current event organisation process at G¨oteborgs nation . . . 3
3 Purpose, Aims, and Motivation 4 3.1 Functionality goals . . . 4
3.1.1 User aspects . . . 4
3.1.2 Administrator aspects . . . 5
3.2 Working environment considerations . . . 6
3.3 Environmental impact considerations . . . 6
3.4 Ethical aspects . . . 7 3.4.1 Working with GDPR . . . 7 3.5 Delimitations . . . 8 4 Related work 9 4.1 Eventbrite . . . 9 4.2 Guestlogic . . . 10 4.3 Tickster . . . 10 5 Methods 11 5.1 MERN stack as developing environment . . . 11
5.1.3 ExpressJS . . . 13
5.1.4 ReactJS . . . 13
5.1.5 HTML and CSS . . . 14
5.2 Using QR technology . . . 14
5.3 Potential design alternatives . . . 14
5.3.1 MEAN stack . . . 15
5.3.2 Mobile application . . . 15
5.3.3 Using Eventbrite’s API . . . 16
5.3.4 Combining current systems . . . 16
6 System structure 16 6.1 Description of the Model-View-Controller pattern . . . 17
6.2 The user interface . . . 18
6.3 The underlying back-end systems . . . 19
7 Requirements and evaluation methods 20 8 Using QuickBook 21 8.1 User flow of the booking system for guests . . . 21
8.1.1 User flow of the booking system for administrators . . . 22
8.1.2 User flow of the booking system for doormen . . . 27
9 Evaluation results 29 10 Results and Discussion 30 10.1 Results . . . 30
10.2 Discussion . . . 31
11 Conclusions 32
12 Future work 33
A Event organisation survey 39
1 The MERN stack . . . 12 2 MVC architectural pattern . . . 17 3 User front page of upcoming events . . . 19 4 Relational database schema of QuickBook. The database contains three
collections: Event, Guest registration and Profile. . . 20 5 The front page that pops up when a user first visits the QuickBook web
application (right picture scrolled down version of left picture). . . 21 6 The QuickBook user booking page. Here, the user signs up for an event. 22 7 QuickBook’s sign up page for users . . . 22 8 QuickBook’s ticket page for users. Here the user is either presented
with a ticket or a place in the reserve queue depending on whether the person already has a seat at the event or not. . . 23 9 QuickBook’s sign in page for users . . . 23 10 When a user has logged into their QuickBook account this page is
pre-sented to them. Here they can see their profile, saved personal data and also their events. The user can choose to edit their profile, to view an event or to view their ticket for a specific event. . . 23 11 QuickBook’s sign in page for admins . . . 24 12 QuickBook’s first page when logged in as an administrator (right picture
scrolled down version of left picture) . . . 24 13 QuickBook’s create event page for admins. Here an administrator can
enter all the desired data for an event and when created, the event will appear for users on the front page of the website. . . 25 14 The page where administrators create a new administrator or a new semi
administrator account for people handling event at G¨oteborgs Nation. . 26 15 The page where administrators edit accounts, both user and
16 The login page for the staff that works at the door at an event, i.e. the
doormen. . . 28
17 The first page that is presented to the doormen when they are logged in to the QuickBook page. . . 28
18 The guest list presented in the QuickBook application when clicking on the guest list icon for a specific event, logged in as a doorman. . . 29
19 The scanning function of the QuickBook application. Here you can see how the scanner opens up when logged in as a doorman. . . 29
20 What nation or student union do you belong to? . . . 39
21 Where do you post links/notifications to events? . . . 39
22 How do you sign up for your events? . . . 40
23 How do you do table seating at your events? . . . 40
24 Do you have a reserve list for your events? . . . 40
25 Can you get the money back if you can’t attend an event but have paid? 41 26 Can you assign a ticket to someone else if you can not attend an event but have paid? . . . 41
27 Do you have physical tickets for your events? . . . 41
28 Do you print maps and table seating for your events? . . . 42
29 How much time would you estimate that it will take for you to check who has signed up, payments and special diets for an event? . . . 42
30 Would it save you time if you had the same system where you create the event, had the registration link, connect with a table placement system, have a reserve list and where the guests can also see their table location in one place? . . . 42
31 When it comes to organising events, what is most time-consuming from a logistics perspective? . . . 43
32 What do you think is missing in the current situation that would facili-tate the organisation of events? . . . 44
35 How easy was it to set dates when creating av event? . . . 46
36 How easy was it to create an account? . . . 46
37 How easy was it to sign in to an account? . . . 46
38 How easy was it to find available events on the website? . . . 47
1 Introduction
1
Introduction
The city of Uppsala is famous for its rich student life [22], and for the students at Up-psala University there are more things that occupy the time than just studies. Most universities have student organisations of different kinds, where students both work and partake in activities [39]. In Uppsala, these organisations are called nations. The na-tions host different types of events such as dinner parties, theme parties, music nights and open restaurants. The employees at the nations in charge of hosting these events are the so-called curators [20]. There is however no standard process or single system to use when distributing information about events and handling registration data. Thus, for these curators, a lot of time is spent using different systems and going through lots of emails containing a lot of event-related information, and attempting to compile all this data into a cohesive format. These issues have been very tangible for G¨oteborgs Nation in Uppsala as they use several platforms for guest registration when they are hosting events, and today the curators have to enter a lot of information by hand, see A. This also makes it more difficult for those who want to find information about an upcoming event and how and where to register for that event.
For these reasons G¨oteborgs Nation requested a single system that can be used when it comes to hosting an event, which is why we developed QuickBook. QuickBook is a system that is accessed through a website where the tools needed to organise an event can be accessed by the employees at G¨oteborgs Nation, and all the information about upcoming events is available for the students. In this system the students have the opportunity to see information about events as well as being able to register to an event in a standardized format. The system also makes the process of planning these events and submitting the data more effective, as it is all collected in one place and is accessible to all the nation’s staff. More time can then be spent on creating the best possible experience for the guests of the events. Having all the data compiled digitally also enables the possibility to monitor information. This includes e.g. guest lists, which guests that have paid, and certain guests’ food preferences, which in turn also makes it easier to create an appropriate menu.
The final product fulfills most of the goals set according to the wishes of G¨oteborgs Na-tion. The system allows the nation the ability to create events, monitor the information and data flow from registrations, and to get a guest list for an event which can be used to scan tickets at the site of the event. The students can view all created events, make a guest registration and receive tickets for the events they have registered to. They can also, if they wish, create an account where personal information will be saved and event registrations can be viewed. Although there is still some smaller functionality missing and the system is not yet launched as a usable website, the system could still in its cur-rent state facilitate the process significantly for G¨oteborgs Nation and thus we consider
the results to be good for this prototype.
2
Background
Different nations and student unions use various methods when organising their events. Today the majority are to at least some extent using digital tools of some kind to create events, make guest registration forms or to handle tickets and payments, see . However, use of manual methods to organise events such as compiling registration information by hand and handling alterations of registered information through email, still occurs. To improve and develop a new booking system it is important to look at the methods that are being used today to see what is not working and what can be improved.
2.1
Student nations
Today there are thirteen different student nations in Uppsala. To become a member in a nation in Uppsala one must be a student at Uppsala University (UU) or the Swedish University of Agricultural Sciences (SLU) [21]. The nations offer places for social interaction and various activities for the students in Uppsala [22]. Students can meet at e.g cafes and restaurants and participate in various events like gasques, a term used at Swedish universities for a type of dinner party including songs and usually an after party [27]. The different nations have varying methods when distributing information about an upcoming event and when handling guest registrations, payment and tickets, see A. The nations also provide practical services for students, for instance accommodation, various discounts and scholarships. The nation to which the system is addressed is called G¨oteborgs Nation.
2.2
G ¨
oteborgs nation the Stakeholder
The stakeholder for this project is Ebba Ulfberg, first curator at G¨oteborgs Nation. As a curator she is the person who oversees the planning process of events, and has con-tact with other organisations that wish to rent their premises for their events. She is also the person at G¨oteborgs Nation who handles emails regarding guest registration and who creates the seating for events. G¨oteborgs Nation host many different events, approximately 10 separate events during one semester [19], that require handling guest registrations and information. Therefore, they could benefit from using this system to connect all the different parts of guest registration into one system. The working staff
2 Background
at the nation were able to provide great input and feedback for the design during the process to tailor it to their specific needs.
2.3
Current event organisation process at G ¨
oteborgs nation
When organising an event, the first thing the curators at G¨oteborgs Nation do, when reaching out to the public, is to publish it on Facebook. This post includes the relevant information about the event, such as what type of event it is as well as date and location. There is always also a link to the guest registration form.
The guest registration form is usually a simple form made with Google Forms [14]. Google Forms is an application one can use to manage event registrations and freely choose the format of the questions such as multiple choice questions or questions that requires text answers [16]. These forms have to be made for each new event with the appropriate queries. The results can be summarised with charts and graphs displaying an overview of the registrations, and exported in tables to Google Spreadsheet [15]. The guest registrations are then handled manually on a computer by the nation staff to compile all the information. The information the guests need to enter usually includes name, email, desired table neighbours, food/drink preferences and possible allergies. This information is then later used when making the guest list as well as when creating the menu for the event, as the guests’ diets and allergies need to be taken into account. The seating arrangement is created using a program called Perfect Table Plan [2]. All the guest information and desired table neighbours are entered into the program where the guests are manually assigned a seat on a map over the event premises. The seating is always printed on paper and placed around the room during the event. The guests then use this map to find their seats. The curators at G¨oteborgs Nation has stated that this process can become quite confusing. Other things such as the reservation list for the guests that were unable to register due to a popular event being booked full, and handling changes or cancellations are done manually and through email. Today, cancellations after the nation has purchased the food are not allowed and one can not get a refund on ones ticket. Therefore the food will still be cooked and the places will be left empty for the participants that could not attend and could not cancel their ticket.
Payment and tickets are handled separately. Payments are made manually by the guests to a specific bank account that the nation has stated in the event information, or directly by card or cash at the place of the event if possible. For the majority of events, no physical or digital tickets are used. Guests that have received a spot and have paid are instead put on a list. The list is then checked off at the entrance of the event using personal identification.
3
Purpose, Aims, and Motivation
The purpose of this project is to develop a web-based event booking system for the student organisation G¨oteborgs Nation. In this section the specific goals of the project and the reasoning behind them will be presented.
3.1
Functionality goals
The main goals of the project is to deliver a working web-based event booking system. This system should be able to be used by G¨oteborgs Nation to create, promote and organise an event, and by the users to make accounts and register for these events. Following are the sub-goals of the system and how those goals will benefit the users and the administrators.
3.1.1 User aspects
Below the goals concerning the user aspects of the system will be presented and dis-cussed. Accessibility
Participants of events will be able to have an overview of upcoming events and all related information. Thereby the risk of missing the opportunity to attend a certain event will be minimised. Finding what events are currently available for registration and making the decision of what events to attend are also made easier.
Account and saving data
By creating an account on QuickBook the users can save personal diet, food allergies, name and email data. This will make the booking process quicker as the saved informa-tion can be automatically filled in when registering for a event.
Reserve list
If an event is booked full users will still be able to register, where they will instead be placed in a reserve list. If a spot becomes available, the first person on the list will be offered this spot with a set time to decide to either accept or decline. When declined, the spot is offered to the person next in line on the reserve list.
Cancel or transfer booking
Users will have the opportunity to cancel a booking or to transfer it to another user before the event takes place. This way the process when a participant changes their mind will be simplified. If the booking is cancelled the spot will be available for other
3 Purpose, Aims, and Motivation
user to book or it will be offered to the first person on the reserve list. Thereby it will be easier to fill all the spots for an event.
QR-code ticket
After a booking has been confirmed, the user can access their ticket on the website. The ticket has an unique QR-code that will be scanned by the doorman before entering the event, making the identification process more effective.
3.1.2 Administrator aspects
Below the goals concerning the administrator aspects of the system will be presented and discussed. Creating event and customising the registration form
The event host will be able to create a registration form that will be available to the users of website. The form will create a standardised registration process that will help G¨oteborgs Nation manage all relevant data that is required to host an event.
Overview of the event participants data
All crucial information from the registrations of av event will be presented to the ad-ministration accounts. This way the hosts of the event will know how many people have currently registered, how many that have paid, and which guests with special food pref-erences there are. The hosts will also be able to convert all the guest information into Excel spreadsheets, as this was a specific request from G¨oteborgs nation.
Diet and food allergies
It’s important that guests with certain food allergies or diets are properly acknowledged. By having this information gathered in advance the chefs at G¨oteborgs Nation will easier be able to plan what to order. The system will make sure that the chefs know how many of each dish they should prepare depending on the diet and food allergy data.
Renting out the facility
G¨oteborgs Nation occasionally rent out their facilities and dining service to e.g. other student associations, dissertation events or private companies. By giving them tempo-rary administrative accounts, the renting hosts will be able to create their own regis-tration form and see all registered information on the website. The regisregis-tration data is then also accessible to G¨oteborgs Nation who have to prepare the dishes and the seating arrangement according to the renters desire.
Seating
The system will help the staff when creating the seating arrangements as the gathered information from the guest registrations can be exported and entered into the program Perfect table plan. The seating will then be available on the website for the guests,
making it easier to find where you are supposed to sit.
3.2
Working environment considerations
The Public Health Agency of Sweden (Folkh¨alsomyndigheten) annually collects data and presents statistics on the health and well being of the Swedish population. The study shows that from 2006 to 2018, the general stress level that a person experiences in the age population 16-29 have increased by 8 percentage points and in the population 30-44 it has increased with 5 percentage points [12]. Studying this data annually may only show a slight increase, but the calculation of the total percentage increase between 2006-2018 shows a more drastic change. In order to prevent this trend from continuing at the same rate, society has to improve in several different fields in order to benefit the health and well being of its population.
A contributing factor to many people experiencing stress, is feeling overworked. There-fore it is very important to contribute to helping develop tools that could lighten the workload for the people working in various fields, e.g. planning and organising events. QuickBook by itself will most likely not solve the overall stress level in the population, but may help to lower the workload for these particular individuals, and could come to be a small part of the endeavor of society to lower the general stress levels.
3.3
Environmental impact considerations
Another noteworthy aspect of this project is the environmental impact. Not having all correct information about the diets and allergies of the guests, as well as the possibility that some might be unable to attend an event, leads to food being wasted. The staff at G¨oteborgs Nation explain that there are rarely times where they have to throw away less than 10 portions. By keeping control of all applicant information and handling the reservation list online for all involved personnel to access, this risk is lessened. One of the aims of the project is therefore to lessen the negative impact on the environment with smart digital solutions.
QuickBook strives to be an actor in the Sustainable Development Goals established by The United Nations [32]. This contains of 17 goals and several targets under each goal, that have been developed by the member states to be achieved by 2030. These 17 goals can be summarized into four main topics that the countries together aim to achieve:
3 Purpose, Aims, and Motivation
2. To promote peace and justice.
3. To reduce inequalities and injustices in the world. 4. To solve the climate crisis.
In goal 12 target 2, The United Nations has written ”By 2030, achieve the sustain-able management and efficient use of natural resources” [33]. This goal is striving for sustainable consumption and production. By lessening the negative impact on the en-vironment with a digital solution as QuickBook strives for, will be a small contribution towards the bigger achievement.
3.4
Ethical aspects
Ethics is an important aspect to consider in software development [5]. It is not unusual that researchers have different codes of ethics, policies and principals to guide them within the span of what they consider to be ethically correct. It can be difficult to distinguish what is ”correct”, and it can be essential to have a method interpretation because these principles and rules may contradict one another and do not always cover all cases. QuickBook handles a lot of personal information, and when handling this type of data it is vital to know how one should handle it to protect the privacy of the person. Therefore, within the EU, we have The General Data Protection Regulation at our disposal.
3.4.1 Working with GDPR
When handling personal data such as login credentials and information from registra-tion forms, you have to process everything according to The General Data Protecregistra-tion Regulation (GDPR) [4]. GDPR exists to protect individual’s fundamental rights and privacy, in particular their right to the protection of personal data. The GDPR is applied throughout the EU and aims to create a uniform and equal level of protection of personal data in order to not disrupt the flow of data within Europe.
A general rule when dealing with personal data is that everything must be handled ac-cording to Swedish law. You should also be transparent to people whose information you store [3]. People should know why and how long their personal data will be stored, they should also know what data is saved and which people will have access to this data and why.
The core of GDPR consists of a few fundamental principles. The principles are ad-dressed to those responsible for personal data. A few principles will be adad-dressed in this project and these are as following:
• You must have support in GDPR to process personal data.
• You may only collect personal data for specific, particularly stated and legitimate purposes.
• You shall not process more personal data than what is necessary for the purposes. • You shall ensure that the personal data is correct.
• You will delete personal data when they are no longer needed.
• You shall protect personal data, for example to prevent unauthorised access to them and so they are not lost or destroyed.
• You should be able to show that you comply with GDPR.
In this case, when personal data is stored on a database, such as a special diet, email, as well as first and last names which is identifying information, it is important that the guests who sign up on the website know how their personal data is stored [1]. The conditions for consent have also been strengthened with GDPR as it clearly states that consent must be given in a clear, understandable and easily accessible form. The guests must therefore clearly know what they consent to when they sign up. When they register, they must understand the purpose of the use of their personal data given by this consent, with the help of understandable language. Guests should be informed directly how they can withdraw their consent. Finally, a person who manages the data must be able to show that a person has given consent.
When creating an account or registering for an event on Quickbook, the user has to tick a box that says the user consents to the website saving and using their information. The user is informed that only the staff at G¨oteborgs Nation will have access to this information and it will strictly be used in the context of event organising. There is also the possibility to unregister from an event and to delete a created account, after which all registered information is removed from the database.
3.5
Delimitations
One significant delimitation of this system is that it is designed for one specific organ-isation only. It would be possible to develop a more generalised system that could be
4 Related work
utilised by many different organisations, however this project focused on developing a system that is customised for G¨oteborgs Nation. Because of this, we could work to-gether with this organisation during the developing process in order to create a system that is as adapted to their needs as possible.
4
Related work
There are different applications with similar properties to QuickBook already on the market. Eventbrite, Guestlogic and Tickster are examples of these types of applications. They all provide different methods for simplifying the process of hosting or attending an event, and have both similarities to and deviations from the way QuickBook operates. In this section these examples are presented and their attributes compared to QuickBook are discussed.
4.1
Eventbrite
Eventbrite is a U.S based worldwide platform for creating, sharing and finding events [8]. Users are able to browse the website for information about upcoming events and to purchase tickets. There is a mobile application available as well, that can be used for example to save one’s tickets [9]. In order to create an event, a user must have an account on the website. Having an account enables the user, an organisation or a com-pany referred to thereafter as a creator, to enter information about the planned event which subsequently will be available for other users on the website. Eventbrite also al-lows the creator of an event to sell their tickets and to handle the payment process using Eventbrite’s service. The service is free as long as the event is free of charge, otherwise Eventbrite will charge a fee. Eventbrite offers three different packages for a creator to choose between when making an account: the essential package, the professional pack-age and the premium packpack-age. The later two give the creator access to more features on the website, but also charges a higher fee for non-free tickets sold. These extra fea-tures depend on the package chosen. With the professional package more tickets types are available and the possibility to create a seating plan is offered. Using the premium package enables having a customised partnership with Eventbrite that offer on-site staff support and rental equipment [11].
Whereas Eventbrite’s service is targeted towards a wider spectrum of events and types of creators, QuickBook is tailor made for a particular organisation. This enables the possibility to have features on website that are designed to aid the staff at G¨oteborgs Nation specifically, according to their processes and needs. This includes for example
the design of the form when signing up for an event, and the ability to export the par-ticipant data to the Perfect table plan program that’s being used by G¨oteborgs Nation. There is also no charge for using QuickBook to organise an event, regardless of the price for the tickets.
4.2
Guestlogic
Guestlogic is an online service that companies can hire to help them organise meetings and events. Their focus lays in working closely with their customers to create a cus-tomised service [18]. Guestlogic’s features include creating a tailor made website for an event, making digital invitations, and handling tickets and check-in at the event [17]. The price for using Guestlogic is calculated according to the amount of features that the hiring company wants to be included. The more features that are desired, such as a digital invitation, event website, qr-tickets or an event app, the higher the price becomes. As opposed to Eventbrite, as well as QuickBook which is completely free of charge, Guestlogic does not provide any services for free. Similar to QuickBook, however, Guestlogic provides services according to a specific company’s requirements. Where they differ from QuickBook is that a company hosting an event needs to contact Guest-logic personally and let them know which features they desire, which are then later provided at a calculated price. With QuickBook, which is developed for one specific organisation, all the tools needed for hosting an event are already on the website at their disposal.
4.3
Tickster
Tickster is a ticket selling system used by 3000 Scandinavian event organisers. Since 2007 they have been expanding their position at the market and are today one of the biggest ticket systems used in Sweden. Most of the clients are event organisers in the music, theater, sport and arena sectors [31]. When an event organiser has created an event they can choose to use Tickster as a ticket selling service. This system gives the organiser an platform from which they can manage, sell and observe the ticket selling process. As the main clients are from the entertainment sector the tickets are mainly an attendance booking, that means that a guest of an event books a seating at e.g. chair in an arena for a concert or a seat in an theater hall. These kinds of bookings that are provided through Tickster are directed to the public, there is not a possibility today to make the booking only targeted for specific clients e.g. only students at Uppsala University. Tickster takes a share of each sold ticket, but they let the event organiser set
5 Methods
a service fee which they can keep. The tickets an event guest receives after payment are mainly in digital format as an email with a QR-code. This code is then scanned at the event location by using an application provided by Tickster on a smartphone.
Since Tickster is mainly for the entertainment sector they don’t have the alternative for guests to individually announce their food allergies. This is because most of the events are not in a form where food is being ordered in advance or even don’t have food at the event. Because Tickster is providing tickets to the open public this would not be convenient as an alternative for G¨oteborgs Nation. In this project the focus is on a specific customer group which is only students that have access to the student nations clubs in Uppsala. The targeted group is smaller and often for a different kind of event than in the entertainment sector and this makes the alternative for taking in the guests food preferences convenient. One more reason the QuickBook system is more suitable for the event selling process then Tickster is that QuickBook is an in-house development and thereby does not have a fee per ticket as in Tickster.
5
Methods
All the techniques, methods and systems used during the project is discussed in this section. It also covers why these choices were made and what made these methods well-suited for this system in particular, as opposed to other possible methods. It also discusses some alternative design choices and why they were ultimately not used.
5.1
MERN stack as developing environment
MERN Stack is a combination of technologies used to create premium web apps [28]. It is a JavaScript stack that helps make the development process smoother [40]. The MERN stack was used when developing this project, along with all its frameworks, libraries and database control. MERN consists of various open source components: MongoDB, ExpressJS, ReactJS and Node.js which can be seen in figure 1. All com-ponents provide an appropriate framework support for developers to work with when developing an application [28]. This made it a good choice for our project, which con-sists of a number of different parts such as the database and the website, as it provides frameworks for all of them. The system require easy-accessible and user friendly tech-nologies as it will be passed along to the G¨oteborgs Nation and maybe other developers in the future. As the MERN stack is well-known and well-documented, there is a lot of information to find online as well as literary information. The stack is also well-tested and user-friendly, thus a very good alternative for this project.
Figure 1 The MERN stack
5.1.1 MongoDB
MongoDB is a document-based, open source database tailored to the needs of the user. It is user friendly in order to be as relevant as possible for the developer [28]. This made it a good choice for this system since it may require storing a lot of data from all the users and events. MongoDB is a NoSQL database, and such databases can be structured in four ways: key-value stores, documents, columns and charts [34]. While SQL databases structure their data with tables, rows and columns, MongoDB stores data as documents in BSON (Binary JSON). These documents are self-descriptive, hierarchical tree data structures [24]. Related information is stored together in key pair values for quick access through the MongoDB query language [28].
Quick access and easy accessible information is also very relevant for QuickBook since we are working with guest registrations where fast data access is important when check-ing if an event is full and the site is under a lot of pressure from users. In milliseconds the system must be able to determine whether or not it is possible to register for an event or if registration should be closed.
5.1.2 Node.js
Node.js is a free open source server environment that runs on multiple platforms [37]. Node.js runs single-threaded, non-blocking asynchronous programming. The result of this is that Node.js eliminates the waiting when handling a file request as well as being
5 Methods
very memory efficient. Node.js have multiple functions such as collect form data, add, delete and modify data in the database and much more, all of which is necessary to be able to do when creating an event planing system.
Since Node.js runs single.threaded it is not appropriate for large scale applications but rather smaller ones, such as QuickBook. When using Node.js on smaller applications the result is the other way around and the environment is a really fast option to use. The fact that Node.js is open source means that the environment will always evolve and there will be an incredible amount of documentation. Which is important if this web application is to be further developed or passed along to another party.
5.1.3 ExpressJS
ExpressJS is a web and application server for Node.js, namely a framework [30]. To-geteher with Node.js they form the back-end component of the MERN stack [28]. Ex-pressJS has several features that make it easier and more efficient to develop rather than if you had used Node.js alone. ExpressJS also simplifies routing by making it easy to route the application based on HTTP methods and URLs. As QuickBook is a web ap-plication this is also very much-needed for this project. ExpressJS is also specifically developed for Node.js to make the handling of Node.js easier and more manageable and therefore very suitable when using exactly Node.js.
5.1.4 ReactJS
ReactJS is an efficient and flexible Javascript library used to build user interfaces [29]. Simply explained, a Javascript library is a collection of previously made functions that you use when writing Javascript[25]. Thus, a library makes it easier to write complex code. ReactJS is developed by Facebook and in addition to Facebook, the giant Insta-gram is also built using ReactJS, which indicates the library’s quality and efficiency [41] [26]. In web development ReactJS is only front-end based, ie what you see on the website, but is later linked with the back-end components MongoDB, Node.js and ExpressJS [28].
The advantages of ReactJS is the very fast learning curve which makes it appropriate for this project, which is limited in time. ReactJS is also a secure language where the actual code is hidden from the user and is therefore very appropriate for this particular sys-tem since it manages login syssys-tem, password handling and personal data management, among other things.
5.1.5 HTML and CSS
HTML stands for HyperText Markup Language [36]. In short, this means that HTML is a markup language, also called page description language, and not a programming language. HTML controls the front-end section of your website. It is essentially HTML that enables the use of titles, subtitles and paragraphs, for example.
CSS stands for Cascading Style Sheet [23]. It simply means that the language is a style template, also called style sheet language. Like HTML, this is not considered a programming language, as it lacks the ability to execute real commands. At the same time, CSS relies on a tag language like HTML to do something. By using tags on the ReactJS components or the HTML elements, it is possible to manipulate the titles, pictures, buttons, lists etc. using CSS.
Since HTML and CSS are two of the most common languages for web design [35], they are easy to handle together with ReactJS and there is also an incredible amount of documentation on both. They do not have the same capabilities as ReactJS has but are good to complement and manipulate react components with.
5.2
Using QR technology
A QR code, or quick response code is a type of matrix bar code. It was first created by a Japanese company named Denso Wave in 1994. The main purpose was to track car parts during manufacturing, but since then it has been used in many other areas e.g. tickets. It is machine-readable and stores some information of choice, and is thus often used for identification purpose [6]. This is an easy way to distribute tickets and the like, and using a camera with a reading application that is able to scan the code individuals can easily be identified and checked off. This is a technology that can be utilised in a number of different areas which enables development of new features of a system quite easily. In this system, the qrcode.react package is used and implemented with npm install also known as Node Package Manager, a part of the open-source Node.js projects. Since Node.js is used in this project, the easiest and most compatible package to use is an npm package.
5.3
Potential design alternatives
Many decisions were made regarding design, different techniques and different lan-guages used during this project. Why these were chosen was explained in the section
5 Methods
above, but there are also other design decisions that were discussed but later on rejected. The section below discusses exactly what these were for some elections and why they were rejected.
5.3.1 MEAN stack
An alternative to the MERN stack is the MEAN stack[28]. They are both very useful, popular and powerful in web development. The components included in the MEAN stack are the same as MERN except that AngularJS is used instead of ReactJS. The discussion between MEAN and MERN is really a discussion between AngularJS, a JavaScript framework, and ReactJS, a JavaScript library. A framework sets the standard for how the code is written and should be formatted, while a library allows you to determine the design yourself.
The main advantage of ReactJS is that the library is better when it comes to performance and is therefore quicker to dynamically update and also, as previously mentioned, has a faster learning curve. The main advantage of AngularJS, on the other hand, is that the ”language” is actually a framework and not a library. Thus, there are rules and conditions to adhere to and much has already been predetermined. The result of a framework, rather than just a library, can therefore be a more organised and consistent code. However, the focus area for this project when choosing a stack was a fast learning curve and a language without too many rules, as rules can easily lead to problems that are difficult to overcome. Therefore the MERN stack was more appropriate for this particular project.
5.3.2 Mobile application
An alternative way of designing this system would have been to create a mobile appli-cation, instead of a web based one. This would have made the user side of the website more adapted for mobile use, which is most likely the way many people will view the website. However, the administrators at G¨oteborgs Nation would still need a web based system for them to interact with and to use when creating events, which would result in that two different applications are required. Another important thing to keep in mind is the different operating systems available in today’s smartphones. In order for an app to be compatible with various operating systems, these apps must be developed in differ-ent ways. This is time consuming and ineffective towards creating a website that can be loaded into the browser of any operating system. Due to this it was ultimately decided to only focus on one type of application, a web-based one.
5.3.3 Using Eventbrite’s API
Another possible method for creating the application would have been to use Eventbrite’s API. As explained in section 4.1, Eventbrite is a platform for creating and distributing events, and they also provide an API for customers to use when creating their own web-sites or mobile applications [10]. The API provides functionality to push and pull data to and from Eventbrite, customise the checkout process and to integrate the application with Eventbrite to promote events and receive real-time updates. This would simplify the process of creating our own website with many functionalities already in place to use. Despite this it was decided against due to G¨oteborgs Nation’s desire for a cus-tomised website that fits their specific needs and working processes. Something that was also taken into consideration was the risk that Eventbrite’s API would be redone, removed or become expensive and therefore it was more secure and cost-effective to develop the application itself.
5.3.4 Combining current systems
QuickBook is meant to be able to export data to be used in the Perfect table planner pro-gram, but it has its own registration format as well as its own interface. An alternative discussed was to combine the systems used today, i.e. Google Forms, emails, Perfect Table Planner and Facebook. This alternative would require access to the various sys-tems APIs, which in turn can be difficult to work with in order to adapt the system as G¨oteborgs Nation wanted it. The risk that these APIs would be regulated or changed was also discussed and the importance for the nation to have a few specific features such as the ability to convert all lists to Excel spreadsheets and the ability to lend the system to external providers outside the nation.
With all these requirements taken into consideration it was therefore decided that the best system for G¨oteborgs Nation and for the applications long-time survival would be to develop the web application from scratch and thereafter combine it with the Perfect Table Planner only.
6
System structure
In this section the system, titled QuickBook, will be described. QuickBook is a client-server model and consists mainly of two parts, the front-end and the back-end. This section describes how these parts collaborate, communicate and how the systems work individually.
6 System structure
6.1
Description of the Model-View-Controller pattern
Model-View-Controller (MVC) is an architectural pattern used in system development [7]. By using MVC there is a separation of the concerns, meaning a separation of the front-end and the back-end code which are parts that at an abstraction level have nothing to do with each other. In the MEAN stack, AngularJS makes up the entire MVC-pattern but in the MERN stack, the division is more abstract. In this project the front-end code makes up the objects that you see on the screen using ReactJS, HTML and CSS. Sep-aration of concerns (SoC) was used in order to separate data (Model) and presentation (View) so that the data management does not have consequences due to changes being made in presentation layer, and that data can be reorganised without having to change the presentation layer[13]. MVC solves this problem by separating data and business logic from presentation and user interaction, by introducing an intermediate compo-nent: the Controller [7] [38], see figure 2. In QuickBook you can see the controller as a combination of ExpressJS and Node.js which handles the communication between the front-end, View, and the back-end, Model, i.e. the communication betweed ReactJS and MongoDB using ExpressJS and Node.js.
Figure 2 MVC architectural pattern
• Model is the domain-specific representation of the information that the applica-tion handles. Model is another name for the domain layer. For example, domain logic can be to check if a person is a member of G¨oteborgs Nation or to check what
place in the reserve list a person has. In this system, MongoBD, a non-volatile storage medium, i.e a database, will be used to store data.
• View renders the model into a form suitable for interaction, normally a user inter-face. In this system, this is what is rendered in the web application, ie ReactJS, CSS and HTML code and the part that dynamically retrieves data for the repre-sentation is the model.
• Controller processes and responds to events, such as user interaction, and can induce changes in model and view. If the user enters data or presses a button, it is then the controller that decides what should be done, whether something should be updated or if e.g. an error message should appear. The controller then calls the model with the information needed to update the page. In this system this controller is Node.js combined with ExpressJS.
6.2
The user interface
The front-end consists of the QuickBook website, which is the interface for the users and administrators when interacting with the system. As previously mentioned, this was created using ReactJS, HTML and CSS. When it came to the front-end, i.e. what the users and administrators see, it was important to have intuitive and simple pages to follow. This you can particularly see in the buttons that always stand out in colour choice, and in the consistency of the design throughout the different pages.
Something that can be seen in the design in figure 3 is that a clean and simple look was prioritised, excluding unnecessary elements that could possibly confuse the user. Each administrative page has the same overall design, which is distinctly more neutral in colour than the user pages. This is due to wanting to avoid lots of visual impressions for the administrators, where the functionality is prioritised. On the user pages, however, a more colourful design was chosen, especially for the front page. This was because we wanted a more inviting look for the pages that the users see, as well as a front page that stood out and inspired a more fun look which fits the website’s purpose of distributing events.
The colours chosen in the application are based on the wishes of the first curator of G¨oteborgs Nation. They wished that the colours would match the colours that they use in various places within the nation, e.g. their own website. The softer colours have been used as background colours, and the brighter ones that more easily catches one’s eye have been used for example as button colours. In figure 3 this is displayed with the dark blue background colour and the contrasting bright yellow button.
6 System structure
Figure 3 User front page of upcoming events
6.3
The underlying back-end systems
The front-end fetches data from and saves data to the database, which is storing the information about events, users and registrations on the server. When an administrator creates an event, the information about this event is stored in the database. The same information is then fetched when displaying the event on the website for the users. When a user registers for an event the entered information is saved in the same way. It is then fetched by the administrator side, where the administrators can monitor and use the registration data. The administrator also has the ability to export the registration data in a table format, which then can e.g. be uploaded in a table seating program. As mentioned in section 5.1, QuickBook is based on a MERN stack structure. This mainly because it’s a covenant and reliable system structure and comes in handy with developing web applications such as Quickbook. The database that’s being used in the backend is MongoDB. When an administrator or a user performs any CRUD-operations (Create, Read, Update or Delete) in the web application it all is being managed in the database by MongoDB with help from the Object Data Modeling (ODM) library Mon-goose. When a person performs a CRUD-operation the ODM library makes sure that the code is translated and represented in the right way, by following the database schema that’s been constructed in each collection in the database.
The database contains three collections: event, profile and guest registration, see the relational schema in figure 4. Each event that’s being created gets a unique id in the event collection. When a user creates a profile in QuickBook, they get a profile with an unique id that’s being saved in the profile collection. When the user then makes a booking to an event, the booking request is then saved in the guest registration
collec-tion. The guest registration collection is then containing the crucial information such as event and profile id from the other collections. This leads to one being able to determine what event a user has booked, the food and beverage preference and the payment status.
Figure 4 Relational database schema of QuickBook. The database contains three col-lections: Event, Guest registration and Profile.
7
Requirements and evaluation methods
Two of the requirements given by G¨oteborgs Nation were that QuickBook has to work on different devices, and that it should be accessible and easy to use for the users. To evaluate the first requirement QuickBook will be used on different virtual devices with different operating systems. This will make it possible to see if all the different func-tions behave as expected and that all pages look the same on any device. The devices tested where both Apple phones and computers as well as Android phones and Windows computers. When it came to the second requirement a different method was used. One way to test if the system is easy to use is to conduct user tests. Thus the method chosen was to perform test where the test persons are given two different tasks to perform and a questionnaire to answer. The first task was to go to the homepage of administrators and create an event with specific parameters and the second one where to create an ac-count, sign in and then register to the event created earlier. The questionnaire contains questions relating to the overall experience and possible difficulties encountered during the tasks and where answered after performing each task. The evaluation was decided to be considered finished when all of the test persons managed the tasks without having to ask questions, not taking longer than 3 min per task or having a significant complaint about a certain feature.
8 Using QuickBook
8
Using QuickBook
In this section it is explained in greater detail how the system is used, both from the user’s and the administrator’s perspective. It is also discussed how data is handled and what is important to keep in mind when using this application.
8.1
User flow of the booking system for guests
When a user first visits the QuickBook website they are greeted by the home page, which can be seen in figure 5. The choices the user has here are:
1. to scroll through the events and go to the booking page for any of the events by pressing ”To booking”.
2. to sign up at QuickBook by pressing ”Sign up”.
3. to press ”My Event” and thus ”semi” log in using reservation number and email and thereby be able to see their ticket and their booked event.
4. to log in and see their booked events, their profile and their tickets by pressing ”Sign in”.
Figure 5 The front page that pops up when a user first visits the QuickBook web appli-cation (right picture scrolled down version of left picture).
1. When pressing the ”To booking” button on any event, the user is greeted by the guest registration form which you can see in figure 6. Once here, the guest will be asked to enter their personal data in order to sign up for an event. When the user later have registered, a confirmation email will be sent to the person’s email with a confirmation number. This number can later be used in order to view their ticket on the website under the ”My Event” button in figure 5.
Figure 6 The QuickBook user booking page. Here, the user signs up for an event.
2. If the user instead clicks the ”Sign up” button, the person will be redirected to QuickBook’s sign up form which can be seen in figure 7. Once here, the user can create an account to more easily get an overview of all events that they have registered for. The user will also be able to save their personal data in order to more easily and quickly register for events.
Figure 7 QuickBook’s sign up page for users
3. When you press ”My Event” as a user, you will be requested to enter your e-mail and your booking number in order to get the information about your ticket. If you are in the reserve queue you will also get information about what place in the queue you have in that case. In figure 8 you can see how the ticket is presented to the user in the case where the user has a seat at the event to the left and in the case where the user is in the reserve queue to the right.
4. When the user presses the login button, it will be routed to figure 9 where they can enter their login details and then be forwarded to figure 10. Here they can see their profile, saved personal data and also their events. The user can choose to edit their profile, to view an event or to view their ticket for a specific event.
8.1.1 User flow of the booking system for administrators
When an administrator first visits the QuickBook website they are greeted by the login page, which can be seen in figure 11. Here the administrator enters their login
informa-8 Using QuickBook
Figure 8 QuickBook’s ticket page for users. Here the user is either presented with a ticket or a place in the reserve queue depending on whether the person already has a seat at the event or not.
Figure 9 QuickBook’s sign in page for users
Figure 10 When a user has logged into their QuickBook account this page is presented to them. Here they can see their profile, saved personal data and also their events. The user can choose to edit their profile, to view an event or to view their ticket for a specific event.
tion and is later redirected to the home page for administrators. When an administrator is logged in they are first presented with figure 12. The choices the administrator has to proceed with here are:
1. to create an event by pressing the ”Create event” button.
2. to create an administration account or a semi-administration account by pressing the ”Create account” button.
3. to edit the already existing user and administrator accounts by pressing ”Edit ac-counts”.
4. to edit the master administrator account, i.e. the account run by the curators at G¨oteborgs Nation, by pressing ”Edit master admin”.
5. See information regarding a specific event by pressing the name of the event in the event list in the top right corner.
Figure 11 QuickBook’s sign in page for admins
Figure 12 QuickBook’s first page when logged in as an administrator (right picture scrolled down version of left picture)
8 Using QuickBook
Figure 13 QuickBook’s create event page for admins. Here an administrator can enter all the desired data for an event and when created, the event will appear for users on the front page of the website.
1. When an administrator is going to create an event figure 13 is presented to them. Here they can enter all of the information needed to present an event for guests. When the desired information is entered, the administrator presses ”Create event” and then the event appears on the front page for users, see figure 5.
2. When the administrator wants to create a new administrator account or a semi administrator account and presses the ”Create account” button, figure 14 is pre-sented to them. Here they can create a new account and also decide what kind of administrator the new account will be by changing the status to semi admin. If G¨oteborgs Nation is going to rent out its nation to a third party, they do not want to make the person hiring a full admin, but then a semi administrator is a good choice. This does not give full access to the system but limits its use to a specific event only.
3. If an administrator wants to change settings for any account, delete accounts or possibly change the status of an account and presses ”Edit accounts”, this is done here in figure 15. This can be done e.g. if someone has become an official within the nation and this should be added, if someone has misbehaved and should be
blocked from events or if a user is duplicated or inactive and the account should be removed.
4. When an administrator presses a specific event on the front page, information about that event appears on the same page but further down, see figure 12.
Figure 14 The page where administrators create a new administrator or a new semi administrator account for people handling event at G¨oteborgs Nation.
8 Using QuickBook
Figure 15 The page where administrators edit accounts, both user and administrator accounts.
8.1.2 User flow of the booking system for doormen
The staff that works at the door and should help identify the people coming to the event is called doormen during this project. The staff at G¨oteborgs Nation will have a joint account for this purpose as all of the information will be saved in one place and there is no need for personal accounts for this purpose. When a doorman first visits the QuickBook website they are greeted by the login page for doormen, which can be seen in figure 16. Here they enter the login information to proceed to the first page for doormen, which is seen in figure 17. Here the doormen are presented with two different choices:
1. see the guest list for a certain event. There they can double check how many of the guests have arrived and also manually check them off the list. This is displayed in figure 18.
2. open the camera to scan tickets to a certain event. When a ticket is scanned, the person is checked off the guest list, see figure 19.
Figure 16 The login page for the staff that works at the door at an event, i.e. the doormen.
Figure 17 The first page that is presented to the doormen when they are logged in to the QuickBook page.
9 Evaluation results
Figure 18 The guest list presented in the QuickBook application when clicking on the guest list icon for a specific event, logged in as a doorman.
Figure 19 The scanning function of the QuickBook application. Here you can see how the scanner opens up when logged in as a doorman.
9
Evaluation results
Testing the system using different devices with different screen sizes and operation sys-tems, showed that it is not optimal to use the system with a phone or other device with
a small screen. It also showed that the design looks slightly different on Apple-devices compared to Windows-devices but not dissimilar enough to be considered a problem. Before mobile devices can show the website in an satisfactory manner, that particular requirement from G¨oteborgs Nation is not fully met. This should not take too long to provide, however it is regarded as future work for now.
The user test, where test persons performed a number of tasks and answered a question-naire, showed an overall positive response to the user interface. There were some parts of the design that some experienced as a bit unclear and not intuitive when using; the survey can be found in B. The feedback was taken in to consideration and the design was altered accordingly. For example were red symbols added on the mandatory fields when registering for an event, and a more visible home button in the header of the page. After implementing the feedback on the system, we deemed that the requirement of a system that is easy to use had been fulfilled.
G¨oteborgs Nation were very satisfied with QuickBook at the final demonstration. They felt like their feedback and requirements had been heard as well as implemented into the system. They believe QuickBook could make an impact and reduce their workload when organising different events, especially when working with other organisations. They stated that they would like to use QuickBook once the final functionalities are put into place and the system can be officially launched.
10
Results and Discussion
This section describes the results that have been achieved during the project. The results are reviewed and reasons to why they look this way is discussed. It also touches on what could have been done differently to achieve a different result, and whether the result in the end was as intended.
10.1
Results
A web application that appealed to G¨oteborgs Nation in terms of design and the most significant functionalities was successfully created. In section 3.1 it is mentioned what the original goals were and a large part of these goals were met, but unfortunately not all.
On the user side, the goals were met regarding an overview of all events on the front page, as well as the ability for users to create accounts, save their data, register for events
10 Results and Discussion
and to see all their registrations. Users can also get their ticket as a QR code, both with an account and without one. If a user chooses not to create an account, they can still easily access the ticket on the website using their email and booking reference. The goal regarding being able to cancel a tickets is also fulfilled.
Regarding the administrator side, the majority of desired functionalities were fulfilled. Firstly, the administrators can easily create events that automatically show up on the first page when visiting the QuickBook application as a user. The ability to customise event registration forms for the different events is also fully implemented. administrators get an overview of all created events on their home page, where a chosen event’s complete information and participant data can be viewed. This information can be exported as an excel file to be used in their table seating program or for other possible usages. Created events can also be edited by the admin, and received payments from a guest can be registered in the event’s participant list.
When registering for an event, the most common diets and allergies can be chosen from a list in the registration form, and other allergies not in the list can be written in a free text field. All this information is visible to the administrators and can be compiled in the exported excel file. However, there is no functionality for grouping guests with the same diets together or to recognise key words in the free text fields. Thus the goal to easily be able to handle the guests’ food preferences is partially fulfilled.
One of the goals that unfortunately did not come to fruition was the reserve list func-tionality, which is not implemented in the finished product. Currently only the number of participants that is stated as the maximum amount for an event are able to register. The possibility for users to transfer tickets to other people instead of canceling was abol-ished as well, due to time. Finally, the system does not currently completely adhere to the GDPR requirements, as complete information about how and why data is stored and use is lacking, as well as securely handling passwords and access to pages.
10.2
Discussion
Overall when looking at the results we are very pleased with the application. The most important of the functionality is currently included in the application, and it is possible to test the usability of the system. Even though QuickBook is not fully completed, G¨oteborgs Nation is still interested in the system if it were to be finished in the future. We see this as a success, since they are overall very satisfied with how it looks thus far, and because they believe that this application would be of great use to them in their work.
tests were very positive and both the test persons and our stake holder at G¨oteborgs Nation appreciated the design. The goal was to create a simple design that would not be cluttered with information and easy to interpret and use, and that was successfully achieved in our opinion.
The reason that not all goals were reached was mainly because of the time constraint. Since we are currently in the midst of a global pandemic due to the Covid-19 outbreak, there was little possibility to meet and to work close together. Because of this, certain things had to be postponed and the affect on the ability to communicate led to some difficulties when merging different parts of the system. This aside, we see no great obstacle to completing the product if more time was given.
When developing the product the front-end was designed first, and the back-end was implemented and merged later. If the opportunity had been given to redo the project, we would have chosen to develop the back-end first, as it became slightly problematic and time-consuming to do the opposite. This combined with the requirements of system would have given the best possible outcome, because more time could be given to finish more functionality. When it became clear that time-consumption was a problem we had to prioritise the requirements, where e.g. the ability to transfer tickets was given a lower priority.
Compared to the related work discussed in section 3.5, this system is more useful specif-ically for G¨oteborgs Nation as it has almost all of the functionalities they required. The specific feature that all related systems lacked is the ability to give access to the system to renting organisations, which QuickBook provides. The other systems are, of course, fully developed and fully functional, but the important aspects that G¨oteborgs Nation require of the system can be implemented. If this system was to be further developed, it has the potential to provide the nation with all functionalities that they desire.
11
Conclusions
The result and the project can be summarised into a functional web-based booking sys-tem, but all the goals that were set were not met. It was nevertheless clear that the functionality of the system is something that G¨oteborgs Nation is interested in. Af-ter a discussion with the curator at G¨oteborgs Nation it was made clear that if all the functionality that we had started working on was finished, the system would be highly appreciated.
The conclusion is therefore that the project was successful as it still managed to get concrete requirements and needs from G¨oteborgs Nation. The functionality on the other
