Dans le développement informatique, quand on parle de gestion de données, et d’édition de ces données au sens large, on arrive souvent à créer le CRUD d’un modèle de données. Le CRUD consiste à développer les outils permettant de :
- Create (Créer, ajouter)
- Read (Lire, accéder)
- Update (Editer, modifier)
- Delete (Supprimer, archiver)
Alors que la partie Read va souvent se trouver en Front Office, la partie visible d’un site web, le Create, l’Update et le Delete vont se trouver en Back Office.
Nous allons ici passer en revue le Create et l’Update et voir comment il peut être intéressant de travailler sur un Create le plus simple possible et de laisser la complexité dans le Edit.
Create simple, une question d’onboarding
Définition de Wikipédia : « User onboarding is the process of improving a person’s success with a product or service.«
L’objectif est donc de faciliter la prise en main d’un produit digital, notamment lors de la première utilisation, en faisant passer son utilisateur par de petites étapes successives, plutôt que par une très longue et fastidieuse étape unique.
C’est ce principe que nous allons utiliser ici.
Imaginons donc que je développe un blog de A à Z. Il va arriver un moment où je vais devoir coder la gestion de mes Articles. Un Article peut être composé des éléments suivants :
- Nom
- Description courte
- Contenu complet
- Auteur
- Date de création
- Thème(s) associé(s)
- Visibilité de l’article
Souvent, le formulaire de création de mon article va ressembler à ça :
Et le formulaire d’édition ressemblera alors à ça :
Il y a quelques ressemblances, non ?
Alors que dans mon code, j’ai bien une logique qui me permet de créer le nouvel Article et une logique qui me permet de mettre à jour un Article existant. Ces 2 logiques seront bien séparées.
Dans le même esprit, nous proposons donc de différencier ces 2 formulaires. Et pour cela, réaliser un formulaire de création le plus simple possible. Ici dans le cas d’un blog, on aurait alors :
En effet, le titre est le seul champ dont j’ai besoin pour réellement créé mon Article. Les autres sont importants aussi, mais pas au moment de la création de mon Article. Surtout que je peux avoir l’idée de mon Article, un (premier) titre donc, mais pas forcément la description ni même le contenu de prêt. Du coup, lors de la création, j’aurais donc laissé ces champs de côté.
De plus, je peux réaliser de premiers traitements dans mon code, propre à l’ajout. Je peux par exemple définir dans mon code que lors de l’ajout :
- La date du jour est utilisée pour la date de création
- La visibilité de l’article est mise à « false » pour que l’article ne soit pas publié avant validation
- L’auteur est paramétré de base avec l’utilisateur authentifié
De cette manière, lorsque je vais être redirigé vers l’édition, après la création, ces champs seront déjà remplis.
De plus, pour pouvoir gérer mon auteur et mes thèmes associés, je dois les récupérer en amont par plusieurs requêtes SQL. Cette fois-ci, lors de ma création, j’économise ces requêtes. Ma page de création est la plus simple possible et ne fait appel à aucune donnée tierce tant que je n’en ai pas besoin.
Enfin, imaginons que je mette à jour mon modèle Article, en rajoutant par exemple une image d’illustration et une description longue dédiée aux réseaux sociaux. Et bien la logique et la page de création ne change pas ! Il y aura des ajustements à faire seulement dans la logique et la page d’édition.
Quelques remarques
Attention, à ne pas pousser le concept trop loin. Il est intéressant dès lors qu’un modèle a minimum 4 ou 5 informations à compléter. S’il n’en a que 3 ou moins, cette séparation du process en 2 étapes pourrait s’avérer contre productive.
De la même manière, ne réduisez pas forcément à 1 seul champ. S’il y a un ou plusieurs autres champs qui sont très importants ou obligatoires, ils peuvent ou doivent être intégrés dès la création. Par exemple, dans le process de création d’un utilisateur. Si vous souhaitez définir une fonction pour un utilisateur, vous saisirez à la création son adresse mail ET sa fonction. Son mot de passe pourrait également être saisi dès la phase de création, par mesure de sécurité, pour éviter un mot de passe par défaut ou un mot de passe vide (Ah les mots de passe… vaste sujet !)
Un peu de javascript pour finir
A l’affichage de la page qui contient le formulaire d’ajout, on peut placer le curseur de l’utilisateur directement dans le champ à remplir. Pas besoin d’un clic supplémentaire pour s’y placer et le controle du formulaire peut même ainsi se faire au clavier.
Pour cela, avec jquery, vous pouvez utiliser :
$('#monInput').focus();
