Spécifications détaillées - TitusVM/stonksmanager GitHub Wiki

Affichages

Login

Lors du démarrage de l'application, un écran Login est présenté sous la forme de deux cases remplissables, un bouton "Login" (qui lancera la connexion) et un bouton "New Account" (qui lancera une procédure de création de compte). Se référer aux maquettes pour les visuels ici.

La première case à remplir de l'écran "Login" sera destinée au nom d'utilisateur et la deuxième au mot de passe de ce dernier. Si la combinaison des deux est bonne, l'utilisateur peut se connecter, sinon un message d'erreur lui sera présenté.

Lors de la création d'un nouveau compte, il faudra choisir un mot de passe adéquat (8 caractères, une majuscule, une minuscule, un signe par exemple). Il faudra aussi être prudent de ne pas choisir un nom d'utilisateur déjà créé localement. Sur la même machine, on ne pourra pas avoir deux comptes séparés toto, Toto, toTo etc...

Ce qui n'est pas présent sur les maquettes, est un menu contextuel en haut de l'écran qui affichera des options comme "Quitter" ou "Aide" ou encore "Infos Pratiques" entre autres.

Écran principal

Première connexion

Une fois l'utilisateur connecté il sera demandé qu'il charge un document bancaire (un extrait du compte qu'il souhaite ajouter).

Remarque importante : Cette fonctionnalité est simplement mise en place pour cause d'impossibilité d'intégration de banques réelles. Pour la production à grande échelle, cette fonctionnalité serait évidemment remplacée par la connexion au compte bancaire directement utilisant une API de la banque choisie. Ici, il s'agira uniquement d'un concept. L'utilisateur pourra charger un document de type XML, JSON ou CSV (cela dépendra de la suite du développement) pour importer une liste de détails (toutes fictives évidemment) d'un compte (solde, IBAN, transactions etc...).

Les informations seront reçues par le Cache de l'application. Ce dernier est mis en place pour prendre en charge la lecture de toute donnée venant de l'extérieur. Cette décision est plus consommatrice en terme de ressources mais est nécessaire. Chaque banque envoie des données sous formes relativement différentes et aussi utilisant des protocoles de sécurité différents. Le Cache permet de faire l'interface de standardisation entre les banques et l'application. En fonction de la configuration donnée au Cache (qui sera propriétaire à chaque banque), il pourra lire les données et envoyer toujours les mêmes sortes de données au programme. Pour plus d'informations voir ici.

Après la connexion

Une fois les données reçues, l'application se chargera de faire des affichages visuels des données reçues. D'un côté seront présentés le solde du compte, les totaux des transactions (gains, dépenses, catégories de dépenses et montants...) ainsi qu'un graphe en camembert représentant visuellement ces même données.

L'utilisateur a aussi la possibilité de générer un fichier qui lui présente de manière structurée l'affichage si dessus. Cela pour but de l'imprimer ou simplement pour ses documents personnels. Ce fichier sera certainement sous forme de PDF. En quelque sorte une belle capture de l'écran principal.

Goals

Une autre fonctionnalité sera la possibilité d’ajouter des prévisions sur un futur achat. L'utilisateur souhaiterait d'acheter une voiture à 25'000.- dans deux ans, il pourra créer un nouveau "Goal" dans l'application ajouter une date quand il souhaite avoir la somme de 25'000.- et l'application lui donnera des détails sur les économies qu'il devra faire pour atteindre ce "Goal". Que ce soit de manière journalière, hebdomadaire, mensuelle etc...

Sur le tiers droit de cet écran sera affiché ce qu'on appelle le gestionnaire de factures.

Gestionnaire de factures

En ouvrant le gestionnaire de factures, l'utilisateur pourra de manière très intuitive, ajouter ses factures à un échéancier. Cela pourra être fait en remplissant les informations demandées (qui ne sont pas toutes obligatoires) comme le Nom du bénéficiaire, la Date d'exécution, le montant dû et la catégorie de la facture, ainsi que le type de la facture (récurrente ou non). Une fois remplis, l'application utilisera ces informations pour ajouter la facture au calendrier de factures. On peut aussi ajouter un PDF ou une photo de la facture afin d'avoir une référence.

Remarque : Dans l'application de production il sera évidemment question de pouvoir payer ces factures directement (ou même implémenter un automate qui les paye à la place de l'utilisateur - en fonction du solde courant sur le compte ainsi que la date de paiement par exemple).

Il sera aussi possible de générer des fichiers iCal (calendrier électronique) prêt à l'import dans une application calendrier type Outlook.

Sur la partie droite de l'écran Gestionnaire de factures on aura aussi deux onglets différents:

• un onglet pour afficher les factures non-payées
• un onglet pour afficher les factures déjà payées

On pourra aussi sélectionner une planche de temps pour ces deux onglets pour ne pas avoir trop de choses affichées en même temps.

Buts secondaires

Gamification des Goals monétaires

Dans cette partie des buts secondaires il serait question de "gamifier" les "Goals" expliqués dans la partie "Connexion".

Cette partie de l'application sera "gamifiée" par le moyen d'un système de points. L'utilisateur gagne des points pour les buts journaliers, hebdomadaires etc... atteints et peut débloquer des trophées d'économies successives.

Il serait aussi question d'un système de surveillance - si l'utilisateur fait 4 sorties au bar par semaines, l'application lui dira qu'il pourrait faire tant d'économies s'il n'allait que deux fois et perdra des points pour les dépenses trop importantes dans les catégories non-essentielles.

Détails techniques

Application web avec Electron, Javascript et possiblement Python.

Inspirés d'applications similaires comme par exemple YNAB ou encore MINT.