auden is an open-source, hackable audience engagement software, supporting multiple features, such as Live quiz and Voting system. Its hackable architecture allows developer to modify and add features to fit the event.
We used auden in Code in the Dark Thailand #3: CNX 2019 to encourage attendees to participate in the event more easily.
Instead of requiring all contestants to register beforehand (which takes quite a courage), a live quiz system allows anyone in the event to compete to become a contestant in each round.
Because this app supports multiple features, when itβs time for voting, attendees can vote on the same webpage without the need to switch between multiple apps (such as Mentimeter, Slido, and Kahoot).
Each feature (called scene) contains 3 user-facing components:
- The Audience component is a mobile UI for audience to engage in the event.
- The Presentation component displays what the audience will see on the big screen.
- The Backstage component allows event staff to manipulate the scene (such as activating a question, displaying scoreboard, etc.)
Play a multiple-choice quiz game with any number of participants, similar to Kahoot.
Create a live poll to gather audienceβs opinion, similar to Mentimeter.
It is a webapp, built on top of:
- React!
- TypeScript!
- Grommet!
- Firebase Real-time Database!
- fiery π₯!
- Hooks and Suspense!
-
Set up Firebase Authentication to allow sign in using Facebook.
-
Sign in using the web app, and obtain the Firebase user ID by running
firebase.auth().currentUser.uid
in the JavaScript console. -
Make the user an admin by writing
true
Firebase Database at/admins/$uid
. Admin users can read and write anything.
Everything is organized into βscenes,β which represents a type of situation in an event.
For example, you can have a scene for a quiz, for a survey, for voting, for announcements, and an idle scene when thereβs nothing interesting going on.
Each scene has:
- A presentation display, for projecting to a large screen.
- A audience UI to let audience engage with the event from their mobile phone (or desktop).
- A backstage UI to manipulate the scene.
Data is structured in Firebase this way: Namespace β Name β Access pattern. This allows using same Firebase rules across all scene types, eliminating need for us to deploy new rules when adding new scene types.
Available access patterns:
public-read
β Anyone can read but only admins can write. Examples:main
βstate
βpublic-read
βshowLeaderboard
main
βsettings
βpublic-read
βmaxVotes
personal
β Anyone can read, however, each user can write to their own personal slot. Examples:main
βpoll
βpersonal
β$uid
βselectedOption
events
β Anyone can read. Each user can publish events. Append-only. Examples:main
βchatMessages
βevents
β$eventId
private
β Each user can read and write to their own personal slot. Examples:answers
β$questionId
βprivate
β$uid
βanswerId
inbox
β Each user can read data assigned to their own personal slot. Examples:main
βrole
βinbox
β$uid
secret
β Only admin can accessmain
βquestions
βsecret
An instance of a scene. It has:
- Data stored in Firebase. How data is used is determined by scene type.
That can be one active screen at a given time.