Wikis Sharepoint

Voici quelques mises en garde que je suis tombé sur qui disparaîtront si vous utilisez un wiki autre que Sharepoint.

Sharepoint vous permet de créer des tonnes de wikis séparés, mais je recommande 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 les wikis individuels, donc si je veux écrire sur quelque chose qui ne correspond pas à l'une des catégories prédéfinies, je dois d'abord trouver un gestionnaire pour créer le wiki.

Deuxièmement, si vous utilisez Sharepoint, assurez-vous que tout le monde sur votre personnel utilise uniquement IE, puisque Firefox ne prend pas en charge L'éditeur WYSIWIG. C'est une Bonne chose pour la plupart des wikis, mais rend la collaboration difficile dans Sharepoint. Imaginez l'édition HTML généré automatiquement dans une toute petite boîte toute la journée.

Troisièmement, essayez d'écrire 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 d'écrire tous vos documents deux fois et regarder les choses deviennent de plus en plus désynchronisées.

Enfin, le support des images dans les wikis Sharepoint est terrible. Vous devez ajouter un fichier à une bibliothèque de documents quelque part et taper L'URL. Mes images ont été supprimées pour toujours parce qu'elles ne semblent pas avoir beaucoup de sens hors 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ée. 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 que vous ne pouvez 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 rend très facile d'avoir des pages courtes.

Vous pouvez manipulez les attributs Wiki d'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? Il suffit de les ajouter en éditant la liste. Vous voulez des vues spécifiques? des éléments de la liste. Créer eux aussi.

Il y a un vrai génie dans la façon dont Microsoft a construit son framework Wiki au sommet des listes Sharepoint - qui sont indéniablement bien faites.

Le véritable inconvénient du Wiki Sharepoint a été mentionné par famerchris. L'approche de la gestion de l'image est étonnamment terrible. C'est un problème si grave que vous devriez considérer d'autres Wikis pour cette seule raison.

Il y a une solution de contournement alambiquée que j'utilise. Il profite du superbe support Sharepoint et de l'édition d'image 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 wiki-image-blog. Déposez votre image dans WLW, redimensionnez-la au besoin, etc. Si vous aimez, utilisez WLW pour écrire votre première ébauche de texte wiki associé à l'image.
3. après avoir publié sur le Wiki, copiez et collez l'image et le texte dans le champ texte enrichi de L'éditeur Wiki.

Cela prend étonnamment peu de temps, beaucoup moins que toute autre option dont j'ai lu. Je l'avoue, c'est alambiqué.

Autre que les problèmes d'image, je suis heureux et impressionné par le produit. Si seulement Microsoft avait pensé plus dur sur les images ... si seulement ...

Le wiki par défaut inclus avec Sharepoint ne prend pas en charge les fonctionnalités communes du wiki. Il n'y a aucun moyen de modifier un article d'une page, et pas moyen d'accéder directement à une section particulière sur une autre page. Le backend est en HTML de sorte que vous perdez la possibilité d'éditer en texte clair en utilisant une syntaxe simple. La fonction diff ne peut pas s'étendre sur plusieurs versions. Mauvaise prise en charge cross browser de L'édition WYSIWYG. Aucun moyen d'insérer automatiquement une table des matières...

Il existe cependant d'autres wiki compléments 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 utilisateur 25) bien que si vous êtes déjà sur Sharepoint, je sens de grands coffres d'entreprise :P. Il semble également y avoir des compléments gratuits comme CKS Enhanced Wiki mais cela semble avoir beaucoup des mêmes problèmes mentionnés ci-dessus.

Nous rencontrons ce sujet tout le temps, et la première question que j'ai prise pour demander aux gens est "pourquoi avez-vous besoin d'un wiki"? Presque toujours les réponses sont des choses "facilité d'édition", "contributeurs multiples", et"Word est à poids lourd". Très rarement avons-nous vu quelqu'un demander ce que je considère être des fonctionnalités uniques de type wiki (balisage spécial "magique", historique des versions à grain fin montrant les changements, etc.). En outre, ils veulent généralement une sorte de catégorisation des choses, pas seulement pages complètement libres.

Dans le monde SharePoint, ces choses devraient vous crier "liste" si vous travaillez avec l'outil depuis un moment. Il n'y a fondamentalement aucune raison particulière d'utiliser un wiki pour ces applications de style base de connaissances, d'autant plus que la "facilité d'édition" est généralement en conflit direct avec l'idée d'apprendre un langage de balisage spécial pour la plupart des utilisateurs. À travers quelques colonnes de texte riche là-dedans, et vous êtes tous ensemble. Si vous n'aimez vraiment pas le haut- éditeur de texte enrichi (oui, le processus de téléchargement d'image est maladroit et ne fonctionne pas dans Firefox), demandez à quelqu'un de votre organisation d'abandonner les 8 Benjamins et d'obtenir le RadEditor pour SharePoint. Il devrait à peu près gérer ces préoccupations.

Généralement, une fois que nous avons surmonté le dogme "mais il doit être un wiki", nous avons eu une très bonne réception des clients pour simplement utiliser des listes. Dans certains cas, où un peu plus d'une installation de modèle de page était nécessaire, nous nous sommes tournés vers l'utilisation du WCM caractéristiques de MOSS, qui nécessite un peu plus de réflexion à l'avance sur les modèles, mais a également une meilleure expérience de la boîte pour des choses comme des extraits de contenu et la gestion des images.

, Car 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" en bas de cette page pour voir la différence. Vous utilisez le balisage dans un wiki, qui est relativement facile à lire et à modifier. HTML formaté obscurcit complètement ce qui est écrit.

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

Je suis en train d'éditer un document dans le Wiki Sharepoint lorsque 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 (précédemment connu sous le nom de WSS), éditant des pages en utilisant IE 9.

Pour résumer les problèmes que j'ai rencontrés: lors de la création de contenu wiki, vous voulez vous concentrer sur le contenu et le moteur wiki devrait être tellement facile à utiliser pour être presque invisible. Avec Sharepoint ce n'est pas le cas. Je me bats vraiment avec l'éditeur pseudo-WYSIWYG, devant résoudre des problèmes de formatage fréquents.

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

Pour l'arrière-plan: J'ai créé quatre wikis internes à notre société - le premier dans Wikimedia, le moteur wiki derrière Wikipedia, les deux suivants dans ScrewTurn, et un 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 des codes de balisage wiki simples pour le formatage. Chacun a une rangée de boutons qui peuvent appliquer des codes de balisage pour des choses simples comme le formatage gras et italique, et pour créer des liens, donc les débutants n'ont pas besoin d'apprendre les codes de balisage par cœur. Alors que les éditeurs semblent simples, ils s'avèrent très simples à utiliser, en particulier pour résoudre les problèmes de formatage.

Wiki Sharepoint, d'autre part, semble lisse mais est - terrible pour l'édition. Au lieu d'utiliser un éditeur de texte brut avec un balisage wiki, il a un éditeur WYSIWYG qui semble beaucoup plus sophistiqué que les autres éditeurs wiki. Cependant, il a une personnalité, un maléfique. Il ajoute fréquemment des lignes vides ou des modifications la couleur du texte. Lorsque je sélectionne du texte à formater, puis allez dans la liste déroulante Styles de balisage pour le formater, parfois l'acte 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 entraîne parfois l'éditeur à doubler ou tripler sur des lignes vides entre les paragraphes à d'autres endroits de la page. Il ne semble pas y avoir de moyen facile de créer une table, en dehors de l'écriture HTML.

Le plus grand le problème à propos de l'éditeur, cependant, est que vous ne pouvez pas facilement voir ce qui se passe dans les coulisses, il est donc difficile de le réparer. Oui, il est possible d'éditer le 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, c'est que c'est un code de niveau alpha qui a été mis en place par un stagiaire d'été. Je sais que la Fondation est la version gratuite alors peut être que je reçois ce que nous avons payé mais je ne peux pas croire qu'une société de logiciels professionnels a mis cela produit.

Pour un groupe de 6 personnes qui vont faire des modifications "de temps en temps", le wiki intégré ira bien.

Le Wiki Sharepoint est essentiellement une liste de Pages HTML statiques, avec la seule fonctionnalité Wiki étant des liens [[article]]. Pas de Modèles, pas de catégories, rien.

Nous avons fini par avoir un MediaWiki séparé et n'utiliser le Wiki Sharepoint que pour le contenu textuel qui n'a pas besoin de beaucoup de mise en page.

N'oubliez pas le kit communautaire pour Sharepoint-Enhanced Wiki Edition . Cela ajoute certaines 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 était Très Mauvais. Et je ne dis pas seulement que j'avais peur de l'utiliser: je suis entré avec un esprit ouvert et l'ai essayé, et beaucoup de choses ont juste l'impression qu'elles ne fonctionnaient pas vraiment bien.

Les raisons mentionnées par Luc Le couvrent plus ou moins.

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

Nous avons regardé Sharepoint pour un wiki de département il y a quelques mois. Même si nous sommes avant tout un magasin MS, nous sommes allés avec DokuWiki . Open-source, si facile à tenir à jour, grands plugins, et un back-end basé sur les fichiers.

Je voudrais aussi tempérer les évaluations du wiki OOB et son manque de fonctionnalité avec le niveau technique des auteurs ici.

Je suis d'accord que le wiki SP pourrait se qualifier en nom seulement-certainement par rapport à certaines offres plus robustes - mais rappelez - vous en tant qu'administrateur-votre succès principal est déterminé par l'adoption de l'utilisateur final. En bref - pour chaque fonctionnalité qu'un wiki comme Confluence ajoute, Il ajoute également l'éducation des utilisateurs, la syntaxe,etc.

Alors que J'aimerais SP wiki pour avoir plus "wiki-like" - il y a une certaine satisfaction indescriptible que vous pouvez prendre lorsque votre CIO ajoute une entrée dans le wiki de l'entreprise-ou vous êtes reconnu par un groupe d'assistants administratifs qui trouvent le nouveau wiki "révolutionnaire".

En bref - la fonctionnalité intégrée peut manquer aux yeux blasés des professionnels de la technologie américains, mais pour les technologiquement naïfs, c'est assez facile à former, et peut les exposer à une technologie dont ils ont peut-être entendu parler mais ne pourrait jamais (avant cela) comprendre ou imaginez l'utilisation.

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

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

Screwturn est wicked awesome-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 êtes en mesure de laisser le Wiki Sharepoint derrière-vous pouvez toujours vous diriger vers le http://www.wikimatrix.org {[4] } pour trouver le wiki qui fonctionne pour vous.

Je suis entièrement d'accord avec ce qui précède (Keng). Quelle que soit cette chose dans SharePoint (en utilisant actuellement 2010), ce N'est pas un Wiki par un long shot.

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, avec balisage de formatage (y compris les tables). Il sort parfaitement formaté et fonctionne avec quelques dizaines de lignes de perl, comprend liens internes vers des pages de doc statiques éditées manuellement, et support pour les espaces de noms afin que je puisse avoir mes informations logiquement organisées. Il n'y a aucun moyen que je puisse faire cela 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 en quelque sorte au site SharePoint (pour garder l'apparence similaire) et le lien hors de SharePoint. :-(