В марте 2002 года Совет по карьере выпускников Австралии (GCCA) обратился к нам с просьбой изучить вопрос о редизайне веб- сайта gradlink и внедрить систему управления контентом (CMS). В этом тематическом исследовании рассматривается перестройка веб- сайта gradlink с использованием системы управления контентом eZ publish с открытым исходным кодом.
Сайт
Веб- сайт gradlink — это ресурс, разработанный в первую очередь для того, чтобы помочь австралийским выпускникам найти работу Он также помогает работодателям в службах найма выпускников и карьерного роста найти работу для выпускников и помогает им в процессе найма.
Сайт был впервые построен в середине 1990-х годов с собственной системой вакансий. Позже это было передано в поисках кампуса. Остальная часть сайта состояла из статического HTML и претерпела ряд изменений. До этого проекта самый последний редизайн был в 1998 году.
Первоначально все обслуживание сайта было передано сторонним фирмам, занимающимся веб-разработкой, в то время как GCCA постепенно приобрела достаточно внутренних навыков для управления большей частью сайта внутри страны. К сожалению, за четыре года, прошедшие с момента последней реконструкции и перестройки, сайт стал намного больше и, следовательно, его стало сложнее управлять и поддерживать. Это было время для капитального ремонта.
Краткое
Еще до того, как были рассмотрены проекты или пакеты CMS, GCCA провела опрос пользователей, чтобы выяснить , кто использовал gradlink , для чего они его использовали и какие улучшения хотели бы получить пользователи.
Результаты опроса были открыты для глаз. Сайт всегда был разделен на три основных раздела: один для студентов, один для работодателей и один для службы занятости. Опрос показал, что более 80% посетителей gradlink были студентами, примерно 10% были службами по трудоустройству и только 2% были работодателями. Подавляющая причина для студентов, приезжающих на место, состояла в том, чтобы найти работу — средство, которое GCCA передало в поисках Кампуса.
Было три ключевых результата, которые GCCA хотела от восстановления gradlink .
- Придайте сайту современный, чистый профессиональный вид.
- Добавьте средство поиска работы, в которое интегрирована база данных вакансий Seek Campus и собственный каталог работодателей GCCA Graduate Opportunities (GO) .
- Внедрить CMS, которая позволит GCCA поддерживать сайт внутри компании.
Смотри и чувствуй
designIT смоделировал многие проекты «внешнего вида», чтобы получить обратную связь от gradlink относительно того, какие из них соответствовали ее целям по представлению организации в Интернете. Поскольку сайт является главной входной дверью и ресурсом для организации, он должен был представлять намерение и отношение GCCA и быть удобным для пользователей на всех «рынках». В то время как 80% пользователей были признаны студентами, финансирование организации поступает из учреждений, поэтому их потребности были в равной степени важными, даже если они составляли группу меньшинств.
Почему бы не построить с нуля?
Мы обсуждали создание индивидуального решения с нуля с GCCA, но настоятельно рекомендовали против этого. Пять лет назад это было бы серьезным вопросом, но с тех пор рынок решений CMS значительно вырос. Требования к новому сайту gradlink соответствуют стандартным предложениям решений CMS. Идея строительства с нуля практически не имела преимуществ и сопровождалась множеством недостатков, таких как время, стоимость и проблемы обслуживания. Решение пойти с готовым решением было легко принять.
Определение решения
Чтобы выбрать CMS, мы начали с этапа сбора требований, который проводился в течение серии длительных совещаний по 3-4 часа каждое.
На этом этапе был подготовлен документ с требованиями, в котором указывалось, что нужно GCCA на новом сайте gradlink . Следующим шагом было преобразование этих требований в функциональную спецификацию. Мы сделали это, создав карту сайта, а затем изготовили каркасные рамки для каждого основного раздела сайта, определив каждый из элементов экрана вместе с применимыми бизнес-правилами.
Требования сказали нам, что сайт должен был достичь. Функциональные спецификации обеспечили план того, как мы собирались это сделать.
Выбор CMS
Было два ключевых элемента, которые мы должны были учитывать при выборе CMS. Первым и самым важным был бюджет: чем больше будет стоить CMS, тем меньше мы будем тратить на разработку и внедрение.
Вторым элементом была его функциональность. В идеале мы надеялись найти решение с открытым исходным кодом, в котором была бы вся необходимая функциональность, но без соответствующей платы за лицензию. Конечно, такого понятия, как бесплатный обед, не существует, и есть вероятность, что решение с открытым исходным кодом потребует больше работы, чем коммерческий продукт. Это был вопрос баланса усилий, необходимых для реализации решения, с преимуществами продукта с открытым исходным кодом без лицензионного сбора.
Нашим первым шагом в выборе CMS было объединение требований и функциональной спецификации в список функций. Мы обнаружили, что существует 18 областей функциональности, которые должна обеспечить CMS. При поиске в Интернете потенциальных решений мы обнаружили, что доступны десятки открытых решений.
При выборе конечного решения первым шагом было выяснить, предоставляет ли решение полный набор функций. Это устранило многие из найденных нами решений, и в итоге мы получили краткий список из 10 возможных вариантов, которые мы зафиксировали в матрице оценки. Затем мы более внимательно рассмотрели каждое из 10 включенных в короткий список решений и проанализировали такие факторы, как:
- Было ли это активно поддерживаться сообществом открытого кода?
- Насколько зрелым было решение?
- Это развивалось по нескольким версиям?
- Было ли решение использовано для коммерческих сайтов?
- Была ли хорошая документация и поддержка?
- Было ли это легко понять и использовать?
Это сократило список до трех возможных решений. Затем мы получили копию каждого решения и установили все три, чтобы ближе познакомиться с базовой архитектурой и структурой. Это также было важно для того, чтобы дать нам представление о том, насколько простым было решение использовать с точки зрения клиента, поскольку GCCA необходимо будет использовать выбранное решение для поддержки сайта. В конце концов, решение, которое, по нашему мнению, было лучшим на всех фронтах, было опубликовано eZ, разработанным системами eZ в Норвегии.
Поэтапный подход
У нас были полные требования и функциональные спецификации, и мы знали, какую CMS мы собираемся внедрить. После того, как мы вернулись к основам, стало очевидно, что объем проекта и, следовательно, бюджет были намного больше, чем ожидалось.
Проблема заключалась в том, что все функциональные возможности были важны и необходимы, но изначально не могли быть предоставлены. Таким образом, мы расставили приоритеты в требованиях, чтобы установить минимальные функциональные возможности, необходимые для первоначального запуска, и назвали это Этап 1. Остальные функциональные возможности были приоритезированы на Этапы 2 и 3, которые будут реализованы позже.
Приоритетный подход был основан главным образом на бюджете, но мы также чувствовали, что важно запустить CMS и на некоторое время поработать с ней GCCA, после чего мы могли бы рассмотреть этапы 2 и 3, извлекая пользу из их знаний и опыта. опыт работы с системой.
Тестовая реализация
Поскольку мы не внедрили публикацию в eZ ранее, мы знали, что в первой реализации будет крутая кривая обучения. Вместо того, чтобы справляться с этой кривой обучения на сайте gradlink, мы решили потратить наше собственное время и ресурсы на выполнение тестовой реализации на нашем собственном сайте, поэтому мы могли быть уверены, что это правильное решение для GCCA.
Что мы обнаружили при реализации публикации eZ на нашем собственном сайте, так это то, что фактическая реализация была легкой частью — определить структуру и то, как она должна была работать, было сложнее. По сути, нам пришлось деконструировать наш сайт на каждый элемент, а затем настроить публикацию в eZ для сборки элементов для создания веб-сайта.
Эти элементы мы определили как:
- Типы контента — структура фактического контента на сайте, каждый со своими атрибутами. Например, одним типом контента была статья, в которой были заголовок, автор, дата, основная копия и изображение.
- Шаблоны — как должен отображаться контент. Шаблоны учитывали внешний вид: в основном, HTML и графику, которая обеспечивала структуру страницы и определяла, как будет выглядеть контент.
- Правила — какой контент должен был отображаться с каким шаблоном в какие разделы сайта? Например, профили сотрудников появились только в разделе «о» сайта.
Какая версия?
В тот момент, когда мы выполнили тестовую реализацию, должна была быть выпущена последняя версия (3.0), но задержки означали, что был доступен только кандидат на выпуск (RC2). Это значительно изменило наши планы, так как мы ожидали, что сможем использовать новые функции, предоставляемые новой версией на сайте GCCA. Мы не хотели внедрять старую версию, а затем, в течение нескольких месяцев, должны были перейти на новую версию, так как в долгосрочной перспективе это будет стоить дороже.
Мы подробно обсудили эту проблему с GCCA и сравнили сроки реализации с предыдущей версией и самой последней версией. В итоге, в соответствии с нашей рекомендацией, GCCA решила отложить крайний срок на 2 недели, чтобы дать нам дополнительное время, необходимое для ожидания выпуска последней версии программного обеспечения CMS.
Когда пришло время начать работу над реальной реализацией, окончательная версия программного обеспечения была еще не готова, и мы были вынуждены продолжить работу над последним кандидатом на выпуск. Финальная версия была выпущена во время нашей реальной реализации, но к тому времени было уже слишком поздно переходить на финальную версию. Это вызвало две незначительные, но раздражающие проблемы. Во-первых, нам пришлось реализовать некоторые обходные пути для ошибок, которые не будут исправлены до окончательного выпуска.
Во-вторых, редактор контента WYSIWYG не был доступен до финальной версии. Это означало, что GCCA придется иметь дело с ручным форматированием контента с использованием HTML-тегов.
Реальная реализация
Изучив многое из публикации eZ в нашей тестовой реализации, мы приступили к определению типов контента, шаблонов и правил для сайта gradlink, которые мы скомпилировали в документ по информационной архитектуре.
Нам потребовалось несколько итераций, чтобы довести информационную архитектуру до такой степени, что мы почувствовали, что готовы начать работу над сайтом. Самым сложным в определении информационной архитектуры была возможность абстрагировать контент от представления и понять, как создать сайт из комбинации типов контента и шаблонов. Это был сложный переход от простого создания сайтов на основе страниц. Например, однажды введенная часть контента может появляться в разных местах на сайте по-разному. Нам пришлось использовать все эти возможности, чтобы сайт работал должным образом. Чрезвычайно важно было правильно настроить информационную архитектуру, чтобы управление контентом было простым для GCCA, и чтобы оно было представлено осмысленным образом для конечного пользователя.
То, что нам потребовалось примерно 10 месяцев, чтобы определить и спланировать от опроса пользователей до информационной архитектуры, заняло чуть меньше двух месяцев.
Содержание Население
Это была настоящая проверка того, насколько хорошо мы справились с информационной архитектурой.
Когда GCCA начал вводить контент, мы обнаружили, что у нас была большая часть системы, но есть некоторые типы контента, которые мы не обслуживали, такие как статьи, которые занимали более одной страницы, и контактные данные. Кроме того, мы подумали, что тип контента статьи будет достаточно гибким для обработки информации о событиях, но когда мы увидели, что она отображается на сайте, мы обнаружили, что она не совсем работает: нам нужно было предоставить другой тип контента только для событий. Были и другие вещи, такие как привязки страниц, которые мы принимаем как должное на статических сайтах, но которые нелегко разместить в CMS.
GCCA подготовилась к этапу заполнения контента, взяв весь контент на текущем сайте и сохранив его в файлах Microsoft Word в папках, чтобы отразить новую структуру. В ходе этого процесса сотрудники обнаружили, что это не так просто, как вырезать и вставлять из одного места в другое. Клиент также нашел репликацию на существующем сайте и должен был отредактировать некоторый контент, чтобы убедиться, что он вписывается в новый сайт.
Чтобы начать GCCA, мы провели тренинг о том, как работает eZ publish. Экраны администрирования были очень удобными для пользователей, и мы обнаружили, что людям достаточно комфортно, чтобы найти дорогу и войти в контент. Трудность заключалась не столько в вводе контента, сколько в понимании того, как этот контент будет отображаться на Веб-сайте, то есть в понимании отделения контента от презентации.
На этапе наполнения контента нам пришлось решить несколько вопросов, но в целом все прошло довольно гладко. Самой большой проблемой было количество форматирования HTML, которое нужно было сделать с контентом, и другие «глючные» проблемы с версией публикации eZ, которую мы использовали (релиз-кандидат 2). В этой версии, кроме отсутствия онлайн-редактора WYSIWYG, были и другие незначительные ошибки, такие как добавление лишних пробелов, что затрудняло предварительный просмотр без предварительной публикации статьи. Это потребовало пересмотра и повторного редактирования, чтобы система работала правильно.
Все эти проблемы были решены, когда код был обновлен до финальной версии eZ 3 через несколько месяцев.
Интеграция поиска работы
Одним из требований нового сайта было предоставление пользователям возможности поиска работы, использующей данные Seek Campus и Graduate Opportunities. Мы создали его как отдельный проект и интегрировали в публикацию eZ, чтобы он был понятен с точки зрения пользователя.
Первоначально мы интегрировали поиск работы непосредственно в код публикации eZ. Хотя это работало, это означало, что обновление eZ publish потребовало бы, чтобы функция поиска работы реинтегрировалась при каждом обновлении.
В eZ publish 3 включены примеры и документация, подробно описывающие создание пользовательских модулей. Вооружившись этой информацией, мы создали функцию поиска работы в виде пользовательского модуля. Это означало, что функциональность не зависела от основного распространения публикации eZ и значительно упростила процесс обновления.
Поддержка и документация
Мы приобрели поддержку предприятия у eZ publish, чтобы мы могли ответить на наши вопросы в течение 24 часов. Поскольку eZ publish создается норвежскими системами eZ, мы не можем полагаться на местный контакт или на поддержку по телефону. Это сделало поддержку по электронной почте очень важной.
В целом мы были впечатлены качеством и профессионализмом службы поддержки публикации eZ. Было только два случая, когда сервис не оправдал ожиданий. В обоих случаях вопросы поддержки были даны ответы в разумные сроки, но не в течение объявленных 24 часов. Первое из них было связано с тем, что персонал поддержки был перегружен, и когда мы запрашивали уровни поддержки, мы получили час поддержки и заверили, что это больше не повторится. Второй инцидент произошел из-за норвежского государственного праздника.
В результате нашего опыта поддержки мы связались с командой менеджеров eZ Systems, чтобы рассказать о наших проблемах. Мы получили ответ, в котором говорилось, что они работают над совершенствованием процедур поддержки, чтобы они могли лучше обслуживать иностранных клиентов.
Что нас действительно расстраивало, тем не менее, был уровень документации, окружающей продукт. Поскольку у нас не было доступа к учебным курсам, наше изучение и понимание публикации eZ в значительной степени зависело от экспериментов, пользовательских форумов и чтения исходного кода. Когда документации было недостаточно, нам, в основном, приходилось учиться нелегко, пытаясь что-то сделать самим. Это привело к значительному количеству проб и ошибок, прежде чем мы разработали лучший способ реализации вещей. С тех пор мы увидели улучшения в документации, и системы eZ взяли на себя обязательства по дальнейшему улучшению документации.
Конечный результат
Новый сайт gradlink был запущен 21 марта 2003 года. Сайт работал хорошо, и теперь GCCA полностью контролирует его. Примерно через месяц после того, как мы начали работу, мы провели с GCCA обзор проекта, чтобы совместно выяснить, что прошло хорошо и что можно было улучшить.
Что прошло хорошо?
- Доставлено вовремя
- Выглядела великолепно
- Получил положительные отзывы от пользователей, клиентов и заинтересованных сторон
- DesignIT и GCCA хорошо работали как команда
- Хорошее планирование заранее
- Опрос пользователей помог сфокусировать проект
- Открытое общение с обеих сторон привело к тому, чтобы давать и получать советы
- Высокий уровень доверия с обеих сторон
- Интеграция с Seek и GO была простой
Что можно было бы улучшить?
- Более тщательный анализ контента, чтобы увидеть, как он вписывается в CMS и какие типы контента определены
- Выбор зрелого продукта (например, не кандидата на выпуск) для снижения риска задержек и сложности в использовании.
Пять месяцев спустя
Примерно через 2 месяца после запуска мы планировали и работали над значительно сокращенным этапом 2, который был в основном косметическим обновлением, но, что более важно, включал окончательную версию (3.0) публикации eZ. Это исправило некоторые из временных решений, которые мы внедрили для своевременного запуска, и улучшило производительность сайта за счет лучшего кэширования и управления шаблонами. Сейчас мы планируем следующий этап, чтобы еще больше расширить функциональность.
В заключение
В конечном итоге проект имел большой успех.
Каждый этап проекта был ценным в формировании следующего этапа и, в свою очередь, конечного результата. Опрос пользователей помог сформировать требования, которые помогли сформировать функциональные спецификации и так далее. Определенно были моменты, когда мы чувствовали, что тратим слишком много времени на документирование и недостаточно времени на сборку. Но скорость, простота внедрения и небольшое количество изменений, которые потребовались после запуска, доказали, что усилия, потраченные заранее, того стоили; мы продолжим пожинать плоды, планируя этап 3.
EZ publish, как продукт, зарекомендовал себя как качественное решение, а системы eZ — профессиональная организация, с которой приходится иметь дело. Продукт хорошо поддерживается, и будущие выпуски добавят ценные функции.
Определение информационной архитектуры — вот где реальная проблема и реальная ценность заключаются в реализации CMS.