# MZAP--Mobile Application for Basketball Match Tracking and Digitalization of Endgame Reports
## 7 MZAP Android Application--User Feedback, Failure Cases, and Error Taxonomy  
Given that the Agile software development methodology was employed, a continuous testing process was integrated into the development cycle. A test group consisting of eight individuals was engaged throughout development and to this day remains active. These users provided continuous feedback through detailed email correspondence, addressing various aspects of the application, such as usability, visual clarity, and the interpretation of user interface (UI) elements. Feedback was also obtained from other basketball officials after MZAP application training sessions.  
The development process was guided by the regulatory requirements set forth by the International Basketball Federation (FIBA) and the Basketball League of Serbia. As such, while most user suggestions were implemented to improve application stability, usability, and interface clarity, feedback that conflicted with these governing rules was not incorporated.  
Initially, the MZAP application was designed primarily for use on mobile phones, with a focus on small-screen optimization and menu-based fragment navigation. However, user feedback indicated a strong preference for a layout more suitable for larger displays. Specifically, users expressed dissatisfaction with the need for frequent fragment switching and requested a unified interface that would consolidate key components, such as the Teams and Running Score sections. In response, a tablet-optimized mode was developed and has since become the primary interface used for match tracking and data entry.  
The majority of observed failure cases were attributed to unanticipated edge cases in user interaction and unhandled input scenarios. These issues were not related to object or list initialization, which was consistently handled correctly throughout the development process. Instead, the failures primarily stemmed from insufficient coverage of atypical usage patterns and incomplete input validation, or, simply put, minor bugs in code. A similar failure case is described in the work of [PERSON] et al. [44].  
To better understand the nature of user errors presented in the work of [PERSON] et al. [45] and form an error taxonomy, we have conducted an analysis of the previously mentioned user feedback. Based on this analysis, the errors that we encountered are categorized into three primary groups:  
* Input Errors--These involved the selection of incorrect options within the application, such as selecting the wrong player, foul type, point value, etc.
* Omission Errors--These referred to instances where users failed to record an event entirely. Users most commonly omitted the end-of-quarter and end-of-game events. Additionally, users frequently neglected to update a player's game entry status, which is a prerequisite for that player to appear on the list of active participants eligible to score. Failure to perform this step often led to subsequent input errors, as the intended player would not be available for selection during scoring actions.
* Navigation Confusion--These errors stemmed from difficulties in navigating the user interface, particularly before the introduction of the tablet-optimized mode, which significantly improved usability.  
Due to this, taxonomy design improvements that were aimed at reducing the frequency and impact of the mentioned errors were devised and implemented. Before the introduction of the tablet-optimized mode, input errors accounted for 34% of all recorded issues, followed by omission errors at 25%, and navigation-related errors at 41%. After the deployment of the tablet mode, a significant reduction in navigation-related errors was observed, with this category decreasing to just 4% of total errors. Conversely, input errors increased to 62%, becoming the most prevalent category, while omission errors rose to 34%.