Вики-сайты Sharepoint

Вики по умолчанию, включенная в Sharepoint, вообще не поддерживает общие функции вики. Нет возможности редактировать отдельный раздел страницы и нет возможности напрямую ссылаться на конкретный раздел на другой странице. Серверная часть находится в HTML, поэтому вы теряете возможность редактировать в открытом тексте с использованием простого синтаксиса. Функция сравнения не может охватывать несколько версий. Плохая кроссбраузерная поддержка редактирования WYSIWYG. Нет возможности автоматически вставить оглавление ...

Однако есть и другие надстройки вики для Sharepoint, которые я не могу категорически отклонить, например, Слияние создает надстройка для Sharepoint. Я сам не оценивал это программное обеспечение, а Confluence стоит довольно дорого (1200 долларов за лицензию на 25 пользователей), хотя, если вы уже пользуетесь Sharepoint, я чувствую большую корпоративную казну: P. Также, похоже, есть несколько бесплатных надстроек, таких как CKS Enhanced Wiki, но у них, похоже, есть много тех же проблем, упомянутых выше.

Моя компания недавно запустила sharepoint, и я должен сказать, что мой пользовательский опыт был Очень плохой. И я не просто говорю, что опасался его использовать: я вошел непредвзято и попробовал, и многие вещи просто чувствовали, что они действительно не работают.

Причины, упомянутые Люком, более или менее покрывают это.

Почему бы вам не подумать об использовании чего-то другого, например Вики Сообщества, которое недавно использовалось для Джефф пожертвовал? Я сам не использовал Screwturn, но он бесплатный и с открытым исходным кодом, и может быть более быстрым легким решением для того, что вам нужно.

Для группы из 6 человек, которые время от времени будут вносить правки, встроенная вики подойдет.

Вот некоторые предостережения, с которыми я столкнулся, которые исчезнут, если вы будете использовать вики, отличную от Sharepoint.

Sharepoint позволяет создавать множество отдельных вики, но я бы рекомендовал иметь одну большую вики для всего. Моя компания сделала кучу маленьких вики для каждого проекта / функции, но только администраторы могут создавать отдельные вики, поэтому, если я хочу написать о чем-то, что не соответствует ни одной из предопределенных категорий, я должен найти менеджер, чтобы сначала создать вики.

Во-вторых, если вы используете Sharepoint, убедитесь, что все ваши сотрудники используют только IE, поскольку Firefox не поддерживает редактор WYSIWIG. Это хороший для большинства вики, но затрудняет совместную работу в Sharepoint. Представьте, что вы целый день редактируете автоматически сгенерированный HTML в маленькой коробочке.

В-третьих, попытайтесь написать документацию по проекту в вики и не поддавайтесь искушению загрузить документы Word в библиотеку Sharepoint. Нет смысла писать все свои документы дважды и смотреть, как все больше и больше рассинхронизируется.

Наконец, поддержка изображений в вики-сайтах Sharepoint ужасна. Вы должны добавить файл где-нибудь в библиотеку документов и ввести URL-адрес. Мои изображения навсегда удалялись, потому что они не имели особого смысла вне контекста.

Sharepoint Wiki - это, по сути, список статических HTML-страниц, единственная функция Wiki - это ссылки [[статья]]. Ни шаблонов, ни категорий, ничего.

В итоге у нас появилась отдельная MediaWiki, и мы используем вики-страницу Sharepoint только для текстового контента, который не требует особой разметки.

Я очень коротко поиграл с SharePoint Wiki Plus. Это стороннее расширение, которое добавляет функции в SharePoint Wiki. Для серьезных пользователей вики вам, вероятно, понадобится нечто большее, чем предоставляемая SharePoint Wiki - либо через расширение, либо через специальный продукт Wiki.

Несколько месяцев назад мы смотрели на Sharepoint вики-страницу отдела. Несмотря на то, что мы в первую очередь магазин MS, мы выбрали ДокуВики. Открытый исходный код, который легко поддерживать в актуальном состоянии, отличные плагины и серверная часть на основе файлов.

Мы сталкиваемся с этой темой все время, и первый вопрос, который я задаю людям, это «Зачем вам нужна вики»? Почти всегда ответы - это «простота редактирования», «несколько участников» и «Word слишком тяжеловесен». Очень мы редко видели, чтобы кто-нибудь спрашивал о том, что я считаю уникальными вики-подобными функциями (особая «волшебная» разметка, детализированная история версий, показывающая изменения и т. д.). Кроме того, им обычно нужна какая-то категоризация вещей, а не просто страницы полностью произвольной формы.

В мире SharePoint эти вещи должны кричать вам «список», если вы какое-то время работали с этим инструментом. По сути, нет особой причины использовать вики для этих приложений в стиле базы знаний, тем более что «простота редактирования» обычно напрямую противоречит идее изучения специального языка разметки для большинства пользователей. Через пару столбцов с форматированным текстом, и все готово. Если вам действительно не нравится встроенный редактор форматированного текста (да, процесс загрузки изображений неуклюж и не работает в Firefox), попросите кого-нибудь из вашей организации бросить 8 Benjamins и получить RadEditor для SharePoint. Он должен в значительной степени решить эти проблемы.

Обычно после того, как мы преодолели догму «но это должно быть вики», у нас было довольно хорошее отношение клиентов к тому, чтобы просто использовать списки. В некоторых случаях, когда требовалось немного больше возможностей для создания шаблонов страниц, мы обращались к использованию функций WCM MOSS, что требует более внимательного отношения к шаблонам, но также имеет более удобный интерфейс для таких вещей, как фрагменты контента и обработка изображений.

Не забудьте комплект сообщества для Sharepoint - расширенная вики-версия. Это добавляет некоторые функции в готовую версию.

Я гораздо более позитивно отношусь к Microsoft Sharepoint Wiki. Во многом это напоминает мне FrontPage 98 - и это был несправедливо оклеветанный продукт.

Комментарий об использовании списка ошибочен. Вики-сайты Sharepoint ЯВЛЯЮТСЯ списками Sharepoint, в которых каждая страница представляет собой элемент списка с вложением HTML.

Это правда, что вы не можете ссылаться на страницу, но если страницы короткие, я не вижу в этом проблемы. SP Wiki упрощает создание коротких страниц.

Вы можете управлять атрибутами Wiki из Access 2008, если хотите, и вы можете добавлять атрибуты к элементам списка вики по желанию. Например - вам нужны категории? Просто добавьте их, отредактировав список. Хотите конкретных просмотров? элементов списка. Их тоже создайте.

Есть настоящий гений в том, как Microsoft построила свой фреймворк Wiki поверх списков Sharepoint, что, несомненно, сделано хорошо.

ИСТИННЫЙ недостаток Sharepoint Wiki был упомянут famerchris. Подход к управлению имиджем на удивление ужасен. Это настолько серьезная проблема, что вам следует рассматривать другие вики только по этой причине.

Я использую запутанный обходной путь. Он использует преимущества превосходной поддержки Sharepoint и редактирования изображений, интегрированных с Windows Live Writer.

1. Создайте блог SP, в котором будут храниться изображения, на которые будут ссылаться вики.
2. Используйте Windows Live Writer для публикации в wiki-image-blog. Перетащите изображение в WLW, измените его размер по мере необходимости и т. д. Если хотите, используйте WLW, чтобы также написать первый черновик вики-текста, связанный с вашим изображением.
3. После публикации в Wiki скопируйте и вставьте изображение и текст в текстовое поле редактора Wiki.

Это занимает на удивление мало времени, гораздо меньше, чем любой другой вариант, о котором я читал. Признаюсь, это запутанно.

Помимо проблем с изображением, я доволен продуктом и впечатлен им. Если бы только Microsoft больше думала об изображениях ... если бы ...

Я бы также умерил рейтинги OOB wiki и ее недостаток функциональности с техническим уровнем авторов здесь.

Я согласен с тем, что вики-сайт SP может квалифицироваться только по названию - конечно, по сравнению с некоторыми более надежными предложениями - но помните, как администратор, ваш главный успех определяется тем, насколько он принят конечным пользователем. Короче говоря, для каждой функции, которую добавляет вики, такая как Confluence, также добавляется обучение пользователей, синтаксис и т. д.

Хотя мне бы хотелось, чтобы вики SP был более «похожим на вики» - вы можете испытывать определенное, неописуемое удовлетворение, когда ваш ИТ-директор добавляет запись в вики-страницу компании - или вас узнает группа помощников по административным вопросам, которые находят новый вики "революционер".

Короче говоря, встроенной функциональности может не хватать для измученных глаз технических специалистов, но для технологически наивных ее довольно легко обучить, и они могут познакомить их с технологией, о которой они, возможно, слышали, но никогда не могли (до этого ) понять или представить себе использование.

Поскольку реализация по умолчанию - это нет вики, это Редактор HTML.

Если вы раньше пользовались вики, вы почувствуете разницу. Просто посмотрите на «Ваш ответ» внизу этой страницы, чтобы увидеть разницу. Вы используете разметку в вики, которую относительно легко читать и редактировать. Форматированный HTML полностью скрывает написанное.

Может быть, попробовать http://wordtosharepoint.codeplex.com/ для переноса содержимого Word в SharePoint? Он заботится о связывании изображений и многом другом.

Screwturn ужасно круто - и это C# / .Net.

Предполагается, что Sharepoint 2010 будет иметь лучшие вики-функции, и всегда есть набор сообщества sharepoint. Если вы можете оставить вики-страницу Sharepoint позади - вы всегда можете перейти на http://www.wikimatrix.org, чтобы найти вики, которая вам подходит.

Перед разглагольствованием расскажу о моем общем опыте работы с SharePoint как вики.

Это плохо реализованная функция, которая потерпела неудачу из-за существенного отсутствия исследования того, что предоставляют текущие вики-среды. Вот почему он потерпел неудачу в своем редакторе и почему он упускает из виду такие моменты, как теги, сравнение истории и плохо сгенерированный html-код.

Вам нужно пропустить это и получить что-то еще, что лучше работает, и ссылку на него из SharePoint.

Имея опыт работы с обоими продуктами производство, я бы рекомендовал ScrewTurn поверх SharePoint.

см. историю редактирования для разглагольствования

Я полностью согласен с вышеизложенным (Кенг). Что бы это ни было в SharePoint (в настоящее время используется 2010), это НЕ Wiki, по большому счету.

Я реализую решение для автоматического документирования, в котором я извлекаю конфигурацию и другую информацию (например, разметку perldoc) из исходного кода и файлов конфигурации XML. Он вставляет информацию в набор страниц DokuWIKI вместе с разметкой форматирования (включая таблицы). Он отлично отформатирован и работает с парой десятков строк perl, включает внутренние ссылки на вручную редактируемые статические страницы документов и поддержку пространств имен, чтобы я мог логически организовать свою информацию. Я никак не мог сделать это в SharePoint (вздох - направление компании) ...

Лучшее, что я могу сделать, - это попытаться сделать шаблон DokuWIKI похожим на сайт SharePoint (чтобы внешний вид был похожим) и ссылку на SharePoint. :-(

Мои два цента стоят как создатель вики-контента и суперпользователь, а не как администратор или разработчик:

В настоящее время я редактирую документ в Sharepoint Wiki, набирая его, и это, безусловно, худший редактор, с которым я когда-либо сталкивался. Если быть точным, я использую Sharepoint Foundation 2010 (ранее известный как WSS), редактируя страницы с помощью IE 9.

Подытоживая проблемы, с которыми я столкнулся: при создании вики-контента вы хотите сконцентрироваться на контенте, и движок вики должен быть настолько простым в использовании, чтобы быть почти незаметным. С Sharepoint дело обстоит иначе. Я действительно борюсь с редактором псевдо-WYSIWYG, поскольку мне приходится исправлять частые проблемы с форматированием.

По моим оценкам, я примерно на 15% менее продуктивно пишу вики-контент с помощью Sharepoint, чем с ScrewTurn или Wikimedia, потому что мне приходится иметь дело с проблемами форматирования. Если я потрачу день на написание вики-страниц, я потеряю около часа, пытаясь исправить проблемы с форматированием.

Для справки: я создал четыре внутренних вики в нашей компании - первый в Викимедиа, движок вики, стоящий за Википедией, следующие два в ScrewTurn и последний в Sharepoint. В каждой вики я написал по 50-100 страниц.

И в ScrewTurn, и в Wikimedia редактор выглядит довольно примитивно - это простой текстовый редактор, который использует простые коды разметки для форматирования. У каждой есть ряд кнопок, которые могут применять коды разметки для простых вещей, таких как форматирование жирным шрифтом и курсивом, а также для создания ссылок, поэтому новичкам не нужно заучивать коды разметки наизусть. Хотя редакторы выглядят простыми, они оказываются очень простыми в использовании, особенно для решения проблем с форматированием.

Sharepoint Wiki, с другой стороны, выглядит гладко, но для редактирования подходит ужасный. Вместо использования обычного текстового редактора с вики-разметкой у него есть WYSIWYG-редактор, который выглядит намного сложнее, чем другие вики-редакторы. Однако у него есть личность, лукавая. Он часто добавляет пустые строки или меняет цвет текста. Когда я выбираю текст для форматирования, а затем перехожу в раскрывающийся список «Стили разметки», чтобы отформатировать его, иногда выбор элемента из раскрывающегося списка отменяет выделение выделенного текста, поэтому форматирование применяется к тексту в случайном месте. Вставка текста, скопированного из Word, иногда приводит к тому, что редактор вдвое или втрое увеличивает количество пустых строк между абзацами в других местах страницы. Кажется, нет простого способа создать таблицу, кроме написания HTML.

Однако самая большая проблема редактора заключается в том, что вы не можете легко увидеть, что происходит за кулисами, поэтому это сложно исправить. Да, можно редактировать HTML страницы, но это действительно сводит на нет цель вики.

Общее впечатление, которое я получаю как пользователя, таково, что это код альфа-уровня, придуманный летним практикантом. Я знаю, что Foundation - это бесплатная версия, поэтому, возможно, я получу то, за что мы заплатили, но я не могу поверить, что профессиональная компания-производитель программного обеспечения выпустила этот продукт.