Réaliste estimations de temps pour les barres de progression
je sais que je ne suis pas le seul à ne pas aimer les barres de progression ou les estimations de temps qui donnent des estimations irréalistes dans le logiciel. Les meilleurs exemples sont les installateurs qui passent de 0% à 90% en 10 secondes et prennent ensuite une heure pour compléter le 10% final.
la plupart du temps les programmeurs estiment juste les étapes pour accomplir une tâche et ensuite afficher currentstep/totalsteps en pourcentage, en ignorant le fait que chaque étape peut prendre un autre temps. Pour par exemple, si vous insérez des lignes dans une base de données, le temps d'insertion peut augmenter avec le nombre de lignes insérées (Exemple facile), ou le temps de copier des fichiers ne dépend pas seulement de la taille du fichier, mais aussi de l'emplacement sur le disque et comment il est fragmenté.
Aujourd'hui, je me suis demandé si quelqu'un avait déjà essayé de modéliser ceci et peut-être créé un bibliothèque avec un estimateur robuste configurable. Je sais qu'il est difficile de donner des estimations robustes parce que des facteurs externes (connexion au réseau, l'utilisateur exécute d'autres programmes, etc) jouent leur rôle.
peut-être qu'il y a aussi une solution qui utilise le profilage pour mettre en place un meilleur estimateur, ou on pourrait utiliser des approches d'apprentissage automatique.
quelqu'un sait de solutions avancées pour ce problème?
à ce propos, j'ai trouvé l'article Repenser la barre de progression très intéressant. Il montre comment les barres de progrès peuvent changer la perception du temps et comment vous pouvez utiliser ces idées pour créer des barres de progression qui semblent être plus rapide.
EDIT: Je peux penser à des façons de régler manuellement l'estimation de temps, et même avec une "bibliothèque d'estimateur" je vais devoir affiner l'algorithme. Mais je pense que ce problème pourrait être traité avec des outils statistiques. Bien sûr, l'estimateur recueillerait des données au cours du processus afin de créer de meilleures estimations pour les prochaines étapes.
Ce que je fais maintenant est de prendre la moyenne chronométrer quelque chose a pris dans l'étape précédente (étapes regroupées par type et normalisées par exemple la taille du fichier, la taille de la transaction) et prendre cette moyenne comme estimation pour les prochaines étapes (encore une fois: compter dans différents types et tailles).
Maintenant, je sais il y a de meilleurs outils statistiques pour créer des estimateurs et je me demande si quelqu'un s'est appliqué au problème.
7 réponses
Alors que le premier cycle, Julian Missig et j'ai fait une expérience semblable à celle de Harrison et al. papier. Comme on pouvait s'y attendre dans le cas d'un projet de classe, nous n'avons pas vraiment obtenu suffisamment de données pour formuler des affirmations convaincantes, sauf que pour un intervalle de 5 secondes, aucune barre de progression n'a été perçue comme étant plus court.
donc, si la tâche est susceptible de prendre moins de disons 10 secondes, il est préférable de ne pas montrer une barre de progression du tout. Cela ne veut pas dire que vous ne devriez pas show feedback, mais une barre de progression est susceptible de le faire sembler plus lent.
si vous êtes intéressé, Julian a le papier et affiche sur son site.
dieu Merci je ne suis pas le seul!
Je ne connais pas de bibliothèque qui gère l'estimation, mais je peux personnellement me porter garant de vos idées de profilage. Une fois, j'ai mis en place une barre de progression qui a été utilisée pour rendre compte de la progression d'une opération de fichier longue et compliquée (plusieurs petits fichiers ont été lus, traités, puis combinés dans un fichier plus grand). J'ai demandé au logiciel de garder une trace du temps qu'il a fallu pour lire, écrire et traiter, puis j'ai ajusté la barre de progression en conséquence. Après que le programme ait été exécuté quelques fois, la barre de progression se déplace aussi lisse que de la soie. Pas de pause et pas rapide de soubresauts.
cela fonctionne aussi longtemps que le temps pris pour vos opérations sont facilement mesurés. Je serais prudent d'utiliser cette méthode sur quelque chose comme un indicateur de progrès de téléchargement, puisque la vitesse du réseau est complètement indéterminée.
Je ne pense pas que le problème est qu'ils estiment le nombre d'étapes autant que c'est souvent la mauvaise définition de "étape" est utilisé. Dans votre exemple de l'installateur allant de 0 à 9% en 10 secondes puis une heure pour le reste, j'ai vu que se produire lorsque le programmeur a décidé de compter le nombre de fichiers à copier, pas le nombre d'octets.
disons qu'il y avait 10 fichiers, 9 d'entre eux étaient 5K chacun (readme, license, icon, etc.) et le dernier était un ISO 2Gig, bien, le premier 9 copiez vraiment rapide et le dernier serait lent! Compter des fichiers était la mauvaise chose à compter, aurait dû compter des octets. Le problème est que, si vous voulez compter les octets, vous devez mettre en œuvre votre propre routine de copie afin de pouvoir fournir des mises à jour d'état pendant la copie du gros fichier. Est-ce que cela vaut vraiment la peine d'implémenter votre propre routine de copie?
L'autre problème est que l'installation (comme beaucoup d'autres choses) est constituée d'empilements de routines qui peuvent être très profonds. Ces routines peuvent faire beaucoup de choses, mais elles sont probablement des routines génériques, et n'ont rien en elles qui soit capable de mettre à jour certains indicateurs de progrès à un niveau beaucoup plus élevé. Vous auriez besoin de réimplanter un certain nombre de routines communes pour obtenir de bonnes informations de progrès.
quant à un estimateur robuste, je pense que ce serait très difficile. Les étapes particulières peuvent être définies dans un fichier de configuration, mais vous devez avoir des mises à jour de chaque étape du processus d'installation. En outre, le temps de faire ces choses cela varie évidemment d'une machine à l'autre, donc vous seriez probablement loin de toute façon. Bien sûr, une fois que vous avez fait l'installation sur une machine spécifique, vous pouvez estimer l'installation sur cette machine la prochaine fois. ; -)
Le problème avec l'aide d'une barre de progression est souvent un processus à plusieurs étapes. Donc, si je faisais un dialogue de progression pour une mise à jour logicielle, Je n'utiliserais pas une seule barre de progression, mais une liste de tâches avec des marques de contrôle pour que l'utilisateur puisse voir quelle tâche est exécutée en ce moment.
mettez une barre de progression à côté de la tâche si elle prend plus de 10 secondes pour qu'ils puissent voir que le travail est fait et qu'ils ne l'abandonnent pas trop tôt.
Télécharger Mise à jour
Arrêtez d'exécuter des processus
Mise à jour du logiciel
Configurer le logiciel
Redémarrez le programme
les tâches individuelles sont agréables parce que le rendement passé indique fortement le rendement futur. Les 10 premières secondes du téléchargement vont probablement vous montrer combien de temps le reste du fichier prend. Idem pour la mise à jour elle-même.
les processus plus courts n'ont pas besoin d'une barre de progression, alors n'en affichez même pas une sur n'importe quel processus jusqu'à celui-là le processus a duré 10 secondes ou plus. De cette façon l'utilisateur sur un système rapide voit juste une coche sur chaque tâche, et sur un système lent, l'utilisateur voit les coches, et si elle reste sur une tâche trop longtemps, ils obtiennent la barre de progression avec effectivement des informations utiles.
et la barre de progression ne fait aucune promesse quant à la durée des tâches ultérieures.
avoir une "estimation du temps restant" en bas qui couvre la meilleure estimation pour toutes les tâches est très utile, mais je ne pas montrer qu'une barre de progression.
la chose à propos des barres de progression est qu'elles sont destinées à voyager linéairement. Quand ils sautent et bégayent c'est très frustrant pour l'utilisateur - ils sont en fait moins utiles et donnent la mauvaise information dans ce cas.
Choisir le bon outil pour le travail. Trop souvent, une barre de progression est choisie alors que c'est le mauvais outil.
- Adam
comme vous le dites, vous pouvez avoir 100 pas, mais chacun de ces pas prendra une quantité différente de temps selon ce qu'ils font.
une approche serait de grouper les tâches par ce qu'elles font (suppression, modification des valeurs du registre, téléchargement, copie de fichiers, etc.) et pour chaque groupe, assigner quelques propriétés clés:
- quels paramètres contrôlables s'appliquent (vitesse de copie, vitesse de déballage, etc.)?
- Quel est le taux moyen de la pire éventualité pour cela processus?
Ensuite, vous devez créer une liste de ce que vous allez faire pour l'ensemble de la tâche, par exemple:
- Déballage d'un 100meg fichier (groupe: déballage, valeur:100)
- Copier 120megs (groupe: la copie, la valeur:120)
- définir les valeurs du registre (groupe: registre, valeur: 25)
- Nettoyer (groupe: la suppression, de la valeur:100)
donc à partir de cela, vous pouvez établir une "estimation" globale basée sur votre moyenne prédéfinie du pire des cas valeurs mais la clé de l'exactitude est la mise à jour de chaque multiplicateur métrique que vous apprenez à quelle vitesse système peut effectuer chaque tâche.
Il a fallu à Microsoft une décennie pour obtenir la droite afin de ne pas être trop en difficulté si elle ne fonctionne pas au premier =)
une autre façon (et beaucoup plus simple) est de simplement garnir l'estimation et la perception de l'utilisateur.
la plupart des barres de progression sont là plus pour la réactivité de L'UI que pour la prédiction de la durée: l'Utilisateur a besoin d'avoir une rétroaction confirmant que le programme n'est pas bloqué - mais ne se soucie pas tant que ça du temps d'achèvement.
si j'attends une tâche, et qu'elle se termine à 50% en 10 secondes - je suis frustré quand il me faut encore 20 secondes pour terminer la dernière 50%.
pour la même tâche, si elle va à 50% en 30 secondes, continue jusqu'à 60% - et puis saute magiquement à 100% - je suis surpris, mais pas ennuyé.
si la tâche est vraiment courte ou complètement imprévisible, une boucle animée fonctionne aussi bien (icône de chargement du navigateur, animation iPhone wait, etc...).
si vous êtes dans les cas de couple où vous avez vraiment besoin de précision - alors il est probablement intéressant de passer un peu de temps dans le code pour une meilleure fiabilité de la bar.
j'utilise DREJ pour les non-linéaire la régression des moindres carrés sur l'évolution de l'histoire. Il fonctionne assez bien.
j'utilise une table de base de données pour stocker mes données historiques. Je reconstruis ma fonction d'estimateur basé sur les 100 dernières entrées dans le tableau.
j'ai des annotations sur les méthodes à long terme pour identifier la variable qui détermine le taux.
YMMV, mais la prochaine fois l'estimation prend cela en compte.