8. User Experience & Accessibility

UX & Accessibility Metrics

Dutch Localization100 / 100
Error Message Quality60 / 100

8.1 Localization & Internationalization

Status: ⚠️Warning

Findings:

  • Single language support: Only Dutch (nl) locale is supported
  • Localization infrastructure exists: flutter_localizations and intl packages are included
  • Hardcoded Dutch strings: Error messages and UI text are hardcoded in Dutch throughout the codebase
  • No translation files: No .arb files or translation resources found
  • Locale set to Dutch: Intl.defaultLocale = 'nl' hardcoded in base_singleton.dart
  • Date/time formatting: Uses intl package for date formatting but only for Dutch locale
  • No language switching: No mechanism for users to change language
  • Mixed localization: Some content comes from backend (mobile content), some is hardcoded

Evidence:

  • lib/app.dart lines 144-146: Only Dutch locale supported: supportedLocales: [const Locale('nl', '')]
  • lib/base_singleton.dart line 54: Intl.defaultLocale = 'nl' hardcoded
  • lib/helpers/error_helpers.dart: Error messages hardcoded in Dutch (e.g., 'Er ging iets mis', 'Controleer je internetverbinding')
  • pubspec.yaml includes flutter_localizations and intl: ^0.18.0
  • lib/app.dart lines 139-143: Localization delegates configured (GlobalMaterialLocalizations, GlobalWidgetsLocalizations, GlobalCupertinoLocalizations)
  • No .arb files or translation resources in project
  • Multiple files use intl package for date formatting: lib/routes/my_gas_receipts_route.dart, lib/routes/gas_receipt_route.dart, etc.
  • Backend content (mobile content) may support multiple languages, but app UI is Dutch-only

Risk Level: Low Risk

Recommendation:

  • Immediate actions:
    • Extract all hardcoded strings to translation files
    • Create .arb files for Dutch (and future languages)
    • Use intl package properly with translation keys
  • Short-term:
    • Implement proper localization using Flutter's localization system
    • Add language switching capability if multi-language support is needed
    • Ensure all user-facing strings are internationalized
    • Document localization process and guidelines
  • Long-term:
    • Plan for additional language support if required
    • Establish translation workflow and guidelines
    • Consider using translation management tools
    • Test localization with different locales
    • Ensure date/time formatting works for all supported locales

8.2 Error Messages & User Feedback

Status: ⚠️Warning

Findings:

  • Centralized error handling: handleDioError function provides consistent error handling
  • Error messages hardcoded in Dutch: All error messages are in Dutch and not internationalized
  • Multiple feedback mechanisms: Uses Flushbar for notifications and AlertDialog for errors
  • Inconsistent error handling: Some routes use centralized helper, others implement inline error handling
  • Generic error messages: Some error messages are generic and don't provide specific feedback
  • Server issue route: Dedicated route for server errors (ServerIssueRoute)
  • Error logging: Errors logged to Firebase Crashlytics for monitoring
  • No error recovery suggestions: Error messages don't provide actionable recovery steps
  • Network error handling: Specific handling for network connectivity issues

Evidence:

  • lib/helpers/error_helpers.dart: Centralized handleDioError function handles Dio exceptions
    • Timeout errors: "We ondervonden een probleem bij het verbinden met de server, probeer het later nog eens."
    • Connection errors: "Controleer je internetverbinding en probeer later opnieuw."
    • Server errors: Navigates to ServerIssueRoute
  • lib/routes/server_issue_route.dart: Dedicated route for server issues
  • lib/helpers/error_helpers.dart line 11: Errors logged to Firebase Crashlytics
  • lib/routes/login_route.dart, lib/routes/register_route.dart: Use Flushbar for success/error notifications
  • Error messages hardcoded in Dutch throughout codebase
  • Some routes implement inline error handling instead of using handleDioError
  • another_flushbar package used for toast-like notifications

Risk Level: Medium Risk

Recommendation:

  • Immediate actions:
    • Internationalize all error messages using localization system
    • Ensure consistent use of handleDioError across all routes
    • Add more specific error messages with actionable recovery steps
  • Short-term:
    • Standardize error message format and tone
    • Add error recovery suggestions where appropriate
    • Improve error messages to be more user-friendly and specific
    • Document error handling patterns and best practices
  • Long-term:
    • Implement error analytics to track common errors
    • Add contextual help for error situations
    • Consider implementing retry mechanisms with user feedback
    • Create error message guidelines and review process
    • Test error scenarios and user feedback mechanisms