Data to include, to showcase, to not store:

Guidelines for Data Management in BJJML

Data to Include:

Focus on objective, actionable, and directly relevant data that enhances the functionality and user experience of the BJJML framework.

1. Objective Position Attributes:
   • Name: Clear and standard names for positions (e.g., "Half Guard").
   • Family: Categorization of positions (e.g., Guard, Takedown).
   • Description: Brief, high-level descriptions of each position's significance and utility.
   • Common Counters: Known counters to each position with brief descriptions (e.g., "Knee Cut Pass").
   • Preferred Game Style: Type of game style the position suits (e.g., Defensive, Offensive).
   • Physical Requirements: Specific physical attributes needed (e.g., "Requires good leg dexterity").
2. Objective Transition Attributes:
   • Technique Name: Standard names for techniques (e.g., "Knee Shield").
   • Starting Position: Position where the transition begins.
   • Ending Position: Position where the transition ends.
   • Type of Technique: Categorization of the transition (e.g., Sweep, Pass).
   • Number of Counters: Number of known counters for the transition.
   • Tokens (Key Steps): Detailed steps required for the transition.
   • Suitability: Type of game style the transition suits (e.g., Defensive game style).
3. Usage and Interaction Data:
   • Frequency of Use: How often each position and transition is used.
   • User Interaction Metrics: Data on how users interact with positions and transitions.
4. Performance Metrics:
   • Transition Time: Average time taken to complete the transition.
   • Energy Expenditure: Estimated physical effort required for the transition.

Data to Showcase:

Highlight data that provides clear, practical insights to users, supporting their learning and strategic planning.

1. Position Data:
   • Name and Family: Clearly display the name and family of each position.
   • Description: Provide a concise overview of the position.
   • Common Counters: List common counters with brief descriptions.
   • Preferred Game Style and Physical Requirements: Indicate suitable game styles and any physical attributes needed.
2. Transition Data:
   • Technique Name and Type: Clearly display the technique name and categorize the type.
   • Starting and Ending Positions: Show the beginning and end of the transition.
   • Number of Counters: Display the counter information.
   • Tokens (Key Steps): List key actions required for the transition.
   • Suitability: Indicate the type of game style this transition fits.
3. Usage Insights:
   • Popular Techniques: Highlight frequently used techniques and positions.
   • User Interaction Patterns: Showcase common paths and transitions based on user interactions.

Data to Not Store:

Avoid storing subjective, redundant, or non-actionable data that does not add value to the user experience or system functionality.

1. User Ratings:
   • Reason: Subjective and may not reflect the true effectiveness of positions or transitions.
2. Success Rates:
   • Reason: Highly variable and subjective, depending on individual skill levels and contexts.
3. Redundant Data:
   • Reason: Avoid duplicating information that can be derived or inferred from other data points.
4. Personally Identifiable Information (PII):
   • Reason: Unless necessary for user accounts, avoid storing sensitive personal data to mitigate privacy and security risks.
5. Overly Detailed Personal Preferences:
   • Reason: Focus on general game style preferences rather than detailed personal preferences, which can be too variable and subjective.