Décomposer des processus complexes
Je développe actuellement un CMS pour une agence de réservation qui organise des festivals de musique de plusieurs jours. Plutôt que de publier des nouvelles ou des articles, la majeure partie du contenu géré ne concerne que ces festivals et spectacles. Cependant, la publication de ces spectacles sur le site nécessite beaucoup de données, et le processus de création d'un nouveau festival est quelque peu impliqué:
- Créer un festival
- Entrer le nom du festival, la date de début, la description
- Téléchargez et joignez des dépliants
- Attachez des événements (par exemple Rock night, Metal night, Hip-Hop, etc.)
- Entrer le nom/la description de l'événement, la date, la programmation, la vedette
- Joignez des dépliants
- Entrer des temps définis (sur plusieurs étages)
- Sélectionnez un lieu (ou créez-en un nouveau)
Le modèle d'implémentation actuel demande simplement à l'utilisateur d'accéder aux Festivals, Events, Flyers, Venues, and - Définir les heures sections du site et remplissez des formulaires individuels pour ajouter/modifier ou supprimer ces données. Mais cela ne semble pas très intuitif. J'essaie donc de convertir ces formes conventionnelles en interfaces AJAX et de les consolider en un seul écran pour rationaliser le processus.
Cependant, c'est beaucoup de données, et je me demande, à quel moment avez-vous besoin de décomposer un processus en plusieurs étapes (par exemple, un assistant)? À combien de champs de saisie essayez-vous de limiter chaque écran?
J'hésite à créer une interface utilisateur de type assistant car je n'aime pas personnellement les utiliser, car la plupart des workflows ne sont pas aussi linéaires (par exemple, les horaires de chaque événement ne sont décidés que la nuit avant le spectacle). J'espère qu'en regroupant les champs de saisie dans des formulaires pliables et en utilisant une boîte de dialogue modale pour télécharger les dépliants, je pourrai limiter le nombre de champs de saisie à l'écran à un moment donné, réduisant l'encombrement. Est-ce une conception raisonnable ou l'utilisateur moyen préfère-t-il une interface de type assistant?
Dans de tels cas, j'utilise onglets de groupe pour organiser les formulaires (afin que l'utilisateur puisse accéder directement à la page dont il a besoin), mais aussi fournir Next: xyz (xyz étant le nom du formulaire suivant) sur chaque page afin qu'un utilisateur qui préfère l'approche de type assistant puisse cliquer sur les pages.
Ce qui rend le processus complexe, ce n'est pas qu'il y ait tellement de données, mais l'hypothèse qu'elles doivent être saisies en une seule fois. La création d'un festival devrait être un processus en trois étapes:
- Créez un festival vierge.
- Modifiez le festival jusqu'à ce qu'il soit terminé.
- Publiez le festival.
L'astuce consiste à faire comprendre à l'utilisateur que le formulaire n'a pas besoin d'être rempli la première fois. Vous pouvez modifier un seul champ et cliquer sur le bouton Enregistrer. Le festival peut rester dans un état de projet incomplet - peut-être même sans date - jusqu'au moment de sa publication.
Je suis curieuse, Lèse majesté, pourquoi tu n'aimes pas les sorciers? Est-ce quelque chose pour lequel vous avez développé un dégoût personnel ou avez-vous quelque chose de plus concret en termes de recherche qui prouve que les assistants créent des problèmes pour les utilisateurs lorsqu'ils accomplissent des tâches particulières? Je travaille actuellement sur une ré-architecture d'une application très complexe et j'ai des considérations et des préoccupations similaires aux vôtres, bien que cela n'ait rien à voir avec les festivals. Je cherchais des assistants non traditionnels et j'ai vraiment aimé l'uploader que Flick'r utilise. Je pense que cela dépend aussi de la quantité d'étapes dans un processus particulier. Ce que j'ai aimé dans l'implémentation Flick'r, c'est sa transparence et sa visualisation verticale, les deux m'ont donné le sentiment que ça allait être facile.