template teams office microsoft library knowledge sharepoint automation sharepoint-wiki

sharepoint - teams - office 365 wiki



Sharepoint Wikis (17)

Antes de la diatriba, aquí está mi experiencia general con SharePoint como wiki.

Se trata de una función implementada deficientemente 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.

Debe omitirlo y obtener algo más que haga el trabajo mejor y vincularlo desde SharePoint.

Al tener experiencia en producción con ambos productos, recomendaría ScrewTurn sobre SharePoint.

ver el historial de edición para despotricar

Ok, he visto algunas publicaciones que mencionan algunas otras publicaciones sobre el uso de SP wikis porque apestan.

Ya que estamos buscando hacer nuestra wiki en SP, necesito saber por qué no deberíamos hacerlo para un grupo de 6 desarrolladores de automatización para documentar los pasos en varios procesos automatizados y los cambios que deben hacerse de vez en cuando. .

Aquí hay algunas advertencias que encontré que se desvanecerán si usa una wiki que no sea Sharepoint.

Sharepoint le permite crear toneladas de wikis por separado, pero recomendaría 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 usa Sharepoint, asegúrese de que todos los miembros de su personal solo utilicen IE, ya que Firefox no es compatible con el editor WYSIWIG. Esto es algo bueno 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.

Debido a que la implementación predeterminada no es una wiki, es un editor de HTML .

Si has usado una wiki antes, sabrás 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.

Estoy totalmente 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 de DokuWIKI se asemeje al tipo del sitio de SharePoint (para mantener el aspecto y la sensación similares) y el enlace de SharePoint. :-(

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.

La wiki predeterminada incluida con Sharepoint no es compatible con las características 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 complemento para 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ó sharepoint recientemente, y debo decir que mi experiencia de usuario fue muy mala . 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 por las que Lucas lo mencionó lo cubren más o menos.

¿Por qué no considerarías usar algo como Screwturn Wiki, que Jeff donó hace poco? 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.

Miramos a Sharepoint para 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.

Mis dos centavos valen como creador de contenido wiki y superusuario, en lugar de como administrador o desarrollador:

Actualmente estoy editando un documento en Sharepoint Wiki mientras escribo esto, y es, con mucho, 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 a los que me he enfrentado: al crear contenido wiki, debe concentrarse 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 arreglar problemas frecuentes de formateo.

Estimo 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 alrededor de una hora tratando de solucionar problemas de formato.

Para el 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 elegante, 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.

Nos topamos con este tema todo el tiempo, y la primera pregunta que hice fue preguntarle a las personas "¿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 pocas veces hemos visto a alguien pedir lo que considero características únicas de wiki (marcado especial "mágico", 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 la imagen es torpe y no funciona en Firefox), haz que alguien de tu organización deje caer los 8 Benjamins y ve a obtener el RadEditor para SharePoint. . Debería manejar esas preocupaciones.

Generalmente, una vez que hemos superado el dogma de "pero tiene que ser un wiki", hemos tenido una buena recepción por parte de los 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.

Para un grupo de 6 personas que realizarán ediciones "de vez en cuando", la wiki incorporada estará bien.

Screwturn es asombroso - y es C # / .Net.

Se supone que Sharepoint 2010 tiene mejores características de wiki, y siempre existe el kit comunitario de sharepoint. Si puede dejar el Wiki de Sharepoint atrás, siempre puede dirigirse a http://www.wikimatrix.org para encontrar el wiki que funcione para usted.

Sharepoint Wiki es esencialmente una lista de Páginas HTML estáticas, con la única característica de Wiki que es [[artículo]] enlaces. Sin plantillas, sin categorías, nada.

Terminamos teniendo un MediaWiki separado y solo usamos la wiki Sharepoint para contenido basado en texto que no necesita mucho diseño.

También atemperaré 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 con el 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, para cada función que agrega una 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 satisfacción indescriptible que puede tomar cuando su CIO agrega una entrada en la wiki de la compañía - o es reconocido por un grupo de asistentes administrativos que encuentran el nuevo wiki "revolucionario".

En resumen: la funcionalidad incorporada puede faltarle a los hastiados ojos de los profesionales de la tecnología de los Estados Unidos, pero para los tecnológicamente ingenuos, es bastante fácil entrenar, y puede exponerlos a una tecnología de la que quizás hayan oído hablar pero nunca pudieron (antes de esto ) entender o imaginar el uso.

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 según lo 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 un verdadero genio en la forma en que Microsoft construyó su marco Wiki encima de las listas de Sharepoint, que sin dudas están bien hechas.

El verdadero 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 compleja que uso. Aprovecha la excelente compatibilidad con Sharepoint y la edición de imágenes integradas con Windows Live Writer.

  1. Crea un blog SP que contendrá las imágenes a las que se hará referencia en la wiki.
  2. Use Windows Live Writer para publicar en wiki-image-blog. Coloque su imagen en WLW, vuelva a clasificar según el tamaño según lo necesitado, etc. Si tiene gusto, utilice WLW para escribir su primera versión del texto de la wiki asociada a la imagen también.
  3. Después de publicar en el Wiki, copie y pegue la imagen y el texto en el campo de texto enriquecido del editor Wiki.

Esto toma sorprendentemente poco tiempo, mucho menos que cualquier otra opción que he leído. Lo admito, es complicado.

Además de los problemas de imagen, estoy satisfecho e impresionado con el producto. Si solo Microsoft hubiera pensado más sobre las imágenes ... si tan solo ...