Question

Ok, j'ai vu quelques messages qui mention quelques autres articles sur la non-utilisation des wikis SP parce qu'ils sont nuls.

Puisque nous envisageons de créer notre wiki dans SP, j'ai besoin de savoir pourquoi nous ne devrions pas le faire pour qu'un groupe de 6 développeurs d'automatisation documente les étapes de divers processus automatisés et les modifications qui doivent être apportées de temps en temps.

Était-ce utile?

La solution 10

Avant le discours, voici mon expérience globale avec SharePoint en tant que wiki.

Il s'agit d'une fonctionnalité mal implémentée qui a échoué en raison d'un manque fondamental d'enquête sur ce que fournissent les environnements wiki actuels.C'est pourquoi il a échoué dans son éditeur et pourquoi il manque des points comme :balisage, comparaison de l'historique et code HTML mal généré.

Vous devez l'ignorer et obtenir quelque chose d'autre qui fait mieux le travail et y créer un lien depuis SharePoint.

Ayant production expérience avec les deux produits, je recommanderais ScrewTurn plutôt que SharePoint.

voir l'historique des modifications pour la diatribe

Autres conseils

Voici quelques mises en garde que j'ai rencontrées et qui disparaîtront si vous utilisez un wiki autre que Sharepoint.

Sharepoint vous permet de créer des tonnes de wikis distincts, mais je recommanderais d'avoir un grand wiki pour tout.Mon entreprise a créé un tas de petits wikis pour chaque projet/fonctionnalité, mais seuls les administrateurs peuvent créer des wikis individuels, donc si je veux écrire sur quelque chose qui ne correspond pas à l'une des catégories prédéfinies, je dois trouver un gestionnaire pour créer le wiki en premier.

Deuxièmement, si vous utilisez Sharepoint, assurez-vous que tous les membres de votre équipe utilisent uniquement IE, car Firefox ne prend pas en charge l'éditeur WYSIWIG.C'est un bien chose pour la plupart des wikis, mais rend la collaboration difficile dans Sharepoint.Imaginez éditer du HTML généré automatiquement dans une toute petite boîte toute la journée.

Troisièmement, essayez de rédiger la documentation de votre projet dans le wiki et résistez à la tentation de télécharger des documents Word dans la bibliothèque Sharepoint.Inutile de rédiger deux fois tous vos documents et de voir les choses se désynchroniser de plus en plus.

Enfin, la prise en charge des images dans les wikis Sharepoint est terrible.Vous devez ajouter un fichier à une bibliothèque de documents quelque part et saisir l'URL.Mes images étaient supprimées à jamais parce qu'elles ne semblaient pas avoir beaucoup de sens hors de leur contexte.

J'ai une vision beaucoup plus positive du wiki Sharepoint de Microsoft.À bien des égards, cela me rappelle FrontPage 98 – et c'était un produit injustement décrié.

Le commentaire sur l’utilisation d’une liste est erroné.Les wikis Sharepoint SONT des listes Sharepoint, dans lesquelles chaque page est un élément de liste avec une pièce jointe HTML.

C'est vrai qu'on ne peut pas créer de lien vers une page, mais si les pages sont courtes, je ne vois pas cela comme un problème.SP Wiki permet d'avoir très facilement des pages courtes.

Vous pouvez manipuler les attributs du wiki depuis Access 2008 si vous le souhaitez, et vous pouvez ajouter des attributs aux éléments de la liste wiki comme vous le souhaitez.Par exemple : voulez-vous des catégories ?Ajoutez-les simplement en modifiant la liste.Vous voulez des vues spécifiques ?des éléments de la liste.Créez-les aussi.

Il y a un véritable génie dans la façon dont Microsoft a construit son cadre Wiki au-dessus des listes Sharepoint – qui sont indéniablement bien faites.

Le VRAI inconvénient de Sharepoint Wiki a été mentionné par farmerchris.L’approche de la gestion des images est étonnamment horrible.C'est un problème tellement grave que vous devriez envisager d'autres wikis pour cette seule raison.

Il existe une solution de contournement compliquée que j'utilise.Il profite de la superbe prise en charge de Sharepoint et de l'édition d'images intégrée à Windows Live Writer.

  1. Créez un blog SP qui contiendra les images qui seront référencées dans le wiki.
  2. Utilisez Windows Live Writer pour publier sur le blog wiki-image.Déposez votre image dans WLW, redimensionnez-la si nécessaire, etc.Si vous le souhaitez, utilisez WLW pour rédiger également le premier brouillon du texte wiki associé à votre image.
  3. Après avoir publié sur le Wiki, copiez et collez l'image et le texte dans le champ de texte enrichi de l'éditeur Wiki.

Cela prend étonnamment peu de temps, bien moins que toute autre option dont j'ai entendu parler.J'avoue, c'est alambiqué.

Hormis les problèmes d'image, je suis satisfait et impressionné par le produit.Si seulement Microsoft avait réfléchi davantage aux images...si seulement ...

Le wiki par défaut inclus avec Sharepoint ne prend pas du tout en charge les fonctionnalités wiki courantes.Il n'existe aucun moyen de modifier une seule section d'une page, ni aucun moyen de créer un lien direct vers une section particulière d'une autre page.Le backend est en HTML, vous perdez donc la possibilité de modifier en texte brut en utilisant une syntaxe simple.La fonctionnalité de comparaison ne peut pas s'étendre sur plusieurs versions.Mauvaise prise en charge multi-navigateurs de l'édition WYSIWYG.Pas moyen d'insérer automatiquement une table des matières...

Il existe cependant d'autres compléments wiki pour Sharepoint que je ne peux pas rejeter catégoriquement, par exemple Confluence fait un complément pour Sharepoint.Je n'ai pas évalué ce logiciel moi-même, et Confluence est un peu cher (1 200 $ pour une licence pour 25 utilisateurs), mais si vous êtes déjà sur Sharepoint, je sens que les coffres de l'entreprise sont importants :P.Il semble également y avoir des compléments gratuits comme Wiki amélioré de CKS mais cela semble avoir beaucoup des mêmes problèmes mentionnés ci-dessus.

Nous tombons sur ce sujet tous le temps, et la première question que j'ai pris l'habitude de poser aux gens est "Pourquoi avez-vous besoin d'un wiki" ?Presque toujours, les réponses sont "facilité d'édition", "contributeurs multiples" et "Word est trop lourd". Très Nous avons rarement vu quelqu'un demander ce que je considère comme des fonctionnalités uniques de type wiki (balisage "magique" spécial, historique des versions à granularité fine montrant les modifications, etc.).En outre, ils souhaitent généralement une sorte de catégorisation des éléments, et pas seulement des pages de forme totalement libre.

Dans le monde SharePoint, ces éléments devraient vous crier « liste » si vous travaillez avec l'outil depuis un certain temps.Il n'y a fondamentalement aucune raison particulière d'utiliser un wiki pour ces applications de type base de connaissances, d'autant plus que la « facilité d'édition » entre généralement directement en conflit avec l'idée d'apprendre un langage de balisage spécial pour la plupart des utilisateurs.Grâce à quelques colonnes de texte enrichi, et vous êtes prêt.Si vous n'aimez vraiment pas l'éditeur de texte enrichi intégré (oui, le processus de téléchargement d'images est maladroit et ne fonctionne pas dans Firefox), demandez à quelqu'un de votre organisation de supprimer les 8 Benjamins et d'aller chercher le RadEditor pour SharePoint.Il devrait à peu près répondre à ces préoccupations.

Généralement, une fois que nous avons surmonté le dogme « mais il faut que ce soit un wiki », nous avons reçu un assez bon accueil de la part des clients quant à l'utilisation de listes.Dans certains cas, lorsqu'un peu plus de fonctionnalités de création de modèles de pages étaient nécessaires, nous nous sommes tournés vers l'utilisation des fonctionnalités WCM de MOSS, ce qui nécessite une réflexion un peu plus préalable sur les modèles, mais offre également une meilleure expérience prête à l'emploi pour des choses comme extraits de contenu et gestion des images.

Parce que l'implémentation par défaut est pas un wiki, c'est un Éditeur HTML.

Si vous avez déjà utilisé un wiki, vous connaîtrez la différence.Il suffit de regarder « Votre réponse » au bas de cette page pour voir la différence.Vous utilisez le balisage dans un wiki, qui est relativement facile à lire et à modifier.Le HTML formaté masque complètement ce qui est écrit.

Mes deux cents en tant que créateur de contenu wiki et super-utilisateur, plutôt qu'en tant qu'administrateur ou développeur :

Je suis actuellement en train de modifier un document dans Sharepoint Wiki au moment où je tape ceci, et c'est de loin le pire éditeur que j'ai jamais rencontré.Pour être précis, j'utilise Sharepoint Foundation 2010 (anciennement WSS) et j'édite des pages à l'aide d'IE 9.

Pour résumer les problèmes que j'ai rencontrés :Lors de la création de contenu wiki, vous souhaitez vous concentrer sur le contenu et le moteur wiki doit être si simple à utiliser qu'il est presque invisible.Avec Sharepoint, ce n'est pas le cas.J'ai vraiment du mal avec l'éditeur pseudo-WYSIWYG, car je dois résoudre des problèmes de formatage fréquents.

J'estime que je suis environ 15 % moins productif en écrivant du contenu wiki avec Sharepoint qu'avec ScrewTurn ou Wikimedia parce que je dois faire face aux problèmes de formatage. Si je passais une journée à écrire des pages wiki, je perdrais environ une heure à essayer de résoudre les problèmes de formatage.

Pour le contexte :J'ai créé quatre wikis internes dans notre entreprise : le premier dans Wikimedia, le moteur wiki derrière Wikipédia, les deux suivants dans ScrewTurn et le dernier dans Sharepoint.Dans chaque wiki, j'ai écrit environ 50 à 100 pages.

Dans ScrewTurn et Wikimedia, l'éditeur semble assez primitif - un éditeur de texte brut qui utilise de simples codes de balisage wiki pour le formatage.Chacun comporte une rangée de boutons qui peuvent appliquer des codes de balisage pour des choses simples comme le formatage en gras et en italique, et pour créer des liens, afin que les débutants n'aient pas besoin d'apprendre les codes de balisage par cœur.Bien que les éditeurs semblent simples, ils s'avèrent très simples à utiliser, notamment pour résoudre les problèmes de formatage.

Sharepoint Wiki, en revanche, a l'air élégant mais est terrible pour l'édition.Au lieu d'utiliser un éditeur de texte brut avec un balisage wiki, il dispose d'un éditeur WYSIWYG qui semble beaucoup plus sophistiqué que les autres éditeurs wiki.Cependant, il a une personnalité, une personnalité maléfique.Il ajoute fréquemment des lignes vides ou change la couleur du texte.Lorsque je sélectionne le texte à formater, puis que j'accède à la liste déroulante Styles de balisage pour le formater, parfois le fait de sélectionner un élément dans la liste déroulante désélectionne le texte sélectionné afin que le formatage s'applique au texte à un emplacement aléatoire.L'insertion de texte copié à partir de Word amène parfois l'éditeur à doubler ou tripler les lignes vides entre les paragraphes à d'autres endroits de la page.Il ne semble pas y avoir de moyen simple de créer un tableau, mis à part l'écriture de HTML.

Le plus gros problème avec l'éditeur, cependant, est que vous ne pouvez pas facilement voir ce qui se passe dans les coulisses, il est donc difficile de résoudre ce problème.Oui, il est possible de modifier le code HTML de la page, mais cela va vraiment à l'encontre du but d'un wiki.

L'impression générale que j'ai en tant qu'utilisateur est qu'il s'agit d'un code de niveau alpha qui a été créé par un stagiaire d'été.Je sais que Foundation est la version gratuite, donc peut-être que j'obtiens ce pour quoi nous avons payé, mais je n'arrive pas à croire qu'un éditeur de logiciels professionnel ait lancé ce produit.

Pour un groupe de 6 personnes qui effectueront des modifications « de temps en temps », le wiki intégré conviendra.

Le wiki Sharepoint est essentiellement une liste de pages HTML statiques, la seule fonctionnalité wiki étant les liens [[article]].Aucun modèle, aucune catégorie, rien.

Nous avons fini par avoir un MediaWiki séparé et n'utilisons le wiki Sharepoint que pour le contenu textuel qui ne nécessite pas beaucoup de mise en page.

N'oubliez pas le kit communautaire pour Sharepoint - Édition Wiki améliorée.Cela ajoute quelques fonctionnalités à la version prête à l'emploi.

Mon entreprise a récemment déployé Sharepoint et je dois dire que mon expérience utilisateur a été Très mauvais.Et je ne dis pas seulement que j'avais peur de l'utiliser :J'y suis allé avec un esprit ouvert et j'ai essayé, et beaucoup de choses semblaient ne pas vraiment fonctionner correctement.

Les raisons mentionnées par Luke le couvrent plus ou moins.

Pourquoi n'envisageriez-vous pas d'utiliser autre chose comme Wiki Tour à vis lequel Jeff a fait un don il y a peu de temps ?Je n'ai pas utilisé Screwturn moi-même, mais il est gratuit et open source, et peut constituer une solution légère et plus rapide pour ce dont vous avez besoin.

Nous avons consulté Sharepoint pour un wiki de département il y a quelques mois.Même si nous sommes avant tout un magasin MS, nous avons opté pour WikiWiki.Open source, si facile à tenir à jour, d'excellents plugins et un back-end basé sur des fichiers.

Je tempérerais également les notes du wiki OOB et son manque de fonctionnalités avec le niveau technique des auteurs ici.

Je suis d'accord que le wiki SP ne peut être qualifié que de nom - certainement par rapport à certaines offres plus robustes - mais rappelez-vous en tant qu'administrateur - votre succès principal est déterminé par l'adoption par l'utilisateur final.En bref, pour chaque fonctionnalité ajoutée par un wiki comme Confluence, il ajoute également la formation des utilisateurs, la syntaxe, etc.

Même si j'aimerais que le wiki SP ait davantage de « type wiki » - il y a une certaine satisfaction indescriptible que vous pouvez ressentir lorsque votre DSI ajoute une entrée dans le wiki de l'entreprise - ou que vous êtes reconnu par un groupe d'assistants administratifs qui trouvent le nouveau wiki "révolutionnaire".

En bref, la fonctionnalité intégrée fait peut-être défaut aux yeux blasés de nous, professionnels de la technologie, mais pour les naïfs en technologie, il est assez facile de s'y former et peut les exposer à une technologie dont ils ont peut-être entendu parler mais n'ont jamais pu le faire (avant cela). ) comprendre ou imaginer utiliser.

J'ai joué très brièvement avec SharePoint WikiPlus.Il s'agit d'une extension tierce qui ajoute des fonctionnalités au wiki SharePoint.Pour les utilisateurs sérieux du wiki, vous aurez probablement besoin de quelque chose de plus que le wiki fourni par SharePoint - soit via une extension, soit via un produit Wiki dédié.

Peut-être essayer http://wordtosharepoint.codeplex.com/ pour migrer votre contenu Word vers SharePoint ?Il s'occupe de relier les images et la plupart des autres choses.

Screwturn est vraiment génial - et c'est C# / .Net.

Sharepoint 2010 est censé avoir de meilleures fonctionnalités wiki, et il y a toujours le kit communautaire de sharepoint.Si vous parvenez à laisser le wiki Sharepoint derrière vous, vous pouvez toujours vous rendre sur le http://www.wikimatrix.org pour trouver le wiki qui vous convient.

Je suis entièrement d'accord avec ce qui précède (Keng).Quoi que cette chose se trouve dans SharePoint (actuellement en utilisant 2010), ce n'est PAS un wiki, de loin.

J'implémente une solution de documentation automatisée, où j'extrait la configuration et d'autres informations (comme le balisage Perldoc) du code source et des fichiers de configuration XML.Il insère les informations dans un ensemble de pages DokuWIKI, complétées par un balisage de formatage (y compris des tableaux).Il est parfaitement formaté et fonctionne avec quelques dizaines de lignes de Perl, comprend des liens internes vers des pages de documentation statiques éditées manuellement et prend en charge les espaces de noms afin que je puisse organiser logiquement mes informations.Je ne peux pas faire ça dans SharePoint (soupir - direction de l'entreprise)...

Le mieux que je puisse faire est d'essayer de faire en sorte que le modèle DokuWIKI ressemble à une sorte de site SharePoint (pour conserver l'apparence et la convivialité) et qu'il soit lié à SharePoint.:-(

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top