User stories: Ticket Sales

Purchasing tickets

• TS-C-1: As a student, I want to be able to purchase tickets to TUM events using an online payment method (Stripe), because it will take less time and effort.

Stripe is chosen as payment option. SEPA, PayPal or other services might be added in the future but are considered too complicated due to external constraints for now. Stripe provides an Android library which can be added simply by adding a reference in the Gradle build file. Detailed information can be found at https://stripe.com/docs/mobile/android.

• TS-C-2: As a student, I receive a QR code for each ticket, so that the ticket check at the entrance is simplified.

QR codes are already used in many areas for mobile ticketing, e.g. for cinema or public transportation. For the implementation an open source library such as zxing can be used (https://github.com/zxing/zxing/wiki/Getting-Started-Developing). The QR code should contain the student name and number, the name and date of the event, and a unique identifier.

• TS-Mi-1: As a student, I want to additionally receive an email containing my tickets, so that I have a backup in case there is a problem with the app.

The server should send the user an email containing the ticket information.

• TS-C-3: As a student, I see an overview of my booked events, so that I can check the time and location at any time.

In the ticket sale activity, the student sees an overview of all events including title, date and time, which she or he booked. The next events should be shown at the top. The list can be updated by using the well-known Swipe-to-Refresh functionality. By clicking the event, the student can access the QR code, so that it can be checked by the cashier.

• TS-Ma-1: As a student, I want to have access to my tickets offline, so that I can show them at the event even without internet connection.

The app should automatically download the QR code of purchased tickets, so that the student is not dependent on an active internet connection when visiting the event. The data should probably be saved in the internal storage of the device, e.g. described in https://stackoverflow.com/questions/10962344/how-to-save-data-in-an-android-app.

• TS-Ma-2: As a student, I want to be sure that I get tickets which I paid for even in case of connection or server issues, so that I do not lose money under any circumstances.

To make sure that purchased tickets are not lost due to connection or server failure, the ticket is created on the server right before the money is transferred. Thus, it cannot happen that money is transferred, but the ticket is not created due to a server error. If the connection of the mobile device is lost after the purchase, the users can simply refresh the app, when connection is established again. Then, the tickets will be loaded from the server.

Finding events

• TS-Ma-3: As a student, I can see all upcoming events including details and time, so that I can choose the ones I am interested in.

In the event overview, the student will initially be presented a list of upcoming events, sorted by date. The necessary data can be retrieved by using the existing function for TUFilm events provided in the TUMCabeAPIService interface, and by creating a similar functionality other event types.

• TS-Mi-2: As a student, I can add the event to my preferred calendar app, so that I can see it in context of my schedule.

Each event should have an “add to calendar“-button in its detail activity (regardless of whether a user has already bought tickets for an event or not). Additionally, we can add an icon for this action to the section of each event in the event overview (possibly a tableView), if there is still space for this. Once an event is added to the local calendar, the icons/buttons should change their appearance to signal that the calendar entry has been created. Clicking on the very same icons/buttons again should simply remove the event from the calendar. Adding an event to the default calendar can be done by using the Calendar Provider, which offers a bunch of Calendar Intents. These allow to specify the action you want to perform on the calendar, in our case, add an event. When executed, this will take the user right to the calendar app itself, where they can still modify and finally confirm the event. Afterwards, the user will be taken back to where they were in our app. Using this approach, we don’t need the WRITE_CALENDAR user-permission in our manifest, as compared to the other possibility of just adding the event to the calendar without user interaction, which would require that permission.

• TS-Ma-4: As a student, I can see the location of the event, so that I know how to get there. [Link to room finder if possible]

The location string should include both the physical address of the building, as well as the internal room number. Clicking on the address should take the user to the Room Finder activity and use the integrated search functionality to search for the specified room and address. The map should be presented at a suitable, rather detailed scale. The address should only be shown in the event overview activity of each event, since showing it in the overview table would take up too much space.

• TS-Mi-3: As a student, I want to see how many tickets are still available for a certain date, so that I know whether I should hurry.

The number of available tickets is a very important info, that should therefore be shown both in the section of each event in the overview as well as the detail activity. This label should be a live ticker, i.e. should be updated without refreshing the page (especially interesting for quickly selling events, like Feuerzangenbowle etc.) by implementing an event listener to the database, which is provided by the Firebase API. To keep this ticker up to date, it must be updated by the server after every purchase. Also, if client sessions are handled in multiple threads, the ticket count must ensure exclusive access, i.e. be implemented with a mutex. It is still to be decided if the ticket count should include only the tickets for online purchase, or all in total. In the latter case, cashiers selling the physical tickets (Fachschaften etc.) would also need a way to update the ticket count after each purchase. Such a feature would be part of the server's web-interface that we extend.

Admin/Cashier side

• TS-C-4: As a cashier/admin, I want to be able to look up the total number of ticket sales for a certain event, so that event planning is facilitated.

This can also be implemented as a live ticker showing the current amount of sold tickets as logged by the server, i.e. using the same data source. This live ticker can be included in the admin gateway that we agreed on to provide in the server's web-interface.

• TS-C-5: As a cashier, I want to be able to reliably check the validity of tickets, so that fraud is prevented.

To enable the cashier to check ticket validity, the value that in the purchasing progress is translated to the QR Code of the ticket must be saved in the database. It must be ensured, that the client receives the same value as saved to the server. The cashier must be provided some kind of QR-Code scanner that translates the QR-Code presented by the students at the event and looks it up in the database. For that purpose, either a smartphone accessing the server's web- interface and using its own camera or a designated scanner device that can be attached to a computer can be used.

• TS-Mi-5: As a cashier, I want to be able to check tickets offline, so that I am not dependent on the network connection.

The content of the ticket, which uniquely identifies the event and purchaser, is at the transaction signed with a private key by the server. Therefore, the cashier can just use the respective public key to check if the ticket content is valid and was actually generated by the server. Since the public key is shared beforehand, this can also happen offline.

• TS-Ma-5: As a cashier, I want to be able to access the tickets purchased by a certain student number, so that also students who have forgotten or lost their phone can be checked.

As one student can only buy one ticket per event, we can link every ticket that is created during a purchasing process with the student’s identity, i.e. name and student ID). We can do this by building the respective database partition for the tickets as a dictionary that maps the student ID to the ticket, as student ID's are unique. In case a student forgot their ticket for the event, cashiers can check the student ID on their student card to match the purchaser’s ID.

Later:

• Integrate other payment options, like SEPA. PayPal probably not realistic for now.
• As a student, I want to be able to select the amount of tickets before purchasing, so that I do not have to buy multiple tickets separately. [Not possible now]
• As a student, I want to have the possibility to cancel a purchase before the event, so that I can get my money back in case I cannot attend. [Too complex for now]
• As a student, I can use search filters, so that I can find events quickly. [e.g. type (Campus Kino, talks, parties, …), time, place] [Currently not necessary - optional]

Deleted:

• As a student, I want to be able to share purchased tickets with friends, so that we can easily visit events together. [via mail, or even via student number to show ticket in TCA of the friend]