Domanda

Ok, ho visto un paio di post che menzione un paio di altri post in merito al non utilizzo di SP wiki, perché succhiare.

Dal momento che stiamo cercando di fare il nostro wiki in SP, ho bisogno di sapere perché non dovremmo farlo per un gruppo di 6 automazione-sviluppatori per documentare i passaggi nei vari processi automatizzati e le modifiche che devono essere fatte di volta in volta.

È stato utile?

Soluzione 10

Prima lo sfogo, qui è la mia esperienza con SharePoint come wiki.

Si tratta di un mal implementata la funzione che non è riuscito perchè c'era un fundemental mancanza di indagare sul wiki attuale ambienti.Che è perché non è riuscito nel suo editor e perché manca in punti quali:tagging, di storia, di confronto, e mal codice html generato.

Hai bisogno di saltare e ottenere qualcos'altro che fa il lavoro migliore e link da SharePoint.

Avendo produzione esperienza con entrambi i prodotti, ti consiglio di ScrewTurn su SharePoint.

vedere modificare la storia per rant

Altri suggerimenti

Qui ci sono alcune cose mi sono imbattuto in che svaniscono se si utilizza un wiki diverso da Sharepoint.

Sharepoint consente di creare tonnellate di separare wiki, ma mi consiglia di avere una grande wiki per tutto.La mia azienda ha fatto un sacco di piccoli wiki per ogni progetto/funzione, ma solo gli amministratori possono creare le singole wiki, quindi se io voglio scrivere su qualcosa che non è non corrisponde a una delle categorie predefinite, devo trovare un manager per creare il wiki prima.

In secondo luogo, se si utilizza Sharepoint assicurarsi che tutti la tua personale usa solo IE che Firefox non supporta l'editor WYSIWIG.Questo è un buona cosa che per la maggior parte dei wiki, ma rende collaborando difficile in Sharepoint.Immaginate la modifica automatica HTML generato in una piccola scatola per tutto il giorno.

Terzo, prova a scrivere il tuo progetto di documentazione del wiki e resistere alla tentazione di caricare documenti di Word per la raccolta di Sharepoint.Non scrivere il backup di tutti i documenti due volte e guardando le cose si fanno sempre più fuori sincrono.

Infine, supporto per immagini in Sharepoint wiki è terribile.È necessario aggiungere un file in una raccolta documenti da qualche parte e digitare l'URL.Le mie immagini sono sempre eliminato perché non sembra avere molto senso al di fuori del contesto.

Ho un molto più positiva di Sharepoint di Microsoft Wiki.In molti modi, mi ricorda di FrontPage 98 -- che ci è stato ingiustamente diffamato prodotto.

Il commento sull'utilizzo di una lista è sbagliata.Sharepoint Wiki SONO elenchi di Sharepoint, in cui ogni pagina è un elemento di una lista con un allegato HTML.

È vero che non è possibile un collegamento in una pagina, ma se le pagine sono breve io non lo vedo come un problema.SP Wiki lo rende molto facile per brevi pagine.

È possibile modificare il Wiki attributi da access del 2008, se si desidera, e si può aggiungere attributi al wiki voci di elenco desiderato.Per esempio, vuoi categorie?Basta semplicemente modificando l'elenco.Vuoi specifici punti di vista?delle voci di elenco.Creare anche loro.

Non c'è vero e proprio genio nel modo in cui Microsoft ha costruito la loro Wiki quadro in cima elenchi di Sharepoint, che sono undeniablly ben fatto.

Il VERO svantaggio di Sharepoint Wiki è stata menzionata da famerchris.L'approccio per la gestione delle immagini è sorprendentemente terribile.E ' un problema serio che si dovrebbe prendere in considerazione altre Wiki solo per questo motivo.

C'è un contorto soluzione che uso io.Sfrutta l'eccellente supporto per Sharepoint e l'editing di immagini integrato con Windows Live Writer.

  1. Creare un SP blog che conterrà le immagini che sarà fatto riferimento nel wiki.
  2. Utilizzare Windows Live Writer a postare i wiki-immagine-blog.Drop la vostra immagine in WLW, ridimensionare questa necessità, etc.Se vuoi, usa WLW per scrivere la vostra immagine associata wiki testo della prima bozza così.
  3. Dopo il post di Wiki, copiare e incollare testo e immagine in Wiki editor di testo rtf campo.

Questo prende sorprendentemente po ' di tempo, molto meno rispetto a qualsiasi altra opzione ho letto di.Lo ammetto, è contorto.

Altro che i problemi di immagine sono soddisfatto e colpito con il prodotto.Se solo Microsoft aveva pensato di più su immagini ...se solo ...

L'impostazione predefinita wiki incluso con Sharepoint non supporta comune wiki caratteristiche del bene a tutti.Non c'è modo di modificare una singola sezione di una pagina, e il modo di collegare direttamente a una sezione particolare su un'altra pagina.Il backend è in HTML così si perde la possibilità di modificare in chiaro utilizzando la sintassi semplice.La diff funzione non può estendersi su più versioni.Poveri cross browser il supporto di editing WYSIWYG.Alcun modo per auto-inserire una tabella di contenuti...

Ci sono, tuttavia, altre wiki aggiuntivi per Sharepoint che io non posso categoricamente di ignorare, per esempio Confluenza fa un add-in per Sharepoint.Non ho valutato questo software di me, e di Confluenza è un po ' costoso ($1.200 per 25 di licenza con l'utente) anche se sei già su Sharepoint sento aziendale di grandi dimensioni casse :P.Ci sembrano essere alcuni liberi aggiuntivi come CKS Enhanced Wiki ma che sembra avere un sacco di gli stessi problemi di cui sopra.

Si esegue in questo argomento tutti il tempo, e la prima domanda che ho preso per chiedere alla gente è: "Perché avete bisogno di un wiki"?Quasi sempre le risposte sono cose "facilità di editing", "di più collaboratori", e "la Parola è pesante". Molto raramente abbiamo visto nessuno chiedere quello che non ho considerare in modo univoco, come wiki caratteristiche particolari (per "magia" di markup, a grana fine la versione della storia che mostra variazioni, ecc).Inoltre, di solito si desidera che un qualche tipo di categorizzazione delle cose, non solo completamente free-form pagine.

Nel mondo SharePoint queste cose dovrebbero urlare "elenco" a voi, se avete lavorato con lo strumento per un po'.Non vi è praticamente nessun motivo particolare per usare un wiki per queste conoscenze di base di applicazioni in stile, soprattutto perché "la facilità di montaggio" di solito direttamente in conflitto con l'idea di imparare un particolare linguaggio di markup per la maggior parte degli utenti.Attraverso un paio di rich-text in là, e tutto è a posto.Se davvero non ti piace il built-in rich text editor (sì, l'immagine di processo di caricamento è goffo e non funziona in Firefox), hanno qualcuno nella vostra organizzazione go drop 8 Benjamins e andare a prendere il RadEditor per SharePoint.Dovrebbe praticamente gestire questi problemi.

Generalmente, una volta che abbiamo ottenuto oltre il "ma deve essere un wiki" dogma, abbiamo avuto abbastanza buona accoglienza clienti per solo uso di elenchi.In alcuni casi, dove un po 'di più di una pagina di template di struttura si è resa necessaria ci siamo rivolti all'utilizzo di WCM caratteristiche di MOSS, che richiede un po' più up-front pensato di modelli, ma ha anche una migliore fuori dalla scatola esperienza per cose come il contenuto di frammenti e di gestione dell'immagine.

Perché l'implementazione di default è non un wiki, è un Editor HTML.

Se hai usato un wiki prima che tu conosci la differenza.Basta guardare "la Tua risposta" in fondo a questa pagina per vedere la differenza.Utilizzare il markup in un wiki, che è relativamente facile da leggere e modificare.Formattato HTML copre completamente quello che è scritto.

I miei due centesimi vale la pena come un wiki creatore di contenuti e super-utente, piuttosto che un amministratore o uno sviluppatore:

Io sono attualmente in fase di modifica di documenti in Sharepoint Wiki come ho tipo questo, ed è di gran lunga il peggiore editor che io abbia mai incontrato.Per essere precisi, sto utilizzando Sharepoint Foundation 2010 (in precedenza noto come WSS), la modifica delle pagine che usano IE 9.

Per riassumere i problemi che ho di fronte:Durante la creazione di wiki il contenuto che si desidera concentrarsi sul contenuto e il motore di wiki dovrebbe essere così facile da usare come essere quasi invisibile.Con Sharepoint che non è il caso.Ho davvero lottato con la pseudo-editor WYSIWYG, a dover correggere i frequenti problemi di formattazione.

Si stima che sono circa il 15% in meno produttiva la scrittura di contenuti wiki con Sharepoint che io sono con ScrewTurn o Wikimedia perché ho a che fare con i problemi di formattazione. Se faccio passare un giorno a scrivere le pagine della wiki vorrei perdere circa un'ora a cercare di risolvere i problemi di formattazione.

Per lo sfondo:Ho creato al proprio interno quattro wiki presso la nostra azienda, il primo in Wikimedia, il motore di wiki dietro di Wikipedia, per i prossimi due in ScrewTurn, e uno finale in Sharepoint.In ogni wiki ho scritto circa 50-100 pagine.

In entrambi i ScrewTurn e Wikimedia l'editor sembra abbastanza primitivo - un editor di testo che utilizza semplici wiki mark-up codici per la formattazione.Ognuno ha una fila di pulsanti che si possono applicare un mark-up codici per le cose semplici come il grassetto e il corsivo, e per creare link, in modo che i principianti non hanno bisogno di imparare il mark-up codici di cuore.Mentre gli editori normale che risultano essere molto semplici da utilizzare, in particolare per il fissaggio di problemi di formattazione.

Sharepoint Wiki, invece, sembra liscia, ma è terribile per la modifica.Invece di utilizzare un editor di testo normale con wiki mark-up è un editor WYSIWYG che sembra molto più sofisticata rispetto ad altri redattori wiki.Tuttavia esso ha personalità, un male.Spesso aggiunge righe vuote o cambia il colore del testo.Quando si seleziona il testo da formattare, quindi andare per il Markup Stili a discesa formato, a volte l'atto di selezionare un elemento dall'elenco a discesa consente di deselezionare il testo selezionato in modo che la formattazione si applica al testo in una posizione casuale.L'inserimento di testo copiato da Word a volte provoca l'editor doppia o tripla su righe vuote tra i paragrafi in altri punti della pagina.Sembra che ci sia alcun modo semplice per la creazione di una tabella, oltre alla scrittura di codice HTML.

Il più grande problema di editor, tuttavia, è che si può facilmente vedere che cosa sta succedendo dietro le quinte, quindi è difficile risolvere il problema.Sì, è possibile modificare l'HTML della pagina, ma che in realtà sconfigge lo scopo di un wiki.

L'impressione generale ho come utente, è che questo è l'alfa a livello di codice che è stato sbalzato da una stagista estivo.So che la Fondazione è la versione gratuita, quindi forse ho quello che abbiamo pagato, ma non posso credere che un software professionale in compagnia di questo prodotto.

Per un gruppo di 6 persone che saranno presenti a "ogni tanto" modifiche, il built-in wiki andrà bene.

Sharepoint Wiki è essenzialmente un elenco di Pagine HTML Statiche, con l'unica Wiki-funzione [[articolo]] collegamenti.Nessun modello, Nessuna categoria, niente di niente.

Abbiamo finito per avere un separato MediaWiki e utilizzare solo il wiki Sharepoint per il contenuto basato su testo che non ha bisogno di molto il layout.

Non dimenticare la Comunità Kit per Sharepoint - Enhanced Wiki Edizione.Questo aggiunge alcune funzioni al di fuori della casella di versione.

La mia azienda ha implementato sharepoint di recente, e devo dire che la mia esperienza utente è stata Molto Male.E non sto solo dicendo che mi era in apprensione per utilizzarlo:Sono andato con animo aperto e provato, e molte cose sentivo come se in realtà non funziona proprio.

Le ragioni Luca citati più o meno a coprire.

Perché non prendere in considerazione di usare qualcosa di diverso, come Screwturn Wiki che Jeff donato a poco tempo fa?Non ho usato Screwturn me, ma è gratuito e open source, e può essere una più rapida soluzione leggera per quello che ti serve.

Abbiamo guardato Sharepoint per un reparto wiki pochi mesi fa.Anche se siamo soprattutto un MS negozio, siamo andati con DokuWiki.Open-source, quindi facile da tenere aggiornato, ottimi plugin e file di back-end.

Vorrei temperare le valutazioni degli OOB wiki e la sua mancanza di funzionalità con il livello tecnico degli autori qui.

Sono d'accordo che la SP wiki potrebbe beneficiare solo di nome - certamente rispetto ad alcuni le offerte più robuste ma ricordate che come admin - primaria successo è determinato dall'utente finale di adozione.In breve, per tutte le caratteristiche che un wiki come Confluenza aggiunge, si aggiunge anche la formazione degli utenti, sintassi, etc.

Mentre mi piacerebbe SP wiki per avere più "wiki" - c'è una certa, indescrivibile la soddisfazione che si può prendere quando CIO aggiunge un ingresso in azienda wiki o riconosciuto da un gruppo di assistenti amministrativi che trovano il nuovo wiki "rivoluzionario".

In breve - il costruito nel funzionalità può essere privo di occhi stanchi di noi tecnici, ma tecnologicamente ingenuo, la sua abbastanza facile da addestrare, e può esporli a una tecnologia che si può avere sentito parlare di, ma non potrebbe mai (prima di questo) comprendere o immaginare che utilizza.

Ho giocato molto brevemente con SharePoint Wiki Plus.Si tratta di un estensione di terze parti che consente di aggiungere funzionalità di SharePoint Wiki.Per gravi wiki utenti, allora probabilmente avete bisogno di qualcosa di più di SharePoint fornito Wiki - sia attraverso un'estensione o una Wiki dedicata del prodotto.

Magari provare http://wordtosharepoint.codeplex.com/ per la migrazione della Parola di contenuto di SharePoint?Si prende cura di collegamento tra le immagini e la maggior parte delle altre cose.

Screwturn è malvagio impressionante - e è C# / .Net.

Sharepoint 2010, si suppone che sia meglio wiki caratteristiche, e c'è sempre la comunità kit di sharepoint.Se siete in grado di lasciare il Wiki Sharepoint dietro si potrebbe sempre la testa verso il http://www.wikimatrix.org per trovare il wiki che funziona per voi.

Sono pienamente d'accordo con quanto sopra (Keng).A prescindere che cosa è all'interno di SharePoint (attualmente utilizzando il 2010), NON è un Wiki da un colpo lungo.

Io sono l'implementazione di un sistema automatizzato di documentare la soluzione in cui ho estratto config e altre informazioni (come perldoc markup) dal codice sorgente e file di configurazione XML.Inserire le informazioni in un insieme di DokuWIKI pagine, completo di formattazione markup (comprese le tabelle).Viene fuori perfettamente formattato e funziona con un paio di decine di righe di perl, include i collegamenti interni alle modificato manualmente statico doc pagine, e il supporto per gli spazi dei nomi così posso avere le mie informazioni sono organizzate in modo logico.Non c'è modo ho potuto fare in SharePoint (sigh - direzione dell'azienda)...

Il meglio che posso fare è provare a fare DokuWIKI modello di assomigliare a una sorta di sito di SharePoint (per mantenere il look and feel simile) e link di SharePoint.:-(

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top