Quelle est la disposition optimale pour un formulaire de recherche mobile avec un grand nombre de champs?
Je travaille sur la mise en page d'un formulaire de recherche contenant environ 8 à 10 champs. À ce stade, le formulaire de recherche remplit presque toute la fenêtre d'affichage. Ma recherche a mis au point des stratégies générales pour les grands formulaires mobiles, mais celles-ci semblent être orientées vers divers formulaires d'inscription, formulaires de contact, etc.
Le problème est que la fonction du formulaire en tant qu'outil de recherche nécessite que les résultats renvoyés incluent tous les champs de saisie d'origine. Par conséquent, la première correspondance renvoyée n'apparaîtra probablement pas tant que l'utilisateur n'aura pas fait défiler la page. Cela semble loin d'être une expérience optimale.
En supposant qu'aucun autre champ ne puisse être supprimé du formulaire, quelle est la meilleure stratégie pour que les utilisateurs parcourent les résultats de la recherche tout en conservant la possibilité de réviser leurs termes de recherche, ainsi que d'effectuer une nouvelle recherche sans naviguer ailleurs?
Voici une capture d'écran d'un formulaire qui ressemblerait assez au type de formulaire dont je parle:
ÉDITER:
En ce qui concerne: http://www.uxbooth.com/blog/mobile-form-design-strategies/ , je suis sûr que les étiquettes alignées à droite suggéraient que je n'avais pas examiné cet article. La décision de s'écarter des étiquettes alignées verticalement a été prise dans le but de remédier au problème d'origine - en réduisant la taille verticale du formulaire.
Parce que toutes les étiquettes sont relativement courtes, le risque d'être coupé est réduit. En outre, les tailles de police, les grilles de conteneur et les tailles de champ ont toutes été modifiées pour réduire le risque de formatage incorrect sur des écrans plus petits. Le problème de la perte de vue de l'étiquette sur le focus a également été résolu en empêchant le zoom automatique.
Je ne pense pas que la combinaison de champs de localisation fonctionnera aussi bien dans ce contexte. Contrairement à l'exemple de l'article, les champs d'emplacement ne sont pas simplement des chemins alternatifs vers le même jeu de résultats. Ex: si le magasin A se trouve dans le district 1, une recherche pour le magasin A uniquement donne des résultats pour ce magasin, mais une recherche pour le district 1 inclut le magasin A et tous les autres du même district.
Il est possible de mettre à jour la gestion côté serveur pour analyser un seul champ et interpréter si l'utilisateur a tapé "District X" ou "Store X", etc. être une expérience moins optimale que d'avoir plusieurs domaines. De plus, la nature non intuitive d'un champ pour 4 options nécessiterait des instructions supplémentaires, annulant ainsi une partie des biens immobiliers enregistrés. Enfin, les mots mal tapés, et donc les résultats erronés, semblent être une source très probable de frustration des utilisateurs.
En ce qui concerne la suppression des champs de localisation et l'utilisation du GPS, cette approche ne fonctionnera tout simplement pas car les utilisateurs peuvent être à des centaines de kilomètres des emplacements qu'ils recherchent.
En ce qui concerne la suppression des champs inutiles, vous devrez me prendre au mot que tous les éléments non requis ont été supprimés.
Je suggère que lors de la recherche, le panneau de recherche soit réduit en un panneau en haut du résultat de la recherche, comme illustré ci-dessous.
Le raisonnement derrière cela est que ce ne serait pas une bonne idée de garder le formulaire de recherche présent et d'afficher le résultat en dessous car, comme vous l'avez également mentionné, cela entravera le résultat. Les solutions possibles à ce que je vois sont soit en créant un lien vers une nouvelle page avec le résultat, soit en repliant le formulaire de recherche, comme ma suggestion le propose.
Étant donné que le panneau de recherche est toujours accessible dans cette suggestion, les utilisateurs peuvent revoir les paramètres de filtre qu'ils ont configurés dans la même vue que le résultat sans quitter la vue.
Pour commencer, je ne sais pas si vous avez lu cet article sur le stand UX sur la conception de formulaires pour mobiles qui donne d'excellentes informations sur la traduction de grands formulaires en leur équivalent mobile. Il est brièvement résumé ci-dessous:
- Alignement des étiquettes : évitez d'utiliser des étiquettes horizontales (alignées à gauche et à droite) pour les formulaires mobiles. Utilisez plutôt des étiquettes d'alignement vertical.
- Supprimer : éliminez les éléments et fonctionnalités inutiles pour aider les utilisateurs à se concentrer sur leurs tâches. Si possible, omettez les champs facultatifs ou
éléments qui n'ont pas d'utilisations principales.- Combiner : combiner divers champs de saisie similaires en un seul champ. Assurez-vous que ce que les utilisateurs peuvent faire et ce qu'ils peuvent saisir sur le terrain est clair.
- Improviser : faites bon usage des fonctionnalités intégrées des appareils mobiles telles que la détection de position via les satellites GPS pour simplifier la saisie de votre formulaire mobile.
- Divisez-vous en petites étapes : divisez un formulaire long en quelques étapes plus petites pour faciliter l'utilisation de vos formulaires mobiles. Utilisez cette approche avec parcimonie. Essayez également de réduire les éléments inutiles sur chaque page pour éviter les téléchargements de pages lents.
- Utilisez les éléments d'entrée et les commandes de menu appropriés : remplacez un type de contrôle par un autre, ce qui pourrait simplifier le formulaire et son interaction. Donnez la priorité au contenu et aux champs obligatoires et évitez de mettre l'accent sur les champs facultatifs ou ceux qui ne sont utiles qu'à un très petit groupe d'utilisateurs.
- Choisissez les sélections de liste appropriées : Il existe deux façons principales de présenter une sélection de liste: liste déroulante verrouillée (dans l'ordre alphabétique ou non alphabétique) et ouvrez la recherche prédictive. Les deux ont des avantages et des inconvénients. Choisissez la sélection de liste appropriée en fonction de votre champ et de vos sélections.
- Définissez des valeurs par défaut raisonnables : fournissez des sélections par défaut, le cas échéant, en fonction du contexte dans lequel vos formulaires sont utilisés.
Cela dit, existe-t-il un moyen pour vous de combiner plusieurs champs en un seul.
Par exemple. La zone, la région et le district peuvent peut-être être combinés en un seul champ, car ils sont tous explorés en détail. Comme indiqué dans le résumé ci-dessus, vous pouvez peut-être utiliser la fonction GPS du téléphone [~ # ~] [~ # ~] pour déterminer la région et d'autres champs
Si cela n'est pas possible, une approche pour vous serait d'avoir votre récupération de données en deux étapes. La première étape montre votre formulaire mobile comme indiqué ci-dessous:
Et les utilisateurs lors du remplissage sont présentés avec une vue de grille qui affiche les résultats comme indiqué ci-dessous
La chose à noter ici est que tous les champs auront leurs valeurs initiales affichées et ils sont modifiables 
Maintenant, je sais que cette approche n'est pas optimale et je doute fortement de la possibilité d'afficher un champ tabulaire à 8 colonnes, mais c'est une option que vous pouvez examiner.
Je serais très heureux de discuter de cette approche consistant à autoriser le texte de forme libre (dans les paramètres) à mettre à jour directement le contenu des résultats.