- L’édition de texte sur Android et iOS a hérité des conventions du desktop, mais sur mobile il n’y a ni pointeur précis ni barre de menus, si bien qu’un simple tap cumule placement du curseur, sélection et appel du menu
- Le cœur du problème n’est pas la saisie de texte mais son édition ; dans une étude menée auprès de 10 utilisateurs, tous ont rencontré des difficultés de ciblage, d’utilisation du presse-papiers et des erreurs répétées
- Les poignées de texte, la loupe, le double tap, l’appui long et les menus contextuels sont chacun des palliatifs raisonnables, mais plus on les combine, plus l’ambiguïté dans l’interprétation du tap augmente
- Le prototype Eloquent interprète toujours le tap comme un placement du curseur, et simplifie le flux d’édition avec un déplacement centré sur le glisser, une loupe intégrée, une sélection par Drag Press et un menu par balayage
- Le principal frein à l’amélioration relève moins de la technique que de l’adoption et des priorités organisationnelles ; pour améliorer la productivité sur mobile, il faut un modèle d’édition adapté au tactile plutôt que des bricolages copiés du desktop
Pourquoi l’édition de texte sur mobile reste peu visible
- Android et iOS ont transposé sur mobile les méthodes d’édition de texte du desktop, alors que le mobile ne dispose ni d’un pointeur de souris précis ni d’une barre de menus / touches de commande
- Résultat : un seul geste de tap doit assumer plusieurs fonctions
- placer le curseur
- déplacer le curseur
- sélectionner du texte
- afficher un menu contextuel
- Le problème se voit moins dans les messages courts ou les commentaires sur les réseaux sociaux, mais dès qu’il faut corriger un texte long comme un e-mail de plusieurs phrases, l’édition devient laborieuse et source de nombreuses erreurs
Les échecs de l’édition révélés par une étude utilisateur de 2017
- En 2017, lors d’un travail sur Android, l’auteur a cherché des études existantes sur l’édition de texte mobile, mais n’en a trouvé aucune, même après avoir parcouru sept années de recherche
- 10 participants ont dû réaliser de simples tâches d’édition de texte, comme supprimer un caractère ou déplacer un mot à la fin d’une phrase
- Tous les participants ont rencontré les mêmes difficultés
- il était difficile de toucher exactement l’emplacement voulu
- l’usage du presse-papiers était peu pratique
- les erreurs répétées étaient fréquentes
- Les participants montraient davantage de frustration dans des textes complexes, comme des e-mails de plusieurs phrases, que dans les applications de messagerie ou sociales
- Plus de la moitié ont répondu qu’au lieu de corriger le texte, il était plus simple de tout sélectionner, supprimer puis ressaisir
- Le problème concerne moins la saisie de texte que l’édition
- grâce au clavier, à la dictée vocale et aux claviers physiques sur tablette, la saisie elle-même s’est améliorée par rapport au passé
- mais il reste toujours nécessaire de corriger une phrase après l’avoir saisie
- L’étude portait sur l’amélioration d’Android, mais iOS présente le même type de problèmes, même si les détails d’interaction diffèrent
Le mobile excelle pour la consommation, mais reste faible en édition
- Les appareils mobiles excellent dans la consommation en mobilité, comme la vidéo, la photo, les réseaux sociaux ou la messagerie
- Le premier iPhone n’avait même pas de prise en charge du presse-papiers
- Les attentes selon lesquelles les tablettes remplaceraient le desktop sont revenues à plusieurs reprises, sans grand succès comme substitut au desktop
- Apple a diffusé la publicité « What’s a computer? »
- En 2013, Google a tenté la campagne « Tablet Tuesdays », où les employés devaient utiliser une tablette toute la journée
- Parmi les problèmes UX profonds qui freinent la productivité sur tablette, on cite notamment l’édition de texte et la gestion des fichiers
- L’objectif n’est pas de revenir au desktop, mais de faire progresser le mobile jusqu’à un niveau de vitesse et de productivité comparable
Le point de référence : l’édition de texte sur desktop
- Depuis 2000, l’édition de texte sur desktop repose sur une structure relativement stable
- Le desktop s’appuie sur trois éléments fondamentaux
- un pointeur précis déplacé par la souris ou le trackpad
- une sélection simple qui commence par un clic puis un glisser
- un menu Édition avec Couper / Copier / Coller et les raccourcis X / C / V
- Cet ensemble rend l’édition de texte relativement peu ambiguë et peu sujette aux erreurs
- Ce n’est pas un système parfait, mais il sert de base de comparaison face à l’édition mobile
Les quatre palliatifs apparus en adaptant le desktop au mobile
-
1. Les poignées de texte
- Le mobile ajoute des poignées de texte en forme de goutte sous le curseur
- Ces poignées rendent le curseur plus visible et permettent de corriger la position après un mauvais tap en faisant glisser
- Mais la poignée elle-même est une cible tactile, tout comme le texte autour, ce qui crée de l’ambiguïté
- Lorsqu’on touche juste à gauche ou à droite du curseur, l’intention de l’utilisateur devient floue
- veut-il déplacer le curseur ?
- ou saisir la poignée pour la faire glisser ?
- Dans les tests utilisateurs, on a observé des personnes qui voulaient placer le curseur à un endroit précis, rataient de quelques caractères puis retapaient à côté, mais la poignée captait le tap en priorité, ce qui faisait échouer l’action
- iOS n’a pas de poignée en forme de goutte, mais le problème du curseur qui capte le tap existe malgré tout
-
2. La loupe
- Pour compenser la petite taille du texte et la relative grosseur des doigts, le mobile a ajouté une loupe
- La loupe aide moins à viser juste avant de taper qu’à corriger après un mauvais tap en glissant
- Comme elle flotte au-dessus du doigt, elle montre en pratique deux curseurs : le vrai curseur et son double dans la loupe, ce qui crée une confusion visuelle
- C’est moins sensible dans un champ de texte court, mais dans un e-mail long, il devient facile de perdre sa position actuelle
- La loupe d’Apple a disparu avec iOS 13 avant de revenir dans iOS 15
-
3. La sélection de texte
- Sur desktop, maintenir le clic puis glisser mène naturellement à la sélection du texte
- Sur mobile, cette méthode est difficile, d’où l’ajout du double tap et de l’appui long comme gestes de sélection
- Interpréter un double tap implique d’attendre l’éventuelle seconde pression, ce qui peut retarder la réaction au tap simple
- Pour sélectionner plus qu’un mot, il faut ensuite faire glisser les poignées aux deux extrémités de la sélection
-
4. Le menu contextuel
- Comme il n’y a pas de barre de menus sur mobile, il faut un autre moyen d’appeler les commandes du presse-papiers
- Lorsqu’un texte est sélectionné, un menu apparaît au-dessus de la sélection, ce qui fonctionne plutôt bien pour Couper / Copier
- Coller est plus caché, car l’action ne part généralement pas d’une sélection
- Pour ouvrir ce même menu, il faut toucher la poignée de texte, ce qui oblige l’utilisateur à apprendre deux gestes différents
- Sur Android, la poignée de texte disparaît après 4 secondes sans saisie
- parce qu’elle masque légèrement le texte situé dessous
- pour rouvrir le menu, il faut retaper pour faire réapparaître la poignée, puis la retaper une seconde fois
- Comme le mobile n’a pas de raccourcis clavier équivalents à Couper / Copier / Coller, débutants et experts doivent tous passer par le même système de menus
Une structure où un seul tap peut être mal interprété de plusieurs façons
- L’édition de texte mobile a multiplié les interprétations possibles du tap en essayant de faire entrer les fonctions du desktop dans le mobile
- Quand l’utilisateur tape une fois, le système peut l’interpréter comme l’une des actions suivantes
- placement du curseur
- ouverture du menu si un curseur est déjà présent
- début d’un glisser
- début d’un double tap
- début d’un appui long
- Avec beaucoup de précaution, on peut distinguer chacune de ces actions, mais la structure elle-même reste fragile
- Les erreurs observées pendant les tests utilisateurs incluent
- le problème des gros doigts, qui fait manquer l’emplacement visé
- l’utilisateur tape à côté pour corriger le curseur, mais touche la poignée et affiche le menu
- le système interprète un léger mouvement comme un minuscule glisser au lieu d’un menu, et rien ne se passe
- en voulant faire un double tap, l’utilisateur touche à côté ou heurte la poignée, et rien ne se passe
- pour coller dans un champ vide, il faut d’abord taper le champ vide pour créer un curseur, puis retaper le curseur pour faire apparaître le menu
- l’utilisateur détourne brièvement le regard après avoir placé le curseur, et la poignée a déjà disparu, ce qui le déroute
- Dans l’étude à 10 personnes, il fallait en moyenne 5 tentatives pour placer correctement le curseur, et un utilisateur a tapé 19 fois
- On comprend ainsi pourquoi beaucoup préfèrent ressaisir l’ensemble plutôt que de vraiment éditer le texte
Les limites des fonctions correctives existantes
- Il existe des palliatifs, comme la sélection de plus de texte en faisant glisser après un double tap, ou des fonctions de clavier permettant de déplacer le curseur
- Mais ces fonctions sont généralement difficiles à découvrir pour la plupart des utilisateurs et ne résolvent pas le problème central
- Le vrai problème est que des centaines de millions d’utilisateurs mobiles subissent chaque jour des erreurs de tap et de sélection
- Pour que le mobile remplace ou rivalise avec le desktop, il faut aller au-delà de hacks de tap copiés du desktop et adopter une approche plus simple et plus claire, pensée pour l’expérience tactile
L’approche du prototype Eloquent
- Le prototype Eloquent a été conçu avec Olivier Bau et présenté à UIST 2021
- Eloquent tente de traiter simultanément les conflits entre tap, sélection, loupe et menus
-
Un placement du curseur simplifié
- L’objectif central d’Eloquent est de rendre le sens du tap explicite, comme le clic de souris sur desktop
- Un tap place toujours le curseur
- Tout contact du doigt avec l’écran est considéré comme le début d’un glisser, et le tap est traité comme un glisser très court
- Si l’on touche à côté de la poignée puis qu’on relâche vite, le curseur se déplace vers la nouvelle position ; si l’on bouge plus lentement, on fait glisser le curseur
- La poignée de texte reste toujours visible
- Elle devient semi-transparente pour ne pas masquer le texte et supprime ainsi le problème de disparition au bout de 4 secondes sur Android
-
Une loupe intégrée
- La loupe est intégrée au-dessus du curseur afin que l’utilisateur voie le curseur dans son contexte textuel
- Comme Eloquent est centré sur le glisser, la loupe améliore la précision du placement du curseur
- Pour gagner de la place et préserver la position dans le texte, Eloquent utilise une technique de lentille fisheye
- À l’usage, une tendance s’est dégagée : faire systématiquement glisser le curseur semblait préférable à de simples taps
- Grâce à la loupe, les utilisateurs ont vite appris un nouveau comportement consistant à approcher rapidement la cible par glisser
-
La sélection de texte avec Drag Press
- L’ambiguïté de l’édition mobile actuelle vient du fait qu’un trop grand nombre de fonctions est concentré sur un geste de tap unique
- Eloquent lance la sélection de texte par un geste de Drag Press, c’est-à-dire en appuyant plus fort pendant un glisser
- Pour détecter cette pression, le prototype utilisait le capteur barométrique du téléphone, disponible sur le matériel de l’époque
- une moyenne glissante longue servait de valeur de référence
- lorsqu’une moyenne glissante courte passait au-dessus de la moyenne longue, un événement drag-press était déclenché
- malgré les variations parfois importantes des valeurs du capteur, le fonctionnement s’est montré très robuste
- Des mécanismes plus avancés, comme le 3D Touch hardware abandonné par Apple, pourraient offrir une meilleure solution
- Le Drag Press sélectionne le mot entier situé en dessous, de sorte qu’un petit tremblement au moment d’appuyer ne se transforme pas en grosse erreur de ciblage
-
Un menu amélioré
- Eloquent cherche à rendre plus rapides pour les utilisateurs expérimentés les actions du presse-papiers, comme copier et coller
- Comme les menus de texte actuels d’Android et d’iOS sont majoritairement hiérarchiques, Eloquent cherche à les aplanir
- Lors des tests utilisateurs, tous les participants ont facilement trouvé ce menu et ont apprécié son utilisation
- Après avoir lancé une sélection avec Drag Press, un second Drag Press fait apparaître le menu, ce qui réunit ciblage, sélection et appel du menu dans un même flux
- Pour les utilisateurs avancés, un geste de flick rapide permet d’exécuter directement une commande du menu
- Le T-Menu d’Eloquent utilise des gestes de balayage pour couper et coller, et glisse hors de l’écran sans hiérarchie
-
Des animations inspirées du jeu vidéo
- Eloquent ajoute de petites animations visuelles pour aider les utilisateurs à apprendre et comprendre les changements d’état
- Le curseur se déplace d’une position à l’autre en « scoot », puis la poignée « wobble » quand il arrive
- Ces mouvements renforcent l’impression que le curseur existe en permanence et peut être glissé à tout moment
- Lors d’un tap, le curseur fait un « dimple » et appelle brièvement la loupe, afin d’inciter l’utilisateur à essayer le glisser plutôt qu’un simple tap
- Quand un Force Press se produit sur un mot, la surbrillance « inflate »
- Les gestes de menu par balayage animent la sélection dans la direction du geste
- un balayage vers le haut pour couper fait disparaître la sélection vers le haut
- un balayage vers le bas pour coller fait tomber la nouvelle sélection vers le bas
-
Compatibilité pour les utilisateurs existants
- Eloquent essaie aussi de préserver autant que possible les gestes actuels afin de garder un lien avec les usages existants
- Si tous les taps et glissers étaient toujours interprétés comme des glissers de curseur, cela poserait problème dans les grands champs de texte à défilement vertical
- Si les premiers pixels du geste sont verticaux au début du glisser, Eloquent l’interprète comme un défilement vertical classique
- Les autres glissers sont traités comme placement et déplacement du curseur
Pourquoi c’est difficile à lancer
- Une évolution comme Eloquent est difficile à mettre en production
- Beaucoup considèrent à tort que l’édition de texte est déjà un problème « résolu », ce qui réduit la volonté de la corriger
- Les utilisateurs se sont adaptés depuis plus de dix ans à un système actuel très imparfait, et il est difficile d’exiger un changement maintenant
- Dans la concurrence entre Android et iOS, améliorer l’édition de texte n’est pas perçu comme une fonctionnalité spectaculaire capable de faire bouger un Net Promoter Score
- Un changement fondamental comme celui de l’édition de texte peut rendre l’usage du téléphone plus confortable, mais ses effets apparaissent lentement et demandent des années d’efforts continus
- Le principal obstacle est moins technique que politique
- Au rythme actuel, il est possible que nous éditons encore le texte mobile de la même manière pendant au moins 20 ans
1 commentaires
Avis sur Hacker News
Sur mobile, on finit par écrire des textes courts qui prennent plus de temps et contiennent plus d’erreurs. C’est pourquoi j’évite activement les situations où je dois taper sur mobile, et si mon ordinateur portable est ouvert, j’utilise aussi WhatsApp ou Signal dessus.
Quand je dois utiliser le clavier du mobile, j’accepte simplement les fautes de frappe, l’absence de majuscules et l’omission de mots non indispensables. Le téléphone sert surtout à consommer des actualités et des médias, et à prendre des photos, plutôt qu’à saisir de longs textes.
Le fait que les étuis-claviers soient populaires même sur iPad montre les limites du clavier tactile. Sur iPad, il y a au moins un clavier et un stylet, mais sur iPhone il n’y a presque pas ce genre d’options, et les téléphones avec un bon clavier matériel, comme les anciens Nokia ou BlackBerry, me manquent.
L’iPad est pire au final, parce qu’il faut appuyer lettre par lettre sur un mauvais clavier tactile QWERTY. Ce serait bien d’avoir une disposition de clavier optimisée pour le glissement, et il y avait autrefois un article qui calculait une disposition plaçant les voyelles aussi loin que possible : https://sangaline.com/post/finding-an-optimal-keyboard-layou...
Si l’on veut saisir un message en conduisant, à moins que la dictée soit parfaite du premier coup, il faut utiliser ses mains ; on est donc presque arrivé à quelque chose de bon, mais tout s’effondre à cause de l’interface d’édition.
Aujourd’hui, je ne tape sur écran tactile que quand je ne peux vraiment pas faire autrement, et même si je ne peux pas utiliser d’ordinateur portable, dès que je peux m’asseoir, je pose le téléphone sur un support et j’utilise un petit clavier Bluetooth pliable.
Toute l’industrie du smartphone s’est iPhoneisée, et nous avons perdu ces options.
Cela dit, je suis d’accord pour dire que la saisie sur iOS pourrait être améliorée : https://youtu.be/x7qPAY9JqE4?si=9_jnM2Ys8JiTXGqC
Le problème existe clairement, mais je ne suis pas sûr que l’auteur ait trouvé une solution. D’après la description seule, cela semble toujours délicat.
Les écrans tactiles sont fondamentalement mauvais comme interface de productivité. Une souris permet de pointer sans cliquer, de faire un clic gauche et un clic droit avec une précision quasiment au pixel près, et si l’on ajoute le clavier, les possibilités deviennent bien plus nombreuses.
Un smartphone ressemble à un ordinateur avec une souris à un seul bouton et un curseur anormalement grand et de forme irrégulière. Le logiciel ne connaît pas la position du curseur avant le clic, et le clavier n’apparaît que sous forme de surcouche couvrant 35 % du petit écran.
Ce n’est pas un problème logiciel, mais un problème matériel.
Il existe des implémentations où l’écran tactile est utilisé pratiquement comme un pavé tactile, comme la manière dont TeamViewer gère les sessions à distance de bureau Windows sur smartphone. Ce serait bien que ce soit disponible dans Android lui-même comme un mode activable, et sélectionner du texte avec des doigts arthritiques est littéralement douloureux.
Le problème, c’est que ce potentiel est très peu exploité en dehors du pincement pour zoomer et du défilement à deux doigts.
C’était une fonction vraiment utile pour l’édition de texte, et j’aurais aimé qu’elle survive.
Je me demande parfois si, sur les appareils tactiles, l’édition modale à la Vim ne serait pas une bonne approche pour parcourir et modifier de longs textes.
Transposer tel quel le modèle clavier-souris aux appareils tactiles ressemble à une occasion manquée. Même la disposition du clavier n’apporte pas vraiment d’avantage quand on tape sur l’écran avec deux pouces.
Une approche qui s’appuierait fortement sur l’inférence fondée sur les caractères tout en adaptant l’interface à une saisie à une main ou à un seul doigt serait aussi intéressante. Dasher en est un exemple : https://www.inference.org.uk/dasher/dashersummary.html
https://en.m.wikipedia.org/wiki/Dasher_(software)
Si c’est un mode où les touches disparaissent, il ne semble pas déraisonnable d’y ajouter une fonction agissant comme un bouton de souris, pour permettre la sélection de texte ou le collage à un emplacement précis. Aujourd’hui, la sélection est beaucoup trop frustrante.
C’est suffisant pour programmer en déplacement.
Ajouter une page dédiée à l’édition du curseur, avec flèches, Ctrl+flèches, Home/End, Page Up/Down, bascule de sélection, Delete et menu de clic droit, semblerait naturel. Ce ne serait pas vraiment une innovation, seulement une façon de rapatrier le reste du clavier de bureau sur le clavier du téléphone.
Avec un clavier Bluetooth, c’est correct ; l’écran est juste un peu petit. C’est suffisant pour de courtes tâches, même si, sur de longues sessions, je m’inquiéterais pour la santé des yeux.
Ce problème n’est, du moins pour moi, pas du tout invisible. Il y a quelques mois encore, je citais l’édition de texte comme exemple montrant qu’iOS n’est pas encore prêt pour un usage professionnel.
La création et l’édition de texte sont au cœur de l’usage professionnel, contrairement à la simple consommation de contenu ; Apple devrait soit reconnaître le problème et le résoudre, soit admettre qu’il ne peut pas le résoudre et cesser de pousser ce récit.
Le fait qu’Apple ait lancé 3D Touch sans cas d’usage valable, puis l’ait abandonné quelques années plus tard sans en avoir trouvé, est aussi symbolique.
Les Tablet Tuesdays de Google sont intéressants, mais si l’on n’utilise une tablette qu’un jour par semaine, on peut tout juste supporter les problèmes et passer à autre chose. Il aurait plutôt fallu que toute l’équipe n’utilise que des tablettes — des Tablet Teams — pour que les problèmes ne restent pas cachés.
Eloquent ressemble à une preuve d’existence qu’une meilleure méthode est possible. Cela vaudrait aussi la peine d’expérimenter des gestes multitouch pour résoudre les problèmes de copier-coller ou de sélection.
À l’inverse, même si certains employés utilisaient des produits sociaux comme Google+, ils n’étaient pas nombreux et n’avaient pas les mêmes besoins fonctionnels que les utilisateurs externes. Même en cas de mécontentement interne, ce n’était pas au cœur du travail, donc il était difficile d’obtenir la même boucle de rétroaction.
Le plus gros problème de l’édition sur mobile, c’est de modifier une sélection qui ne tient pas entièrement à l’écran, comme une URL longue ou un long paragraphe.
Dès qu’il faut déplacer les poignées de sélection tout en faisant défiler verticalement — pire encore, horizontalement — l’expérience utilisateur s’effondre complètement.
C’est le plus gros problème, et j’ai aussi du mal à comprendre pourquoi les claviers mobiles n’ont pas de boutons copier/coller.
C’est maladroit, mais ça fonctionne.
Sur les anciens téléphones N9 et Jolla, on pouvait toucher n’importe quel endroit du texte pour y placer le curseur.
Sur iOS, sauf lorsqu’on active le curseur au premier toucher, même si l’on appuie précisément au milieu d’un mot, le curseur se colle toujours au début ou à la fin du mot.
Même avec un petit écran et de gros doigts, on arrive assez bien à viser la position voulue dans un mot ; j’aimerais donc qu’on nous laisse simplement le faire.
J’ai du mal à expliquer exactement pourquoi c’était si utile, mais il était beaucoup plus facile de positionner le curseur là où on le voulait.
Le clavier iOS a beaucoup de côtés frustrants, mais en réalité il est plutôt correct. Le vrai problème vient souvent d’outils JavaScript tiers comme les anciennes versions de CodeMirror.
Sur BlackBerry, je tapais 55 mots par minute sans même regarder. Avec les claviers à l’écran, il faut sans cesse regarder et corriger, ce qui capte énormément l’attention et tue la vitesse de saisie
Sur BlackBerry, une erreur était un seul mauvais caractère, mais sur un clavier à l’écran avec saisie par glissement et correction automatique, on peut se retrouver avec un ou deux mots complètement à côté. Par temps de pluie, les claviers à l’écran fonctionnent mal
Sur de vieux appareils Android, le clavier intégré était parfois si lourd qu’il fallait ralentir jusqu’à environ un caractère par seconde, et le passage entre glissement et tapotement n’était pas fluide non plus. Le fait qu’un mot soit inséré dès la première tentative quand on essaie de déplacer le curseur en faisant glisser la barre d’espace est aussi agaçant
L’édition sur BlackBerry se faisait aussi uniquement avec des touches de curseur, donc c’était plus rudimentaire que les manipulations tactiles dont il est question ici. Le point essentiel n’est pas seulement de corriger les fautes de frappe, mais de permettre à des appareils mobiles de remanier fortement du texte existant et de peaufiner des documents
J’étais un peu plus lent avec le clavier coulissant du Droid 4, puis le passage à l’écran tactile m’a énormément ralenti. Sur BlackBerry, je pouvais traiter mes e-mails presque à la même vitesse que sur un ordinateur portable, alors qu’aujourd’hui, même après beaucoup d’entraînement à la saisie par glissement et au texte prédictif, écrire un e-mail de longueur moyenne paraît douloureusement lent par rapport à la vitesse de la pensée
Si j’essaie de retranscrire un podcast sur téléphone, je dois souvent revenir en arrière et ralentir à 0,7×, alors que sur ordinateur portable je peux taper même plus vite qu’une personne qui parle rapidement. Avec un BlackBerry Bold, j’aurais pu prendre en note une présentation en temps réel, et taper à la vitesse de ma pensée
La différence entre éditer sur un MicroPC avec touchpad et clavier physique, et éditer sur un téléphone, est énorme
On peut peut-être saisir plus vite ou naviguer dans l’UI plus rapidement sur un téléphone à écran tactile capacitif, mais la frustration liée au placement du curseur et à la frappe reste forte, même après plus de dix ans d’usage des smartphones
Je comprends aussi pourquoi les gens ne perçoivent pas vraiment cela comme un problème. Avec le temps, ils ont appris à ne pas éditer de texte sur mobile. Les systèmes d’exploitation mobiles modernes proposent pourtant des suites bureautiques assez puissantes, mais la plupart des gens se limitent aux messages et aux notes, et ont rarement besoin de déplacer le curseur
Sur Squeekboard du PinePhone, la fonction permettant de déplacer le curseur en faisant glisser la barre d’espace et la saisie par glissement manquent beaucoup, mais le fait que l’édition de texte dans Phosh, même bien moins polie que sur Android ou iOS, n’ajoute pas vraiment beaucoup de difficulté en dit long
Si l’on ne regarde que l’édition de texte, quand les chiffres, les symboles nécessaires et les touches de modification sont sur la couche de base, Vim et Emacs deviennent étonnamment utilisables avec un clavier tactile
Le problème du pointage précis et des gros doigts peut être résolu en utilisant l’écran tactile comme un touchpad, avec une saisie relative. C’est possible avec un simple programme en espace utilisateur qui se connecte directement à evdev et uinput, et cela fait de l’exécution de logiciels desktop autre chose qu’un simple gadget : https://gitlab.com/CalcProgrammer1/TouchpadEmulator
Pour la saisie par glissement, la prise en charge expérimentale de wvkbd fonctionne plutôt bien. Elle convient particulièrement aux mots longs ou aux dictionnaires réduits, et ouvre aussi des possibilités comme l’exploitation de la complétion zsh écrite dans un fichier : https://git.sr.ht/~proycon/wvkbd
La latence de sxmo_inputhandler.sh est difficile à comprendre. Traiter de simples gestes de shell du système d’exploitation avec un long script shell, sur une plateforme où même un seul pipeline grep ajoute une latence perceptible, paraît très inefficace
C’est comme si l’on retirait le clavier d’un ordinateur portable, que l’on affaiblissait le système d’exploitation, puis que l’on appelait cela « mobile »
Ensuite, quand quelqu’un dit que l’édition de texte n’est plus pratique, on répond : « il ne s’agit pas de revenir au desktop, mais de faire avancer le mobile »
Je ne vois pas pourquoi il faudrait traiter une expérience informatique volontairement affaiblie comme un avenir inévitable. Presque toutes les tendances que le mobile ouvre sont mauvaises
Parce que ces appareils offrent une expérience informatique plus médiocre, plus verrouillée et plus centrée sur la consommation. Ce genre d’idée semble aussi être inculqué aux employés
C’est comme la télévision : ce n’est pas un substitut à un ordinateur portable
On ne voit pas non plus très bien en quoi cela nuirait à l’expérience desktop
J’ai écrit tellement de code dans Termux que désormais je n’utilise mon ordinateur portable que pour éditer OpenStreetMap. Je cherche un moyen de compiler de nouvelles apps Android directement dans Termux
Sur mobile, rien ne va vraiment. Tout le monde aime les smartphones, mais à part leur portabilité, ce sont à tous égards de mauvais ordinateurs.
Si l’on veut vraiment faire quelque chose, il faut utiliser un ordinateur ; un smartphone est un appareil qu’on n’utilise que lorsqu’on ne peut pas se servir d’un vrai ordinateur.
C’est pourquoi ce genre d’article est important. Il ne faut pas abandonner, mais améliorer les choses, et il n’y a aucune raison de penser que l’édition de texte sur téléphone ait atteint sa forme définitive.
Écrit avant l’iPhone, ce texte traitait de la nécessité implacable de réduire l’expérience utilisateur mobile à l’essentiel. En créant une app Apple Watch, cela m’est revenu à l’esprit : https://jenson.org/The-Simplicity-Shift.pdf
Il est difficile d’accepter qu’un appareil vendu à ce prix offre une expérience utilisateur médiocre en faisant passer le pistage et les combines publicitaires avant l’utilité.
Ce n’est pas au niveau d’un ordinateur de bureau, mais c’est bien mieux que la plupart des appareils mobiles ; pour WhatsApp Web ou l’app de bureau Signal aussi, dès qu’il faut écrire plus d’une ou deux phrases, je préfère les utiliser sur desktop.
Si vous devez écrire un texte un tant soit peu long sur téléphone, mieux vaut acheter un clavier. Même un petit clavier Bluetooth est nettement mieux, et les anciens BlackBerry ou les téléphones Android à clavier de forme similaire ont aussi leur attrait.