Как оживить корпоративный сайт?

В статье попробую рассказать почему многие корпоративные сайты выглядят заброшенными и что можно с этим сделать на примере неофициальный сайт Университетского Центра Интернет, являющегося реализацией моего видения вопроса построения сайта подразделения университета. Предпосылкой к созданию сайта является результаты анализа ситуации с официальным сайтом центра интернет (не доступен из интернета, но есть на скриншоте справа).
Неофициальный сайт
Официальный сайт Центра Интернет

Типичная организация работы с сайтом в компаниях:

Есть самописный сайт с несколькими десятками страниц и меню навигации, охватывающем основные сферы деятельности организации. Сайт поддерживает один человек, с которым необходимо связаться для обновления информации или добавления чего-то нового. Так как пользователи не имеют прямого доступа к обновлению сайта, они должны либо сказать что и где надо изменить, либо прислать html-код новой статьи. По крайней мере у нас это построено именно так.

Отсюда разворачивается проблема:

  • Не все могут прислать готовый html-код, поскольку не все могут писать сайты.
  • Сотрудникам сложно заставить себя изменять информацию, поскольку необходимо связаться с ответственным в удобное ему время и каким-то образом передать необходимую информацию. Если речь идет об изменениях без сложной верстки, добавления рисунков и т.п., то актуаллизация сводится к  отправке письмом что на что изменить. В случае, если необходимо добавить еще и рисунки или таблицу, то эти рисунки надо выслать вложением, потом подойти к ответственному и словами объяснять что и как надо вставить, куда переместить и как оформить и, по мере верстки статьи, стоять с ответственным рядом.
  • Процесс совместной верстки может занять довольно длительное время и является утомительным для обоих участников. В результате, ответственный и сотрудники не желают заниматься ни добавлением, ни актуаллизацией информации на сайте.
  • Через один - два года работы в таком режиме большая часть событий и информации не отражены на сайте, а, даже то что на сайте есть - успевает устареть.
  • Сайт превращается в пустую формальность. Он есть, но его можно заменить сайтом-визиткой из четырех страниц и никто ничего не потеряет.   

Решение проблемы:

Дебюрократизировать процесс добавления и изменения информации, вообще избавившись от ответственного. Все сотрудники сами добавляют любую информацию и сами могут изменять любые статьи, в том числе и других сотрудников. Добавление информации должно быть простым, без предмодерирования и осуществляться сразу на сайт с использованием WYSIWYG-редакторов.
Итак, если сотруднику надо что-то поменять, он просто заходит на сайт, нажимает кнопку редактирования и меняет. Если надо добавить, нажимает кнопку "создать" и в визуальном редакторе составляет текст, вставляет картинки с таблицами и сам на сайте верстает статью.
Визуальные редакторы - наше все!

При таком подходе вытекают следствия:

  1. Иерархическое меню, по которому можно добраться с главной страницы сайта в любую область, более невозможно. От таких меню необходимо вообще отказаться, заменив  поиском и навигацией при помощи тегов.
  2. Будет значительное сопротивление старшего поколения сотрудников, в принципе не воспринимающих возможность существования официального сайта без предмодерации.
  3. Существенно больший объем информации и рост числа авторов приводит к тому, что никто толком не знает где и что лежит и, через некоторое время, часть информации просто не будет соответствовать действительности.
  4. В процессе совместного написания и редактирования статей возможна ситуация, когда человек А перезаписывает статью еще нужную человеку Б. Чтобы избежать потери данных, следует использовать сайт с поддержкой ревизий статей (как в википедии), тогда, даже если сотрудник при редактировании что-то случайно удалит, можно будет всегда посмотреть изменения или откатиться к предыдущей версии.

Популярные сообщения из этого блога

Мастерим компьютер для прямых интернет трансляций и записи с видеокамеры или системы ВКС

Тестирование производительности Drupal: MySQL vs PostgreSQL часть 2