Barre de progression de saut ou indicateur de processus en cours?
Je suis en train de développer un processus avec un nombre prédéfini d'étapes à terminer, donc pendant que le processus est en cours, je peux savoir jusqu'où le processus est allé et combien il reste à faire.
Mon processus s'exécute en quelque sorte dans un mode d'arborescence où chaque branche a le même nombre de nœuds, mais toutes les branches ne mènent pas à un résultat. ce qui signifie que le processus reviendra à un nœud qui a une jonction et essaiera une autre branche.
Cela signifie que si ma longueur de branche est de 100 nœuds, il peut arriver que pendant que le processus arrive au nœud 75, il voit une impasse et revienne au nœud 50 et continue avec une branche de cette jonction.
Question
Puisque mon processus peut définir le point de son exécution, je préfère toujours afficher la barre de progression à la place juste un indicateur en cours d'exécution ou barre de progression indéfinie qui ne fournit absolument aucun retour à l'utilisateur.
ne barre de progression sautant est-elle incorrecte et ne doit-elle pas être utilisée du tout?
Donnée supplémentaire
Chaque étape de progression est un jour de toute la gamme. Il y a un calcul complexe en cours pour chaque jour, mais le processus fonctionne de telle sorte que:
- ça prend le lendemain (premier dans la première étape)
fait le calcul
- lorsque le calcul réussit, il marque tous les points de jonction.
- lorsque le calcul échoue, remontez autant de jours jusqu'à ce qu'il trouve le premier point de jonction et continuez à partir de ce point.
- passez à l'étape 1 jusqu'à ce qu'il ne reste plus de jours.
De ce processus, vous pouvez voir que je ne peux déterminer que le nombre de jours pour effectuer le calcul, mais pas le nombre de jonctions car elles dépendent fortement de chaque jour ainsi que du chemin emprunté lors des étapes précédentes.
C'est la raison pour laquelle j'ai décidé d'incrémenter la barre de progression en termes de calcul du jour X de Y . et lorsque je retourne aux intersections, je peux revenir en arrière quelques jours avant de pouvoir commencer de nouveaux calculs ... D'où une barre de progression en arrière.
Solution possible
Je pourrais montrer une barre de progression indéterminée (qui est probablement meilleure qu'une jauge rotative) avec des informations quantitatives sur le jour (de tous) actuellement calculé et combien ont été totalement sauvegardés jusqu'à présent.
Est-ce que cela aurait du sens pour les utilisateurs? Dois-je afficher d'autres chiffres?
Je suppose que quelque chose d'autre à côté de la barre de progression indéterminée est nécessaire, car cette sorte de barre de progression est identique au contenu statique. Ça ne change pas. Il ne fournit donc aucun retour d'information réel à l'utilisateur que quelque chose se passe ...
Il y a un principe en science cognitive qui nous ressentons une perte de quelque chose de bien plus que nous ne ressentirions un gain de cette même chose. Donc, si je vous donne 10% de progrès, puis 10% de progrès, d'un point de vue humain, je suis plus comme -20% que ce que les mathématiques me diraient.
Outre l'aspect des sciences cognitives ci-dessus, vous devez éviter de faire quoi que ce soit qui puisse dérouter les gens. Si la barre était à 88% et qu'elle est maintenant à 70%, cela n'a tout simplement pas de sens et ajoute confusion.
De plus, cela signifie que votre 88% n'était pas vraiment 88%, ce qui peut avoir un impact sur le fait qu'ils trust autres choses que vous dites.
Il y a probablement des nœuds dans la progression qui, une fois que vous n'aurez plus jamais à revenir en arrière. Vous ne pouvez incrémenter la progression que lorsque vous arrivez à ces nœuds. De cette façon, vous n'aurez jamais besoin d'annuler les progrès.
Cependant, avez-vous même besoin une barre de progression? Qu'ajoutez-vous à l'UX en faisant savoir aux gens dans quelle mesure les progrès sont? (Je les aime souvent parce que je suis une personne chargée des numéros techniques et que j'aime les données, mais cela ne les rend pas nécessaires). Selon l'application, cela pourrait ajouter beaucoup à l'UX, mais très souvent, la seule information nécessaire est que quelque chose se charge. Dans ce cas, vous pouvez simplement utiliser une animation de chargement. Quelque chose comme:
Edit: D'après ce que vous décrivez, vous n'avez aucune idée du temps que quelque chose va prendre, vous ne pouvez donc pas montrer de% de progrès. Ce que vous pourriez faire, c'est afficher un simple compteur à chaque fois que vous traitez un autre nœud afin que quelqu'un puisse voir que le processus est toujours en cours d'exécution et non bloqué. Ils pouvaient le voir passer de 154 à 155 avec quelque chose comme "155 nœuds traités" (en supposant qu'un nœud traité signifierait quelque chose pour eux).
En règle générale, le saut de barre de progression n'est pas une bonne idée et doit être évité. Vous feriez mieux de laisser 100% de tous vos nœuds du tout et de sauter en avant pendant que vous sautez certaines étapes si vous voyez que c'est une impasse. De cette façon, les progrès ne seront pas fluides, mais les utilisateurs verront certaines garanties que quelque chose a déjà été fait et ne sera pas calculé à nouveau.
Le seul moyen de sauter la progression est autorisé si vos utilisateurs comprennent parfaitement le modèle de calcul et savent pourquoi il pourrait reculer. Mais même dans ce cas, il devrait y avoir quelque chose qui va de l'avant uniquement, par exemple une autre progression qui affiche la quantité de tentatives déjà effectuées, ou le temps passé, s'il n'y a pas d'autre mesure.
Cela dépend beaucoup de ce que vous traitez et du temps que cela prend habituellement.
Si cela prend un court laps de temps (10-30 secondes ou moins), vous pouvez simplement prendre le nombre attendu de nœuds fois 2 et augmenter la barre de progression comme vous le feriez normalement. (en gros, vous prenez les 50% supérieurs comme "temps tampon"). Cela dépend de votre travail habituel et de la divination standard.
Si cela prend plus de temps (30 secondes ou plus), j'irais pour un compteur croissant (X nœuds scannés à partir du nombre total de nœuds Y) et terminerais simplement quand je serais prêt avec une petite étiquette d'information disant que le nombre Y est le pire des cas et le le travail pourrait se terminer plus tôt.
Si le rapporteur de progrès est vraiment important, vous pouvez utiliser une combinaison des deux montrant la quantité de progrès et la quantité de travail attendue restant en utilisant des chiffres réels testés.
Bien que les barres de progression puissent être agréables visuellement, dans certains cas, il pourrait être plus utile de signaler deux valeurs numériquement, avec une vitesse de mise à jour qui permet de les lire facilement:
1. Amount of work done.
2. Estimated total amount of work that will be necessary.
Si les estimations initiales de la quantité totale de travail s'avèrent inexactes, la deuxième quantité ci-dessus peut augmenter ou diminuer considérablement, ce qui affecterait à son tour toute estimation de la fraction des travaux achevés. D'un autre côté, une personne qui regarde l'écran et voit les chiffres serait mieux en mesure de dire quels progrès ont été réalisés qu'une personne qui a simplement vu une barre de progression, surtout si la personne qui a effectué un processus plusieurs fois savait que le une sous-estimation initiale serait corrigée à un certain moment du processus. Si le processus semble être accompli à 80% lorsque la quantité totale de travail estimée est multipliée par cinq, une simple barre de progression n'aurait aucun moyen d'indiquer que le travail était toujours effectué au même rythme continu - seule la quantité totale estimée de travail a changé. En regardant les chiffres, cependant, quelqu'un pouvait remarquer le changement dans la quantité estimée de travail et mieux comprendre ce qui se passait.