L’idée d’un « processus itératif » n’est pas nouvelle dans le développement de logiciels. Elle est présente dans un certain nombre de méthodologies différentes et probablement parce qu’elle fonctionne bien, en particulier lorsqu’il s’agit d’obtenir des commentaires des clients.
L’un des endroits où je le trouve également utile est lors de la création d’interfaces d’administration pour les plugins WordPress.
Pour être clair, je ne suis pas designer, donc quand il s’agit de travail front-end, je me réfère toujours à la charte graphique et aux maquettes que le designer me fournit dès le début du projet. (Je ne mentionne cela que parce que je pense que c’est une pratique que toute personne qui n’est pas designer devrait suivre, mais je m’égare).
Mais quand il s’agit de travailler sur des écrans d’administration ou des écrans back-end pour WordPress, j’ai tendance à suivre une règle stricte : assurez-vous que cela semble aussi naturel que possible.
Comment, alors, le développement itératif et l’interface des écrans d’administration de WordPress ont-ils quelque chose à voir ?
Conception d’écran d’administration WordPress
Cet article particulier renonce à parler des choses qui sont attendues pour enregistrer des informations. C’est-à-dire que j’assume tout :
- assainissement,
- validation,
- chèques nonce,
- vérification des autorisations,
Et les autres sont compris et manipulés.
Pour ce post, je vais faire simple. Disons que nous voulons avoir :
- quelques champs de texte,
- un bouton de sauvegarde,
- un bouton de réinitialisation,
- et peut-être quelque chose de plus à la fin.
Comment cela pourrait-il se traduire par un processus itératif lors de sa conception ?
1 Esquisse
Supposons que vous travaillez sur quelque chose et que vous planifiez à quoi ressemblera l’écran d’administration. Compte tenu de ce que nous avions ci-dessus, peut-être qu’un croquis initial pourrait ressembler à ceci :
Assez facile, non? Il représente ce que le projet doit maintenir et affiche tout ce dont nous avons besoin pour cet écran d’administration particulier.
2 Construire
Une fois assemblé, il devrait avoir l’air aussi natif que possible. Compte tenu des styles disponibles dans WordPress, il est relativement facile de le créer avec les API et le balisage disponibles :
Et que font chaque champ et bouton ?
3 Affiner
C’est là que le raffinement des fonctionnalités entre en jeu. Par exemple:
- Je ne pense pas que le bouton Enregistrer doive être activé tant que les champs obligatoires ne sont pas renseignés,
- Je pense que le bouton Réinitialiser devrait effacer ce qui est présent,
- Il devrait y avoir un certain nombre de messages d’erreur qui représentent tous ce que nous devons faire lorsque quelque chose échoue, lorsque quelque chose ne va pas ou que quelque chose ne va pas du tout.
De toute évidence, il est beaucoup plus facile d’en parler lorsqu’il ne s’agit pas d’un projet spécifique, mais peut-être que certaines des idées sont applicables à tout ce que vous avez en cours.
Améliorations asynchrones ?
L’une des choses auxquelles nous nous sommes habitués avec des appareils comme nos téléphones et certaines parties de nos systèmes d’exploitation est que lorsque nous basculons un interrupteur ou apportons un petit changement, les données sont enregistrées.
Autrement dit, aucune action de confirmation (autre que quelque chose de destructif comme la suppression d’un fichier, bien sûr) n’est requise. Les données sont simplement enregistrées et l’option fonctionne.
Pourtant, nous voyons encore beaucoup de boutons Enregistrer dans WordPress, n’est-ce pas? Qu’en est-il de la sauvegarde des entrées via Ajax ou une autre méthode asynchrone ? C’est quelque chose que je n’ai pas encore mis en œuvre, mais j’y ai certainement pensé.