2024-03-07
Je viens de découvrir un nouveau pattern UX.
Ces composants ne sont pas des input fields…
Ce sont des boutons ou des liens !
Ils ouvrent tous une nouvelle page ou pop-up pour faire sa recherche
En code ce sont des <button>
ou <a>
, pas des <input type="search">
2024-03-06
Aujourd'hui j'ai utilisé Pageflows(.com)
C'est une première pour moi. 🫣
Le site permet de s'inspirer d'applications connues.
J'avais d'un côté, dans Figma, mes flows "bruts" avec les fonctions principales que je voulais ;
Sur Pageflows j'ai trouvé 3 applications qui proposent des flows plus ou moins proches ;
En fusionnant mes flows et ces inspirations je peux avancer sans trop d'efforts ! 🌟
2024-03-05
Clémence Oney a passé en revue mon flow principal.
J'en retire 3 leçons :
Il faut me baser sur le flow réel, dans mon cas la phrase d’initiation étant : "Avez-vous déjà une carte fidélité ?"
Éviter les écrans qui se ressemblent trop car cela ne donne pas le sentiment que l'on progresse dans le flow
C'est un classique, mais indétectable sans discuter : ce qui est logique pour nous concepteur de l'app ne l'est pas pour une personne externe.
2024-03-04
Ma semaine résumée en 5 minutes.
C'est en vidéo et disponible sur Youtube.
→ Objectif 5k€ de MRR - Épisode 1 - Je change d'idée 🎉
2024-03-03
Après le papier, j'utilise Figma pour mes écrans et mes flows. Ça m'aide sur plusieurs points :
- Voir le flow dans son ensemble
- Aller très vite dans les itérations
- Simplifier où c'est possible
- Penser au wording global (tonalité)
- Définir les composants et models
2024-03-02
- Front-end: Front
- Full-stack: Back + Front
- Solopreneur: Idea, Design, Back, Front, Marketing
2024-03-01
Je viens d’acheter et de publier jebuildinpublic.com 🎉
Tu peux retrouver tous mes posts là-bas.
Pas de contenu exclusif, mais :
- Pour toi, tout est au même endroit
- Pour moi, le contenu m'appartient
- Pour nous, on peut chercher avec un Cmd + F
2024-02-29
Je démarre le prototypage de ma nouvelle idée…
Sur papier, comme toujours. Facile, rapide.
2024-02-28
Je jette mon idée de Pixifamily.
J’avais un red flag. Maintenant 2.😱
🔴 Le nouveau red flag Trop de privilèges sur les groupes Whats App de mes utilisateurs : capacité de lire tous les messages et de récupérer les contacts. Si je me fais hack, la responsabilité est trop lourde.
🔴 Le premier red flag Ma cible n’est pas assez identifiée / identifiable. Je n’ai jamais réussi à répondre à mon critère « Les prospects peuvent facilement être contactés. Je dois pouvoir prendre mon téléphone, e-mail ou compte Facebook et pouvoir contacter un prospect en moins de 2 minutes. »
Aucun regret, ce n’est ni la première ni la dernière idée que je jette.
J’ai un autre projet qui valide mes 17 points de contrôle. Stay tuned. ☀️
2024-02-27
J'ai testé Pico CSS. J'en retiens 5 choses :
→ 0 class = liberté d’esprit
→ 0 div = force à simplifier l’interface
→ Utile pour monter un proto facilement
→ Pratique pour lancer un blog rapidement
→ Mais est-ce suffisant pour un MVP de produit ?
2024-02-26
Marc Lou n'écrit pas de tests…
Pieter Levels n'écrit pas de tests…
Pourquoi je continue à écrire des tests…
2024-02-25
Cette semaine j'ai réussi à travailler 14h sur Pixifamily.
Principalement de 05h à 08h quand ma fille de 3 mois termine sa nuit en écharpe contre moi.
J'ai perdu du temps sur l'écriture de tests…
Ce sera le sujet du post de demain.
2024-02-24
Il faut que je connecte un service d’envoi d’e-mails à Pixifamily. J’allais partir sur Brevo car le builder permet de faire des choses visuellement sympathiques, mais le free tier de 300 e-mails n’est pas dingo. Je pense que je vais me laisser tenter par le "new kid on the block" qu’est Resend (.com). 100 e-mails par jour gratuitement (3000 par mois), et la possibilité de coder ses templates d’e-mails avec React & Tailwind, WTF ! 🤯
Je vous tiens au courant de mes avancées sur le sujet la semaine prochaine.
2024-02-23
Aujourd'hui j'ai pris le temps d'harmoniser les tests de mes 3 models. Si tu as des conseils en plus sur le sujet, je suis preneur.
1. Création d'une fixture "default" pour chaque model
↳ J'avais "one", le nom par défaut. Pas très explicite.
↳ Elle encapsule l'ensemble des propriétés nécessaires pour passer le test model.valid?
2. J'ai réutilisé la nomenclature ressource_name SHOULD be_something
↳ J'utilisais des "should not be valid" par exemple, ce qui ne correspond pas au pattern habituel en code du "if (something) do ___"
↳ Crédit à Michael Hartl et son cours "Learn Enough Ruby to Be Dangerous" pour le nom des tests
3. Pour les assert_difference "Model.count" lors du destroy du user (en bas à gauche du screenshot), j'utilise maintenant un model_count, ce qui me permettra d'ajouter à loisir plusieurs ressources à la fixture sans casser ces tests
↳ Je n'ai pas encore vu ce pattern, je ne sais pas si c'est une bonne chose à faire ou non, mais l'idée me plaît.