Une économie partagée pour les corvées dont personne ne veut
Une app multiplateforme pour attribuer des tâches, et pour les faire réellement aboutir, par récompenses et pénalités.
Toutes les applications de tâches ménagères supposent que le difficile, c'est le suivi. C'est faux. Celui qui distribue la tâche sait déjà ce qu'il y a à faire, et celui qui la reçoit sait déjà qu'il ne l'a pas faite. Ce qui manque, c'est une raison pour que ça compte encore jeudi. Mon travail de bachelor est parti de là : dans les tâches déléguées, le problème intéressant est la motivation dans la durée, et c'est la partie que personne ne budgète.
Travail de bachelor en solo à la HEIA-FR, supervisé par Pascal Bruegger. Le cahier des charges, l'enquête, les choix technologiques, les deux applications, le backend et les dépôts sur les stores.
Deux personnes, ou une seule, conviennent d'une économie commune : ce que valent les tâches, ce que coûte de les manquer, et ce que les points permettent d'acheter.
Chaque écran lit la base en direct, restreint à la relation active, si bien que les deux côtés voient toujours le même état.
Une tâche planifiée clôt la journée : les tâches non terminées déclenchent leur sanction, les tâches terminées versent leurs points.
Les points achètent les récompenses définies par l'autre personne, et c'est tout l'intérêt : l'incitation se négocie, elle n'est pas imposée par l'application.
Une grille mensuelle par tâche, chaque jour en vert, orange ou rouge, pour qu'apparaisse une tendance plutôt que l'échec d'une seule journée.
Une seule base de code pour les deux stores, choisie sur une comparaison pondérée face à React Native et Xamarin, pas par goût
L'identité, et le flux auquel tout l'état de l'application est accroché
Huit collections, avec les règles de sécurité comme véritable contrôle d'accès : un document n'est atteignable que par les deux personnes qui sont à ses extrémités
Les comptes de la nuit, sous forme d'un point de terminaison par fuseau horaire
L'horloge réelle, qui déclenche chaque point de terminaison dix minutes après son propre minuit local
plutôt que · Uniquement en binôme, comme les deux applications que j'avais comparées
57% des répondants s'attendaient à tenir les deux rôles, et la plupart voulaient s'attribuer des tâches à eux-mêmes, un usage que je n'avais pas prévu. Plutôt que de greffer un mode solo, l'inscription crée une relation avec soi-même. Sept personnes et huit questions ont davantage changé le produit qu'un mois de réflexion.
plutôt que · Minuit pile, ou une fenêtre indulgente jusqu'au matin
L'enquête demandait quel degré de sévérité l'application devait avoir, et la réponse était nette : sévère, avec une petite marge pour l'oubli de cocher. Minuit punit celui qui a fait le travail mais a oublié de le noter. Six heures du matin laisse pourrir l'échéance. Dix minutes, c'est la plus petite marge qui respecte les deux.
plutôt que · Une seule fonction prenant le fuseau horaire en paramètre
La plateforme lie une planification à une fonction déployée : faire se déclencher le traitement à minuit local en vingt-sept endroits imposait vingt-sept points de terminaison. C'est indéfendable au regard de n'importe quel critère de qualité de code, et c'était le bon choix face à l'échéance. Je l'ai écrit dans le rapport plutôt que de le cacher. C'est l'exemple le plus net que j'aie d'une décision mauvaise selon une mesure et juste selon une autre.
plutôt que · Présenter les deux moitiés comme également fondées
Je pouvais citer des travaux de recherche pour le mécanisme de récompense. Je ne le pouvais pas pour la moitié sanction, alors j'ai écrit « à notre avis » plutôt que de déguiser une intuition en résultat. Cette asymétrie reste le paragraphe le plus honnête du rapport.
Dutine suit et gère les tâches attribuées à des personnes, et les motive à finir dans les temps par un système de récompenses et de sanctions plutôt que par des rappels.
Publiée sur les deux stores depuis une seule base Flutter, avec un backend Node sur Firebase et Google Cloud.