Хорошо, я видел несколько сообщений, в которых упоминаются несколько других сообщений о том, что вы не используете SP wikis, потому что они сосут.
Поскольку мы смотрим на работу с нашей вики в SP, мне нужно знать, почему мы не должны делать это для группы из 6 разработчиков автоматизации для документирования шагов в различных автоматизированных процессах и изменений, которые должны быть сделаны из время от времени.
До разговора, вот мой общий опыт работы с SharePoint как вики.
Это плохо реализованная функция, которая не удалась из-за отсутствия фундаментального отсутствия расследования того, что предоставляет текущая среда вики. Вот почему он не смог в этом редакторе и почему он пропускает такие пункты, как: тегирование, сравнение истории и плохо сгенерированный html-код.
Вам нужно пропустить его и получить что-то еще, что улучшит работу и свяжется с ним из SharePoint.
Имея production опыт работы с обоими продуктами, я бы рекомендовал ScrewTurn над SharePoint.
см. историю изменений для rant
Вот некоторые предостережения, которые я встретил, которые исчезнут, если вы используете вики, отличную от Sharepoint.
Sharepoint позволяет создавать тонны отдельных вики, но я бы рекомендовал иметь одну большую вики для всего. Моя компания создала кучу маленьких вики для каждого проекта/функции, но только админы могут создавать отдельные вики, поэтому, если я хочу писать о чем-то, что не соответствует одной из предопределенных категорий, мне нужно найти менеджер для создания wiki.
Во-вторых, если вы используете Sharepoint, убедитесь, что все ваши сотрудники используют только IE, поскольку Firefox не поддерживает редактор WYSIWIG. Это хорошо для большинства вики, но затрудняет сотрудничество в Sharepoint. Представьте, что вы редактируете автоматически сгенерированный HTML в крошечной коробке весь день.
В-третьих, попробуйте написать свою проектную документацию в вики и не поддаться соблазну загрузить документы Word в библиотеку Sharepoint. Нет смысла записывать все ваши документы дважды и наблюдать за происходящим все больше и больше из-за синхронизации.
Наконец, поддержка изображений в sharepoint wikis ужасна. Вам нужно добавить файл в библиотеку документов и ввести URL-адрес. Мои изображения навсегда удалялись, потому что они, похоже, не имеют особого смысла из контекста.
У меня гораздо более позитивный взгляд на Microsoft Sharepoint Wiki. Во многом это напоминает мне FrontPage 98 - и это был несправедливо злокачественный продукт.
Комментарий об использовании списка ошибочен. Sharepoint Wikis ARE Списки SharePoint, в которых каждая страница является элементом списка с вложением HTML.
Верно, что вы не можете ссылаться на страницу, но если короткие страницы, я не вижу в этом проблемы. SP Wiki упрощает работу с короткими страницами.
Вы можете манипулировать атрибутами Wiki из доступа 2008, если хотите, и можете добавлять атрибуты в элементы списка вики, как пожелаете. Например, вы хотите категории? Просто добавьте их, отредактировав список. Хотите конкретные взгляды? элементов списка. Создайте их тоже.
Там реальный гений в том, как Microsoft построила свою Wiki-структуру поверх списков Sharepoint, - которые, без сомнения, хорошо сделаны.
ИСТИННЫЙ недостаток Sharepoint Wiki был упомянут famerchris. Подход к управлению изображениями на удивление ужасен. Это такая серьезная проблема, что вам следует рассмотреть другие Вики только по этой причине.
Существует сложное обходное решение, которое я использую. Он использует превосходную поддержку Sharepoint и редактирование изображений, интегрированную с Windows Live Writer.
Это занимает удивительно мало времени, гораздо меньше, чем любой другой вариант, который я читал. Я признаю, что он запутан.
Помимо проблем с изображением, я доволен и впечатлен продуктом. Если бы только Microsoft усложнила изображения... если только...
Вики-страница по умолчанию, включенная в Sharepoint, вообще не поддерживает общие функции вики. Невозможно отредактировать один раздел страницы и не иметь возможности напрямую ссылаться на конкретный раздел на другой странице. Бэкэнд в HTML, поэтому вы теряете возможность редактировать в открытом тексте с помощью простого синтаксиса. Функция diff не может охватывать несколько версий. Плохая поддержка браузера WYSIWYG. Невозможно автоматически вставить оглавление...
Существуют, однако, другие надстройки wiki для Sharepoint, которые я не могу категорически отклонить, например Confluence делает надстройка для Sharepoint. Я сам не оценил это программное обеспечение, и Confluence несколько дороже (1200 долларов за 25 пользовательских лицензий), хотя, если вы уже на Sharepoint, я ощущаю большую корпоративную казну: P. Там также есть некоторые бесплатные надстройки, такие как CKS Enhanced Wiki, но, похоже, есть много тех же проблем, о которых говорилось выше.
Мы постоянно сталкиваемся с этой темой, и первый вопрос, который я задал людям: "Зачем вам нужна вики"? Почти всегда ответы - это "легкость редактирования", "несколько вкладчиков" и "Слово - тяжеловес". Очень редко мы видели, что кто-то спрашивает, что я считаю уникальными wiki-подобными функциями (специальная "волшебная" разметка, мелкозернистая история версий, показывающая изменения и т.д.). Кроме того, они обычно хотят какую-то категоризацию вещей, а не только полностью свободных страниц.
В мире SharePoint эти вещи должны кричать "список" на вас, если вы некоторое время работаете с инструментом. В основном нет особых причин использовать вики для этих приложений в базовом стиле знаний, тем более что "простота редактирования" обычно напрямую противоречит идее изучения специального языка разметки для большинства пользователей. Через пару столбцов с богатым текстом, и вы все настроены. Если вам действительно не нравится встроенный редактор полнотекстового текста (да, процесс загрузки изображений неуклюже, и он не работает в Firefox), попросите кого-нибудь в вашей организации сбросить 8 вениаминов и получить RadEditor для SharePoint. Это должно в значительной степени справиться с этими проблемами.
Как правило, после того, как мы преодолели догму "но она должна быть вики", у нас был довольно хороший прием клиентов, просто используя списки. В некоторых случаях, когда требовалось немного больше возможностей для создания шаблонов страниц, мы обратились к использованию функций WCM в MOSS, что требует более пристального внимания к шаблонам, но также имеет лучшее из коробки для таких вещей, как фрагменты контента и обработка изображений.
Поскольку реализация по умолчанию - это не вики, это редактор HTML.
Если вы использовали вики, прежде чем узнаете разницу. Просто посмотрите на "Ваш ответ" внизу этой страницы, чтобы увидеть разницу. Вы используете разметку в вики, которую относительно легко читать и редактировать. Отформатированный HTML полностью затеняет написанное.
Мои два цента стоят как создатель содержимого вики и суперпользователя, а не администратор или разработчик:
В настоящее время я редактирую документ в Wiki Sharepoint, когда я печатаю его, и это самый плохой редактор, с которым я когда-либо сталкивался. Если быть точным, я использую Sharepoint Foundation 2010 (ранее известный как WSS), редактируя страницы с использованием IE 9.
Подводя итог проблемам, с которыми я столкнулся: при создании вики-контента вы хотите сосредоточиться на контенте, а движок вики должен быть настолько прост в использовании, чтобы быть почти невидимым. С Sharepoint это не так. Я действительно борюсь с редактором псевдо-WYSIWYG, вынуждая фиксировать часто возникающие проблемы форматирования.
Я оцениваю, что я примерно на 15% менее продуктивен для написания вики-контента с помощью Sharepoint, чем с ScrewTurn или Wikimedia, потому что мне приходится иметь дело с проблемами форматирования. Если я потрачу день на создание вики страниц я бы потерял около часа, пытаясь исправить проблемы с форматированием.
Для фона: я создал четыре внутренних вики в нашей компании - первый в Викимедиа, вики-движок за Википедией, следующие два в ScrewTurn и последний в Sharepoint. В каждой вики я написал около 50-100 страниц.
В ScrewTurn и Wikimedia редактор выглядит довольно примитивно - простой текстовый редактор, который использует простые коды разметки wiki для форматирования. Каждый из них имеет ряд кнопок, которые могут применять коды разметки для простых вещей, таких как полужирное и курсивное форматирование, и создавать ссылки, поэтому новичкам не нужно учить наизусть коды разметки. Хотя редакторы выглядят просто, они оказываются очень простыми в использовании, особенно для устранения проблем с форматированием.
Sharepoint Wiki, с другой стороны, выглядит гладкой, но ужасной для редактирования. Вместо использования обычного текстового редактора с разметкой wiki у него есть редактор WYSIWYG, который выглядит намного сложнее, чем другие редакторы wiki. Однако у него есть личность, злая. Он часто добавляет пустые строки или изменяет цвет текста. Когда я выбираю текст для форматирования, перейдите в раскрывающееся меню "Разметка стилей", чтобы отформатировать его, иногда действие выбора элемента из раскрывающегося списка отменяет выбранный текст, поэтому форматирование применяется к тексту в случайном месте. Вставка текста, скопированного из Word, иногда заставляет редактор удваивать или утроить пустые строки между абзацами в других местах на странице. Кажется, нет простого способа создания таблицы, кроме написания HTML.
Самая большая проблема с редактором заключается в том, что вы не можете легко увидеть, что происходит за кулисами, поэтому сложно его исправить. Да, можно редактировать HTML-страницу, но это действительно поражает цель вики.
Общее впечатление, которое я получаю как пользователь, заключается в том, что это код альфа-уровня, который был опрокинут летним стажером. Я знаю, что Фонд - бесплатная версия, поэтому, возможно, я получаю то, за что заплатил, но я не могу поверить, что профессиональная компания-разработчик программного обеспечения выпустила этот продукт.
Для группы из 6 человек, которые будут редактировать "время от времени", встроенная вики будет в порядке.
Sharepoint Wiki - это, по сути, список статических HTML-страниц, причем единственной ссылкой Wiki является [[article]]. Нет шаблонов, нет категорий, ничего.
В итоге у нас появился отдельный MediaWiki, и мы используем только виджеты Sharepoint для текстового контента, который не нуждается в макете.
Не забывайте, что Community Kit для Sharepoint - расширенная версия Wiki. Это добавляет некоторые функции в исходную версию.
Моя компания недавно выпустила sharepoint, и я должен сказать, что мой пользовательский интерфейс был Очень плохой. И я не просто говорю, что опасаюсь использовать его: я вошел с открытым умом и попробовал, и многие вещи просто чувствовали, что они действительно не работают правильно.
Причины, по которым Лука упоминал, более или менее охватывают его.
Почему бы вам не подумать об использовании чего-то другого, например Screwturn Wiki, который Джефф пожертвовал на некоторое время назад? Я сам не использовал Screwturn, но он бесплатный и с открытым исходным кодом, и может быть более легким решением для того, что вам нужно.
Мы рассмотрели Sharepoint для вики-раздела несколько месяцев назад. Несмотря на то, что мы в основном являемся магазином MS, мы отправились с DokuWiki. С открытым исходным кодом, так легко следить за обновлениями, отличными плагинами и файловым концом.
Я бы тоже оценил рейтинги OOB-вики и отсутствие функциональности с техническим уровнем авторов здесь.
Я согласен, что SP wiki может претендовать только на имя - конечно, по сравнению с некоторыми более надежными предложениями, но помните, как администратор - ваш основной успех определяется принятием конечного пользователя. Короче говоря, для каждой функции, которую добавляет вики, например, Confluence, она также добавляет обучение пользователей, синтаксис и т.д.
В то время как я хотел бы, чтобы SP wiki имела больше "вики-подобных" - есть определенное, неописуемое удовлетворение, которое вы можете предпринять, когда ваш CIO добавляет запись в вики-компанию - или вы признаны группой административных помощников, которые найти новую вики "революционную".
Вкратце - встроенная функциональность может отсутствовать у измученных глаз технических специалистов, но к технологически наивному, ее довольно легко обучить и можно подвергнуть их технологии, о которой они, возможно, слышали, но никогда не могли (до этого) понять или представить, используя.
Я очень кратко сыграл с SharePoint Wiki Plus. Это стороннее расширение, которое добавляет функции в Wiki SharePoint. Для серьезных пользователей wiki вам, вероятно, нужно что-то большее, чем предоставленная SharePoint Wiki - через расширение или выделенный продукт Wiki.
Возможно, попробуйте http://wordtosharepoint.codeplex.com/ для переноса содержимого Word в SharePoint? Он заботится о связи изображений и большинства других вещей.
Screwturn - злой ужас - и это С#/.Net.
У Sharepoint 2010 должны быть лучшие вики-функции, и всегда есть общий набор sharepoint. Если вы можете оставить ссылку Sharepoint Wiki позади - вы всегда можете перейти к http://www.wikimatrix.org, чтобы найти вики, которая работает для вас.
Я полностью согласен с вышеизложенным (Keng). Независимо от того, что происходит в SharePoint (в настоящее время используется в 2010 году), это НЕ Wiki длинным выстрелом.
Я внедряю автоматическое решение для документирования, где я извлекаю конфигурацию и другую информацию (например, perldoc-разметку) из исходного кода и файлов конфигурации XML. Он вставляет информацию в набор страниц DokuWIKI, включая разметку форматирования (включая таблицы). Он отлично отформатирован и работает с несколькими десятками строк perl, включает внутренние ссылки для редактирования вручную статических страниц документа и поддержку пространств имен, чтобы я мог логически организовывать свою информацию. Я не могу сделать это в SharePoint (sigh-company direction)...
Лучшее, что я могу сделать, это попытаться сделать шаблон DokuWIKI похожим на сайт SharePoint (чтобы он выглядел похожим) и ссылку из SharePoint.: - (