Mentor Showcase: DINGO!
by Channing Brown, Founder of DeafBits & Mentor
Executive Summary
The DINGO! app is a simple yet visually stunning game tool that displays 52 playing cards face down and randomly draws cards at set intervals.
It addresses an ongoing problem in both the Deaf/Hard-of-Hearing communities and hearing communities, where they lack a reliable application to perform this simple task without the complexity of antiquated Windows-specific software, the requirement of Microsoft Access 2007 Runtime, and dependency on abandoned software. This new app serves the goal of revitalizing the lesser-known game of "card bingo" for communities with the ease of web access or desktop and mobile use at no cost, maintaining accessibility nationwide. The project demonstrates how genuine community engagement can drive meaningful software solutions that serve real user needs.
The Challenge
Background
There are only a handful of software available that serve the niche purpose of randomly drawing and displaying the playing cards, which can be used for several types of "games", more commonly the game of DINGO (Deaf Bingo), which is a variation of card bingo where playing cards are utilized instead of bingo cards and balls.
One popular piece of software was contracted and created by a Canadian company that developed their own version of a dingo platform that was discontinued in 2020. Developed using Microsoft Access 2007 as its foundation, this software includes the Access 2007 Runtime environment but faces growing compatibility concerns with modern Windows 10/11 systems, potentially requiring troubleshooting or compatibility mode installation. The interface is reminiscent of old-fashioned Windows applications, but is also uninviting and overwhelming to technologically-inept senior citizens who are typically responsible for hosting dingo games.
This particular software became the de facto app for running dingo games, and has been "shared" across several Deaf organizations due to the high cost and the lack of support and understanding, creating uncertainty and fear of spending money on something that would not work.
Problem Statement
When I sat at my first dingo game and witnessed this application being displayed on a projection screen for the entire audience to see, I could identify several problems and found more as I researched alternative dingo software afterwards.
- The application is mainly focused on functionality, not so much form
- Visual accessibility could be improved
- The menus and options were overflowing with choices, and hosts/hostesses were often overwhelmed trying to scan through them for specific functions
- Designed "hearing people-first" and delivered with little to no intent for collaboration and improvement based on feedback
- Fixed 1366x768 resolution requirement doesn't adapt to modern display sizes or accessibility needs
- Dependency on aging Microsoft Access 2007 Runtime creates long-term sustainability concerns
- No web version available
- Discontinued support since 2020 leaves organizations without technical assistance
These were the biggest pain points that stood out to me, and I set out on a personal journey to address this challenge that seemed to face the entire Deaf community - with nobody willing to create something new in this space, as if it had simply become an afterthought and the old software was "good enough" in their eyes. Not mine.
Success Criteria
The following criteria define the success of the new DINGO! app deployment:
Quantitative Metrics:
- Setup time: Bingo Rose: 15+ minutes with troubleshooting → DINGO: <2 minutes
- User feedback rating: Baseline: N/A → Target: 4+ stars average
- Support requests: Bingo Rose: Discontinued → DINGO: <5% of users need help
- Geographic reach: 0 → 5+ Deaf organizations across east and west coast regions
- Repeat usage: Target: 60%+ of users retain app usage instead of their previous alternatives
Technical Improvements:
- Accessibility: Fixed 1366x768 → Responsive design supporting 100% of modern displays
- Cross-platform availability: Windows-only → Web + Windows + Mobile
- System compatibility: 100% compatibility with Windows 10/11 without requiring troubleshooting or compatibility mode
Project Sustainability:
- Project sustainability: Maintain active development and community support beyond the 3-year mark when Bingo Rose was discontinued
Community Engagement:
- Community involvement: Direct feedback incorporation from at least 3 different Deaf organizations
Qualitative Indicators:
- User testimonials mentioning ease of use
- Continued positive feedback from the Deaf community about visual accessibility improvements
- Community adoption and word-of-mouth recommendations
Solution Overview
I chose to build a completely new application from the ground up. My strategy focused on three core principles: simplicity over complexity, accessibility over functionality, and community-driven design over developer assumptions. The goal was to create a lightweight, visually appealing tool that could run anywhere without technical barriers, while directly addressing the pain points I witnessed in the Deaf community.
Key Design Decisions
After researching game engines, one stood out to me thanks to this particular video, and from the demonstrations I could see that using GDevelop would be the easiest and fastest way to create an MVP.
I also had some graphic design experience and chose not to use any sold/licensed assets and make everything in-house wherever possible to maintain complete creative control and avoid licensing complications.
Decision: Choosing GDevelop Over Traditional Game Engines
What: Used visual scripting instead of code-heavy engines like Unity/Unreal
Why: Fastest deployment and MVP creation in the shortest time, as a college student (at the time in 2023) with limited availability for side projects
Alternative considered: Unity, Godot, or a JavaScript-heavy web game app
Trade-offs: I learned GDevelop at a rapid pace, but in the late stages of development I encountered some roadblocks due to the deep abstraction of the no-code approach. This was offset by using plugins or minor JavaScript coding (GDevelop is not strictly no-code, it accepts JavaScript)
Decision: Creating All Assets In-House
What: Designed all visual elements using accessible design tools rather than professional software
Why: Complete creative control, no licensing costs, and faster iteration using tools I already knew
Alternative considered: Purchasing asset packs, hiring a designer, or learning professional design software
Trade-offs: Time investment in asset creation vs. guaranteed visual consistency and community-appropriate design
Technology Stack
- Game Engine: GDevelop - Enabled rapid prototyping and cross-platform deployment without deep programming knowledge
- Asset Creation: Canva, Procreate, Final Cut Pro
- Design: Having used Canva extensively for Non-Profit Organizations in the past, I was able to create custom assets using shapes and tools more quickly than feature-heavy tools by Affinity or subscribing to Adobe
- Deployment: Exported the game as an HTML5 game for the web, and as MacOS / Windows / Linux applications, which is supported by GDevelop's export process
This approach prioritized getting a working solution into the hands of the community quickly, rather than pursuing technical perfection that might never reach the users who needed it.
Implementation
Development Process
I worked solo using an iterative, feature-driven approach without formal methodology. Since I was still completing my software development studies at WGU, I started small and built incrementally - beginning with basic visual generation on a game table in GDevelop, then progressing to card array management, random selection, and mirroring functionality. Each feature became the foundation for the next, creating a natural progression toward an MVP that could run automated card reveals with win conditions. This organic approach allowed me to learn GDevelop's visual scripting environment while building, adapting scope based on what proved feasible and user feedback as the application evolved.
Technical Challenges & Solutions
Challenge 1: Joker Trigger Logic in Visual Scripting Environment
The Problem: The Joker functionality remained broken for months due to GDevelop's visual abstraction making it difficult to debug where the logic flow was failing. Traditional debugging approaches didn't translate well to the visual scripting paradigm.
Our Solution: Persistent experimentation with code placement and logic positioning until discovering the correct execution order within GDevelop's event system.
Why This Worked: Visual scripting tools have specific execution sequences that aren't immediately obvious to developers coming from traditional coding backgrounds. The solution wasn't changing the logic itself, but understanding where that logic needed to exist within the tool's architectural framework.
Challenge 2: User Interface Design Based on Real-World Feedback
The Problem: Initial sliding bar for time selection only worked in fixed intervals (steps of 1, 2, or 3 seconds), but user feedback from organizations revealed they needed specific combinations like 7, 10, 12, or 13 seconds that didn't align with the slider's step constraints.
Our Solution: Redesigned the interface from a slider to individual selection buttons displaying a curated set of commonly requested time values based on actual user preferences.
Why This Worked: This approach prioritized user needs over technical convenience. Rather than forcing users to adapt to the tool's limitations, the interface was rebuilt to match real usage patterns from organizations, improving adoption and satisfaction.
Challenge 3: State Management for Card History Tracking
The Problem: Users frequently missed card reveals during conversations and needed to reference the previous card without manually scanning the entire board against their personal cards - a time-consuming process that disrupted game flow.
Our Solution: Implemented a "previous card" indicator using a variable chain system where current card data "bumps" to previous card storage before new data overwrites the current position.
Why This Worked: This creates a simple two-state history without complex data structures. The bump system ensures data integrity by preserving the previous state before any new assignment occurs, providing users with the exact reference point they needed.
Key Features
-
Automated Card Revelation System
- Continuously reveals random cards at user-defined intervals until win condition or full deck completion
- Addresses the core problem of manual card calling being time-consuming and prone to human error
- Users simply press play and the system handles all timing and randomization
-
Flexible Timing Controls
- Provides selection buttons for various time intervals (7, 10, 12, 13+ seconds) based on organizational preferences
- Eliminates the need for manual timing and accommodates different game pacing requirements
- Users click their preferred timing option rather than adjusting sliders or entering values
-
Previous Card Reference Display
- Shows the last revealed card in a dedicated corner indicator
- Prevents users from having to scan the entire board when they miss a call during conversation
- Always visible reference point that updates automatically with each new card reveal
-
Visual Game Board with Card Mirroring
- Displays full 52-card layout with real-time revelation tracking and mirrors current card prominently
- Provides clear visual feedback of game progress and current state
- Users can quickly assess board status and identify which cards remain in play
-
Automatic Win Detection and Game Reset
- Pauses game automatically when win conditions are met and offers immediate new game setup
- Eliminates need for manual game state management and reduces friction between rounds
- Users experience seamless transitions from game completion to new game start
Results & Impact
Qualitative Feedback
User testimonials, feedback, and observed behavioral changes
Organizational Adoption: Over five deaf organizations have switched to using the application and provided direct feedback for improvements.
Visual Design Success: Users consistently praised the robust visuals and color options, with particular appreciation for the 30+ theme combinations. Several organizations noted that certain color themes proved "projector friendly," solving a common problem where projectors struggle with color and contrast in bright room environments.
"The color themes work great with our projector setup - using the 'White' theme, we can actually see everything clearly even with the lights on."
Accessibility-Driven Feature Requests: Received thoughtful suggestions for additional functionality, including a request from a Florida deaf club for an on-screen counter system. This feature would allow game masters to track how many players have one card remaining, addressing the specific need of senior players who cannot easily stand up to signal their near-victory status.
Business Impact
How this affected organizations beyond technical metrics
Improved Accessibility: The application eliminated barriers for organizations serving deaf and senior communities by providing visual alternatives to traditional audio-based calling systems and physical gestures.
Equipment Optimization: The projector-friendly color themes solved a practical problem many organizations faced with visibility in various lighting conditions, allowing for more flexible venue usage.
Privacy-Conscious Design: By design, the application collects no user data or analytics, respecting user privacy while still delivering functionality - a deliberate choice that aligns with community values and trust.
Community-Driven Development: Real user feedback directly shaped feature development, demonstrating responsive development that prioritizes actual user needs over theoretical requirements.
Lessons Learned
What Worked Well
Visual Development Platform Choice: Despite having no background in game engines and struggling with Godot and Unreal Engine previously, GDevelop's learning curve proved ideal for rapid skill development. The visual scripting approach provided a bridge to understanding game engine principles that later transferred back to code-heavy engines, making Godot much more approachable.
Community-Centered Feedback Integration: The feedback process exceeded expectations, receiving not only traditional emails but also ASL video messages from Deaf users providing spatial demonstrations of desired features. This created genuine connections across the country and ensured the application truly served its intended community.
Design Vision Execution: The visual design approach resonated strongly with users, earning consistent compliments about the "nice and modern" appearance and robust visual quality that enhanced the overall user experience.
Unexpected Discoveries
Real-World Hardware Limitations: While the initial design with darker themes looked excellent on computer screens, testing with a low-quality office projector at a local Deaf organization revealed significant color washout issues. Dark elements became nearly invisible against dark backgrounds in bright rooms, leading to the creation of "white" themes that dramatically improved projector visibility.
No-Code Debugging Complexity: The joker dismissal feature revealed an unexpected challenge where fixing what seemed like a simple timing bug required more complex workarounds than anticipated. In traditional coding, resetting a timer after an interrupt would be straightforward, but the visual scripting paradigm required rethinking the entire event flow structure. This insight informed the v2.0 architecture improvements.
Future Improvements
Integrated Prize Management System: Planning to incorporate a financial calculator that automatically handles prize distribution across multiple rounds, including the joker penalty system where triggered jokers split current winnings in half, with the remainder rolling over to increase the next round's prize pool.
Enhanced Game Flow Logic: The v2.0 update already addresses the joker timing issue, ensuring card drawing resumes immediately after joker dismissal rather than waiting for the full interval timer to complete.
Distribution Platform Expansion: Pursuing official app store distribution to eliminate installation friction and enable seamless automatic updates for users.
Conclusion
This project has become something I'm genuinely proud to call my own. It also demonstrates that meaningful software solutions often emerge from genuine community involvement rather than abstract problem-solving exercises such as creating a to-do app or a planner.
By attending a local dingo event and being curious enough to ask questions others overlooked or didn't think to ask, a simple observation turned into a tool that now serves Deaf organizations across the country.
The development process reinforced several key principles: iterative building allows for manageable learning curves even with unfamiliar platforms and technologies, real user feedback drives better design decisions than assumptions, and accessibility considerations often benefit broader audiences than initially intended.
Perhaps most importantly, this project illustrates how technical skills become most valuable when combined with community awareness. The strongest features - from timing interval flexibility to card history tracking - emerged directly from observing how people actually used the application, not from feature specs or speculative analysis.
For other developers, the takeaway is straightforward: engage with the communities around you. Software opportunities exist everywhere, often hidden in plain sight during everyday activities.
Sometimes the most impactful projects begin with simply paying attention and asking, "Could I make this better?"
Prepared by Channing Brown | Founder @ DeafBits.org | CBrown@deafbits.org