Re: Trender
Posté : lun. 5 juin 2017 16:56
J'ai repris divers éléments pur faire une chtite carte https://framindmap.org/c/maps/362359/public
en reprenant le code du timekeeper hier, je me dis qu'il faut qu'on se fasse une session soft... (et probablement hard)...
faudrait sonder les possibles utilisateurs sur leur manière d'imaginer le fonctionnement du timekeeper (la version jenkins me paraît plus simple car plus statique au final, à part le changement de la connectivité, je vois peu de customisation)
mais pour le timekeeper, je pense que ça serait bien de recueillir l'avis des utilisateurs (interaction avec l'objet, manipulation, branchement, ..)
en l'état le code sur le github du timekeeper ne passait pas pour moi, j'ai donc simplifié un peu - fait du mono mode, virer le mot de passe sur l'AP wifi, ...j'ai pas fait de pull request car je me dis que c'est peut être de ma faute et qu'il faudrait que je creuse un peu..
qq questions en vrac
- mono mode/multi-mode => je vote pour 1 objet 1 usage...mais je sais qu'on n'est pas tous d'accord.
Pour moi c'est surtout par soucis de simplification
sur le timekeeper basique (sans rien en mémoire par défaut) on a un truc du genre
* démarrage
* mode AP
* entrée des valeurs de timers
* timekeeper
* retour en mode AP pour attendre les nouvelles valeurs
ça me paraît simple et robuste (pas de gestion de modes, de mémoires, de lumières..)
un appli (anroid/IoS) plutôt que le "très sobre" navigateur pourrait être un peu plus convivial mais rien de dramatique
On pourrait aussi imaginer une config en mémoire et quand on l'allume si on trouve les valeurs on commence immédiatement (ça évite de se connecter à l'objet) mais bon ça ne me paraît pas non plus insurmontable d'avoir une action via le téléphone pour lancer le décompte..
note: déclinaison timekeeper du cube + papier calque + leds remontées => ça flashe bien même en plein jour https://drive.google.com/open?id=0B2lmI ... GFNSUU4X1E
en reprenant le code du timekeeper hier, je me dis qu'il faut qu'on se fasse une session soft... (et probablement hard)...
faudrait sonder les possibles utilisateurs sur leur manière d'imaginer le fonctionnement du timekeeper (la version jenkins me paraît plus simple car plus statique au final, à part le changement de la connectivité, je vois peu de customisation)
mais pour le timekeeper, je pense que ça serait bien de recueillir l'avis des utilisateurs (interaction avec l'objet, manipulation, branchement, ..)
en l'état le code sur le github du timekeeper ne passait pas pour moi, j'ai donc simplifié un peu - fait du mono mode, virer le mot de passe sur l'AP wifi, ...j'ai pas fait de pull request car je me dis que c'est peut être de ma faute et qu'il faudrait que je creuse un peu..
qq questions en vrac
- mono mode/multi-mode => je vote pour 1 objet 1 usage...mais je sais qu'on n'est pas tous d'accord.
Pour moi c'est surtout par soucis de simplification
sur le timekeeper basique (sans rien en mémoire par défaut) on a un truc du genre
* démarrage
* mode AP
* entrée des valeurs de timers
* timekeeper
* retour en mode AP pour attendre les nouvelles valeurs
ça me paraît simple et robuste (pas de gestion de modes, de mémoires, de lumières..)
un appli (anroid/IoS) plutôt que le "très sobre" navigateur pourrait être un peu plus convivial mais rien de dramatique
On pourrait aussi imaginer une config en mémoire et quand on l'allume si on trouve les valeurs on commence immédiatement (ça évite de se connecter à l'objet) mais bon ça ne me paraît pas non plus insurmontable d'avoir une action via le téléphone pour lancer le décompte..
note: déclinaison timekeeper du cube + papier calque + leds remontées => ça flashe bien même en plein jour https://drive.google.com/open?id=0B2lmI ... GFNSUU4X1E