Comment choisir un CMS : un administrateur utilisera réellement

Les développeurs le choisissent, vous l'utilisez

Un système de gestion de contenu est presque toujours choisi par celui qui l'installera plutôt que par celui qui y travaillera tous les jours. La plupart des plaintes ultérieures en découlent.

Le développeur choisit sur la familiarité et construit la vitesse, ce qui est raisonnable de leur côté. Mais ce ne sera pas celui qui ajoutera une centaine de produits, qui publiera un article un vendredi soir, ou qui changera un prix sur chaque page à la fois.

Le résultat est un site techniquement sain et que son propriétaire a peur de toucher. Six mois plus tard, ils arrêtent de le toucher entièrement, et le site est en panne.

Ci-dessous : comment choisir pour que les deux parties soient satisfaites, et que vérifier avant la décision est prise.

Ce qu'est un système de contenu et ce qu'il n'est pas

Un système de gestion de contenu est ce qui vous permet de modifier le contenu d'un site sans développeur. Texte, images, produits, prix, pages.

Ce n'est pas la conception: le même système peut ressembler à n'importe quoi, et un beau site ne signifie pas un administrateur utilisable. C'est exactement ce qui se confond lors d'une démonstration.

Ce n'est pas non plus le jeu de fonctionnalités du site. Un catalogue filtré, des paiements, une zone de compte — ceux-ci sont construits sur le dessus, et ils peuvent être construits sur le dessus de tout.

Dans la pratique, la question est la suivante : que devez-vous être en mesure de vous changer, sans envoyer d'email à l'agence ? La réponse à cela détermine le choix.

Et encore une chose: un système de contenu n'a pas besoin d'être un seul système pour l'ensemble du site. Souvent, il est logique que le catalogue soit tiré d'un système de comptabilité alors que le texte est édité dans un administrateur distinct.

Trois approches

Ils diffèrent non pas en capacité, mais en qui est responsable des mises à jour et à quelle distance vous pouvez passer d'un comportement standard.

Un système open-source prêt à l'emploi. Installé, étendu avec des plugins, familier à un grand bassin de développeurs. Pas cher au départ avec beaucoup de spécialistes disponibles, mais les mises à jour et la sécurité sont de votre côté.

Un service en nuage. Toute la maintenance est celle du vendeur, il se met à jour, il se casse rarement. En échange, vous vivez dans ses règles et payez mensuellement.

Un administrateur personnalisé sur votre propre code. Exactement les champs dont vous avez besoin, rien de rechange, le contrôle total. Plus cher à construire et il a besoin de quelqu'un pour le maintenir.

Notre propre site est construit à la troisième façon, et la raison principale n'est pas la flexibilité mais les règles éditoriales: une pièce ne pénètre pas la recherche tant qu'elle ne satisfait pas environ vingt-cinq conditions sur la longueur, l'approvisionnement et la structure. Ce type de porte ne peut pas être fixé dans un système prêt à l'emploi.

Le critère principal: qui fera les changements

Répondez honnêtement, car tout le reste en découle.

Si la personne qui édite le contenu n'a pas d'arrière-plan technique, l'administrateur doit être simple au point d'être ennuyeux, et la flexibilité mérite d'être sacrifiée.

Si vous avez un développeur ou une agence sur reliure, vous pouvez prendre un outil plus puissant, parce que la complexité n'a pas d'entrave à leur façon.

Si presque rien ne changera jamais et que des mises à jour se produisent une fois par an, la question n'a guère d'importance et ne mérite pas d'être débattue.

Et séparément: si plusieurs personnes ayant des rôles différents entrent dans le contenu, c'est sa propre exigence et doit être indiqué à l'avance. Les permissions réaménagées par la suite s'adaptent mal.

Cinq tâches pour tester un administrateur contre

Ne regardez pas une démonstration — demandez l'accès et faites cinq choses à la main.

Créez une nouvelle page ou un nouveau produit à partir de zéro, avec une photographie et une description. C'est l'heure.

Modifier le texte sur une page existante et voir à quelle vitesse il apparaît sur le site et si la mise en page survit.

Chargez une photo de la mauvaise taille et voyez ce qui se passe. Un bon système se cultive et le compresse; un pauvre le montre comme-est et étend la disposition.

Trouvez un moyen de changer quelque chose sur vingt pages à la fois. Si cela n'existe pas, vous le ferez à la main pour la vie du site.

Et essayez de défaire votre propre édition. Être capable de revenir à une version précédente d'un texte est rappelé exactement une fois, et à cette occasion il est grandement nécessaire.

Ce qu'une démonstration ne montre pas

Les démonstrations se déroulent sur un site vide avec trois produits. Les problèmes commencent à 300.

Vitesse d'administration au volume. Une liste de mille objets qui prend vingt secondes pour ouvrir est ordinaire, et une démonstration ne le révélera jamais.

Rechercher dans l'administrateur. Une fois qu'il ya beaucoup d'articles, la recherche est la seule façon de trouver un, et il peut être étonnamment mauvais.

Opérations en vrac. Changer la catégorie sur quarante produits, augmenter les prix de 5 %, sans publier tout ce qui ne se vend pas. Sans ça, le travail devient un slog.

Et comportement quand deux personnes travaillent à la fois. Qui gagne si les deux ont ouvert la même page et sauvegardé? La bonne réponse est un avertissement; la réponse commune est que celui qui a sauvé d'abord est silencieusement écrasé.

Plugins: la résistance et le danger principal

Les systèmes ready-made ont un plugin pour chaque tâche, et c'est leur principal avantage. C'est aussi leur principal risque.

Chaque plugin est le code de quelqu'un d'autre dans votre site. Il peut ralentir les pages, entrer en conflit avec d'autres plugins, et porter des vulnérabilités que vous ne verrez jamais.

Un plugin abandonné est le plus dangereux de tous : il continue de fonctionner mais cesse d'être mis à jour, et dans un an il devient le trou que les gens entrent.

Les règles pratiques sont simples. Avant d'installer, regardez la date de la dernière mise à jour et le nombre d'installation. Ne pas exécuter deux plugins faisant le même travail. Tous les six mois supprimer ce que vous n'utilisez pas — un plugin désactivé est toujours en code assis sur le serveur.

Et gardez une liste: ce qui est installé, pourquoi, et qui a décidé. Dans deux ans, personne ne se souviendra.

Mises à jour: Les démonstrations se déroulent sur trois produits; les…

La partie la plus terne et la cause la plus commune d'un effraction.

Les mises à jour ne sont pas publiées pour de nouveaux boutons, mais le plus souvent pour fermer les vulnérabilités. Une vulnérabilité devient une connaissance du public et, à partir de ce jour, un balayage automatisé commence pour les sites qui n'ont pas appliqué la mise à jour.

Les gens les sautent pour une raison compréhensible : une mise à jour casse parfois le site. D'où la logique de si elle fonctionne, ne la touchez pas, qui tient jusqu'à la première effraction.

Il y a un ordre correct : une zone de mise en scène, la mise à jour là-bas, un contrôle des scénarios clés, puis la production. Cela prend une demi-heure et élimine presque tous les risques.

Et d'accord à l'avance qui le fait. Les mises à jour sont des travaux récurrents; elles ont besoin d'un propriétaire et d'une place dans le budget. Votre hôte ne vous les appliquera pas.

Autorisations

Un point qui se trouve à un moment gênant.

Si plusieurs personnes gèrent le contenu, chacune a besoin de son propre compte avec un rôle. Pas un seul compte partagé dont un ancien employé connaît aussi le mot de passe.

L'ensemble minimum de rôles : quelqu'un qui écrit mais ne peut pas publier, quelqu'un qui publie, quelqu'un qui change les paramètres. Cela couvre la plupart des cas.

Pensez séparément à ce qui se passe quand quelqu'un part. Le compte est désactivé, non supprimé — sinon l'enregistrement de qui a changé ce qui disparaît avec lui.

Et vérifiez si ce disque est visible. Un journal de changement répond qui a retiré ce bloc en une seconde; sans lui, la même question est un argument irrésoluble.

Que demander à l'agence

Six questions posées avant la signature plutôt qu'après.

Qui mettra à jour le système et ses plugins après le lancement, et c'est cela dans le prix.

Y a-t-il une zone de mise en scène où les mises à jour sont vérifiées avant la production.

Est-ce que tout le contenu peut être exporté sous une forme portable si nous passons à une autre agence.

Combien de personnes sur le marché peuvent travailler avec ce système. La réponse seule n'est pas un avantage.

Et montre-moi comment faire un gros changement sur quarante pages dans cet administrateur. Ne pas le décrire — montre - le.

Comment vérifier avant de décider

Une procédure courte pour une soirée.

Prenez la liste de ce que vous allez changer sur le site sur un an: texte, prix, produits, articles, promotions.

Contre chaque point notez qui le fera et à quelle fréquence.

Demandez l'accès à une version de démonstration et effectuez les trois éléments les plus fréquents à la main, en vous-même.

Multipliez ce temps par la fréquence annuelle. Le nombre d'heures résultant est le coût réel de l'administrateur, et il dépasse généralement la différence de prix de construction.

S'il n'y a pas de temps pour l'arithmétique, il y a une règle courte : choisissez la chose la plus simple qui couvre vos tâches. Une pénurie de capacités est immédiatement remarquée et corrigée par le développement. Un excès de complexité est remarqué en un an, et alors rien ne le corrige.