Сведения о вопросе

FUTER

04:55, 3rd August, 2020

Теги

Sharepoint Вики

Просмотров: 518   Ответов: 17

Хорошо, я видел несколько сообщений, которые упоминают несколько других сообщений о том, что не используют SP Вики, потому что они отстой.

Поскольку мы рассматриваем выполнение нашей wiki в SP, мне нужно знать, почему мы не должны делать это для группы из 6 разработчиков автоматизации, чтобы документировать шаги в различных автоматизированных процессах и изменения, которые должны быть сделаны время от времени.



  Сведения об ответе

crush

14:50, 11th August, 2020

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

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

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

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

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


  Сведения об ответе

9090

13:45, 7th August, 2020

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

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

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

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

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

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

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

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

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

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


  Сведения об ответе

ITSME

17:16, 3rd August, 2020

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

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


  Сведения об ответе

прога

11:06, 28th August, 2020

Мы постоянно сталкиваемся с этой темой , и первый вопрос, который я задаю людям, - это "зачем вам нужен wiki"? Почти всегда ответы - это вещи "ease of editing", "multiple contributors", and "Word is to heavyweight". Очень редко мы видели, чтобы кто-то спрашивал о том, что я считаю уникально wiki-подобными функциями (специальные "magic" markup, мелкозернистая история версий, показывающая изменения и т. д.). Кроме того, они обычно хотят какой-то категоризации вещей, а не просто полностью свободной формы страниц.

В мире SharePoint эти вещи должны кричать "list" на вас, если вы уже некоторое время работаете с инструментом. В принципе, нет никакой особой причины использовать wiki для этих приложений в стиле базы знаний, тем более что "ease of editing" обычно напрямую конфликтует с идеей изучения специального языка markup для большинства пользователей. Там есть пара колонок с богатым текстом, и все готово. Если вам действительно не нравится встроенный редактор rich-text (да, процесс загрузки изображений неуклюж, и он не работает в Firefox), попросите кого-нибудь в вашей организации отказаться от 8 Benjamins и получить RadEditor для SharePoint . Он должен в значительной степени справиться с этими проблемами.

Как правило, как только мы преодолели догму "but it needs to be a wiki",у нас был довольно хороший прием клиентов, чтобы просто использовать списки. В некоторых случаях, когда требовалось немного больше возможностей для создания шаблонов страниц, мы обращались к использованию функций WCM из MOSS, что требует немного более продуманного подхода к шаблонам, но также имеет лучший внешний опыт для таких вещей, как фрагменты контента и обработка изображений.


  Сведения об ответе

PAGE

03:16, 8th August, 2020

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

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


  Сведения об ответе

+-*/

20:54, 6th August, 2020

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

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

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

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

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

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

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

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

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


  Сведения об ответе

ASER

13:30, 1st August, 2020

Для группы из 6 человек, которая будет делать "every now and then" правок, встроенный wiki будет в порядке.


  Сведения об ответе

dump

16:27, 11th August, 2020

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

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


  Сведения об ответе

FAriza

09:06, 13th August, 2020

Не забудьте о наборе сообщества для Sharepoint-Enhanced Wiki Edition . Это добавляет некоторые функции к версии out of the box.


  Сведения об ответе

DO__IT

00:01, 8th August, 2020

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

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

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

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

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


  Сведения об ответе

PAGE

06:24, 10th August, 2020

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

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

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


  Сведения об ответе

prince

21:06, 1st October, 2020

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


  Сведения об ответе

9090

19:04, 4th August, 2020

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

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

В то время как я хотел бы SP wiki иметь больше "wiki-like" - есть определенное, неописуемое удовлетворение, которое вы можете получить, когда ваш CIO добавляет запись в компанию wiki - или вас узнает группа административных помощников, которые находят новый wiki "revolutionary".

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


  Сведения об ответе

lool

18:48, 5th August, 2020

Я полностью согласен с вышесказанным (Кенг). Независимо от того, что эта вещь находится в пределах SharePoint (в настоящее время используется 2010), это NOT a Wiki с большой вероятностью.

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

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


  Сведения об ответе

dump

05:53, 4th August, 2020

Screwturn-это очень круто, и это C# /. Net.

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


  Сведения об ответе

fo_I_K

05:37, 26th August, 2020

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


  Сведения об ответе

davran

00:56, 10th August, 2020

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


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться