Event-Management Project
(Seat Booking Tool)
OVERVIEW
Technical details
Frontend
Backend
1
1
1
1
TARGETS / ‘MILESTONES’
2
FEATURES
Basic Website/Tool
User attributes / data
UI-Mockups
Visitor-View Mainpage (not logged into an account)
Logged in, normal user; seeing an overview of the current event
Logged in admin; Viewing the normal site as a regular user. Additional options in
Navigation
Login-Form (light mode)
Registration form (light mode)
Permission system
Basic permission system
Events
Attributes
Token
Token Attributes
Basic seating
Creating a new seating plan (admin)
Seat plan attributes
Adding/Removing seats to seating plan (admin)
Other Admin-Stuff regarding seating
Seat attributes
Seat colors on grid in UI
Mockup
Advanced seating
Grouped seats
3
3
4
5
5
5
6
6
7
7
7
7
8
8
9
10
10
11
11
11
12
13
13
13
13
Documentation
14
OVERVIEW
A web application for planning events, including seat booking (a web-shop is NOT required to be
developed. When users are buying tickets, they get a ‘token’ (UUID sent via mail)), where users
are able to create an account and use the web app for all communication and actions while being
a guest at an event.
Pretty much all functions shall be doable within the web app, like the layout of the seat plan,
creating the Event-Object and basic user management (eg. re-seating a user) etc.
Of course not any user shall be able to create events, seat plans etc.
Therefore a simple permission system will be required.
In order to keep it simple, hard roles (USER, ADMIN) where any configuration steps are on an
Admin-UI, only accessible by admins, would be enough.
A bit of background and what we used to do, as this tool doesn’t exist yet, can be read in
Feature - Events - Token
Technical details
The code MUST NOT be obfuscated and shall be documented for further development of the
tool.
Frontend
As frontend, MaterializeCss (https://materializecss.com) will be used.
Some Mockups and semi-working UI are already made by me and can/shall be used and
extended.
Some UI-Work is definitely needed. UI-Work on your side doesn’t have to use MaterializeCss. you
may build these parts in with simple styling etc. Materializing it would be done by myself
afterwards than.
Backend
A MariaDB/MySQL database will be used as the backend. Some table definition ideas are already
in the document. These are by no means complete, fully working or anything and need to be
extended by link tables, further attributes etc.
1
TARGETS / ‘MILESTONES’
This is just a list to give a quick overview of the project and the parts of it. Each feature is
specified in detail with images/mockups within the chapter ‘Features’.
1.
Basic website functionality:
A ‘router’ and web-server is implemented to serve the frontend when calling a path.
The frontend is based on templates, combined by the Golang code. Templates are easily
editable.
Users are able to register and login on the web application.
A permission system is implemented to grant access to configuration-features (creating
events, seating plans etc.) only to admins.
Editing/Adding text would be great if possible directly in the web application without
needing to touch html-files. Multi-Language support would also be a nice addition, but
both isn't a deal breaker if not implemented.
2. Creating ‘Events’:
An Event may have multiple seating plans and attendees (‘registered’ users for a specific
event. registration is not the same as ‘registering a new account’ and more like ‘link user
to token so he has access to the event’ as tokens are generated for each event and
therefore directly linked to an event. see Token for further information)
Admins can create these Events within the application (Title of the Event, starting day,
max. attendees, ...). All targets/features below are Part/’Childs’ ’of an event and therefore
linked to an event.
3. Basic seat booking:
Logged in Users, registered for an event, are able to select a seat on the seating plan to
book or reserve that seat.
Each seat can only be booked by a single user.
Admins shall be able to configure the seating plan on the website (and not by using
config-files or in-code).
The seating plan is a grid. It should be possible to add an image as background.
4. Advanced seating system:
There are 2 types of tickets resulting in “Normal” and “Team” users. The type is an
attribute of the tokens.
Therefore multiple ‘seating plans’ must be possible to create for an event. Also the
booking and reservation actions must be dependent on the token-type the user got.
Users shall be able to see information of seats ‘in the other area’, but not able to
book/reserve seats in an area apart from their bought ticket type.
2
Also the ticket type ‘Team’ is basically 5 tickets (and therefore 5 tokens) for a cheaper
price, intended for teams of players to buy and sit together.
A ‘grouping’ of seats should therefore be possible. If a user, signed up to the event using
a ‘team’-token, books a seat in the correct area, his selected seat is booked (and linked to
his token/user) and the other 4 seats of the group are simultaneously planned/reserved
for the other 4 tokens of the team.
The Layout-creation shall therefore also be able to create 5 seats at once and group them
together.
FEATURES
Basic Website/Tool
This might be a usable sitemap for the application; at least that’s what I planned a time ago. Feel
free to adjust as needed. I believe you know better what will result in a better user experience:
●
/
Main page for visitors (not logged in visitors of the site)
○
/registration
registration wizard to create an account
○
/login
login-form to log into an account
○
/admin
Admin-UI to create Events, manage seating plans, users, etc.
eg.: /admin/event/<VISIBLE_ID>/seating to configure seating plans for the Event.
○
/event/<VISIBLE_ID>
‘Dashboard’ of the event <VISIBLE_ID>. Contains user-specific and other dynamic
data apart from ‘static’ content.
Contains seating plan(s) for users to book/reserve their seat.
If easier to implement, the seating plan and booking can be ‘outsourced’ to
/event/<VISIBLE_ID>/seating.
All seating plans shall be on a single page, tho!
○
/profile or /account
Users can see their data and change it.
Login-Sessions stored in a cookie (for auto-login, or dark/light-mode) shall be included as well.
3
User attributes / data
Data-Type
Attribute
Description
ID
Primary Key
internal id of the user dataset
UUID generated on creation
EMAIL
Unique, Not null
e-mail address used for logging into the account
PASSWORD
Not null
password of the user. MUST BE encrypted (obvisually)
varchar
FIRST_NAME
Not null
varchar
LAST_NAME
Not null
varchar
STREET
Not null
varchar(8)
HOUSE_NO
Not null
varchar as some house-numbers are like ‘12A/B’ etc.
varchar(8)
ZIP
Not null
best saved as varchar (as some of our visitors are from other
countries, and I’m not sure what their zip-codes look like. 8
chars should be enough tho)
COUNTRY
Not null
date
BIRTHDAY
Date
timestamp
CREATE_DATE
DB-Timestamp of data-set creation
boolean
LOCKED
if ‘true’ the user is unable to log in
timestamp
LAST_LOGIN
DB-Timestamp of last login
varchar(8)
PERMISSION_
LEVEL
if only the basic permission system gets implemented
Permission-Level of the user
USER - normal user without any special access
ADMIN - access to admin-UI, able to create events, seating
plans etc.
varchar
if advanced permission system is implemented; a single
attribute surely won’t cut it, so further designing of the
database structure in that case will be needed by you.
4
UI-Mockups
Visitor-View Mainpage (not logged into an account)
Logged in, normal user; seeing an overview of the current event
5
Logged in admin; Viewing the normal site as a regular user. Additional options in Navigation
Login-Form (light mode)
6
Registration form (light mode)
Permission system
Basic permission system
At least these 3 Permission-Levels are needed within the tool:
●
●
User:
○
Default
○
Can register for Events using a token
○
Can book a seat and plan seats (up to 3) in the seating plan of an Event
Admin:
○
Access to Admin-UI
○
Specific includes in template (eg. navigation item to get to admin-ui)
○
Create Events
■
○
Configure seating plans, etc. for events
Permission is given via Database (only)
Events
An Event is basically just an organisation object to group multiple things together.
Childs of an Event will be Tokens, Seating plans, Users (signed up to the event using a token) and
more in the future.
7
Attributes
Data-Type
Attribute
Description
ID
Primary Key, Not null
internal id of the event object
UUID generated on creation
varchar(32)
VISIBLE_ID
Unique constraint, Not null
Visible ID shown in admin-ui and used in routing (eg.
/event/lan1/...)
Generated by default as ‘event<Number of entry>’ and editable
by the admin in the ui when creating an event.
Number of entry: count over the EVENTS-table + 1
varchar(64)
TITLE
Title of the event; Header on the ‘Main-Page’ of the web-app
after logging in (as the ‘detail’-view of the event is shown)
timestamp
START_DATE
Start-date and time of the event
timestamp
END_DATE
End-date and time of the event
int
MAX_GUEST
S
Amount of users able to ‘sign up’ for the event.
Depends on the tokens being generated for the event → sum of
‘standard’-type tokens and ‘team’-tokens’
varchar(16)
STATE
status of the event
hidden - Event is only visible to admins in the admin-ui.
Detail-view of the event is only accessible for admins.
Default after creation.
open - event is active, and shown directly on the ‘main’-page to
logged in users. Users can sign up for the event using a token.
afterwards they see the ‘detail-view’ of the event including
seating plan etc.
closed - the event is ‘archived’. Admins shall only be able to
change text (if a feature of your implemented CMS in general).
No creation or editing of any sort (besides text-editing) to the
seating plan etc. It is intended as read-only (also for users who
were signed up to that event)
Token
As i am talking pretty often about these ‘tokens’ i guess it’s a good idea to describe what i mean
with that.
8
There is already an online-shop to sell tickets. After ordering a ticket, the user got a ‘token’ (UUID
as a string) within an email, that we had ‘linked’ to an ticket-type in another excel. Seat
reservation was done using a publicly readable excel, created for each event by hand. For the
user to ‘book’ a seat, he head to fill out the information from my registration form and paste his
token into a field, so that we knew whether he should be able to book a seat in the area he
wanted (due to the ticket-type linked to his token) and that he actually bought a ticket.
We did it like that for 2 events. And as you may guess for 200+ people for the first event (and
100+ because of the pandemic for the second) it is an unbearable amount of labour…
Therefore within an event on the Admin-UI I shall be able to generate a bunch of tokens with a
few clicks. Perhaps in a tab of the web app ‘Tokens’ i have a dropdown to select the type
‘STANDARD’ or ‘TEAM’ and a field next to it to enter the amount of tokens i want to generate.
After clicking a button, the tokens (uuids) are generated and linked to the event in the database.
Below these fields to generate tokens, a table lists all generated tokens (and a clickable link to
the user, if already used by one. Tokens not linked to a user should be deletable (in case I
generated too much of the wrong type).
I don’t know the best way to link a user to a token, after using it to sign up for an event with it.
Probably I would have attached the user ID as a foreign key to the token itself.
Better ideas/practises are welcome.
Token Attributes
Data-Type
varchar(16)
Attribute
Description
ID
Primary Key, Not null
internal id of the token, send to users when ordering a ticket
UUID generated on creation
EVENT_ID
Foreign key, Not null
ID of the event, this token is generated for
TYPE
Not null, default ‘STANDARD’
Type of the token
STANDARD or TEAM
USER_ID
Foreign key
links to user-id who used the token to ‘register’ for the event
GROUP_ID
UUID generated on creation of tokens with type ‘TEAM’.
logically connects the 5 TEAM-tokens and is used by advanced
seating
9
Basic seating
The best, rough description I can give is the seat booking of cinemas.
The seating descriptions are pretty sparse regarding mockups.
Seats are always part of a ‘block’. The ‘block’ is pretty much the same as ‘rows’ in a cinema (eg.
seat “A3” or seat “D15”). The number of seats per block is not limited. ‘Block’ because we might
not only do rows.
For Example:
Creating a new seating plan (admin)
In the Admin-UI, after opening an Event, I’m able to create a seating plan.
When creating a seating plan, the admin needs to fill in some data:
●
Event-ID:
○
●
●
●
Read-Only. Filled with the VISIBLE_ID of the event
Visible ID:
○
required, stored in SEAT_PLAN.VISIBLE_ID
○
Pre-filled with auto-generated id
○
Changeable by the admin.
Category:
○
required, stored in SEAT_PLAN.CATEGORY
○
dropdown to select ‘STANDARD’ or ‘TEAM’.
○
Changeable by the admin
Grid-Size:
○
required, stored in SEAT_PLAN.SIZE_X and SEAT_PLAN.SIZE_Y
○
Width and height of the grid for the seating plan
○
Changeable by the admin
○
Allowed Values: 1 - n
10
Seat plan attributes
Data-Type
Attribute
Description
ID
Primary Key, Not null
internal id of the seating plan
UUID generated on creation
EVENT_ID
Foreign key, Not null
linked to EVENT.ID
varchar(16)
VISIBLE_ID
must be unique in the event, Not null
Visible ID shown in admin-ui
Generated by default as ‘plan<Number of entry>’ and editable
by the admin in the ui when creating an event.
Number of entry: count over the seat-plans table + 1
varchar(16)
TYPE
Defines what token-type can interact with this seat plan
(book/plan seats)
int
SIZE_X
Grid-size in x-direction (left → right)
int
SIZE_Y
Grid-size in y-direction (top → bottom)
Adding/Removing seats to seating plan (admin)
After creating the seating plan object, the plan is opened in the admin-ui (eg.
/admin/event/<event>/seating/<VISIBLE_ID>), enabling the admin to place seats on the grid as
needed.
Above the grid information of the seating plan is displayed (Event-VISIBLE_ID, Seat-Plan
VISIBLE_ID, Category, Size) as well as some ‘tools’ for creating and removing the seats itself on
the plan.
I do not have a mockup for such an UI. I’m expecting something fitting into the rest of the web
application, easy to use and intuitive to use while having access to all the options needed.
Other Admin-Stuff regarding seating
Admins shall also be able to ‘disable’ seats, so that they are grayed out for users and can not be
booked/reserved.
11
Seat attributes
Data-Type
Attribute
Description
ID
Primary Key, Not null
internal id of the seat
UUID generated on creation
SEAT_PLAN_ID
Foreign key, Not null
linked to SEAT_PLAN.ID
varchar(1)
BLOCK
Not null
Block this seat is a part of
varchar(16)
STATE
Status of the seat:
disabled - seat cannot be selected for planning/booking
free - seat can be selected for planning/booking
planned - seat can be booked (no check needed of who
planned this seat).
Each token (and therefore user) can only plan up to 3 seats.
booked - seat cannot be booked or planned, some
information about the seat (BLOCK, SEAT_NO) and ) the
‘owner’ of this seat shall be displayed (FIRST_NAME).
Each token (and therefore user) can only book 1 seat.
The token is used as it is a relation to the user, the event
etc. as it is the ticket of a user.
int
POSITION_X
Position on X in the grid of the SEAT_PLAN
used for visualization
int
POSITION_Y
Position on Y in the grid of the SEAT_PLAN
used for visualization
GROUPING_ID
used for Advanced seating in order to group together
multiple seats.
if one seat such a grouping is booked, all other seats of the
group must be set to ‘planned’.
TOKEN
Foreign key
Links to the token of the user, who booked/planned this
seat.
RESERVER_TOKEN
Foreign key
contains the TOKEN.GROUP_ID uuid
12
Seat colors on grid in UI
The color of the seat on the seating plan in the UI is dependent on the state of the seat.
Example colors:
●
disabled - gray
●
free - blue
●
selected by user - (state-color) with red outline
●
planned - orange
●
booked - red
●
booked (your seat) - green
Mockup
This ‘mockup’ is the seat booking of a nearby cinema; I hope it’s clear what I’m
needing/expecting
Advanced seating
Besides being able to create more than one seating plan for an event, the seating plans need to
be restricted to the token-type (what ticket type the user bought - ‘STANDARD’ or ‘TEAM’. These
restrictions should be expandable). Users with a ‘STANDARD’ token shall only be able to
book/reserve seats in the ‘STANDARD’ seating plan, while having read-only access to the ‘TEAM’
seating plan.
Grouped seats
This is regarding the token-type ‘TEAM’, as these tickets are sold as a bundle of 5 tokens,
intended for teams. These teams shall sit together. That's why ‘grouped seats’ shall be creatable
13
in the seating plan. A seat group is therefore a row of 5 seats (either horizontally or vertically
arranged), created simultaneously when placing seats on the seating plan with type ‘TEAM’.
When selecting a seat of a seat group, the other 4 seats of that group are highlighted as well.
Workflow when a user with a team-token books a seat:
The user selects a seat on the seating plan for team-token owner. The seat he clicked is
highlighted, while the remaining 4 seats of the seat group are highlighted using another color, so
the user sees where his friends can sit. When booking the seat, the token of the user is written to
the seats attribute ‘TOKEN’, linking this seat to the user, and the state of that seat is changed to
‘booked’. The state of the remaining 4 seats is changed to ‘reserved’ while the attribute
‘RESERVER_TOKEN’ of those seats is filled using the attribute ‘GROUP_ID’ of the token the user
used to book his seat.
As all 5 tokens have the same GROUP_ID, the link is complete.
Reserved seats containing a UUID in the attribute ‘RESERVER_TOKEN’ can only be booked using
a token with the same UUID as ‘GROUP_ID’, therefore reserving these seats of the seat group for
his teammates only.
Reserved seats in the ‘STANDARD’ area will not get their ‘RESERVER_TOKEN’ filled, and are
bookable by anyone who has a standard-token and hasn’t booked another seat yet.
Users shall also be able to ‘unbook’ a seat, therefore setting it as free again, to book another seat
somewhere else on the plan.
Documentation
The code must be documented.
A short documentation, on how to setup everything locally in order to test and further develop
the project is required.
14