Est-ce une mauvaise pratique de supprimer les commandes d'avance rapide et de rembobinage du lecteur vidéo?
J'ai la possibilité de personnaliser un lecteur vidéo pour une application mobile iOS/Android et j'envisage d'omettre les commandes "<<" (rembobinage/saut précédent) et ">>" (avance rapide/saut suivant).
Je pense que ce sont des fonctionnalités héritées redondantes à partir du moment où les magnétoscopes et autres n'avaient pas de barre de temps scrubbable pour que l'utilisateur puisse rembobiner et avancer rapidement. De plus, la majorité du contenu vidéo de cette application sont des vidéos uniques et ne font pas partie d'une liste de lecture, donc la vidéo précédente/suivante n'est pas une fonctionnalité utile.
Ma question est de savoir si ce serait une mauvaise pratique, car cela briserait les attentes des utilisateurs et pourrait être légèrement désorientant. Aussi s'il y a des problèmes d'accessibilité ou d'autres problèmes imprévus à cette approche.
Merci!
Il ne serait pas inapproprié de supprimer un bouton dédié d'avance rapide (FF) ou de rembobinage (RW) d'une interface utilisateur vidéo numérique.
A quoi servent-ils?
Les boutons FF et RW ont été conçus pour se déplacer rapidement sur les supports de bande physiques. Dans le cas de l'image ci-dessous une cassette, mais ils sont apparus sur des supports avant cela.
Sinon, il n'y avait aucun moyen pratique d'avancer ou de reculer dans les médias, sauf si vous jouiez la bande. Les fonctions étaient significatives et pratiques pour le médium.
Duplication de fonctionnalités.
La duplication des fonctionnalités n'est pas toujours mauvaise, mais elle n'est vraiment bonne qu'en cas de besoin - les problèmes de sécurité en sont un bon exemple. Les lecteurs vidéo numériques affichent presque toujours une barre de progression - qui vous indique également la durée totale de la vidéo.
Prenez l'interface de YouTube:
La barre de progression (un seul élément d'interface utilisateur) fait le travail de plusieurs choses:
- Heure actuelle
- Temps total
- Avance rapide
- Rembobinage
- Aller à un emplacement spécifique
FF et RW sont accomplis par l'action de faire glisser le widget "position actuelle". L'utilisateur peut également accéder à un emplacement spécifique en cliquant quelque part sur la barre de progression elle-même. Toutes ces fonctions ne sont pas possibles sur les supports de bande, où les touches FF/RW ont un sens, en raison de contraintes physiques.
Il n'est pas nécessaire d'ajouter une autre méthode pour accomplir ce que fait déjà la barre de progression.
Evolution de l'UX
Ce qui s'est passé n'est pas la "suppression" des boutons FF ou RW, mais leur évolution dans la barre de progression. L'interface numérique (ordinateur ou écran tactile) combinée aux capacités des supports numériques (temps total disponible, saut instantané, autres) a rendu inutile de se déplacer à travers les supports de manière séquentielle. La barre de progression est FF et RW, pour les médias à portée de main.
Priorité
Les inquiétudes quant à savoir si les utilisateurs manqueraient un bouton FF ou RW devraient rapidement se dissiper avec un examen rapide des autres lecteurs multimédias à leur disposition. Prenez YouTube, illustré ci-dessus, sur le bureau ou l'un des exemples suivants tirés de mon iPhone:
YouTube:
Netflix:
Remarquez l'absence d'un bouton RW, mais il y a un bouton de saut de 10 secondes. Idéal lorsque vous regardez quelque chose et que vous n'avez pas tout à fait saisi ce dernier dialogue. Au lieu de forcer l'utilisateur à déplacer la barre de progression, ou devinez en appuyant sur un bouton RW générique, Netflix a judicieusement ajouté une seule touche pour sauter rapidement en arrière.
Vidéo (lecteur vidéo par défaut d'Apple):
Tous ont supprimé les boutons FF et RW au profit de la barre de progression beaucoup plus polyvalente. Il est très peu probable que vos utilisateurs aient du mal à passer de l'utilisation des boutons FF/RW à votre application (s'ils le font encore).
Accessibilité
Cela dépend de la façon dont vous l'implémentez, mais d'une manière générale, une barre de progression ne devrait pas être moins accessible que les boutons dédiés.
Tous les systèmes d'exploitation mobiles ont des tailles de bouton recommandées. Ils vont normalement de 5-9 mm, donner ou prendre, selon le but du bouton. L'espace de hit fourni à la "position actuelle" de la barre de progression devrait être au moins aussi grand, et pourrait facilement être plus grand car votre application n'a probablement pas beaucoup d'autres contrôles flottant autour que l'utilisateur pourrait autrement frapper accidentellement. La longueur supplémentaire de la barre de progression offre également un espace supplémentaire pour la saisie.
Si votre souci d'accessibilité vient des contraintes physiques de votre population d'utilisateurs (âge, arthrite, etc.), alors comment vous implémentez la barre de progression peut également changer. Une pensée, faites glisser le curseur vers la gauche/droite sur la vidéo pour déplacer la barre de progression aussi - pas seulement le glisser sur la barre de progression.
Les boutons dédiés pourraient également être considérés comme moins accessibles.
- Les boutons FF/RW dédiés ont une vitesse définie. Je contrôle la vitesse lorsque je fais glisser la barre de progression.
- Cette vitesse définie peut être trop rapide ou trop lente pour moi.
- Comment puis-je arrêter l'action FF/RW avec des boutons dédiés? Si je traîne, j'arrête juste de glisser.
- Restreindre le point auquel je veux m'attendre peut nécessiter plusieurs pressions sur les touches FF/RW. Faire glisser un peu avant est facile à faire.
Sur un grand écran, la barre de progression fournit en effet les fonctionnalités FF et RW.
Ce n'est pas le cas pour les appareils mobiles avec de petits écrans tactiles - il est très difficile d'obtenir une précision meilleure que 10% si le lecteur vidéo est utilisé en mode portrait à l'aide d'un doigt et d'une barre de progression. Pour des vidéos plus longues (plus d'une demi-heure) sur de tels appareils, la barre de progression n'est rien de plus qu'une source d'anxiété.
Je recommanderais de tester votre barre de progression sur l'écran de taille minimale prise en charge et de voir la vidéo la plus longue possible, si elle est suffisamment utilisable.
En ce qui concerne les spécificités de la lecture vidéo, qu'il y ait ou non quelque chose "avant" ma lecture actuelle, le "<<" est ce que je recherche pour rembobiner instantanément au début. Et si le ">>" n'a pas de sens, alors ne l'incluez pas.
LE PLUS IMPORTANT : Si l'élément GUI ne sera jamais utilisé, alors c'est [~ # ~] plus [~ # ~] désorientant l'utilisateur pour les lui présenter.
Sinon, chaque fois que je suis confronté à une question de la forme suivante:
Dois-je inclure des contrôles GUI qui ne seront utilisés que de temps en temps ?
Je commence à penser en termes de fourniture de deux modes, une interface graphique avancée et une plus allégée. Cela peut être fait de multiples façons, le plus simple est un bouton plus petit que la normale qui ajoute simplement d'autres boutons au contrôle.
Remarque cependant: cela n'est pas destiné à masquer des fonctionnalités qui n'ont aucun sens. Au lieu de cela, pensez-y comme un outil de désencombrement.