Module #8: La recherche

Module #8: La recherche



Considérée comme LA fonctionnalité par excellence d’un intranet d’entreprise, la recherche n’en demeure pas moins sa fonctionnalité la plus généralement critiquée (et qui au passage nuit, à tort, à l’image de SharePoint). En effet, combien de fois avons-nous entendu cette fameuse phrase :

on ne trouve rien dans ce portail

un utilisateur en colère

Alors la faute à qui ? À SharePoint qui n’est pas assez bon pour trouver l’information ? Pas vraiment en réalité…

  • Qu’entend-on par « recherche » ?

Avant toute chose, on définira la fonctionnalité de recherche par le fait de spécifier explicitement un ou plusieurs mots clés via un composant dédié (une boîte de recherche) dans le but d’obtenir des contenus correspondants. La fonctionnalité de recherche implique donc une action manuelle de l’utilisateur.

  • La recherche : un complément à l’architecture d’information du portail

Disposer d’une recherche performante dans SharePoint se fait nécessairement au prix d’une architecture d’information adaptée. Pour être plus concret, plus les contenus seront bien catégorisés, classés ou taggués, plus il sera alors facile de les retrouver. Un trop grand investissement dans un moteur de recherche d’entreprise dénote bien souvent des lacunes dans l’organisation des contenus du portail lui-même. La recherche est donc là pour les « compenser ».

De notre point de vue, l’utilisation de la recherche devrait être en réalité modérée par rapport aux autres fonctionnalités du portail et notamment le parcours du contenu via les menus de navigation. Par exemple, lors de la réalisation de nos projets, nous n’implémentons jamais la fonctionnalité de recherche avancée. Pourquoi ? Car elle supposerait d’emblée que d’une part, la recherche « plein texte » ne serait pas capable de renvoyer des résultats satisfaisants et que d’autre part, l’information ne serait pas accessible autrement dans le portail. La recherche doit donc être vu comme un moyen complémentaire d’accès au contenu et non celui principal.

  • Un changement de paradigme en cours

Depuis sa création, la fonctionnalité de recherche de SharePoint impose à la fois la définition de données structurées (les sacrosaintes métadonnées traduites par le couple type de contenus + colonnes) et une configuration du moteur de recherche adaptée (le schéma de recherche avec les propriétés gérées et le langage KQL permettant de les manipuler).

Cependant, ce modèle à une faille : pour être réellement efficace, il impose que ces fameuses métadonnées soient renseignées en amont (de manière automatique ou manuelle) et que, à un moment donné, il faille prendre en compte la variable « utilisateur » et penser à l’expérience de création du contenu. Pensez-vous que forcer les utilisateurs à remplir une cinquantaine d’informations supplémentaires (j’exagère à peine) en plus de leur contenu initial pour permettre une recherche efficace encouragera leur utilisation du portail ? Évidemment non…

C’est donc un fait : bien que nécessaire, remplir des métadonnées c’est rébarbatif, peu importe la justification que vous pourrez leur donner…

Cette réaction quasi « pathogène » face aux métadonnées, source de frustration et assimilée à de la perte de temps, les nouveaux outils du marché eux, l’ont bien compris. L’heure n’est donc plus à leur définition explicite sur les contenus, mais à la recherche « intelligente ». En d’autres termes le modèle « traditionnel » laisse place à davantage de données non structurées (ou structurées de manière automatique et transparente pour l’utilisateur) et des outils de recherche superpuissants qui comblent ce manque de structure via des algorithmes de plus en plus complexes. « Delve » et « OneDrive for Business » dans Office 365 en sont les parfaits exemples. Bien que le premier soit basé sur SharePoint, voyez-vous l’once d’un système de métadonnées structurées dans la fonctionnalité « OneDrive for Business » ou même votre « OneDrive » personnel (cela n’apparait pourtant clairement pas comme un challenge technique) ?

Bonne ou mauvaise chose, la question n’est pas là. Il faut simplement garder à l’esprit que tant que vous travaillerez avec SharePoint (plus pour longtemps encore ?) il faudra respecter « l‘ancienne » façon de faire et que la classification des informations sera principalement à la charge de vos utilisateurs et que la configuration du moteur de recherche devra être faite en conséquence. L’enjeu est donc de trouver le meilleur compromis entre l’efficacité de la recherche et l’expérience de création des contenus tout en mitigeant l’effort investi.

Qu’on se le dise, le moteur de recherche de SharePoint ne sera jamais équivalent à celui de Google Bing. Néanmoins, avec un minimum de configuration et une structure de portail pertinente, il peut s’avérer largement suffisant pour la plupart des besoins des utilisateurs. Tout est une question de stratégie.

Rôles concernés et responsabilités

Voici les besoins que nous allons traiter dans ce module :

Qui?

Quoi?

Notion(s) clé(s)

Utilisateur

[SEARCH_01] Rechercher du contenu

  • Secteurs verticaux de recherche
  • Source de résultats de recherche
  • Panneau d’affinements de recherche et résultats de recherche
  • Règles de requêtes
  • Types de résultats
  • Navigation par facettes
  • Boîte de recherche

La recherche dans SharePoint

La recherche dans SharePoint a énormément évolué depuis l’arrivée de SharePoint 2013 notamment avec l’intégration native de FAST. Outre les composantes historiques qui forment cette fonctionnalité (Web Parts, mécanismes du schéma de recherche, etc.), plusieurs aspects importants sont à considérer lors de sa mise en place dans un portail d’entreprise.

La recherche « plein texte »

Type de recherche le plus couramment utilisé, la recherche « plein texte » se fait sur la base de mots clés tapés par les utilisateurs et mis en correspondance avec des données contenues dans un index. En effet, dans la pratique, il est très rare que les utilisateurs du portail utilisent la syntaxe de requête fournie par le langage KQL pour améliorer leur recherche (à titre de comparaison, bien qu’étant disponible, le faîte vous dans Google Bing ?). La configuration des propriétés gérées de recherche et leur comportement vis-à-vis de la recherche « plein texte » en devient donc d’autant plus importante car sollicitée constamment.

Dans le schéma de recherche de SharePoint, il est possible de rendre disponible la valeur d’une propriété gérée (et donc la valeur qui a été spécifiée dans la colonne SharePoint originale) pour une recherche de ce type. Par exemple, les propriétés par défaut « Titre » et « Corps » sont configurées de cette manière via le paramètre « Searchable ».

Mise à disposition de la valeur d’une propriété gérée dans l'index pour une recherche plein texte

Mise à disposition de la valeur d’une propriété gérée dans l’index pour une recherche plein texte

Chaque propriété peut être associée à un index spécifique. Dans SharePoint, il en existe plusieurs types :

  • L’index de recherche par défaut (disponible sous les noms Default, FullTextIndex1, FullTextIndex2 et FullTextIndex3) qui regroupe la grande majorité des propriétés du schéma global. À noter que toutes les nouvelles propriétés gérées créées par SharePoint sont configurées avec cet index.
  • Un index PeopleIdx, dédié aux valeurs des propriétés gérées issues du profil des utilisateurs. Cet index devra notamment être choisi pour celles ayant été marquées comme indexable :
Propriété de profil indexable

Propriété de profil indexable

  • Un index spécifique aux termes Pour ce dernier, nous ignorons son utilité réelle étant donné que les propriétés gérées de la forme owstaxId… n’y résident même pas. De toute façon, cela paraît peu probable que vous ayez à l’utiliser (très peu de documentation disponible).
Détermination de l'index pour une propriété digérée de recherche

Détermination de l’index pour une propriété digérée de recherche

Dans le cas d’un portail, toutes les propriétés ne doivent pas nécessairement être accessibles en recherche « plein texte ». Privilégiez celles contenant une ou plusieurs lignes de texte ou des termes de taxonomie pertinents.

Le classement des résultats

Pour améliorer la pertinence d’une recherche, il peut être intéressant de classer les résultats selon un ordre précis. Pour cela plusieurs moyens peuvent être utilisés :

Spécifier un modèle de classement de résultats spécifique

Par défaut, SharePoint dispose de plusieurs modèles pour le classement des résultats de recherche. Chaque requête de recherche est soumise obligatoirement à un modèle à en particulier. La liste exhaustive est récupérable en utilisant les commandes PowerShell suivantes :

Liste des modèles de classement de SharePoint par défaut

Liste des modèles de classement de SharePoint par défaut

Le choix d’un modèle peut se faire directement à partir de l’assistant de requête dans les paramètres de tri. Il suffit pour cela d’utiliser la propriété « Rank » puis de choisir le modèle approprié :

Choix d'un modèle de classement pour une requête

Choix d’un modèle de classement pour une requête

Ainsi, on utilisera plutôt un modèle de classement adapté aux personnes pour une recherche dans le bottin et le modèle par défaut pour les autres contenus. Notez que, bien qu’étant possible, il est très rare pour une solution d’intranet d’avoir à créer un modèle de classement personnalisé. Ceux par défaut, combinés à d’autres méthodes, suffisent largement.

  • Visualisation de l’effet d’un modèle sur un contenu

Pour vous aider à choisir le bon modèle, il est possible de visualiser le détail du calcul du classement pour un élément en particulier selon un modèle spécifique grâce à la page ExplainRank.aspx accessible via l’URL suivante :

http://<searchCenter>/_layouts/15/ExplainRank.aspx?q={searchquery}&d={documentpath}&rm={modelID}

Détail du calcul de classement pour un élément selon un modèle

Détail du calcul de classement pour un élément selon un modèle

Utiliser l’opérateur XRANK

En complément du modèle de classement utilisé pour une requête, il est possible d’utiliser l’opérateur XRANK disponible dans le langage KQL. Cet opérateur permet arbitrairement de promouvoir ou au contraire de réduire l’importance d’un contenu répondant à une ou plusieurs conditions (par exemple privilégier les nouvelles avant les pages de contenu, etc.).

Utilisation de l'opérateur XRANK

Utilisation de l’opérateur XRANK

À noter que des conditions XRANK peuvent être imbriquées entre elles et que très souvent, seul le paramètre « constant boost (cb) » sera suffisant pour classer les résultats. Par exemple pour favoriser les nouvelles par rapport aux pages de contenu et les petites annonces, on utilisera la requête suivante (notez les parenthèses pour indiquer la précédence) :

((({SearchBoxQuery})
XRANK(cb=5000) « ContentTypeId:0x01008093F9E3678D3D4392C57B0E6929DE0501010201* »)
XRANK(cb=3000) « ContentTypeId:0x01008093F9E3678D3D4392C57B0E6929DE0501010101* »)
XRANK(cb=1000) « ContentTypeId:0x010100FFB027F3142B4A64B952979C78C23336* »

Spécifier un contexte de poids au niveau des propriétés gérées

En plus de pouvoir spécifier l’index d’une propriété de recherche, il est également possible de contrôler son classement dans les résultats au regard d’une recherche. Celui-ci se fait à travers un contexte auquel est associé un poids dont la valeur est déterminée arbitrairement par un modèle de classement SharePoint. Chaque type d’index est divisé en plusieurs contextes.

Contexte d’une propriété gérée

Poids de classement du modèle par défaut associés aux contextes de propriétés de recherche

Poids de classement du modèle par défaut associés aux contextes de propriétés de recherche

Attention, la valeur de ce poids dépendra du modèle de classement utilisé pour la recherche (voir le XML associé à chaque modèle pour connaître le poids associé à chacune des propriétés).

Les secteurs verticaux de recherche

Si vous observez la plupart des moteurs de recherche grand public, vous remarquerez qu’il est possible de rechercher dans des catégories de contenus spécifiques (images, vidéos, etc.). On appelle ces catégories des « secteurs verticaux de recherche ». Ils ont pour but de segmenter les résultats par type d’information pour d’une part, orienter plus facilement les utilisateurs, mais aussi alléger l’expérience de recherche globale en évitant de mélanger tous les contenus ensemble.

VerticalsGoogle

Catégories de recherche dans les moteurs de recherche grand public

Catégories de recherche dans les moteurs de recherche grand public

Cette fonctionnalité existe également en SharePoint 2013 et porte le nom de « navigation par la recherche », configurable dans les paramètres de recherche d’un site :

Définition des secteurs verticaux de recherche

Définition des secteurs verticaux de recherche

SearchNavigationLinkAdd

Chaque secteur est représenté par un lien vers une page de recherche physique. Cette page doit être configurée manuellement avec des Web Parts de recherche et une source de résultats correspondant à la catégorie naviguée. Les paramètres de navigation par la recherche peuvent ensuite être exploités à la fois via la boîte de recherche et par un Web Part du même nom que la fonctionnalité :

Utilisation de la navigation par la recherche avec la boite de recherche

Utilisation de la navigation par la recherche avec la boite de recherche

SearchBoxVerticalsConfig

Composant Web Part de navigation par la recherche

Composant Web Part de navigation par la recherche

SearchNavigationWPGallery

 Notes :

  • Les mots clés de recherche sont conservés entre le changement de catégorie (peu importe le Web Part).
  • La navigation par la recherche ne supporte pas les URL conviviales. Si vous spécifiez une page physique soumise à une URL de ce type, la catégorie de sera tout simplement pas cliquable dans le composant (mais sera tout de même affichée).
  • Le composant Web Part de navigation par la recherche ne supporte pas les mécanismes de modèles d’affichages pour la personnalisation graphique. La personnalisation devra se faire par CSS.

[SEARCH_01] Utilisateur : Rechercher du contenu

Permets à un utilisateur du portail de rechercher du contenu dans l’intranet.

La recherche peut se faire sur le contenu web (pages, nouvelles) les documents ou les personnes.

#

Étape

1

Créer les catégories de recherche

2

Créer les sources de résultats de recherche

3

Configurer les Web Parts de la page de recherche et les pages pilotées par les termes

4

Créer les règles de requête

5

Créer les types de résultats et les modèles d’affichages

6

Configurer la navigation par facettes et le Web Part d’affinement de recherche

7

Créer le contrôle de boîte de recherche

Stratégie d’implémentation de la recherche

Pour bien comprendre la stratégie de recherche que nous allons expliquer, voici le schéma global de la configuration et le numéro des étapes qui sera détaillé dans ce besoin :

Stratégie d'implémentation de la recherche dans le portail

Stratégie d’implémentation de la recherche dans le portail

Critères d’acceptation

Voici les critères d’acceptation qui permettent de valider les objectifs du besoin [SEARCH_01] Utilisateur : Rechercher du contenu

#

Description

AC0

La recherche peut se faire sur les contenus web (pages de contenu et nouvelles), les documents et les personnes.

AC1

Les paramètres de période de publication à la minute sont pris en compte dans les résultats.

AC2

Il est possible d’affiner une recherche.

AC3

Les mots clés de recherche sont conservés entre les catégories.

Étape 1 : Créer les catégories de recherche

Nous avons choisi de diviser la recherche dans l’intranet en trois catégories distinctes (i.e. secteurs verticaux de recherche) :

  1. Le contenu « web » de l’intranet comme les nouvelles ou les pages de contenu (et tout autre contenu provenant de listes SharePoint).
  2. Les documents provenant du centre documentaire.
  3. Les personnes dans l’annuaire de l’entreprise.
Recherche de personnes

Recherche de personnes

Recherche de contenu web

Recherche de contenu web

La raison technique de cette segmentation est de permettre l’utilisation de requêtes de recherche différentes en fonction du type de contenu recherché. Par exemple, il n’est pas pertinent d’appliquer du ciblage de contenu sur des personnes ou même de les filtrer par date de publication, tout simplement car elles ne possèdent pas ces métadonnées.

Les catégories sont traduites en termes de taxonomie dans l’arbre de classification global du portail et redirigent sur les URL conviviales suivantes :

Ajout des catégories de recherche sous forme de termes de taxonomie

Ajout des catégories de recherche sous forme de termes de taxonomie

Comme mentionné plus haut dans ce module, les secteurs verticaux de recherche par défaut de SharePoint ne prennent pas en compte les pages possédant des URL conviviales. De plus, leur composant Web Part associé n’est pas très flexible au niveau de la personnalisation de l’affichage. C’est pourquoi nous avons implémenté notre propre composant, sur le même principe que les autres menus de navigation du site (cf. Module #2 : La navigation). Nous en avons également profité pour calculer les nombres de résultats approximatifs pour chacune des catégories pour améliorer l’expérience utilisateur (Knockout.js + Search REST API) :

Composant de catégories de recherche personnalisé

Composant de catégories de recherche personnalisé

Étape 2 : Créer les sources de résultats

Pour récupérer les résultats de ces trois catégories, nous créons les sources de résultats suivantes avec les requêtes correspondantes. A noter que pour le contenu web et les documents, le ciblage de contenu s’applique (cf. Module #7 : Le ciblage de contenu).

Source de résultats

Requête de recherche

Search – Intranet

Récupération de tout le contenu web de l’intranet (nouvelles et pages de contenu).

Search – Documents

Récupération du contenu du centre documentaire.

Local People Results

Récupération des personnes de l’annuaire d’entreprise

Plusieurs choses à noter ici :

  • Pour filtrer sur le type de contenu (nouvelle, page de contenu ou document) nous utilisons la propriété gérée de recherche ContentTypeId :0x….*
  • Pour la recherche, nous réutilisons la source de résultats par défaut de SharePoint « Local People Results».
  • Les autres éléments SharePoint sont retirés pour ne pas polluer les résultats.
  • On utilise la variable {searchTerms} et non {searchBoxQuery} pour récupérer les mots clés entrés par l’utilisateur. Cette dernière correspond à la requête après toutes les transformations (règles de requêtes ou autre).

Étape 3 : Configurer les Web Parts de la page de recherche et les pages pilotées par les termes

Pour permettre un affichage des résultats, nous créons un modèle de page (SearchTemplate.aspx) qui sert pour l’affichage des résultats pour les trois catégories*. La page est composée d’un Web Part d’affinement de recherche ainsi qu’un Web Part de résultats de recherche (pour bénéficier du support de la fonctionnalité de types de résultats).

Ajout des Web Parts à la page de recherche globale « SearchTemplate.aspx »

Ajout des Web Parts à la page de recherche globale « SearchTemplate.aspx »

Comme les 3 catégories utilisent la même page pour la présentation de leurs résultats, la configuration des pages pilotées par les termes se fait de la manière suivante (via le principe d’héritage) :

Configuration des pages pilotées par les termes pour les catégories de navigation

Configuration des pages pilotées par les termes pour les catégories de navigation

Par défaut, nous définissons la source de résultats « Search – Intranet » pour le Web Part de résultats de la page de recherche. Par ce moyen et selon la configuration des pages pilotées par les termes, l’utilisateur verra par défaut les résultats pour l’intranet pour les URL /search et /search/intranet). Les sources de résultats pour les deux autres catégories (/search/documents et /search/people) seront déterminées par des règles de requêtes.

*Note importante 

Pour cette étape, deux scénarios sont en réalité possibles. Rappelez-vous, dans le Module #5 : Le cycle de vie, nous avons vu que le filtrage des contenus à la minute près sur les dates via la recherche et le langage KQL n’était pas supporté par défaut. Pour mitiger ce point, nous avons donc implémenté une solution de contournement utilisant un Web Part personnalisé. Le problème avec cette solution est que le filtrage subséquent s’applique en tout temps et ceci peu importe la requête originale. Par conséquent, si vous utilisez ce principe, vous serez obligés de créer des modèles de pages séparés pour les contenus ayant cette condition (par exemple, dans notre cas, le filtrage de date pour les documents et les personnes ne renverrait aucun résultat car ces contenus ne possèdent pas ces métadonnées). Si vous n’êtes pas dans ce cas, une unique page est suffisante pour l’affichage des résultats de toutes les catégories.

Étape 4 : Créer les règles de requête

Le principal intérêt d’utiliser des règles de requêtes pour la recherche dans le site est la possibilité de limiter la gestion des résultats à un seul modèle de page pour plusieurs catégories de recherche sans avoir à dupliquer une page physique pour chacune (avec des configurations embarquées directement dans les Web Parts). L’idée est donc d’adapter automatiquement les résultats en fonction de l’URL naviguée sans changer de page physique.

Étant donné que la source de résultats par défaut pour la page SearchTemplate.aspx est « Search – Intranet », celle-ci va servir de contexte pour le déclenchement des règles :

QueryRulesLink

Création des règles de requêtes à partir de la source de résultat par défaut du modèle de la page de recherche

Création des règles de requêtes à partir de la source de résultat par défaut du modèle de la page de recherche

Chacune des règles de requêtes se configure de la manière suivante :

  • Déterminer un nom de règle explicite
  • Spécifier la catégorie sur laquelle la règle doit s’appliquer. Ici la catégorie représente le terme de taxonomie utilisée pour la navigation.
  • Supprimer la condition par défaut car seule la catégorie sera utilisée pour déclencher la règle.
  • Changer la requête en spécifiant la nouvelle source de résultats à utiliser tout en gardant les mots clés de recherche existants.
Configuration des règles de requêtes pour les catégories de recherche

Configuration des règles de requêtes pour les catégories de recherche

Règle de requête

Catégorie

Source de résultats

Search documents

/search/documents

Search – Documents

Search people

/seach/people

Local People Results

Étape 5 : Créer les types de résultats et les modèles d’affichages

Comme énoncé dans le tout premier module, les types de résultats permettent de spécifier un modèle d’affichage dynamiquement en fonction d’une ou plusieurs conditions. Ainsi l’affichage des résultats sera différent pour chaque type d’information selon la catégorie :

  • Personne

PeopleDisplayTemplate

PeopleResultType

  • Document

DocumentDisplayTemplate

DocumentResultType

  • Contenu web de l’intranet (ici, exemple avec une nouvelle)

NewsDisplayTemplate

NewsResultType

Étape 6 : Configurer la navigation par facettes et le Web Part d’affinement de recherche

La navigation par facettes permet de proposer des filtres d’affinements contextuellement à la catégorie naviguée et ainsi de s’affranchir de les renseigner directement dans le Web part associé. Ce fonctionnement laisse ainsi la possibilité d’avoir une page générique de recherche s’adaptant au contexte de navigation de la même manière que les types de résultats ou les règles de requêtes. La configuration des paramètres de navigation par facettes se fait depuis les paramètres du magasin de termes accessible depuis la collection de sites (et non depuis l’application de service).

Configuration de la navigation par facettes depuis les paramètres de la collection de sites

Configuration de la navigation par facettes depuis les paramètres de la collection de sites

Prise en compte des paramètres de la navigation par facettes dans le Web Part d'affinement de recherche

Prise en compte des paramètres de la navigation par facettes dans le Web Part d’affinement de recherche

Pour les catégories « Intranet » et « Document », nous avons défini les filtres suivants pour la configuration de la navigation par facettes dans la recherche du portail (pour information, la recherche de personne ne devait pas permettre de filtres) :

  • Le type de contenu (information fournie par SharePoint via la propriété gérée SPContentType).
  • La catégorie (colonne de taxonomie « Navigation »).
  • L’emplacement (pas important dans ce cas d’étude).

CategoriesTax

Configuration des affinements pour la navigation par facettes

Configuration des affinements pour la navigation par facettes

L’expérience de filtrage se fait de la manière suivante :

Stratégie de filtres d'affinement de recherche

Stratégie de filtres d’affinement de recherche

  1. L’utilisateur sélectionne une catégorie de recherche
  2. Parmi les résultats trouvés, il peut filtrer selon le type de contenu au sens SharePoint (ici nouvelles ou page de contenu)
  3. Selon le type de contenu choisi, un deuxième niveau de filtrage apparaît dynamiquement.

Cette stratégie de filtres n’est pas anodine. Elle solutionne une problématique induite par le mécanisme de classification du contenu lui-même (cf. Module #1 : La publication). Pour rappel, tous les contenus du portail partagent la même et unique colonne pour leur catégorisation (la colonne « Navigation ») pouvant amener à ce genre de cas :

Titre de l’élément

« Ma nouvelle locale »

« Notre histoire »

Valeur de la colonne « Navigation »

« Nouvelle locale »

« Notre histoire »

Type de contenu

Nouvelle

Page de contenu

Les pages de contenu sont toujours associées à un unique terme taxonomie dans l’arbre de classification global correspondant bien souvent à leur titre dans les menus de navigation tandis que les nouvelles utilisent cette valeur pour préciser leur catégorie dans le catalogue correspondant. Si nous souhaitons proposer un filtre basé sur cette colonne, plusieurs problématiques se posent alors :

  •  Problématique #1 : La pollution des affinements de recherche par les pages de contenus

Dans ce cas précis, la valeur de la propriété « Navigation » serait pertinente pour le filtrage subséquent d’une nouvelle ayant répondue à un mot clé (nouvelle locale, corporative, etc.), mais ne le serait en aucun cas pour une page de contenu (car celle-ci est accessible directement depuis les menus de navigation). Pire, les filtres issus de cette dernière viendraient encombrer inutilement les affinements disponibles. En effet, les affinements de recherche sont extraits des résultats de la requête, ce qui signifie que si des pages de contenus se trouvaient dans les résultats (ce qui peut sembler assez probable), leur « catégorie » serait proposée automatiquement en tant qu’affinement. Cependant, cela demeurerait inutile car de toute façon, il n’exxiste qu’une seule page pour ce terme…

  •  Problématique #2 : Introduction d’une ambiguïté dans les relations entre les filtres

Conséquence directe du partage commun de la colonne de classification, les filtres d’affinements proposés ne mettraient pas en évidence les relations entre les filtres. Par exemple, avec le comportement par défaut du panneau de raffinement, il serait difficile de savoir si le filtre fait partie d’un type de contenu en particulier :

Ambiguïté entre les filtres introduite par le comportement de base du panneau d’affinements

Ambiguïté entre les filtres introduite par le comportement de base du panneau d’affinements

Nous avons donc réalisé notre propre modèle d’affichage pour le panneau d’affinements pour ajouter un comportement « conditionnel » au mécanisme de filtrage dans le but d’améliorer l’expérience utilisateur et lever toutes ces problématiques.

Étape 7 : Créer le contrôle de boîte de recherche

Considérant la recherche comme une fonctionnalité transversale du portail, la boîte de saisie de mots clés est directement intégrée à la page maître pour être accessible en tout temps. Nous utilisons le Web Part par défaut de SharePoint et un modèle d’affichage personnalisé. L’URL de la page de recherche est déterminée dynamiquement par JavaScript via le menu des catégories :

Implémentation de la boîte de recherche

Implémentation de la boîte de recherche

Les mots clés de recherche sont ensuite transmis (de manière encodée) via le paramètre « k » de l’URL pour être interprétés par le Web Part de résultats de recherche.

Résumé de la thématique

Dans ce huitième module, nous avons vu comment mettre en place une stratégie recherche adaptée à l’architecture d’information vue dans les précédents modules via le besoin suivant :

  • [SEARCH_01] Contributeur : Rechercher du contenu

D’un point de vue technique, nous avons :

  • Créé des catégories de recherche en utilisant des termes de taxonomie.
  • Créé une page modèle de recherche avec des Web Parts génériques.
  • Créé des règles de requêtes pour adapter les résultats en fonction de la catégorie.
  • Créé les modèles d’affichages et des types de résultats pour distinguer les résultats pour chaque catégorie.
  • Configuré la navigation par facettes et adapté la stratégie de filtrage aux problématiques induites par la classification de contenu.
  • Intégré la boîte de recherche directement à la page maître pour une utilisation transversale de la fonctionnalité.

Dans le prochain (et dernier!) module (#9) de cette série, nous verrons comment gérer les problématiques de design et d’identité visuelle dans un intranet.

Restez à l’écoute!

Questions fréquemment posées

  • Suis-je obligé d’utiliser des règles de requêtes pour les catégories de recherche ?

Non. Une stratégie utilisant des pages de recherche séparées configurées adéquatement est tout à fait viable. L’avantage des règles de requêtes est qu’elles permettent de faciliter la maintenance en limitant la recherche à une seule page.

  • Pourquoi n’implémentez-vous pas de recherche avancée ?

Nous voyons la recherche avancée comme la traduction d’une approche défaitiste concernant l’accès au contenu. Si les utilisateurs y ont recours, ce que probablement la structure du portail n’est pas/plus adaptée. De plus, cette fonctionnalité tend à disparaître. Il n’y a qu’à regarder du côté des moteurs de recherche grand public. Le gain par rapport au coût reste donc discutable.

  • Qu’en est-il des pages d’archives comme « Toutes les nouvelles » ou « Toutes les petites annonces » et celle de la recherche ? N’est-ce pas un peu redondant comme principe (moyennant l’utilisation boîte de recherche) ?

Totalement. Dans notre portail, la notion d’archive utilise en réalité l’interface de recherche préfiltrée selon le bon type (nouvelles, annonces). En effet, pourquoi faire deux interfaces séparées alors que la seule différence réside dans l’utilisation de la boite de recherche ? Dans cette approche, l’intégration de ce composant dans la page maître prend ainsi tout son sens permettant ainsi de pouvoir réutiliser le modèle de page de recherche à la fois pour les archives de tout type et la recherche globale du portail. Cependant, l’approche expliquée dans le module #1 (token de recherche GPP) reste entièrement valide.

 

+ There are no comments

Add yours