Pourquoi la plupart des programmes séparent-ils les boîtes de dialogue Rechercher et remplacer?
Pourquoi la plupart des programmes séparent-ils les boîtes de dialogue Rechercher et remplacer? Évidemment, je parle d'applications telles que les éditeurs de texte et les traitements de texte, des applications utilisées pour éditer du contenu.
Il semble tout simplement étrange, au mieux, de séparer complètement les fonctions qui sont fondamentalement les deux faces de la même pièce, et peut devenir carrément frustrant lorsqu'elles sont implémentées en tant que fenêtres distinctes au lieu d'onglets dans la même fenêtre et que vous décidez de remplacer certaines des déjà trouvé des correspondances.
Du point de vue de la conception de l'interface, je ne vois pas comment l'inclusion d'une autre zone de texte et de deux boutons supplémentaires requis pour Remplacer (toutes les autres options sont généralement les mêmes pour Rechercher et Remplacer) provoque un tel encombrement dans l'interface et une surcharge cognitive qui il nécessite une version de base de Find pour les "non-utilisateurs".
Le seul programme auquel je peux penser qui combine ces deux est TextEdit. (Ironiquement, il y a ne question sur Apple StackExchange sur l'endroit où se cache la fonction Replace dans TextEdit, mais c'est parce qu'elle est nommée simplement "Find" au lieu de quelque chose de sensé comme " Rechercher ou remplacer ".)
Une question intéressante, et je pense que beaucoup d'entre nous auraient pu réfléchir avant sans vraiment plonger trop profondément dans les problèmes possibles. Du point de vue purement design, je peux penser à un certain nombre de raisons plausibles:
- Convention: la première personne l'a fait de cette façon, puis tout le monde a suivi parce que "c'est comme ça que c'est fait".
- La sécurité d'abord: il est important de séparer une action destructrice (remplacer) d'une action non destructive (rechercher) afin que les gens n'effacent pas accidentellement des informations sans obtenir d'abord une confirmation. Je suppose que "Annuler" n'était pas toujours disponible ou qu'il y a d'autres détails de mise en œuvre que je ne connais pas.
- Facilité de conception/mise en œuvre: il est peut-être facile de créer les fonctions de recherche et de remplacement séparément en tant que modules différents (car tous les programmes n'ont pas besoin des deux), et il sera alors facile de faire la conception de l'interface utilisateur lorsque vous ajoutez ou supprimez l'une ou l'autre fonctionnalité.
En fin de compte, si c'est un problème pour l'utilisateur final, on s'attendrait à ce que ces logiciels l'aient changé, alors peut-être que les gens y sont habitués (de la même manière que nous utilisons toujours QWERTY plutôt que les dispositions de clavier DVORAK ou Colemak).
Find et Find and Replace sont liés fonctionnellement comme vous le mentionnez. Mais les deux actions semblent être orthogonales en termes de besoins des utilisateurs (état d'esprit) auxquels elles répondent. Vous saurez à l'avance soit vous voulez trouver quelque chose ou vous voulez plutôt substituer occurrences de quelque chose. Dans ce dernier cas, il se trouve que vous devez trouver des occurrences de la chose que vous souhaitez remplacer, mais c'est une préoccupation secondaire ou même pas importante dans certains cas.
Par conséquent, la présentation d'une seule option appelée Rechercher et remplacer confondra les utilisateurs qui veulent simplement trouver quelque chose. Ils n'interpréteront pas cette action comme celle qui leur permet d'accomplir ce dont ils ont besoin. De même, avoir Find qui offre un remplacement ne semblera pas être l'action appropriée s'ils doivent remplacer quelque chose dans le document.
Si vous pouvez vous attendre à ce que vos utilisateurs soient des utilisateurs de l'éditeur de texte , par exemple des programmeurs , il est alors logique de combiner ces boîtes de dialogue en une seule, ou, mieux encore, d'en faire une barre d'outils et d'afficher les résultats en temps réel pendant que vous tapez. C'est une fonctionnalité attendue pour les outils de développement de nos jours, car elle accélère considérablement le processus d'édition. Les IDE (environnements de développement intégrés) font généralement un très bon travail dans ce domaine, par exemple tous produits JetBrains ou Qt Creator by The Qt Company.
Un exemple de JetBrains:
Je vois cela comme un nouveau comportement. Sans une ancienne installation de MSOffice à tester, je ne peux pas être absolument sûr, mais dans le passé, les boîtes de dialogue de recherche/remplacement étaient souvent modales et couvraient beaucoup de texte. Pour les outils de recherche niquement, cela n'est pas nécessaire - ils ont généralement 2 à 4 contrôles dont un seul est une zone de texte (large). Remplacer nécessite au moins une autre zone de texte et un autre bouton, généralement plus ("remplacer tout", etc.). Les boutons peuvent également avoir besoin d'étiquettes plus claires à remplacer, car les conséquences des erreurs sont plus importantes - encore plus grandes. Ainsi, un outil de recherche peut tenir dans une barre d'état ou une barre d'outils d'une largeur que vous pouvez saisir en un coup d'œil. Remplacer est tout simplement trop gros pour cela. Cela indique également pourquoi les nouvelles versions de Word mettent "recherche avancée" avec remplacer malgré l'utilisation d'une barre latérale qui est assez grande (l'espace semble être utilisé pour afficher les emplacements des éléments trouvés).
Il existe une tendance vers des outils de recherche non intrusifs, par exemple dans la barre d'état. Exemples: Libreoffice; Firefox; Adobe Reader (les deux derniers sont spécifiquement inclus comme exemple de la nouvelle méthode, où "remplacer" n'est pas utilisé)
MS Word (et peut-être le reste d'Office, mais pas Outlook lors de la rédaction d'un e-mail) utilise une boîte de navigation "barre latérale" assez différente. Cela fournit différentes capacités à l'outil de recherche/remplacement hérité (onglets dans la même boîte de dialogue, le bit de recherche maintenant appelé "recherche avancée"). L'outil de recherche/remplacement semble plutôt démodé maintenant, mais ne peut probablement pas changer grand-chose sans interrompre le flux de travail des utilisateurs expérimentés (les dactylographes tactiles qui aiment les raccourcis clavier et se souviennent combien de fois appuyer sur l'onglet).
La recherche est judicieuse avec un document non modifiable. Remplacer ne l'est pas. Historiquement, "remplacer" était-il grisé ou non affiché en mode lecture seule? Peut-être de retour alors qu'il n'y avait que de l'espace pour une copie du document sur la disquette 720k?
De nos jours, il est normal que le texte du document soit toujours modifiable et que ce soit le fichier qui ne l'est pas. C'est donc "Enregistrer" qui est grisé, pour indiquer que " Enregistrer sous "est requis. (Vous recevez également souvent un avertissement lorsque vous ouvrez le fichier en lecture seule).
Un remplacement global erroné de quelque chose avec (disons) la chaîne nulle, est un peu catastrophique, surtout si "annuler" n'est pas capable d'annuler un remplacement global en un seul clic. Alors peut-être qu'il est toujours logique d'avoir une entrée de menu complètement différente pour l'option qui est intrinsèquement beaucoup plus "dangereuse".
Il y a beaucoup de histoire aux éditeurs de texte . par exemple. vi qui est l'un des plus anciens, car il existe un partage défini entre l'affichage d'un document (recherche) et l'édition d'un document (remplacement).
En termes techniques, ce sont des choses très différentes, comme GET vs POST pour le Web, et les éditeurs de texte sont généralement des outils assez techniques.
Les traitements de texte le sont moins, mais je suppose qu'ils se sont inspirés des éditeurs de texte.
Je soupçonne également, mais je ne trouve pas les données, les opérations de recherche sont effectuées beaucoup plus souvent que les opérations de remplacement.