Module #9: Le design et l’identité visuelle

Module #9: Le design et l’identité visuelle



Depuis sa création, SharePoint souffre d’une réputation d’outil pas vraiment « sexy » au regard de ses interfaces. Pourtant, l’aspect visuel d’un portail détermine bien souvent la première impression des utilisateurs ainsi que leur perception générale sur la qualité de la solution. En plus de la nécessité de gérer les nouveaux usages mobiles en entreprise (téléphone, tablette), il est donc important de proposer des interfaces visuellement attrayantes et ergonomiques (évident me direz-vous !).

Cependant, avant de se lancer dans un chantier de personnalisation graphique d’un portail SharePoint, plusieurs éléments sont à prendre en compte.

  1. Bien évaluer les besoins en termes d’identité visuelle

C’est un fait, l’humain a toujours été attiré par ce qui brille, et les interfaces web n’en font pas exception. En effet, tout le monde souhaite un visuel attrayant pour son portail…Cependant, un intranet est avant tout un outil de travail d’entreprise, et non une vitrine de celle-ci (généralement, le site web est là pour ça). Un trop gros investissement dans l’aspect graphique d’un portail peut même avoir un effet pervers sur le ressenti général des utilisateurs. Si celui-ci est très évolué, mais que les autres fonctionnalités offertes sont perfectibles (navigation, accès à l’information, etc.), il est très probable que les utilisateurs remettront en question la répartition de l’effort vis-à-vis du gain réel.

Cela ne signifie pas qu’il est proscrit de mettre beaucoup d’efforts dans l’identité visuelle d’un portail SharePoint (tout dépendra au final de la culture de l’entreprise et fortement de votre budget) mais il est simplement utile de se rappeler que d’une part, la notion de « beauté » est totalement subjective et que d’autre part, un intranet d’entreprise ne poursuit, à priori, pas les mêmes objectifs qu’un site web public. En résumé, l’efficacité prime souvent sur la beauté au moment de faire des compromis.

Pour l’anecdote, il nous est déjà arrivé d’avoir eu pour consigne de ne pas faire quelque chose de trop « beau » pour un site web d’un organisme public pour ne pas soulever de commentaires du type « mais où ont-ils trouvé l’argent pour faire ça, il aurait pu servir à autre chose ! ». Le design peut donc être un sujet sensible et il est bien important de ne pas tomber dans le piège de la personnalisation excessive.

  1. Répartir l’effort de personnalisation graphique

Un avantage majeur lié à l’utilisation de la publication intersites pour un intranet réside dans le fait de pouvoir séparer physiquement la visualisation des données de leur création. Ainsi, l’effort de personnalisation peut davantage être mis sur la partie « publique », visible par tous les utilisateurs (le site de publication). Il est en effet peu probable que les contributeurs aient besoin d’une interface mobile ou bien d’une page maître personnalisée pour la création de leurs contenus. Pour ces derniers, un thème SharePoint sera bien souvent suffisant. De même, avec cette approche, il n’est pas nécessaire de concilier la personnalisation d’un portail en mode lecture ET édition, chose jamais très aisée avec SharePoint.

Stratégie de personnalisation d'un intranet en publication intersites

Stratégie de personnalisation d’un intranet en publication intersites

  1. Approche « Responsive » ou « Adaptive » ?

Lorsque l’on parle de design et de mobilité dans une interface web, deux philosophies s’affrontent. D’un côté, l’approche responsive permettant d’afficher un site de manière fluide s’adaptant automatiquement à toutes les résolutions et de l’autre, l’approche adaptive permettant de décliner un site en plusieurs expériences selon des résolutions prédéfinies. Si l’on se place d’un point de vue utilisateur, l’approche que vous allez prendre ne fait au final, aucune différence. Ce qui lui importe, c’est de pouvoir naviguer correctement dans le portail via un ou plusieurs types d’appareils (mobile ou non). C’est pourquoi, nous n’allons pas rentrer dans le détail des problématiques d’ergonomie ou de design web, qui ne sont en rien spécifiques à SharePoint mais au web en général. LE choix que vous ferez dépendra avant tout de votre budget et des attentes vis-à-vis du projet. Cependant voici quelques caractéristiques importantes à retenir concernant ces deux approches :

Responsive

Adaptive

  • Vous définissez des « breakpoints» servant de déclencheurs à la réorganisation dynamique de la page selon la résolution. Ceux-ci s’appuient sur les « Media Queries » apparues avec CSS3.
  • Le Framework par excellence pour faire du design responsive se nomme Bootstrap, créé par Twitter et fonctionnant selon un système de grille à 12 colonnes.
  • SharePoint 2013 ne fournit aucun support par défaut pour la gestion du design responsive. Cependant, des exemples existent sur internet pour vous aider à démarrer.
  • Vous décidez de chaque élément/format à afficher selon les résolutions/type d’appareil.
  • Vous devez potentiellement créer autant d’expériences que de résolutions/appareils à supporter.
  • SharePoint 2013 offre par défaut la fonctionnalité des canaux d’appareils (« Device channels ») pour l’implémentation de cette approche.

Un intranet compatible « mobile » ne signifie pas non plus que toutes ses fonctionnalités doivent nécessairement l’être. Dans bien des cas, seules certaines sont vraiment pertinentes pour ce genre d’utilisation. C’est par exemple le cas du parcours de contenu via les menus de navigation ainsi que l’expérience de visualisation de celui-ci (nouvelles, pages, etc.).

  1. La délicate question des navigateurs supportés

Lorsque l’on parle d’identité visuelle dans un portail, la question des navigateurs supportés n’est jamais très loin. Dans la plupart des cas, et selon la liste des navigateurs supportés par SharePoint, vous aurez à gérer les principaux du marché, à savoir Internet Explorer, Google Chrome, Firefox et Safari (Opéra étant très marginal). Cependant, on peut distinguer deux familles de navigateurs :

  • Les navigateurs « rapid release »

Ces navigateurs se tiennent à jour automatiquement à intervalles réguliers relativement courts (6 semaines environ). Les versions s’incrémentent donc automatiquement sans que l’utilisateur n’ait besoin de faire quoi que ce soit. D’un point de vue développement, ce principe permet d’assumer que ces derniers disposent de la dernière version offrant donc les plus récentes possibilités. Parmi ces navigateurs, on retrouve :

  • Mozilla Firefox (depuis la version 5.0)
  • Google Chrome
  • Microsoft Edge
  • Les navigateurs avec versions fixes

Les versions de ces navigateurs sont généralement étroitement liées avec celles des systèmes d’exploitation des mêmes firmes. D’un point de vue développement, cela signifie que la solution doit être compatible avec potentiellement une ou plusieurs de ces versions et que l’on ne peut pas assumer une mise à jour à la dernière en date. Les possibilités en sont donc limitées en plus de devoir gérer les problématiques de compatibilité interversions. Parmi ces navigateurs, on retrouve évidemment Microsoft Internet Explorer et ses multiples déclinaisons des versions 6 à 11 faisant l’objet d’installations séparées, mais aussi Apple Safari lié au système d’exploitation iOS.

Pour quelqu’un ayant fait un minimum de CSS/JavaScript dans une application web (SharePoint ou autre) sait que l’ennemi juré se nomme Internet Explorer et ses nombreuses incompatibilités et autres retards sur les standards du web. Comprenez bien que ce n’est pas par mauvaise volonté que des entreprises utilisent encore IE 8 ou 9, c’est bien souvent à cause d’applications métiers nécessitant obligatoirement ces versions. Ceci dit, de plus en plus d’entre elles optent maintenant pour Internet Explorer 11 pour bénéficier du mode « Entreprise » qui justement permet de garder la compatibilité avec d’anciennes applications tout en mettant à jour vers un navigateur en phase sur les standards du web. À noter qu’une évolution vers cette version nécessitera aussi une migration du système d’exploitation à Windows 7 au minimum.

Si IE11 n’est pas une alternative, il vous faudra alors composer avec les « anciennes » versions d’Internet Explorer (IE8 et 9 principalement). Dans ce cas, nous vous conseillons fortement l’utilisation de la librairie Modernizr.js qui permet de détecter les possibilités des navigateurs et ainsi proposer des fonctionnalités adaptées.

Modernizr

De manière générale, nous vous conseillons de minimiser vos efforts sur IE8 et 9 car, pour l’avoir fait sur plusieurs de nos projets, le support de ces versions entraine des coûts qui, très souvent, ont un gain associé plus que négligeable.

La gestion de l’aspect graphique dans SharePoint

Le gestionnaire de conception

Le gestionnaire de conception (ou « Design Manager » en anglais) est une nouveauté apparue avec la version 2013. Avec cet outil, Microsoft a en quelque sorte tenté de réconcilier les designers avec SharePoint. Ici plus de code barbare à même les pages *.master ou *.aspx, la plupart des éléments formant l’expérience graphique SharePoint peuvent maintenant être écrits directement en HTML puis traduit automatiquement par l’outil dans le format approprié. Cela laisse notamment la possibilité aux designers (aux vrais, pas les développeurs ;)) d’utiliser leur éditeur web préféré (Dreamweaver, Notepad++, etc.).

Il regroupe plusieurs notions (déjà existantes pour la plupart) sous un même chapeau :

  • Les pages maitres
  • Les gabarits de pages
  • Les modèles d’affichages utilisés pour les composants Web Part de recherche

Les canaux d’appareils, traduction de l’approche de design adaptive.

Le gestionnaire de conception de SharePoint 2013

Le gestionnaire de conception de SharePoint 2013

Ce qu’il est important de retenir, c’est que pour chacun des éléments éditables au format HTML, SharePoint créé maintenant automatiquement une version synchronisée dans le format approprié. Ainsi :

Le fichier…

devient…

MasterPage.html

MasterPage.master

PageLayout.html

PageLayout.aspx

DisplayTemplate.html

DisplayTemplate.js

Remarques :

  • Il est possible de travailler directement avec les fichiers .master ou .aspx sans passer par un fichier .html. Dans ce cas, il n’y aura pas de synchronisation (celle-ci est unidirectionnelle).
  • Une action d’extraction puis d’archivage (« Check-Out/Check-In») est nécessaire pour déclencher une régénération du fichier associé au .html.
  • Pour l’inclusion et la personnalisation de composants SharePoint aux gabarits de pages et aux pages maîtres, il existe un assistant permettant de générer le code approprié à insérer dans la page :
    Assistant de personnalisation des composants SharePoint

    Assistant de personnalisation des composants SharePoint

Options de personnalisation visuelle

Avant de mettre en place une stratégie d’identité visuelle dans un intranet SharePoint, il est important de connaitre et comprendre les options offertes par l’outil pour déterminer les meilleures solutions et leurs impacts vis-à-vis des attentes du projet.

Voici les principaux moyens ou techniques/technologies indépendantes permettant d’avoir un effet sur l’apparence, le comportement ou bien la disposition des éléments dans un site SharePoint 2013, le tout résumé en une seule page :

Options de personnalisation visuelle dans SharePoint 2013

Options de personnalisation visuelle dans SharePoint 2013

Page maitre

Gestion des éléments communs à toutes les pages. Permet de charger ses propres fichiers JavaScript/CSS aux pages de manière transversale.

Thème (ou « Composed Look »)

Gestion simple de l’aspect d’un site (couleurs, polices, logo et page maître).

Thèmes SharePoint

Thèmes SharePoint

Redéfinition des styles CSS SharePoint

Redéfinition des styles CSS des éléments par défaut présent dans un site SharePoint. Par exemple en spécifiant une feuille de style alternative pour la page maitre agissant sur les menus de navigation ou bien la barre de navigation supérieure :

AlternateCSS

Gabarit de page

Gestion de la disposition des éléments et du format des pages selon leur type (nouvelles, pages de contenu, etc.).

Modèle d’affichage (« Display Template »)

Technologie de rendu HTML/JavaScript (côté client donc) pour les composants Web Part de recherche (recherche de contenu, résultats de recherche, boîte de recherche.). Impose une syntaxe particulière et peut-être secondée d’une feuille de style XSL alternative pour les considérations SEO.

Client Side Rendering (JSLink)

Gestion du rendu pour les éléments de listes. Applicable sur des champs, type de contenu, vues, Web Part de liste et formulaires (NewForm.aspx, EditForm.aspx, etc.).

Feuille de styles XSL

Ancienne technologie de rendu (côté serveur) pour les Web Parts SharePoint basés sur du XML (requête de contenu, etc.).

Code source HTML direct

Écriture de code HTML et styles CSS directement à même une page SharePoint ou un Web Part  « éditeur de contenu ».

Composant personnalisé

Add-In ou un Visual Web Part (ou autre) dont la structure HTML, les styles CSS et les comportements sont libres.

Bien qu’il soit difficile de les comparer sur un même plan (car grandement dépendantes du contexte), voici un portait global des solutions offertes par SharePoint en termes de personnalisation visuelle et leur complexité relative vis-à-vis des attentes (attention, ceci est une interprétation purement personnelle) :

Graphique montrant la complexité des solutions versus les attentes en termes de design dans SharePoint

Graphique montrant la complexité des solutions versus les attentes en termes de design dans SharePoint

Parmi les deux axes mis en valeur sur ce schéma :

  • La complexité relative de la solution, avec notamment les critères suivants (non exhaustifs) :
    • Prise en main de la technologie
      • La solution possède-t-elle un fonctionnement ou une syntaxe particulière à connaître autre que les technologies actuelles du web (HTML/CSS/JavaScript) ?
    • Type et effort de déploiement
      • La mise en place de la solution déploiement nécessite-il du code ou bien est-il réalisable manuellement via l’interface ?
  • La flexibilité de personnalisation de la solution permettant de répondre le plus précisément aux attentes :
    • Contrôle sur la structure
      • A quel point la structure du code HTML est-elle modifiable ?
      • La solution permet-elle l’application de styles CSS personnalisés ?
      • La solution permet-elle de changer les comportements par JavaScript ?

Il n’y a évidemment pas de schéma de décision exact concernant les solutions de personnalisation à utiliser. Cependant ce graphique peut au moins vous donner une idée globale des possibilités selon les cas. Certaines techniques seront davantage adaptées pour sites dits de « collaboration » avec des besoins modérés en terme de visuel (sites d’équipes, etc.) et d’autres davantage destinés à de la « publication » classique. De même, pour certaines, le niveau de complexité peut évoluer proportionnellement aux attentes (de manière plus ou moins exponentielle !).

Dans le cadre de cette étude de cas, nous avons opté pour la combinaison « modèles d’affichages, gabarits de pages, page maitre et composants personnalisés » pour l’implémentation de l’identité visuelle globale du portail (site de publication uniquement, les sites d’auteurs n’ayant qu’un simple thème). En effet, la publication intersites se basant sur la recherche, les modèles d’affichages demeurent une solution tout indiquée et assez flexible pour la plupart des besoins en termes de design.

Rôles concernés et responsabilités

Voici les besoins que nous allons traiter dans ce module :

Qui?

Quoi?

Notion(s) clé(s)

Utilisateur

[DSGN01] Visualiser l’image de marque de l’entreprise

  • Page maître
  • « Delegate Controls »
  • Modèles d’affichages
  • Bootstrap
  • Knockout.js

[DSGN_01] Utilisateur : Visualiser l’image de marque de l’entreprise

Permets à un utilisateur de visualiser l’image de marque de l’entreprise à travers la partie publique du portail.

L’interface doit être compatible sur téléphone mobile et tablette (en mode responsive).

#

Étape

1

Créer la page maître

2

Intégrer Bootstrap pour la gestion du design responsive

3

Créer les modèles d’affichages

4

Utiliser des librairies JavaScript tierces

Critères d’acceptation

Voici les critères d’acceptation qui permettent de valider les objectifs du besoin [DSGN_01] Utilisateur : Visualiser l’image de marque de l’entreprise.

#

Description

AC0

La visualisation du portail est adaptée aux résolutions des téléphones, tablettes et écrans d’ordinateur en mode « responsive ».

AC1

L’affichage de l’intranet est supporté sur les navigateurs les plus récents (IE11, Chrome, Firefox).

Étape #1 : Créer la page maître

La première étape pour la mise en place de l’identité visuelle d’un intranet concerne la création d’une page maître appropriée.

 Mécanisme d’inclusion des composants dans la page

La page maître est découpée en plusieurs zones distinctes (en-tête, corps, pied de page). Pour ne pas la surcharger avec le code HTML de chaque composant formant l’expérience globale (menu de navigation, boîte de recherche, pied de page, etc.), chacune de ces zones contient un ou plusieurs emplacements prédéfinis (des « placeholders ») servant à l’inclusion de composants à postériori via le mécanisme de « Delegate Controls » de SharePoint :

Structure et stratégie de la page maitre du portail

Structure et stratégie de la page maitre du portail

Avec ce principe, outre le fait de ne pas polluer la structure HTML de la page, vous prévoyez dès le départ les emplacements physiques des différents composants sans avoir à les implémenter nécessairement tout de suite et surtout sans avoir à modifier le code de la page maître le cas échéant. De même votre approche de développement est plus modulaire, améliorant de fait la lisibilité de la solution.

Conseil : Utilisez des composants « factices » comme un bloc de couleur avec le nom de la fonctionnalité prévue à l’emplacement indiqué. Cela vous permettra d’avoir une vue globale de la disposition des éléments et de vous projeter plus facilement dans la suite du projet (en plus d’introduire un certain challenge de devoir compléter les trous  à chaque sprint de développement).

Voici un exemple du principe de chargement du menu de navigation dans une page maître via le mécanisme de « Delegate Controls » :

Inclusion des composants via le mécanisme de « delegate control »

Inclusion des composants via le mécanisme de « delegate control »

Remarques :

  • Vous pouvez ajouter plus d’un contrôle dans un «PlaceHolder ». Cette technique est notamment utilisée pour le chargement des fichiers CSS et JavaScript généraux de la solution (AllowMultipleControls= »true »).
  • Les composants chargés dans des « PlaceHolders» peuvent eux-mêmes en contenir pour inclure d’autres composants en cascade (pour par exemple simplifier le découpage des éléments d’une même fonctionnalité).

 Inclusion des fichiers CSS et JavaScript

Les fichiers JavaScript et CSS globaux à l’intranet sont chargés respectivement dans la page maître via les balises <SharePoint:ScriptLink/> et <SharePoint:CssRegistration/> (permet la gestion de la séquence de chargement):

Chargement des fichiers JS

Chargement des fichiers JS

Chargement des fichiers CSS

Chargement des fichiers CSS

De même, ceux-ci sont tous stockés dans le répertoire \15\TEMPLATE\LAYOUTS de SharePoint au lieu de la bibliothèque de styles. La raison de ce choix est de permettre l’accessibilité de ces fichiers à la fois dans le site de publication et dans les sites d’auteurs.

Étape #2 : Intégrer Bootstrap pour la gestion du design responsive

Pour la gestion de l’affichage de l’intranet sur des appareils mobiles, nous avons opté pour une approche de design responsive via l’utilisation de Bootstrap (version 3.3.2). Par conséquent, nous n’avons pas utilisé la fonctionnalité de canaux d’appareils de SharePoint. Voici un aperçu de l’expérience mobile de l’intranet que nous permet le Framework :

Expérience mobile dans l'intranet avec Bootstrap

Expérience mobile dans l’intranet avec Bootstrap

Comme énoncé plus haut dans ce document, toutes les fonctionnalités d’un intranet ne doivent pas être nécessairement compatible mobile. C’est pourquoi, nous avons principalement orienté le travail sur les éléments qui forment la base de l’expérience mobile d’un site, à savoir :

  • La page d’accueil
  • Le parcours des pages du portail comme les pages de contenu ou bien les nouvelles
  • La recherche

Bien que le but de ce module ne soit pas d’expliquer le fonctionnement de Bootstrap en tant que tel (de nombreux tutoriels existent et cela n’est pas spécifique à SharePoint !), il est important de savoir, que lorsque vous l‘intégrez avec l’outil, plusieurs (même beaucoup) d’effets de bords visuels peuvent apparaitre sur les styles par défaut (à cause de la redéfinition de certaines classes CSS communes). Pour résoudre ce problème, il est préférable de maintenir un fichier CSS séparé corrigeant au cas par cas ces anomalies :

Maintien continu d’un fichier de corrections des collisions CSS entre SharePoint et Bootstrap

Maintien continu d’un fichier de corrections des collisions CSS entre SharePoint et Bootstrap

Heureusement, pour vous éviter de partir de zéro, il existe des fichiers CSS existants sur internet. Toutefois, il est probable que vous ayez à le compléter au fur et à mesure de votre développement.

Étape #3 : Créer les modèles d’affichages

Comme expliqué dans le module #1, nous utilisons les modèles d’affichage pour le rendu du contenu des pages (nouvelles, pages de contenu) ainsi que pour les résultats de la recherche globale du portail. Plusieurs points sont à retenir concernant de l’utilisation de cette fonctionnalité, surtout si votre déploiement se fait de manière automatique.

 Extraction et archivage pour la génération des fichiers *.js à partir des *.html

Lorsque le déploiement de modèles d’affichages se fait de manière programmatique, il est nécessaire de réaliser une extraction (« Check-Out ») puis un archivage (« Check-In ») depuis le code pour déclencher la conversion par SharePoint du fichier .html en JavaScript. Cette opération se fait généralement dans un récepteur d’événements associé à la feature déployant les fichiers .html. En effet, ceux-ci sont toujours déployés avant que le code ne soit exécuté, permettant ainsi de les manipuler à postériori:

Récepteur d'événements pour la génération des fichiers JS des modèles d'affichage

Récepteur d’événements pour la génération des fichiers JS des modèles d’affichage

La méthode GenerateJavaScriptFile(), disponible dans notre Framework Dynamite, implémente la logique d’extraction/archivage servant au déclenchement du mécanisme de génération:

Génération du fichier JavaScript pour un modèle d'affichage par extraction/archivage

Génération du fichier JavaScript pour un modèle d’affichage par extraction/archivage

 Utilisation de Knockout.js en remplacement de la syntaxe par défaut de SharePoint

Pour ceux qui travaillent souvent avec les modèles d’affichages SharePoint, savent que la syntaxe imposée par défaut peut s’avérer parfois frustrante voire même un peu « fouillis » lorsque la complexité augmente.  Ainsi, il n’est pas rare que nous la remplacions par un modèle géré exclusivement en Knockout.js pour obtenir plus de flexibilité. Voici un exemple simplifié de la structure HTML et du code JavaScript associé pour obtenir l’affichage du contenu d’une nouvelle :

  • Exemple de rendu d’une nouvelle dans la page

NewsRendering

  • Structure HTML du modèle d’affichage
  • Code JavaScript associé
Notes :

  • Les « bindings» Knockout.js sont appliqués après le chargement complet du modèle d’affichage via la méthode « AddPostRenderCallback ».
  • Un « binding handler » (imageUrl) personnalisé est créé pour la récupération de l’URL de l’image. La raison est que, par défaut, le contenu d’une propriété gérée de recherche de type « image » renvoie le code HTML final de celle-ci et non URL (<img … />). De manière générale, vous pouvez créer vos propres bindings de la même façon pour encore plus de flexibilité (par exemple pour la détermination du bon redu d’image selon la page).

Étape #4 : Utiliser des librairies JavaScript tierces

Enfin, que cela soit pour ajouter du dynamisme aux interfaces ou bien simplifier la gestion du code JavaScript et HTML, nous utilisons couramment plusieurs librairies tierces dans les projets d’intranet. En voici les principales :

Librairie

Utilisée pour

Exemple

Implémentation du modèle MVVM en JavaScript (Modèle Vue Vue-Modèle) (voir étape précédente).

Utilisé dans :

  • les modèles d’affichages SharePoint en lieu et place de la syntaxe par défaut.
  • les contrôles personnalisés comme les menus de navigation et autres.

La manipulation de l’affichage de dates en JavaScript.

MomentJs

La gestion des ellipses pour les textes longs (comme le résumé d’une nouvelle par exemple).

jQueryDotDotDot

La gestion du comportement (afficher plus/réduire) pour de longs blocs de textes.

ReadmoreJS

Résumé de la thématique

Dans ce neuvième et dernier module, nous avons vu les principaux éléments permettant de personnaliser le design d’un intranet SharePoint 2013 à travers le besoin suivant :

D’un point de vue technique, nous avons :

  • Créé une page maître appropriée au format HTML via le gestionnaire de conception.
  • Utilisé la technique des « delegate controls» pour le chargement dynamique des composants dans la page et créer des composants factices pour donner un aperçu du placement des éléments dans la page.
  • Intégré le Framework Bootstrap pour la gestion de l’affichage mobile en mode responsive avec les breakpoints par défaut pour un affichage sur écrans d’ordinateur, téléphones et tablettes.
  • Créer un fichier CSS séparé pour résoudre les collisions entre les styles SharePoint et Bootstrap.
  • Créé les modèles d’affichages pour le rendu du contenu en forçant un « Check-Out» / « Check-In » dans la feature pour appliquer les modifications.
  • Utilisé js dans les modèles d’affichage SharePoint au lieu de la syntaxe par défaut pour faciliter l’écriture du code et sa maintenance.
  • Utilisé des librairies tierces pour améliorer l’expérience utilisateur.

Cette étude de cas touchant à sa fin, le prochain article en sera la conclusion. Dans celle-ci, nous résumerons toutes les notions clés et les points à retenir pour chacun des modules et ferons une synthèse globale sur l’utilisation de la fonctionnalité de publication intersites dans un intranet SharePoint 2013.

Restez à l’écoute !

Questions fréquemment posées

  • Cette approche est-elle applicable avec SharePoint Online ?

Oui et non. La personnalisation de pages maître n’est plus considérée comme une bonne pratique dans la version Online au motif qu’elle peut « briser » à n’importe quel moment si Microsoft décidait de mettre à jour certains éléments ou changer le fonctionnement. On peut toutefois nuancer ce point :

  1. Étant donné l’orientation de Microsoft sur la partie publication dans Office 365 et les annonces faites au sujet du nouveau « Knowledge Management Portal», il parait peu probable que des modifications arrivent bientôt. On parie même qu’elles n’arriveront jamais et qu’un tout nouvel outil verra le jour à la place.
  2. Même si des modifications arrivaient, il parait, là encore, peu probable qu’elles remettent en question l’intégralité de votre travail.
  3. Quittes à réaliser un design personnalisé pour un intranet, autant s’éloigner de l’expérience « trop classique » des pages maîtres par défaut et sortir un peu des clous. Cela signifie que seules les fonctionnalités vraiment importantes seraient gardées et que le reste serait, de toute façon, du développement personnalisé HTML/CSS/JavaScript en rien lié à SharePoint.

Si toutefois vous ne souhaitez pas prendre de risques, vous devrez alors :

  • Soit créer une application web séparée (MVC ou autre) branchée à SharePoint pour la récupération du contenu. Dans ce cas, difficile de dire ou s’arrêterait la limite et si SharePoint aurait, au final, encore une utilité…
  • Soit faire du design plus « light » avec les autres solutions disponibles (CSS alternatifs, Client Side Rendering, modèles d’affichages).

 

  • Pourquoi n’utilisez-vous pas le mécanisme de packages fourni par le gestionnaire de conception ?

Nous n’utilisons pas à proprement parler de packages de conception au sens SharePoint. Cependant, si l’on observe bien, un package de conception est simplement un WSP généré par SharePoint comprenant des features et autres fichiers pouvant être déployés ailleurs. Au final, nous utilisons nous aussi des packages WSP, à la différence que nous avons le contrôle total sur les éléments le composant.

2 Comments

Add yours

+ Leave a Comment