Bon, les soucis énumérés demeures :
1. si je ne bouge pas assez vite ma pièce ou mon billet, le nav me propose de l'ouvrir dans un onglet.
si je répond par la négative, la pièce ou le billet reste en grand et vient recouvrir les autres...
J'ai pas assez cherché le pkoi mais je pense que ma proposition de résolution reste intact.
2. J'ai toujours le message d'erreur dans la console mais ça n'a pas l'air d'être impactant.
Pour la suppression avec appui long, ça fonctionne.
Peut-être rendre dispo le drag and drop inverse (ça me parait tellement intuitif).
Pour avoir une consigne adapté au tactile, je te conseil d'avoir 2 divs (.consigne et .consigne-touchscreen par ex) et afficher en fonction de cette méthode :
code provenant du projet modernizr.
Pour "tactile pur". On va dire que je suis comme toi, je découvre des recommandations d'usage au fil du temps.
Je pense qu'il faudra les formaliser dans le draft pour les appliquer un peu partout et surtout travailler avec des échelles de priorité.
Par exemple :
- quel taille min on prend en charge. Si c'est en dessous, est-ce qu'on averti l'utilisateur qu'il risque d'être dans un mode dégradé ?
- comment ça se passe si l'on est en mode portrait
- le tactile nécessite d'avoir des boutons 1/3 plus gros que de l'interface desktop car la précision est moindre.
- les modales sans actions (juste ok) devrait pouvoir se fermer à l'appuie en dehors de la zone.
- le tactile a des zones mortes ou l'interaction est plus délicate (par exemple, le menu de l'os va être prioritaire sur une zone) : prévoir un padding globale assez conséquent pour éviter ces désagréments.
- le tactile nécessite souvent des petites animations pour mieux comprendre une action
- comment on gère les écrans à haute densité
etc.
Le but premier c'est déjà que ça soit "utilisable" dans une première passe.
1. si je ne bouge pas assez vite ma pièce ou mon billet, le nav me propose de l'ouvrir dans un onglet.
si je répond par la négative, la pièce ou le billet reste en grand et vient recouvrir les autres...
J'ai pas assez cherché le pkoi mais je pense que ma proposition de résolution reste intact.
2. J'ai toujours le message d'erreur dans la console mais ça n'a pas l'air d'être impactant.
Pour la suppression avec appui long, ça fonctionne.
Peut-être rendre dispo le drag and drop inverse (ça me parait tellement intuitif).
Pour avoir une consigne adapté au tactile, je te conseil d'avoir 2 divs (.consigne et .consigne-touchscreen par ex) et afficher en fonction de cette méthode :
Code :
function is_touch_device() {
try {
document.createEvent("TouchEvent");
return true;
} catch (e) {
return false;
}
}code provenant du projet modernizr.
Pour "tactile pur". On va dire que je suis comme toi, je découvre des recommandations d'usage au fil du temps.
Je pense qu'il faudra les formaliser dans le draft pour les appliquer un peu partout et surtout travailler avec des échelles de priorité.
Par exemple :
- quel taille min on prend en charge. Si c'est en dessous, est-ce qu'on averti l'utilisateur qu'il risque d'être dans un mode dégradé ?
- comment ça se passe si l'on est en mode portrait
- le tactile nécessite d'avoir des boutons 1/3 plus gros que de l'interface desktop car la précision est moindre.
- les modales sans actions (juste ok) devrait pouvoir se fermer à l'appuie en dehors de la zone.
- le tactile a des zones mortes ou l'interaction est plus délicate (par exemple, le menu de l'os va être prioritaire sur une zone) : prévoir un padding globale assez conséquent pour éviter ces désagréments.
- le tactile nécessite souvent des petites animations pour mieux comprendre une action
- comment on gère les écrans à haute densité
etc.
Le but premier c'est déjà que ça soit "utilisable" dans une première passe.