Une caisse de page a été dans le débat depuis très longtemps maintenant. Il y a des dizaines d’articles sur les thèmes « Si vous choisissez un achat d’une page? » « Avantages et inconvénients de One Page Checkout » et ainsi un. La plupart de ces articles traitent efficacement les inconvénients, mais il semble que nous promouvons ces inconvénients comme ils sont là pour toujours et ne peuvent pas être prises vers le bas de toute façon.
Avouons la vérité, chaque nouvelle introduction a quelques inconvénients à coup sûr. Peu à peu, avec le développement et la recherche, ces inconvénients disparaissent à coup sûr.
Dans ce blog, je vais aborder 3 ces inconvénients d’une caisse d’ une page que nous éliminions de notre Magento une extension de la caisse de la page et aussi le PrestaShop Un module de commande de la page . La plupart de ces inconvénients étaient jamais là dans notre extension de la caisse, que nous avons pris soin d’eux pendant la phase de développement et de test lui – même.
Un des inconvénients fixes checkout page
1. Une grande partie de détails sur une seule page? Il sera encombré
La plupart des pages de paiement, lors de son introduction dans le passé, a eu ce problème. Ce fut vraiment une énorme tâche de tout régler à partir d’une caisse de plusieurs pages sur une seule page.
Le défi le plus problématique était de répondre à tous les éléments de caisse sur une seule page et il devrait fournir une vue complète de toute page de paiement ainsi. De plus, tous les éléments de caisse comme connexion, sous forme d’adresse de livraison, sous forme d’adresse de facturation, les options de paiement, options d’expédition, et l’examen de panier ne doivent pas se chevaucher, et ils ne doivent se chevaucher sur eux-mêmes. Beaucoup de HTML, CSS, JavaScript et Ajax ont été nécessaires pour être manipulés pour maintenir la conception tout va bien avec la valeur par défaut ainsi que le tiers des thèmes Magento. Mais nous avions l’intention de les garder aussi moins que possible pour le chargement des pages plus rapide.
C’est ce que nous sommes arrivés avec:
Beaucoup de HTML, CSS, JS, Ajax et ont été peaufiné par nos designers pour répondre à tous les éléments d’une manière ordonnée et clairement sur une seule page et aussi pour garder le temps de chargement de la page optimale. De plus, grâce à nos designers, après tout cela, il y avait suffisamment d’ espace laissé pour ajouter l’ option de connexion sociale en utilisant Facebook et Google sur notre page de paiement.
2. Le formulaire sur la page sont encombrées sans espace blanc et l’utilisation de l’étiquette appropriée
Lors de la conception des formes, les principaux aspects que nous recherchions étaient les suivants:
- Garder les formes compactes
- Tous les champs nécessaires devraient être là
- Les champs doivent avoir appropriés blanc-espaces
- Les étiquettes ne doivent pas confondre les utilisateurs
- Admin devrait être en mesure de choisir quel champ forme qu’il souhaite afficher sur la page aux clients.
Étiquettes
Les étiquettes sortaient comme une préoccupation majeure ici. Si nous garderions les étiquettes du côté des champs respectifs, la longueur horizontale de la forme donnerait un espace très moins pour les autres sections de la page.
Nous avons également pensé à une conception de formulaire où nous sauter les étiquettes et utiliser des espaces réservés à leur place. Quelque chose comme ça:
Mais, il y avait un problème à cet égard. , Si le client une fois rempli pour des formes considérablement longues comme des formulaires de facturation et les détails, et plus tard s’il voudrait les vérifier à nouveau, il se confus au sujet de ce que sont en réalité ces détails. Étant donné que l’espace réservé disparaît loin que vous tapez, et il n’y a pas d’étiquette aussi bien, il reste toujours une confusion si mes informations sont bonnes ou mauvaises.
Nous ne voulions pas que vos clients d’entrer dans une telle confusion et d’oublier l’objectif principal de faire un achat, c’est pourquoi nous laissons tomber l’idée. Dans le cas contraire, il aurait pu sauver beaucoup d’espace aussi bien.
Enfin, nous avons décidé de ne pas compromettre l’expérience utilisateur et de toute façon nous avons adopté la mise en place de l’étiquette au-dessus des champs comme indiqué dans cette image:
Il a sauvé l’espace horizontal que nous avions besoin d’autres éléments et a également contribué à une autre caractéristique qui a été discuté ci-dessous.
Les champs nécessaires
Après avoir traité le placement de l’étiquette, la dernière chose que dans les formes qui nous ont donné un cauchemar était d’inclure tous les champs nécessaires sous la forme. Le problème est, le terme nécessaire est toute relative ici. Un champ de formulaire qui est nécessaire pour un propriétaire de magasin peut être d’aucune utilité à l’autre.
Par exemple, le numéro de TVA, et le nom de la société est un champ nécessaire d’un propriétaire de magasin qui a une entreprise de vente B2B. Tous vos clients d’affaires européens aurait également besoin de ce terrain pour faire des achats sur votre magasin. D’autre part, un propriétaire de magasin qui vend directement aux consommateurs aurait pas d’utilisation des champs comme numéro de TVA et le nom de la société.
Comment nous manipulaient?
Il fut un temps d’ouvrir notre extension de la caisse un peu et donner aux propriétaires de magasin un certain accès au développement facile mais crucial. Nous ajoutons une fonctionnalité dans notre module, à l’aide duquel l’administrateur peut facilement activer, désactiver, ajouter et supprimer un champ du formulaire de commande. Cela aussi, sans modifier le code. Tout cela peut être fait à partir du backend lui-même.
Donc, si l’un des champs n’est pas utilisable pour un propriétaire de magasin, il peut tout simplement cacher avec un simple clic et enregistrer. Pas besoin de passer par les codes complexes Magento ou PrestaShop faire maintenant.
3. Page Frequent reload sur la mise à jour du panier
Ces caisses de plusieurs pages ont une page dédiée à l’édition des caddies. Ce fut un défi pour nous d’inclure le panier sur la page de paiement. Les clients seraient souvent mettre à jour le panier en augmentant ou en diminuant les comptes de ce produit, retirer un produit du panier et ainsi un.
Toutes ces demandes ont nécessité une page reload de mettre à jour tous les détails de la caisse et des informations selon le dernier état de la commande. Si un produit a été retiré du panier, nous avions besoin de mettre à jour le coût total, la quantité de produit panier, les méthodes d’expédition et ainsi de suite avec elle.
Il serait devenu si irritant pour les clients si la page de paiement se recharger de temps en temps. Ce défi est confronté par tous d’une page de développement de votre commande. Cependant, nous avons réussi à le fixer avec le panier à base d’Ajax et le formulaire de demande de mise à jour.
Maintenant, avec Ajax panier et mises à jour, si un client change quoi que ce soit dans le panier, tous les détails à charge seraient automatiquement mises à jour sans recharger toute la page de paiement. Même le client peut demander un code promo à votre panier et page validerait le coupon sans être rechargés.
Voici comment nous avons résolu ces problèmes dans notre extension de la caisse. Vous pouvez avoir une démo gratuite de découvrir toutes ces fonctionnalités de l’extension. Démo gratuite une caisse page Magento et PrestaShop et OpenCart .
