Ok, he visto algunas publicaciones que mencionan algunas otras publicaciones sobre el uso de SP wikis porque apestan.Sharepoint Wikis
Puesto que estamos mirando que hace nuestro wiki en SP, necesito saber por qué no hay que hacerlo para un grupo de 6-desarrolladores de automatización para documentar los pasos en varios procesos automatizados y los cambios que tienen que hacerse de vez en cuando.
Antes de la queja, esta es mi experiencia general con SharePoint como wiki.
Es una característica mal implementada que falló porque había una falta fundamental de investigación sobre lo que ofrecen los entornos wiki actuales. Es por eso que falló en su editor y por qué falla en puntos como: etiquetado, comparación de historial y código html mal generado.
Necesita omitirlo y obtener algo más que haga el trabajo mejor y vincularlo desde SharePoint.
Tener producción experiencia con ambos productos, recomendaría ScrewTurn en SharePoint.
ver editar historia de diatriba
La wiki predeterminada incluida con Sharepoint no es compatible con las funciones comunes de wiki. No hay forma de editar una sola sección de una página, y no hay forma de vincular directamente a una sección en particular en otra página. El back-end está en HTML, por lo que se pierde la capacidad de editar en texto sin formato con sintaxis simple. La característica de diferencia no puede abarcar múltiples versiones. Mala compatibilidad con navegadores cruzados de edición WYSIWYG. No hay forma de insertar automáticamente una tabla de contenido ...
Sin embargo, hay otros complementos wiki para Sharepoint que no puedo descartar categóricamente, por ejemplo Confluence hace un add-in for Sharepoint. No he evaluado este software yo mismo, y Confluence es un poco caro ($ 1,200 para 25 licencias de usuario) aunque si ya está en Sharepoint percibo grandes arcas corporativas: P. También parece haber algunos complementos gratuitos como CKS Enhanced Wiki, pero parece que tiene muchos de los mismos problemas mencionados anteriormente.
Mi compañía lanzó recientemente SharePoint, y tengo que decir que mi experiencia del usuario era Muy malo. Y no solo digo que tenía miedo de usarlo: entré con la mente abierta y lo probé, y muchas cosas simplemente parecían no funcionar correctamente.
Las razones que Lucas mencionó más o menos lo cubren.
¿Por qué no consideraría usar otra cosa como Screwturn Wiki que Jeff donated hace poco tiempo? No he usado Screwturn, pero es gratis y de código abierto, y puede ser una solución ligera más rápida para lo que necesita.
Para un grupo de 6 personas que realizarán ediciones "de vez en cuando", la wiki incorporada estará bien.
Aquí hay algunas advertencias que encontré que se desvanecerán si usa una wiki que no sea Sharepoint.
Sharepoint te permite crear toneladas de wikis por separado, pero te recomiendo tener una gran wiki para todo. Mi compañía creó varios wikis pequeños para cada proyecto/función, pero solo los administradores pueden crear wikis individuales, por lo que si quiero escribir sobre algo que no coincide con una de las categorías predefinidas, tengo que encontrar un gerente para crear la wiki primero.
En segundo lugar, si utiliza Sharepoint asegúrese de que todos los miembros de su personal solo utilicen IE, ya que Firefox no es compatible con el editor WYSIWIG. Esta es una buena cosa para la mayoría de los wikis, pero dificulta la colaboración en Sharepoint. Imagínese la edición de HTML autogenerado en una pequeña caja pequeña todo el día.
En tercer lugar, intente escribir la documentación de su proyecto en la wiki y resista la tentación de cargar documentos de Word en la biblioteca Sharepoint. No tiene sentido escribir todos sus documentos dos veces y ver cómo las cosas se desincronizan cada vez más.
Finalmente, el soporte de imagen en Sharepoint wikis es terrible. Debe agregar un archivo a una biblioteca de documentos en algún lugar y escribir la URL.Mis imágenes fueron borradas para siempre porque no parecen tener mucho sentido fuera de contexto.
FWIW, el producto Telerik "RadEditor Lite" es un reemplazo gratuito para el control de edición enriquecido específico de IE en SharePoint que tiene la misma funcionalidad que el básico. Funciona en Firefox 2 y Chrome, al menos. http://www.telerik.com/community/free-products.aspx –
La versión gratuita del "RadEditor" ahora se llama "ASP.NET RadEditor for MOSS Lite Edition" en la página @ChrisFarmer vinculada a. Parece que solo funciona con Sharepoint 2007, pero podría estar equivocado. Una versión de Sharepoint 2010 no es gratuita. – Aardvark
No vuelvo a escribir la URL. Hago clic con el botón derecho en el enlace del documento (imagen), hago clic en copiar en el menú contextual y lo pego en el cuadro de URL. Ahorra bastante tiempo sobre la escritura. Con un poco de previsión y planificación, debería ser capaz de generar primero una buena parte de las imágenes que necesitará, cargarlas y luego vincularlas a medida que escribe. –
Sharepoint Wiki es esencialmente una lista de Páginas HTML estáticas, con la única característica Wiki que es [[artículo]] enlaces. Sin plantillas, sin categorías, nada.
Terminamos teniendo una MediaWiki separada y solo usamos la wiki Sharepoint para contenido basado en texto que no necesita mucho diseño.
He jugado muy brevemente con SharePoint Wiki Plus. Es una extensión de terceros que agrega funciones al Wiki de SharePoint. Para usuarios de wiki serios, probablemente necesites algo más que el Wiki provisto por SharePoint, ya sea a través de una extensión o un producto Wiki dedicado.
Miramos en Sharepoint una wiki de departamento hace unos meses. Aunque somos principalmente una tienda de MS, fuimos con DokuWiki. Código abierto, tan fácil de mantener actualizado, grandes complementos y un back-end basado en archivos.
Nos encontramos con este tema todo el tiempo, y la primera pregunta que he hecho a las personas es "¿Por qué necesitas una wiki"? Casi siempre las respuestas son cosas como "facilidad de edición", "múltiples colaboradores" y "Word es para el peso pesado". Muy rara vez hemos visto a nadie preguntar por lo que considero que son características exclusivas del wiki (marcado "mágico" especial, historial de versiones detalladas que muestra cambios, etc.). Además, generalmente quieren algún tipo de categorización de las cosas, no solo páginas completamente libres.
En el mundo de SharePoint estas cosas deberían gritarte "lista" si has estado trabajando con la herramienta por un tiempo. Básicamente, no hay ninguna razón particular para usar una wiki para estas aplicaciones de estilo de base de conocimiento, especialmente porque la "facilidad de edición" generalmente entra en conflicto directamente con la idea de aprender un lenguaje de marcado especial para la mayoría de los usuarios. A través de un par de columnas de texto enriquecido, y ya está todo listo. Si realmente no te gusta el editor de texto enriquecido (sí, el proceso de carga de imágenes es torpe y no funciona en Firefox), haz que alguien de tu organización deje caer los 8 Benjamins y ve a buscar el RadEditor for SharePoint. Debería manejar esas preocupaciones.
En general, una vez que hemos superado el dogma "pero tiene que ser un wiki", hemos tenido una muy buena recepción de clientes al solo usar listas. En algunos casos, cuando se requirió un poco más de una función de creación de plantillas de páginas, recurrimos a las funciones de WCM de MOSS, lo que requiere un poco más de pensamiento inicial sobre las plantillas, pero también una mejor experiencia inmediata para cosas como fragmentos de contenido y manejo de imágenes.
No es un dogma, es lo que los usuarios esperan y usarán realmente. Las listas son una gran molestia en comparación con la naturaleza de "solo edítelo para que sea lo que queremos" de los wikis. –
No olvide el Kit de comunidad para Sharepoint - Enhanced Wiki Edition. Esto agrega algunas características a la versión original.
Tengo una visión mucho más positiva de Sharepoint Wiki de Microsoft. En muchos sentidos, me recuerda a FrontPage 98, y ese fue un producto injustamente difamado.
El comentario sobre el uso de una lista está equivocado. Sharepoint Wikis ARE listas de Sharepoint, en las que cada página es un elemento de la lista con un archivo adjunto HTML.
Es cierto que no se puede vincular a una página, pero si las páginas son cortas, no lo veo como un problema. SP Wiki hace que sea muy fácil tener páginas cortas.
Puede manipular los atributos de Wiki desde Access 2008 si lo desea, y puede agregar atributos a los elementos de la lista de la wiki como desee. Por ejemplo, ¿quieres categorías? Solo agréguelos editando la lista. ¿Quieres vistas específicas? de artículos de la lista. Créelos también.
Hay una genialidad real en la forma en que Microsoft construyó su framework Wiki en la cima de las listas de Sharepoint, que sin dudas están bien hechas.
El fabuloso inconveniente de Sharepoint Wiki fue mencionado por famerchris. El enfoque de la administración de imágenes es sorprendentemente horrible. Es un problema tan grave que debería considerar otras Wikis solo por esta razón.
Hay una solución enrevesada que uso. Aprovecha la excelente compatibilidad con Sharepoint y la edición de imágenes integradas con Windows Live Writer.
Esto toma sorprendentemente poco tiempo, mucho menos que cualquier otra opción que he leído. Lo admito, es complicado.
Aparte de los problemas de imagen, estoy satisfecho e impresionado con el producto. Si solo Microsoft hubiera pensado más sobre las imágenes ... si solo ...
Esta respuesta tiene mucho valor si la decisión de usar SP ya se ha tomado. LiveWriter alivia el dolor enormemente. Abra la entrada del blog publicada en el modo de edición, pegue el contenido en el cuadro de diálogo Crear página SP Wiki, realice los ajustes necesarios y sea bueno. ¡Gracias! – TheZenker
¿Por qué no crear una biblioteca de documentos y llamarla "imágenes", almacenar allí sus imágenes y copiar el hipervínculo directo? De acuerdo, esto es un dolor si alguna vez cambias el nombre de la biblioteca, pero no es más doloroso que si cambiaste el nombre de una carpeta de imágenes en un sitio web ... Es mucho menos intrincado ... –
Yo también atenuaría las clasificaciones de la wiki OOB y su falta de funcionalidad con el nivel técnico de los autores aquí.
Estoy de acuerdo en que el wiki del SP podría calificar solo de nombre, ciertamente cuando se compara con algunas ofertas más robustas, pero recuerde que como administrador, su éxito primario está determinado por la adopción del usuario final. En resumen: por cada característica que agrega un wiki como Confluence, también agrega educación del usuario, sintaxis, etc.
Aunque me encantaría SP wiki para tener más "wiki-like" - hay una cierta e indescriptible satisfacción puede tomarse cuando su CIO agrega una entrada en la wiki de la compañía, o es reconocido por un grupo de asistentes administrativos que encuentran la nueva wiki "revolucionaria".
En resumen: la funcionalidad incorporada puede faltar para los ojos cansados de los profesionales de la tecnología estadounidenses, pero para los tecnológicamente ingenuos, es bastante fácil de entrenar y puede exponerlos a una tecnología de la que pueden haber oído hablar pero que podría nunca (antes de esto) comprender o imaginar el uso.
Como la implementación predeterminada es no una wiki, es editor de HTML.
Si ha utilizado una wiki antes, sabrá la diferencia. Simplemente mira "Tu respuesta" en la parte inferior de esta página para ver la diferencia. Utiliza el marcado en una wiki, que es relativamente fácil de leer y editar. El formato de HTML oscurece completamente lo que está escrito.
Tu punto principal es válido, pero "wiki" simplemente significa "rápido". El marcado expuesto es una tradición arraigada en una base de usuarios técnicamente capaz. La mayoría de las personas son extremadamente desafiadas por la tecnología. Esto es más cierto de las personas a cargo. Ellos están a cargo porque mientras estabas ocupado aprendiendo a hacer cosas, estaban ocupados aprendiendo cómo tomar las cosas. Si insistes en confrontarlos con su incompetencia técnica, eventualmente exigirán su venganza. –
¿Quizás intente http://wordtosharepoint.codeplex.com/ para migrar su contenido de Word a SharePoint? Se encarga de vincular imágenes y la mayoría de otras cosas.
Screwturn es asombroso - y es C#/.Net.
Se supone que Sharepoint 2010 tiene mejores características de wiki, y siempre existe el kit de comunidad de sharepoint. Si puede dejar el Wiki de Sharepoint atrás, siempre puede dirigirse al http://www.wikimatrix.org para encontrar el wiki que le conviene.
Estoy plenamente de acuerdo con lo anterior (Keng). Sea lo que sea que esté dentro de SharePoint (actualmente usando 2010), NO es un Wiki por una posibilidad remota.
Estoy implementando una solución de documentación automatizada, donde extraigo config y otra información (como el marcado perldoc) desde el código fuente y los archivos de configuración XML. Inserta la información en un conjunto de páginas DokuWIKI, completa con el formato de marcado (incluidas las tablas). Sale perfectamente formateado y funciona con un par de decenas de líneas de perl, incluye enlaces internos a páginas de documentos estáticos editados manualmente y soporte para espacios de nombres para que pueda organizar mi información de forma lógica. No hay forma de que yo pueda hacer eso en SharePoint (suspiro - dirección de la compañía) ...
Lo mejor que puedo hacer es tratar de hacer que la plantilla DokuWIKI se parezca al sitio de SharePoint (para mantener el aspecto y la sensación similares) y enlace desde SharePoint. :-(
Mi valor de dos centavos como creador de contenidos wiki y super-usuario, en lugar de un administrador o desarrollador:
Actualmente estoy editando un documento en Sharepoint Wiki mientras escribo esto, y es por hasta el peor editor que he encontrado. Para ser precisos, estoy usando Sharepoint Foundation 2010 (anteriormente conocido como WSS), editando páginas usando IE 9.
Para resumir los problemas que he enfrentado: Al crear El contenido wiki que desea concentrar en el contenido y el motor wiki debe ser tan fácil de usar que sea casi invisible. Con Sharepoint ese no es el caso. Realmente lucho con el editor pseudo-WYSIWYG, teniendo que corregir problemas frecuentes de formateo. lems.
Creo que soy aproximadamente un 15% menos productivo escribiendo contenido wiki con Sharepoint que con ScrewTurn o Wikimedia porque tengo que lidiar con los problemas de formato. Si paso un día escribiendo páginas wiki, perdería aproximadamente una hora tratando de solucionar problemas de formato.
Para fondo: He creado cuatro wikis internos en nuestra compañía: el primero en Wikimedia, el motor wiki detrás de Wikipedia, los siguientes dos en ScrewTurn y el último en Sharepoint. En cada wiki, he escrito entre 50 y 100 páginas.
Tanto en ScrewTurn como en Wikimedia, el editor se ve bastante primitivo: un editor de texto sin formato que utiliza códigos simples de marcado de wiki para formatear. Cada uno tiene una fila de botones que pueden aplicar códigos de marcado para cosas simples como el formato en negrita y cursiva, y para crear enlaces, por lo que los principiantes no necesitan aprender los códigos de marcado de memoria.Si bien los editores parecen simples, resultan ser muy simples de usar, especialmente para solucionar problemas de formato.
Sharepoint Wiki, por otro lado, se ve bien, pero es terrible para la edición. En lugar de utilizar un editor de texto sin formato con marcado wiki, tiene un editor WYSIWYG que se ve mucho más sofisticado que otros editores de wiki. Sin embargo, tiene personalidad, una maldad. A menudo agrega líneas en blanco o cambia el color del texto. Cuando selecciono texto para formatear, vaya al menú desplegable Estilos de marcado para formatearlo, a veces el acto de seleccionar un elemento de la lista desplegable anula la selección del texto seleccionado, por lo que el formato se aplica al texto en una ubicación aleatoria. Insertar texto copiado de Word a veces hace que el editor se duplique o triplique en líneas en blanco entre párrafos en otros lugares de la página. No parece haber una manera fácil de crear una tabla, aparte de escribir HTML.
El mayor problema del editor, sin embargo, es que no se puede ver fácilmente lo que sucede detrás de las escenas, por lo que es difícil solucionarlo. Sí, es posible editar el HTML de la página, pero eso realmente frustra el propósito de una wiki.
La impresión general que obtengo como usuario, es que este es un código de nivel alfa que ha sido golpeado por un interno de verano. Sé que Foundation es la versión gratuita, así que quizás obtengo lo que pagamos, pero no puedo creer que una compañía de software profesional haya lanzado este producto.
Odio el hecho de que no admiten la sintaxis de la tabla mediawiki http://meta.wikimedia.org/wiki/Wiki_markup_tables –
Pero prepárese para el formateo de errores si intenta hacer algo remotamente avanzado, p. Ej. indentación o pegado en correos electrónicos. Una vez quebrado, debe editar las etiquetas HTML complicadas (todas en una sola gota grande) para corregirlas. – Nick