-
Notifications
You must be signed in to change notification settings - Fork 4
Voting System
The voting system is designed to be highly customizable, allowing administrators to configure vote events according to different requirements. This flexibility ensures that the system can adapt to a wide variety of voting scenarios. This was done as part of a Final Year Project, and the final report pdf can be found here.
The system is organized into four main pages, each serving a unique function for either administrators or voters:
-
Vote Events Page: Displays a list of vote events. Administrators can add new vote events, delete existing ones, or view event details.
-
Voting Page: Voters participate in the voting process by selecting their preferred candidates (projects). This page is customizable to support different types of candidate displays (e.g., list view, gallery view).
-
Results Page: After the voting period ends, voters can view the aggregated results of the vote event.
-
Manage Vote Event Page: This page is used by administrators to configure settings and manage the data related to vote events. Administrators can modify configurations like candidate displays, role weights, and candidate displays.
The voting system provides various customization options that allow administrators to adjust settings and tailor the voting process to meet their specific needs. Below are the key customization features:
-
Display Formats: The voting page supports customizable candidate displays. This includes options such as:
- Gallery View: Candidates are displayed with images in a grid format.
- List View: A simple, text-based list of candidates.
- Table View: Displays candidates and their details in a tabular format.
-
Roles: Weights can be adjusted for the different roles. This includes options such as:
- Administrator: System admin.
- Mentor: One of the roles in Orbital.
- Adviser: One of the roles in Orbital.
- Student: One of the roles in Orbital.
- Public: This role is for all external voters.
-
Results Display Mode: Administrators can choose how the results will be displayed. This includes options such as:
- Display limit: Limit the results to the top few
- Show/Hide Rank: Choose to show or hide rankings
- Show/Hide Vote: Choose to show or hide the number of votes the project received
- Show/Hide Points: Choose to show or hide the points the project has after applying weights to votes
- Show/Hide Points Percentage: Choose to show or hide the percentage of total points
The system is built with a React component-driven architecture, which is central to the flexibility and customization of the voting pages and event management interfaces. Each part of the system is broken down into small, reusable components that can be dynamically rendered based on the configurations provided by administrators.
The Component Factory Pattern is used to dynamically generate and render components based on configuration options. More on this here
Customization is achieved by mapping configuration options to specific React components through a central mapping object.
Example:
const DISPLAY_OPTIONS: Record<DISPLAY_TYPES, DisplayOption> = {
[DISPLAY_TYPES.NONE]: {
component: VotingForm,
description:
"No candidates will be displayed. Voters will have to enter the project ids (separated by commas) into a textbox to vote.",
},
[DISPLAY_TYPES.TABLE]: {
component: VoteCandidateTable,
description:
"Display candidates in a tabular format with id and name shown.",
},
[DISPLAY_TYPES.GALLERY]: {
component: VotingGalleryGrid,
description:
"Display candidates in a gallery grid with images of their posters, their names, and ids.",
},
};
Each Enum value for the candidate display option is mapped to their respective React component. Additional details, such as description of each option in the example given can be added to the mapping if needed.
Common components like wrappers, buttons, text fields, etc are not shown


