Le sous-domaine ou l'URL unique par entreprise est-il préférable pour l'application Web
J'écris une application web, l'application est destinée aux petites entreprises où chaque entreprise aura plusieurs utilisateurs.
Qu'est-ce qui est mieux:
donner à chaque entreprise un sous-domaine (pour accéder à l'application sur my-company.example.com)
tout le monde accède au service sur www.example.com (dans ce cas, vous devez entrer le nom de l'entreprise dans la page de connexion).
Je demande ce qui est mieux du point de vue de l'utilisabilité, les deux auront la même séparation complète entre les entreprises et les deux nécessiteront exactement la même quantité de travail à mettre en œuvre.
Mise à jour: la plupart (sinon la totalité) des employés de l'entreprise utiliseront l'application.
Je pense que cela dépend de qui est censé utiliser l'application. Si les clients ou employés de mon entreprise sont censés utiliser l'application, il serait plus facile et plus confortable d'utiliser un sous-domaine (cela pourrait également permettre la personnalisation de la page avec un logo, etc.). .).
Si l'application n'est destinée à être accessible qu'à quelques personnes de niveau administrateur, il est probablement plus facile de simplement se connecter à l'application principale et de configurer les choses là-bas.
Par exemple, il est plus simple pour un seul utilisateur d'utiliser gmail, mais pour une organisation, il est plus simple d'utiliser les applications Google. Bien que cela prenne un peu plus de temps à mettre en place, il est alors spécialisé pour mon entreprise
Utilisez certainement un sous-domaine par entreprise.
Vous pouvez procéder de deux manières différentes:
- company.yourcoolapp.com
- yourcoolapp.company.com 1
La différence entre les deux options est faible, mais pour moi, il semble qu'avec l'option numéro un, l'utilisateur du logiciel voit que son entreprise est autorisée à utiliser votre logiciel sur votre domaine (ce qui est probablement le cas). Ils peuvent ou non se sentir propriétaires des données qu'ils saisissent (en fonction de ce que fait réellement votre application).
Avec l'option numéro 2, l'utilisateur du logiciel voit que votre application fait partie de son domaine, presque comme les données/applications sont hébergées par leur entreprise. Dans ce cas, je pense que l'utilisateur se sentirait plus comme si l'application faisait partie de son entreprise, plutôt que comme un produit extérieur qu'il venait d'utiliser.
Vous pouvez même configurer les deux URL, l'un des domaines pointant vers l'autre. Voici comment Blackboard (un logiciel éducatif) le fait dans mon université:
1 Cela peut être une URL moche si vous écrivez une application que le célèbre cabinet d'avocats Dewey, Cheatem et Howe pourrait utiliser: http://mycoolapp.DeweyCheatemAndHoweAttorneysAtLaw.com
Avoir un sous-domaine donne un sentiment plus fort de propriété (et peut-être de confidentialité).
Vous pouvez personnaliser la page de destination du sous-domaine, avec le logo de l'entreprise, les actualités, etc.
En revanche, si vous utilisez une seule page centrale, la seule image de marque de votre organisation (le fournisseur de services) peut être présente.
Si vous n'avez qu'une seule page, assurez-vous de prendre en charge les URL qui remplissent automatiquement le champ d'organisation, afin que vos utilisateurs puissent envoyer des liens directs.
À bien y penser, vous pouvez peut-être ignorer l'organisation:
Pourriez-vous avoir des utilisateurs multi-organisations?
Cela signifie que Beth travaille dans l'organisation A, qui fournit des services à l'organisation B, donc Beth doit se connecter aux deux organisations.
Si c'est PAS le cas, alors les utilisateurs peuvent se connecter à partir d'une page centrale et ne doivent remplir aucun champ d'organisation car elle sera automatiquement associée au le bon.
Cela dit, il peut être plus logique de se connecter à partir d'un sous-domaine différent.
Pour notre application, nous avons décidé de les combiner, et nous pensons que cela fonctionne plutôt bien:
- Les utilisateurs peuvent visiter ourapp.com et cliquer sur "Se connecter" pour être redirigés vers l'écran de connexion
- Les utilisateurs peuvent visiter directement l'écran de connexion
- Une fois connecté, tous les utilisateurs sont placés dans l'environnement "Connecté" sur xxx.ourapp.com
- Lorsque les utilisateurs créent une entité dans notre application, ils peuvent lui donner un nom de sous-domaine sur yyy.ourapp.com
- yyy.ourapp.com est "orienté client" et ne montre donc aucune marque de ourapp, y compris les liens de connexion.
Nous avons décidé de ne pas faire la partie "saisir le nom de l'entreprise sur la page d'accueil", car nous avons réalisé qu'il serait préférable, du point de vue du modèle de base de données et de domaine, de laisser tout le monde avoir son propre "compte" et de se connecter avec cela, puis écrivez la logique métier pour associer les utilisateurs les uns aux autres. Des trucs techniques, mais parfois vous devez en tenir compte lors de la conception de l'expérience utilisateur.
Il y a 2 choses à considérer avant de choisir l'une d'entre elles, qui sont:
- Sécurité du site.
- Référencement du site.
sous-domaine personnalisé
Si vous avez besoin d'un sécurité renforcée, alors vous devriez vous rendre dans un sous-domaine personnalisé, il y a plusieurs choses qui renforceront la sécurité de votre site lorsque vous choisissez un sous-domaine personnalisé, qui sont:
- Pas d'indexation Google. Vous pouvez éviter l'indexation de Google sur votre site client privé et vous pouvez indexer en toute sécurité l'ensemble de votre site www sans craindre que votre système soit compromis.
- Évitez le piratage du site en affichant votre fichier robots.txt. Vous pouvez en toute sécurité interdire à Google d'indexer plusieurs de vos pages ou structure de répertoire, mais quelqu'un peut facilement jeter un coup d'œil dans votre robots.txt et y trouver quelque chose de précieux.
Si vous préférez la sécurité à l'optimisation des moteurs de recherche, vous pouvez choisir un sous-domaine personnalisé, mais l'implémentation est un peu délicate, n'utilisez pas dns pour ajouter un cname ou un enregistrement à votre sous-domaine, ajoutez simplement un enregistrement pour * .votredomaine.com, et vous pouvez gérer en toute sécurité votre sous-domaine avec vhost à partir de votre serveur Web, afin que personne ne puisse entrer dans le sous-domaine sans en connaître le nom exact au préalable.
sous-dossier personnalisé
Si vous avez besoin d'optimiser le classement de votre site dans les moteurs de recherche, vous pouvez utiliser cette méthode. Vous pouvez interdire certains endroits d'être indexés par le moteur de recherche avec robots.txt, et j'espère que personne ne sait où il se trouve. Vous pouvez également avoir un classement de votre site plus élevé que la méthode précédente, car tous vos clients visitent votre site principal, plutôt que leur propre sous-domaine.
Résumé
Personnellement, je choisis la première option, car je ne peux pas me permettre de perdre certaines pages pour être indexées involontairement par le moteur de recherche, ou quelqu'un a en quelque sorte trouvé mon robots.txt. Si j'ai plus que jamais besoin de référencement, je peux simplement créer un blog pour l'entreprise et l'indexer, ce qui attirerait plus de gens et aurait une visite unique plus élevée, et augmenterait le classement, plutôt que de risquer mon système plus facilement d'être compromis.
Avec la mise en garde qu'avec votre deuxième solution, l'utilisateur devrait entrer le nom de sa société, la seule bonne solution est les sous-domaines de la société. Pensez-y de cette façon - avec la solution 1, voici ce que l'utilisateur doit faire:
- Accédez à l'URL du site
- Entrez leur nom d'utilisateur
- Entrez leur mot de passe
- S'identifier
Avec la solution 2, voici ce qu'ils doivent faire:
- Accédez à l'URL du site
- Entrez le nom de leur entreprise
- Entrez leur nom d'utilisateur
- Entrez leur mot de passe
- S'identifier
Pourquoi ajouter l'étape supplémentaire si vous n'en avez pas besoin? En outre, faire en sorte que l'utilisateur saisisse le nom de son entreprise est une charge cognitive supplémentaire, car il doit maintenant se rappeler comment pour saisir correctement le nom de son entreprise. Que se passe-t-il s'ils font généralement référence à l'entreprise via un acronyme ou un nom court? À quoi sert votre page de connexion? Pourquoi inciter les utilisateurs à se souvenir de ces détails supplémentaires lorsqu'ils n'en ont pas besoin?