Curseurs occupés - pourquoi?

Question

Quelqu'un peut-il me donner un scénario où ils pensent que les curseurs occupés sont justifiés? J'ai l'impression qu'ils sont toujours une mauvaise idée du point de vue d'un utilisateur . Précision: par curseurs occupés, je veux dire lorsque l’utilisateur ne peut plus interagir avec l’application, il ne peut que déplacer son pointeur de souris en sablier et siffler une mélodie.

Answer 1

Je pense que vous avez peut-être raison: dans une application asynchrone décente, vous n'avez jamais besoin d'afficher un curseur occupé. L'utilisateur peut toujours faire quelque chose même si la dernière opération la plus importante est terminée.

Cela dit, parfois les applications Java telles que Netbeans ou Eclipse, voire Visual Studio, se bloquent sans curseur occupé ni espoir. Mais dans ce cas, un curseur occupé n’aiderait probablement pas beaucoup non plus ... mais je pense que vous avez raison: les curseurs occupés appartiennent à une époque où les applications ne fonctionnaient pas en multithreading. Par exemple, dans les applications Flex, EVERYTHING est automatiquement rappelé par des événements. Par conséquent, la définition d’un curseur occupé n’aurait aucune signification (bien que ce soit possible, bien sûr).

Answer 2

En résumé, je pense que l'utilisateur ne devrait être autorisé à faire des choses dans votre application que lorsque l'intervalle d'attente est très court (2 secondes ou moins) et que la surcharge cognitive liée à la mise en multi-thread est susceptible de se traduire par app stable. Pour plus de détails, voir ci-dessous.

Pour une opération inférieure à 0,1 seconde , vous n'avez généralement pas besoin de passer en mode asynchrone ni même d'afficher un sablier.

Pour une opération comprise entre 0,1 et 2 secondes , vous n'avez généralement pas besoin de passer en mode asynchrone. Placez simplement le curseur sur le sablier, puis effectuez le travail en ligne. Le repère visuel suffit à satisfaire l'utilisateur final.

Si l'utilisateur final initie une opération qui ne prendra que quelques secondes, il est en mode "concentré". mode de pensée dans lequel il attend inconsciemment les résultats de son action, et il n’a pas détourné son cerveau conscient de cet objectif particulier. Donc, bloquer l'interface utilisateur - avec un indicateur visuel que cela s'est produit - est parfaitement acceptable pour une période aussi courte.

Pour une opération d'une durée supérieure à 2 secondes , vous devez généralement passer en mode asynchrone. Mais même dans ce cas, vous devriez fournir une sorte d'indicateur de progrès. Les gens ont du mal à se concentrer en l’absence de stimulation et 2 secondes sont suffisamment longues pour que l’utilisateur final se mette naturellement de passer de la conscience à une conscience concentrée. activité à prendre conscience & # 8216; attendre & # 8217; activité.

L’indicateur de progression leur donne l’intérêt de les occuper pendant qu’ils se trouvent dans ce mode d’attente et leur donne également le moyen de déterminer à quel moment ils reviendront à leur position "ciblée". le contexte. Les signaux visuels donnent au cerveau un élément autour duquel structurer ces changements de contexte, sans exiger une pensée trop consciente.

Les opérations en cours sont généralement terminées dans X, mais prennent parfois Y , où Y est beaucoup plus grand que X. Cela peut se produire pour des actions distantes telles que un réseau. C'est à ce moment-là que vous pourriez avoir besoin d'une combinaison des actions ci-dessus. Par exemple, envisagez d’afficher un sablier pendant les 2 premières secondes et d’apporter ensuite votre indicateur de progression. Cela évite d'extraire l'utilisateur final du contexte "ciblé" directement au contexte "attente" sans étape intermédiaire.

Answer 3

Ce n'est pas spécifiquement le curseur occupé qui est important, mais il est absolument important, toujours de faire savoir à l'utilisateur que quelque chose se passe en réponse à ses commentaires. Il est important de réaliser que sans un curseur occupé, une barre de progression, une pulsation, un bouton clignotant, un bâton tourbillonnant, un clown dansant… peu importe, si vous n'en avez pas et que l'ordinateur reste assis à ne rien faire, l'ordinateur semble cassé pour l'utilisateur.

Un retour immédiat pour chaque action de l'utilisateur est extrêmement important.

Answer 4

Vous affichez un curseur occupé lorsque l'utilisateur ne peut rien faire jusqu'à ce que l'opération soit terminée - y compris quitter l'application.

Je trouve intéressant de ne pas voir les curseurs occupés dans les navigateurs Web. C'est peut-être pour cela que les gens les aiment tant.

Non, attendez, j'ai une meilleure réponse. Vous affichez un curseur occupé lorsque l'ordinateur réfléchit .

Answer 5

Lorsque l'on clique sur le bouton Actualiser d'un navigateur Web, le curseur occupé doit apparaître immédiatement pour que l'utilisateur sache qu'une page est en cours de chargement.

Je pense que c'est Don't Make Me Think qui dit que le temps de chargement tolérable pour un humain est zéro seconde.

Google dit:

  

Responsive

     

Il est possible d'écrire du code gagnant   chaque test de performance dans le monde,   mais cela envoie encore des utilisateurs dans un feu   faire rage quand ils essaient de l'utiliser. Celles-ci   sont les applications qui ne sont pas   assez réactif - ceux qui se sentent   paresseux, suspendre ou geler pendant   périodes importantes ou trop longues   traiter les entrées.

Answer 6

Son objectif est double:

1. Indiquez à l'utilisateur qu'il se passe quelque chose.
2. Indiquez à l'utilisateur que rien ne peut être fait pour le moment.

Le curseur occupé indique mieux le fonctionnement que rien. Pour des opérations de plus longue durée, mieux vaut utiliser quelque chose Par exemple, les navigateurs sont toujours opérationnels lorsqu'une page est en cours de récupération et qu'il existe même un bouton pour arrêter l'opération. L'interface utilisateur étant entièrement fonctionnelle, il n'est pas nécessaire d'utiliser un curseur occupé. Cependant, le curseur occupé peut être utilisé même dans ce type de situation dans les phases de transition, comme lors du démarrage ou de l'arrêt de l'opération.

Answer 7

J'essaie de les utiliser pour toute action pouvant durer de 0,5 à 3 secondes. Pour des actions plus longues, je pense que des indicateurs de progrès avec suffisamment d'informations devraient être utilisés.

Answer 8

Au moins avec Fedora 8, j’ai remarqué que lorsqu’une application définit le paramètre "occupé". curseur, le " interactif occupé " l'un est réellement affiché. J'imagine que c'est parce que le système réagit toujours à la saisie de la souris (par exemple en faisant glisser la fenêtre, etc.). En passant, sélectionnez l’option "interactive interactive". le curseur explicitement sur linux est délicat: http://www.pixelbeat.org/programming/x_cursors/

Answer 9

La seule chose que je crois que le curseur occupé fait, c'est informer l'utilisateur que ...

  

Je ne vous ignore pas carrément, je fais juste autre chose qui peut prendre un peu de temps

Answer 10

S'il est absolument nécessaire d'avertir l'utilisateur que votre application est en train de faire quelque chose, un curseur occupé n'est utile que pendant les premières secondes de traitement. Pour un délai de plus de 15 à 20 secondes environ, il faut présenter autre chose, par exemple une barre de progression, un message d'état, une boîte de message, etc. Les gens partent du principe que votre logiciel est verrouillé après une minute environ et tenteront de le terminer. Parfois, les indices visuels généraux sont aussi importants qu'un curseur occupé.

Par exemple, les applications avec des onglets qui ne répondent pas avec une mise en surbrillance appropriée jusqu'à la fin de l'opération dans l'onglet peuvent être corrigées en mettant à jour cet onglet temporairement jusqu'à ce que toutes les opérations soient terminées. Parfois, juste un peu d'optimisation ou de refactoring permettra de nettoyer la réactivité horrible de l'interface utilisateur telle que celle-ci.

Answer 11

Je ne les utiliserais que pour terminer rapidement, par exemple moins d’une demi-seconde. Si quelque chose prend plus longtemps que cela, une boîte de dialogue de progression devrait apparaître ou une barre de progression devrait apparaître dans la barre d'état ou ailleurs dans l'interface.

L'utilisateur doit toujours pouvoir annuler l'action si son exécution prend trop de temps.

En réponse au commentaire, le curseur occupé ne serait visible que pendant une demi-seconde environ, puisqu’une fois le dialogue de progression affiché, il devrait devenir l’un de ceux-ci "moitié occupé". curseurs, ou juste le curseur en forme de flèche normale.

Vous devez éviter de placer un curseur occupé vers le haut sauf dans des circonstances extrêmes. Si vous pensez en avoir besoin, réfléchissez-y de nouveau et refaites la conception.

Answer 12

Par exemple, pour indiquer que vous avez cliqué sur un bouton, même si le traitement de l'événement n'est pas terminé. S'il n'y a pas d'indication, l'utilisateur peut essayer de cliquer à nouveau sur le bouton, provoquant ainsi toutes sortes de problèmes.