Sharepoint Wikis

Wiki-ul implicit inclus în Sharepoint nu acceptă deloc caracteristicile wiki comune. Nu există nicio modalitate de a edita o singură secțiune a unei pagini și nici o modalitate de a conecta direct la o anumită secțiune dintr-o altă pagină. Backend-ul este în HTML, astfel încât să pierdeți capacitatea de a edita în text simplu folosind o sintaxă simplă. Funcția de difuzare nu poate include mai multe versiuni. Suport necorespunzător pentru browserul de tip WYSIWYG. Nu puteți introduce automat un cuprins ...

There are, however, other wiki add-ins for Sharepoint which I can't categorically dismiss, for instance Confluence makes an add-in for Sharepoint. I haven't evaluated this software myself, and Confluence is somewhat expensive ($1,200 for 25 user license) although if you are already on Sharepoint I sense large corporate coffers :P. There also appear to be some free add-ins like CKS Enhanced Wiki but that appears to have a lot of the same problems mentioned above.

Wiki-ul Sharepoint este în esență o listă de pagini HTML statice, singura caracteristică Wiki fiind linkurile [[articolul]]. Nu există șabloane, nu există categorii, nimic.

Am ajuns să avem un MediaWiki separat și să folosim doar wiki-ul Sharepoint pentru un conținut bazat pe text, care nu are nevoie de un aspect mult.

Compania mea a lansat recent sharepoint și trebuie să spun că experiența mea cu utilizatorul a fost Foarte rea . Și nu spun doar că sunt îngrijorat să o folosesc: am intrat cu o minte deschisă și am încercat-o și multe lucruri au simțit că nu au funcționat corect.

Motivele pe care Luke le-a menționat mai mult sau mai puțin acoperă.

De ce nu v-ați gândi să utilizați altceva precum Screwturn Wiki care Jeff a donat o scurtă vreme în urmă? Nu am folosit Insurubatorul insusi, dar este gratuit si open source si poate fi o solutie mai usoara pentru ceea ce ai nevoie.

Pentru un grup de 6 persoane care vor face modificări "din când în când", wiki-ul încorporat va fi bine.

I've played very briefly with SharePoint Wiki Plus. It's a third-party extension that adds features to the SharePoint Wiki. For serious wiki users then you probably need something more than the SharePoint provided Wiki - either via an extension or a dedicated Wiki product.

Înainte de rant, aici este experiența mea generală cu SharePoint ca un wiki.

Este o caracteristică prost pusă în aplicare, care a eșuat, deoarece a existat o lipsă fundementală de anchetă în ceea ce privește mediile wiki actuale. Acesta este motivul pentru care a eșuat în editorul său și de ce se ratează pe puncte cum ar fi: etichetarea, compararea istoricului și codul html greșit generat.

Trebuie să o săriți și să obțineți altceva care să facă mai bine această treabă și să o legați de ea din SharePoint.

Având o experiență de producție cu ambele produse, aș recomanda ScrewTurn pe SharePoint.

vedeți istoricul modificărilor pentru rant

Deoarece implementarea implicită este nu un wiki, este un editor HTML .

Dacă ați folosit un wiki înainte de a afla diferența. Uită-te la "Răspunsul tău" din partea de jos a acestei pagini pentru a vedea diferența. Utilizați marcare într-un wiki, care este relativ ușor de citit și editat. Formatul HTML ascunde complet ceea ce este scris.

Don't forget the Community Kit for Sharepoint - Enhanced Wiki Edition. This adds some features to the out of the box version.

Iată câteva avertismente pe care le-am întâlnit și care vor dispărea dacă folosiți un alt wiki decât Sharepoint.

Sharepoint vă permite să creați tone de wiki separate, dar aș recomanda să aveți un wiki mare pentru tot. Compania mea a făcut o mulțime de wiki mici pentru fiecare proiect/facilitate, dar numai administratorii pot crea wiki-urile individuale, așa că dacă vreau să scriu despre ceva care nu este într-o categorie predefinită, trebuie să găsesc manager pentru a crea primul wiki.

În al doilea rând, dacă utilizați Sharepoint asigurați-vă că toată lumea din personalul dvs. utilizează numai IE, deoarece Firefox nu suportă editorul WYSIWIG. Acesta este un lucru bun pentru majoritatea wiki-urilor, dar face colaborarea dificilă în Sharepoint. Imaginați-vă că modificați HTML-ul generat automat într-o cutie mică, toată ziua.

În al treilea rând, încercați să scrieți documentația proiectului în wiki și să rezistați tentației de a încărca documentele Word în biblioteca Sharepoint. Nu are rost să scrieți toate documentele dvs de două ori și să vedeți că lucrurile devin din ce în ce mai sincronizate.

În cele din urmă, suportul imaginilor în wiki din Sharepoint este teribil. Trebuie să adăugați un fișier la o bibliotecă de documente undeva și să tastați adresa URL. Imaginile mele au fost pentru totdeauna obtinute sterse pentru ca nu par sa aiba prea mult sens din context.

Ne-am uitat la Sharepoint pentru un departament wiki cu câteva luni în urmă. Chiar dacă suntem în primul rând un magazin MS, am mers cu DokuWiki . Open-source, ușor de ținut la curent, plug-in-uri excelente și un back-end bazat pe fișiere.

Ne confruntăm cu acest subiect toate timpul, iar prima întrebare pe care am adresat-o oamenilor este "De ce aveți nevoie de un wiki"? Aproape întotdeauna răspunsurile sunt lucrurile "ușurința editării", "contribuitorii multipli" și "Cuvântul este greu". Foarte rareori am văzut pe cineva să ceară ceea ce consider că sunt caracteristici unice ale wiki (marcare specială "magică", istoric de versiuni fine cu modificări etc.). De asemenea, ei doresc, de obicei, un fel de categorizare a lucrurilor, nu doar pagini cu formă liberă.

În lumea SharePoint, aceste lucruri ar trebui să țipă "lista" la dvs. dacă ați lucrat cu instrumentul pentru un timp. În principiu, nu există niciun motiv special pentru a utiliza un wiki pentru aceste aplicații bazate pe cunoștințe, mai ales că "ușurința de editare", de obicei, intră direct în conflict cu ideea de a învăța un limbaj special de marcare pentru majoritatea utilizatorilor. Printr-o pereche de coloane cu text bogat, și tu ești setat. Dacă într-adevăr nu vă place editorul built-in text-rich (da procesul de încărcare a imaginilor este clunky și nu funcționează în Firefox), aveți pe cineva din organizația dvs. să renunțe la cele 8 Benjamins și să meargă pentru a obține un RadEditor pentru SharePoint . Ar trebui să se ocupe destul de mult de aceste preocupări.

În general, odată ce am ajuns peste dogma "dar trebuie să fie o wiki", am primit o recepție destul de bună a clienților, folosind doar liste. În unele cazuri, în cazul în care a fost nevoie de puțin mai mult dintr-o facilitate de creare a paginilor, am apelat la utilizarea caracteristicilor WCM ale MOSS, care necesită o gândire puțin mai avansată despre șabloane, dar are și o experiență mai bună din cutie pentru lucruri precum fragmente de conținut și manipularea imaginilor.

Am o viziune mult mai pozitivă asupra Wiki-ului Sharepoint al Microsoft. În multe privințe îmi amintește de FrontPage 98 - și acesta a fost un produs nedrept de malign.

Comentariul despre utilizarea unei liste este greșit. Sharepoint Wikis ARE Sharepoint liste, în care fiecare pagină este un element de listă cu un atasament HTML.

Este adevărat că nu puteți să vă conectați la o pagină, dar dacă paginile sunt scurte, nu o văd ca o problemă. SP Wiki face foarte ușor să aveți pagini scurte.

Aveți posibilitatea să manipulați atributele Wiki din accesul 2008 dacă doriți și puteți adăuga atribute la elementele listei wiki după cum doriți. De exemplu - vrei categorii? Doar adăugați-le editând lista. Vrei viziuni specifice? a elementelor din listă. Creați-le și pe ele.

Există un geniu real în modul în care Microsoft și-a construit cadrul Wiki la nivel de liste Sharepoint - lucru care este fără îndoială bine făcut.

Deficiența reală a Sharepoint Wiki a fost menționată de famerchris. Abordarea gestionării imaginilor este surprinzător de groaznică. Este o problemă atât de gravă încât ar trebui să luați în considerare alte Wikis numai din acest motiv.

Există o soluție complicată pe care o folosesc. Acesta profită de suportul superb al Sharepoint și editare de imagini integrat cu Windows Live Writer.

1. Creați un blog SP care va conține imaginile care vor fi menționate în wiki.
2. Utilizați Windows Live Writer pentru a posta pe blog-ul wiki-image. Puneți imaginea în WLW, redimensionați-o după cum este necesar, etc. Dacă doriți, utilizați WLW pentru a scrie și textul wiki asociat cu imaginea.
3. După ce postați pe Wiki, copiați și inserați imaginea și textul în câmpul de text îmbogățit în editorul Wiki.

Acest lucru durează puțin, mult mai puțin decât orice altă opțiune am citit. Recunosc, este complicat.

În afară de problemele de imagine, sunt mulțumit și impresionat de produs. Dacă numai Microsoft ar fi crezut mai greu despre imagini ... dacă numai ...

De asemenea, mi-ar tempera rating-ul wiki-ului OOB și lipsa de funcționalitate cu nivelul tehnic al autorilor aici.

Sunt de acord că SP wiki se poate califica numai în nume - cu siguranță, în comparație cu unele oferte mai robuste - dar amintiți-vă ca un administrator - succesul dvs. principal este determinat de adoptarea de către utilizatorii finali. Pe scurt - pentru fiecare caracteristică pe care o adaugă un wiki, cum ar fi Confluence, se adaugă și educația utilizatorului, sintaxa etc.

În timp ce mi-ar plăcea SP wiki să aibă mai multă "wiki-like" - există o anumită satisfacție nedescrisă pe care o puteți lua atunci când CIO-ul dvs. adaugă o intrare în wiki-ul companiei - sau sunteți recunoscut de un grup de asistenți administrativi care găsesc noul wiki "revoluționar".

Pe scurt - funcționalitatea încorporată poate fi lipsită de ochii neplăcuți ai profesioniștilor noștri tehnologici, ci de cei naivi din punct de vedere tehnologic, de ei destul de ușor de antrenat și de expunerea lor la o tehnologie despre care au auzit, dar nu ar putea (înainte de ) să înțeleagă sau să-și imagineze utilizarea.

Screwturn este rău minunat - și este C #/.Net.

Sharepoint 2010 se presupune că are caracteristici wiki mai bune și există întotdeauna setul comunitar de sharepoint. Dacă sunteți în stare să părăsiți Sharepoint Wiki în spatele - puteți să mergeți întotdeauna la http://www.wikimatrix.org pentru a găsi un wiki care funcționează pentru dvs.

Sunt complet de acord cu cele de mai sus (Keng). Indiferent ce lucru se află în cadrul SharePoint (care utilizează în prezent 2010), nu este un Wiki printr-o lovitură lungă.

Am implementat o soluție de documentare automată, unde extrag config și alte informații (cum ar fi markdownul perldoc) din codul sursă și fișierele de configurare XML. Se inserează informațiile într-un set de pagini DokuWIKI, completate cu marcare de formatare (inclusiv tabele). Acesta este perfect formatat și funcționează cu câteva zeci de linii de perl, include link-uri interne la pagini statice editate manual și suport pentru spații de nume pentru a-mi putea organiza logic informațiile. Nu există nici o modalitate de a face acest lucru în SharePoint (suspin - direcția companiei) ...

Cel mai bun lucru pe care îl pot face este să încercați să faceți ca șablonul DokuWIKI să semene cu un fel de site SharePoint (pentru a păstra aspectul și simțul similar) și pentru a trimite link-uri din SharePoint. :-(