Activating Office 365 groups is not an option

 I see a lot of different reactions when it comes to Office 365 groups. But there is one thing that unites close from every IT department I know : deactivate it, hide it ! (and pray for users to not get aware of its existence). Caricature ? Maybe

Reasons ?

  • We are not ready
  • We can’t control everything yet
  • We have difficulties matching every tool with a use case
  • We only want users to have the tools we decided they needed

Here is why those arguments are irrelevant in my opinion.

growefficiently-turntocloud

Everything is built upon groups

This is SaaS. Microsoft is deciding (with feedback from users of course) what the future is. And Microsoft decided the future will be built upon groups.

Lots of features have rolled out, some others are rolling out right now. And not only for first release customers. The only way to go back to good old SharePoint Sites : stop Office 365.

We are building technical debt

Technical debt is something we fight a lot as developers. Every problem, every bug that we just hide will come back one day. And it will be far more difficult to fix. We all know what happens when we shut down some work because we have other priorities. We will always have other priorities.

One day we will have to activate it,  whether there is no more ability to stop it or because no tool works without. And it is going to hurt. A lot.

This is the perfect moment to prepare

Features are rolling out, one by one. It is easy to stay tuned, news after news. We still have time. The perfect moment to try it. To get feedback from users. To check which tools we prefer for our usages. To build our adoption strategy. We may be surprised, as users may prefer groups to the big SharePoint template we spent months building.

All the time we spend creating SharePoint branding that will be obsolete in 6 months. All the energy we spend trying to hide O365 features. We could be monitoring usages, communicating, building adoption strategies, building tools to do what groups don’t do.

What’s wrong with giving tools to users ?

Everything that is rolling out now is just a set of extra tools users can have. Why so much hate ? It’s like IT departments want to tell people a list of scenarios with a tool attached to each one. We want to control everything. We are control freaks. There are reasons we build procedures, of course. But sometimes we should let go.

Maybe users know better than us what they need. Maybe they are used to massive tooling in there private life. Maybe they are now using Slack + Dropbox + Trello and have the same features but without you monitoring it. Maybe they just need a go and will be delighted to use those tools. Maybe not. The best way to know is to go for it, and get feedback. Feedback, iterative or lean strategies are not only for startups !

What is the worst case scenario ?

Users creating an important amount of groups, and information is not well organized ? Users creating groups they shouldn’t create ? Users uploading top secret documents in external groups ?

We can have power users with a global vision of the team and responsible for organizing work and data. Those people are already organizing other content in their team.

We can classify groups to remind users about what content should be in each group. We will soon be able to apply policies with each classification.

Users are adults with responsibility on their actions. We don’t block  every action that could be possibility dangerous if maybe someone was doing something very stupid. Or it is not yet the case in my country. We should stop doing that in IT every day, treating users as brainless children.

If you really need to ensure some documents will never ever possibly get out of your company, there are true solutions.

So what now ?

We don’t have to use everything now. We don’t have to love every feature. We don’t have to stop everything we had and migrate to groups. But we have to get used to them. And I think we will finally love using them.

Why and how we started contributing to Patterns & Practices

Our journey with Patterns & Practices

Our journey with Patterns & Practices started when we first saw the project on GitHub, maybe two years ago. We already had our own internal framework so we just checked what this new tool could do for us. It clearly didn’t cover all our use cases, and we would still have to use our own framework.

Then I came to Ignite in 2015, and I saw Vesa Juvonen presenting the provisioning framework. It was like “Damn, it has grown a lot!”. We started using it as nugget package. It was still not covering all our use cases, but we were migrating our code slowly. As a lot of people were using this project, we found PnP functions more tested than ours, and it was great. We still had our framework tho, but it was disappearing.

But we still had issues:
        We couldn’t debug when we had a problem
        We had to wait for fixes, so we copied PnP functions in our framework to fix them for ourselves
        We had to go to GitHub and browse files to understand fully all we could do with this framework

Contributing

And then, we decided to fork the project (we are using PnP-Sites-Core as a fork, as this is the project we use the most). When you know git (and I really recommend reading at least the first three chapters of the git documentation if you are new to it), it is really fast to set up your environment for development.

Our contribution workflow is:

contribution-patterns-practices

1.      We locally clone our fork
2.      When we want to do some changes, we create a branch for this change that we merge to master when it’s ready
3.      We have a dev branch, created from the tracked PnP-Sites-Core dev branch
4.      When we have something interesting to propose we create a branch, get the commits from our master branch and create the pull request

We then just have to regularly get updates from PnP repositories, and reference our fork as a submodule in other projects.

This new approach has some advantages:
        Our whole team has a better understanding of how the project works
        We can debug
        We don’t have to wait for official fixes
        We can add our own code directly into the framework
        It’s exciting to take part of a bigger community 

5 pull requests merged so far, and a 6th waiting 🙂

 

Intégrer Yammer à SharePoint : Yammer Embed et API REST

Yammer offre deux modes pour son intégration aux sites et applications tierces : Yammer Embed ou une API REST. Voici un descriptif des possibilités offertes par chacun.

Yammer embed

Mode simplifié d’ajout de Yammer à un contenu HTML :

  • Un javascript Yammer à référencer
  • Un bloc HTML comme conteneur
  • Une fonction d’appel avec options


<div id="embedded-feed" style="height:800px;width:400px;"></div>

<script type="text/javascript" src="https://assets.yammer.com/assets/platform_embed.js"></script>
<script type="text/javascript"> yam.connect.embedFeed({
container: "#embedded-feed",
network: "mcnext.com",
feedType: "group",
feedId: "2211345"});
</script>

Note : il est possible d’obtenir cela très facilement en l’exportant directement à partir d’un groupe Yammer ou en utilisant l’utilitaire de configuration fourni par Yammer.

Fonctionnalités offertes

Les fonctionnalités offertes sont exactement les mêmes qu’à l’intérieur d’un flux Yammer :

  • Lecture de messages
  • Ecriture de messages avec pièces jointes
  • Like
  • Suivi
  • Partage
  • Réponse
  • Ajout de sujets
  • Se l’envoyer par email

Le rendu est fait dans une iframe dont la hauteur et la largeur sont fixes.

Les options disponibles

  • Réseau auquel se connecter
    Par défaut le réseau actif de l’utilisateur
  • Forcer la connexion au réseau principal de l’utilisateur, même s’il vient de visiter un réseau externe
  • ID du groupe Yammer utilisé par défaut lors de la saisie d’un nouvel élément
  • Texte à afficher dans la zone de saisie avant que l’utilisateur ait commencé à écrire son message
    Post-IntegrerYammer-TexteParDefaut
  • Type de flux :
    • MyFeed = flux de l’utilisateur
    • Group = choix d’un groupe à afficher par ID
    • User = choix d’un utilisateur à afficher par ID
    • Topic = choix d’un sujet à afficher par ID
    • Open Graph = commentaires sur l’élément courant (par exemple une page d’article ou un document). Plusieurs paramètres complémentaires sont disponibles pour permettre de choisir l’élément commenté, les métadonnées associées au poste…
  • Si le composant utilise le SSO

Modification de l’apparence

Le composant sera affiché dans une iframe et peut être sujet à modifications dans le futur : il ne faut pas chercher à modifier son apparence.

Il est néanmoins possible d’indiquer :

  • Si le header doit être affiché (nom du réseau)
    Post-IntegrerYammer-Header
  • Si le footer doit être affiché (option de déconnexion)
    Post-IntegrerYammer-Footer
  • Si le nom du réseau doit être caché dans le header : si le header est affiché, alors il indiquera un message neutre comme « Conversations Yammer » plutôt que d’indiquer le nom du réseau

API REST

Une api REST permet d’intégrer Yammer comme souhaité au sein de n’importe quelle application. L’apparence est alors complètement personnalisable puisque tout est à la charge du développeur.

Une documentation très complète et claire est fournie sur le site de développement Yammer.

Connexion

Il faut :

  1. Enregistrer l’application dans Yammer
  2. S’authentifier en utilisant le bouton Yammer ou en OAuth.

Une ID d’application est nécessaire pour la connexion. Tous les utilisateurs devront accepter l’application.

Limites d’appels

Le nombre de requêtes par utilisateur et par application est limité. Une erreur sera retournée lorsque l’utilisateur dépassera cette limite. La limite est différente selon le type d’élément demandé :

  • Messages = 10 requêtes en 30 secondes
  • Notifications = 10 requêtes en 30 secondes
  • Tous les autres = 10 requêtes en 10 secondes

Possibilités

Voici les différentes possibilités offertes par l’API REST :

Messages

Type de requête Description Commentaires
GET
  Derniers messages Il est possible de récupérer tout le thread ou uniquement le premier message de chacun.

·        Tous

·        Flux de l’utilisateur

·        Top

·        Suivis

·        Envoyés

·        Messags privés

·        Reçus

  Messages d’un thread
  Messages liés à un sujet
POST
  Ecrire un nouveau message ·        Corps du message

·        ID du groupe dans lequel poster

·        ID du message pour la réponse

·        Utilisateur à qui envoyer le message en privé

·        S’il s’agit d’un broadcast

·        Sujets

·        Pièces jointes

·        Objet opengraph associé

  Envoyer une copie d’un message par email à l’utilisateur courant
  Liker un message
DELETE
  Supprimer un message Par ID
  Unliker un message

Corps d’un message

  • Parsed : les URL sont telles quelles, les mentions d’utilisateurs sont mises sous la forme user:id
  • Plain : les URL sont telles quelles, les mentions utilisateurs sont sous la forme « Nom complet »
  • Rich : HTML à afficher, avec les balises <a></a> pour les URL

Propriétés d’un message

  • ID
  • ID de l’utilisateur ayant posté
  • Date de création
  • ID du réseau
  • Type de message
  • Type de sender
  • URL
  • ID du groupe
  • Body
  • ID de thread
  • Type de client (web, app…)
  • ID des utilisateurs notifiés
  • Message privé ou publique
  • Pièces jointes
    • ID
    • Type
    • Nom
    • Description
    • ID du réseau
    • URL
    • URL de la miniature
    • Type d’objet
    • Nom de l’objet
    • URL de l’hôte
    • HTML à afficher
  • LikedBy : nombre + liste des utilisateurs

Utilisateurs

Type de requête Requête Commentaires
GET
  Utilisateurs du réseau Paginée, triée par nombre de messages, nombre de followers ou alphabétiquement
  Utilisateur courant
  Utilisateur par ID
  Utilisateur par email
  Utilisateurs d’un groupe Paginée, triée par nombre de messages, nombre de followers ou alphabétiquement
  Utilisateurs ayant utilisé un sujet
  Utilisateurs ayant liké un message
  Relations pour l’utilisateur courant ou par ID Supérieurs, subordonnés et collègues
POST
  Créer un utilisateur
  Inviter un utilisateur au réseau Yammer actif
  Ajouter une relation
DELETE
  Supprimer un utilisateur
PUT
  Modifier un utilisateur

Propriétés d’un utilisateur

  • Email
  • ID
  • Réseau : ID, Nom, Domaines
  • Etat
  • Activation : Date, auto activé ou non
  • Nom complet
  • URL du profil
  • Image de profil (48×48)
  • Date de naissance
  • S’il est administrateur
  • Statistiques : nombre de followers, nombre de personnes suivies
  • Poste
  • Département
  • Emplacement
  • Téléphone de travail
  • Téléphone mobile
  • Intérêts
  • Résumé
  • Expertise
  • Diplômes
  • Entreprises précédentes

Groupes

Type de requête Requête Commentaires
GET
  Groupes suggérés
POST
  Rejoindre un groupe
DELETE
  Quitter un groupe
  Supprimer une suggestion de groupe

Suivi

Type de requête Requête Commentaires
GET
  Utilisateurs suggérés pour le suivi
  Vérifier si on suit un utilisateur
  Vérifier si on suit un thread
  Vérifier si on suit un sujet
  S’abonner à un élément
DELETE
  Se désabonner d’un élément
  Supprimer une suggestion d’utilisateur à suivre

Autres

Type de requête Requête Commentaires
GET
  Notifications de l’utilisateur courant
  Recherche Faire des requêtes de recherche, comme dans le portail Yammer
  Liste des réseaux auxquels l’utilisateur a accès