Коллеги из департамента информационных технологий г. Москвы подготовили данный документ и попросили нас собрать комментарии экспертов к нему.

Содержание

1. Основные термины и сокращения
2. 2. Доменные имена
   1. 2.1 Требования
   2. 2.2 Рекомендации
3. Комплектность
   1. 3.1 Система управления сайтом
      1. 3.1.1 Требования
      2. 3.1.2 Рекомендации
   2. 3.2 Поисковая система
      1. 3.2.1 Требования
      2. 3.2.2 Рекомендации
   3. 3.3 Статистика
      1. 3.3.1 Требования
      2. 3.3.2 Рекомендации
   4. 3.4 Версия для слабовидящих
      1. 3.4.1 Требования
      2. 3.4.2 Рекомендации
   5. 3.5 Мобильная версия
      1. 3.5.1 Требования
      2. 3.5.2 Рекомендации
   6. 3.6 Версия для печати
      1. 3.6.1 Требования
      2. 3.6.2 Рекомендации
4. Технологическое исполнение
   1. 4.1 Верстка
      1. 4.1.1 Требования
      2. 4.1.2 Рекомендации
   2. 4.2 Протоколы и форматы передачи данных
      1. 4.2.1 Требования
      2. 4.2.2 Рекомендации
   3. 4.3 Url материалов
      1. 4.3.1 Требования
      2. 4.3.2 Рекомендации
   4. 4.4 Доступность
      1. 4.4.1 Требования
      2. 4.4.2 Рекомендации
   5. 4.5 Надежность
      1. 4.5.1 Требования
      2. 4.5.2 Рекомендации
   6. 4.6 Безопасность
      1. 4.6.1 Требования
      2. 4.6.2 Рекомендации
5. Размещение на аппаратных средствах
   1. 5.1 Требования
   2. 5.2 Рекомендации
6. 6. Оптимизация под поисковые системы
   1. 6.1 Требования
   2. 6.2 Рекомендации
7. Информационное наполнение
   1. 7.1 Текстовые материалы
      1. 7.1.1 Требования
      2. 7.1.2 Рекомендации
   2. 7.2 Изображения
      1. 7.2.1 Требования
      2. 7.2.2 Рекомендации
   3. 7.3 Видеоматериалы
      1. 7.3.1 Требования
      2. 7.3.2 Рекомендации
   4. 7.4 Юридическая информация
      1. 7.4.1 Требования
      2. 7.4.2 Рекомендации
   5. 7.5 Контактная информация
      1. 7.5.1 Требования
      2. 7.5.2 Рекомендации
   6. 7.6 Частота обновления
      1. 7.6.1 Требования
      2. 7.6.2 Рекомендации
8. Визуальное оформление и эргономика
   1. 8.1 Требования
   2. 8.2 Рекомендации

1. Основные термины и сокращения

БД – база данных.

ГОСТ – государственный стандарт.

Домен – это область пространства иерархических имен сети Internet, которая обслуживается набором серверов доменных имен (DNS) и централизованно администрируется.

Доменное имя – это адрес сетевого соединения (например, www.mos.ru), который идентифицирует владельца адреса.

Доменная зона – совокупность доменных имён определённого уровня, входящих в конкретный домен.

Поддомен – домен, являющийся частью домена более высокого уровня.

Редирект – перенаправление.

Фреймворк – каркас программной системы (или подсистемы). Может включать вспомогательные программы, библиотеки кода, язык сценариев и другое программное обеспечение, облегчающее разработку, объединение разных компонентов большого программного проекта и его выполнение.

DNS – Domain Name System, система доменных имен.

HTML – HyperText Markup Language, стандартный язык разметки документов в сети Интернет.

JavaScript – прототипно-ориентированный скриптовый язык программирования.

JSON – текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком

RSA – криптографический алгоритм с открытым ключом, основывающийся на вычислительной сложности задачи факторизации больших целых чисел.

URL – Uniform Resource Locator, стандартизированный способ записи адреса ресурса в сети Интернет.

W3C – World Wide Web Consortium, организация, разрабатывающая и внедряющая технологические стандарты для сети Интернет.

XML – eXtensible Markup Language, структурированный язык разметки данных.

2. Доменные имена

2.1 Требования

1. Права на доменное имя должны принадлежать государственному органу, органу местного самоуправления или подведомственной организации. Категорически запрещается использовать доменные имена, принадлежащие физическим лицам.
2. Права на управление DNS-серверами должны принадлежать государственному органу, органу местного самоуправления или подведомственной организации.
3. Запрещается использовать в доменном имени наименования товарных знаков, права на которые принадлежат другим организациям или физическим лицам.
4. Запрещается использовать в доменном имени слова, оскорбляющие человеческое достоинство, пропагандирующие насилие или экстремизм, разжигающие расовую, национальную или религиозную вражду, а также нецензурную лексику.
5. Запрещается использовать доменное имя в зоне, не контролируемой государственной организацией.
6. Органы исполнительной власти города Москвы, их подведомственные организации, а также проекты общегородского, окружного и районного уровня имеют право на регистрацию доменного имени в зоне mos.ru при соблюдении следующих условий:
   — доменное имя состоит более чем из одного символа;
   — доменное имя начинается и заканчивается буквой латинского алфавита или цифрой;
   — доменное имя состоит из букв латинского алфавита, цифр, знака дефиса;
   — доменное имя не содержит слов «mos», «moskva», «moscow» и т.п.
7. Органы исполнительной власти и общегородские проекты имеют право на регистрацию и использование доменного имени третьего уровня в зоне mos.ru.
8. Подведомственные организации органов исполнительной власти города Москвы, а также проекты окружного и районного уровня имеют право на регистрацию и использование доменного имени четвертого уровня в зоне mos.ru.
9. По согласованию с Департаментом информационных технологий города Москвы допускаются исключения из вышеизложенных требований.

2.2 Рекомендации

1. Для облегчения доступа пользователей к сайту рекомендуется дополнительно использовать кириллическое доменное имя в зоне рф.
2. Рекомендуется регистрировать и использовать короткие, запоминающиеся доменные имена. Рекомендуемая длина доменного имени находится в диапазоне от 10 до 20 символов, включая разделительные знаки.
3. Рекомендуется регистрировать и использовать доменные имена, простые в написании и произношении.
4. Рекомендуется избегать использования в доменном имени символов, которые могут ввести в заблуждение, таких как цифра ноль (0) вместо буквы «O» или цифра один (1) вместо буквы «L».
5. В имени сайта в доменной зоне следует использовать аббревиатуры, акронимы или ключевые слова. При этом аббревиатуры и акронимы лучше использовать в случаях, когда они хорошо знакомы гражданам.
6. Не рекомендуется использовать доменное имя пятого и нижележащего уровня.
7. Рекомендуется использовать одно основное написание доменного имени:
   1. Для доменных имен третьего и четвертого уровня – без префикса www;
   2. Для доменных имен второго уровня – с префиксом www или без него.
8. Для задания основного написания доменного имени рекомендуется применять директиву «Host» в файле robots.txt. Пример использования: Host: www.site.ru.
9. Для автоматического перенаправления пользователей, заходящих по ссылке с использованием не основного написания доменного имени, на страницу сайта с использованием основного написания доменного имени рекомендуется использовать 301 редирект.
10. В целях экономии средств и унификации доменных имен сайтов единого веб-пространства города Москвы рекомендуется регистрировать доменное имя в зоне москва.рф. При этом должны соблюдаться следующие условия:
    1. Доменное имя состоит более чем из одного символа;
    2. Доменное имя начинается и заканчивается буквой русского алфавита или цифрой;
    3. Доменное имя состоит из букв русского алфавита, цифр, знака дефиса.
11. Примеры различных наименований доменных имен:
    1. Полное имя

       Пример: portaluslug.mos.ru

       Преимущества:

       • Точное и полное совпадение домена фактическому названию сайта.

       Недостатки:

       • Сложно запомнить;
       • Легко ошибиться в написании.

       Рекомендации:

       • Следует использовать, только если полное имя короткое и запоминающееся.
    2. Акроним

       Пример: dit.mos.ru

       Преимущества:

       • Короткое, легко читается и запоминается.

       Недостатки:

       • Может быть непонятным для пользователей.

       Рекомендации:

       • Рекомендуется использовать, только если акроним хорошо известен пользователям.
    3. Аббревиатура

       Пример: guminjust.mos.ru

       Преимущества:

       • Короткое

       Недостатки:

       • Может быть непонятным для пользователей.

       Рекомендации:

       • Рекомендуется использовать, только если аббревиатура хорошо знакома пользователям.
    4. Ключевое слово

       Пример: sport.mos.ru

       Преимущества:

       • Короткое, легко читается, пишется и запоминается;
       • Обычно хорошо понятно для пользователей.

       Недостатки:

       • Может восприниматься в очень широком смысле, чем вводить в заблуждение пользователей о типе предоставляемой информации.

       Рекомендации:

       • Рекомендуется использовать в большинстве случаев, предварительно удостоверившись, что пользователи не вводятся в заблуждение. 

3. Комплектность

3.1 Система управления сайтом

3.1.1 Требования

1. Запрещено использование программного обеспечения полностью или частично защищенного авторскими или другими правами, без разрешения владельца или его полномочного представителя.
2. Система управления сайтом должна позволять управлять уровнями доступа пользователей к различным сервисам и возможностям сайта.
3. Должна использоваться модульная архитектура, подразумевающая реализацию основных функций в качестве отдельных модулей, обеспечивающих возможность их независимой модификации. Сбой в работе одного из модулей не должен приводить к полному прекращению функционирования сайта в целом.
4. Должна быть возможность управления всем информационным содержимым сайта.
5. Должна быть возможность задания уникальных заголовков браузера (title), мета-тегов (description, keywords) и URL для всех страниц сайта.
6. Должна быть возможность выделения на странице одного заголовка h1 и, при необходимости, нескольких заголовков более низкого уровня.
7. Должна быть возможностью выделения отдельных слов на странице жирным шрифтом в теге <b> и курсивом в теге <em>, задания  атрибута alt для изображений.
8. Должны поддерживаться цепочки публикаций, позволяющие пропустить материал через ряд инстанций для его окончательного утверждения и публикации.

3.1.2 Рекомендации

1. Использование готовых решений рекомендуется при наличии на стороне производителя гарантированной технической поддержки, обеспечивающей оперативное решение всех вопросов, связанных со стабильностью и безопасностью.
2. Рекомендуется ограничивать средства форматирования информационного содержания страниц через административный интерфейс.
3. Рекомендуется наличие функциональной возможности предварительного просмотра материала перед публикацией.
4. Рекомендуется наличие возможности отложенной публикации материала при достижении заданного времени.

3.2 Поисковая система

3.2.1 Требования

1. Форма поиска должна быть доступна на каждой странице сайта. Поле для ввода поискового запроса должно обеспечивать ввод в видимой области не менее 20 символов.
2. Поиск должен осуществляться по всем текстовым материалам сайта.
3. Результаты поиска должны выводиться на отдельной странице в общем визуальном оформлении сайта. Данная страница должна иметь соответствующий заголовок и содержать поле для ввода нового поискового запроса.
4. Если в результате поиска не были найдены документы, удовлетворяющие поисковому запросу, то пользователь должен быть проинформирован об этом соответствующим образом, кроме того, на странице должна быть предоставлена краткая информация по улучшению поискового запроса.

3.2.2 Рекомендации

1. На сайтах с большим количеством информации рекомендуется наличие функциональных возможностей расширенного поиска по различным параметрам.
2. Рекомендуется наличие возможности раздельного поиска информации по разным разделам сайта.
3. Рекомендуется при поиске учитывать морфологию русского языка.
4. Ввод поискового запроса в форму для поиска рекомендуется сопровождать выводом подсказок.
5. Рекомендуется наличие возможности сортировки результатов поиска по релевантности и дате изменения материала.
6. По умолчанию список результатов поиска рекомендуется сортировать по релевантности.
7. В результатах поиска для каждого документа рекомендуется указывать дату его обновления.

3.3 Статистика

3.3.1 Требования

1. На всех страницах сайта должен быть установлен счетчик, выдаваемый в Департаменте информационных технологий города Москвы.
2. Должна собираться статистика, характеризующая посетителей сайта, а также его популярность в сети Интернет. В частности должны собираться следующие параметры:
   1. посещаемость:
      1. число уникальных посетителей;
      2. число просмотров страниц;
      3.  число сессий;
   2. характеристики аудитории:
      1. демографические (возраст, пол);
      2. географические;
      3. аппаратно-технические (браузер, операционная система, разрешение экрана);
   3. параметры, характеризующие поведение аудитории на сайте:
      1. время нахождения на сайте;
      2. число страниц, просмотренных за одно посещение;
      3. пути перемещений пользователя по структуре сайта;
   4. источники трафика:
      1. сайты-источники;
      2.  поисковые запросы.
3. Статистика сайта должна быть доступна только администраторам сайта.

3.3.2 Рекомендации

1. Рекомендуется использовать счетчик, невидимый для посетителей сайта.
2. Рекомендуется наличие функциональных возможностей по сбору и хранению статистики поисковых запросов.
3. Для определения наиболее востребованных сервисов и возможностей сайта рекомендуется собирать статистическую информацию, характеризующую активность пользователей в рамках соответствующих частей сайта.
4. Рекомендуется собирать и хранить статистическую информацию за весь период существования сайта.

3.4 Версия для слабовидящих

3.4.1 Требования

1. На сайте должна быть специальная версия для слабовидящих.
2. У пользователей не должно возникать сложностей с переходом от обычной версии к версии для слабовидящих и обратно.
3. Версия для слабовидящих должна быть выполнена в соответствии с ГОСТ Р 52871-2007 «ДИСПЛЕИ ДЛЯ СЛАБОВИДЯЩИХ. Требования и характеристики» и ГОСТ Р 52872-2007 «Интернет-ресурсы. Требования доступности для инвалидов по зрению».
4. Должна быть возможность увеличения размера шрифта и выбора различных цветовых схем.
5. Все элементы визуального оформления должны быть отключены в версии для слабовидящих.

3.4.2 Рекомендации

1. Рекомендуется размер шрифта основного текста делать не менее 14 пунктов.
2. Рекомендуется в качестве основной цветовой схемы использовать черный текст на белом фоне.
3. Рекомендуется располагать смысловые элементы сайта друг под другом.

3.5 Мобильная версия

3.5.1 Требования

1. На сайте должна быть специальная версия, адаптированная для просмотра на мобильных устройствах, в том числе на планшетных компьютерах.
2. Должно автоматически определяться устройство пользователя и открываться адаптированная под него версия сайта.
3. Пользователям должна быть предоставлена возможность переключения между обычной и мобильной версией сайта.

3.5.2 Рекомендации

1. Версию сайта, адаптированную для просмотра на мобильных устройствах, рекомендуется размещать на поддомене.
2. Рекомендуется автоматически определять ширину экрана пользовательского устройства и оптимизировать интерфейс под данную ширину.
3. Количество графических элементов рекомендуется делать минимальным, но достаточным для выполнения основных информационных функций.
4. Рекомендуется не использовать тяжелые изображения.
5. Рекомендуется не использовать нестандартные шрифты.

3.6 Версия для печати

3.6.1 Требования

1. У пользователей должна быть возможность отправить на печать любую страницу сайта.
2. Должна быть версия страниц, адаптированная для печати.

3.6.2 Рекомендации

1. Рекомендуется отключать все элементы дизайна (кроме логотипа), навигации и вспомогательные элементы, не имеющие отношения к основному содержимому страницы.
2. Фон версии страницы для печати рекомендуется делать белым, цвет шрифта – черным.
3. Не рекомендуется использовать шрифты с размером менее 8 пунктов.

4. Технологическое исполнение

4.1 Верстка

4.1.1 Требования

1. При верстке должны учитываться семантика элементов DOM'а, принципы вложенности элементов, модульность, семантическая иерархия.
2. Должен использоваться блочный тип верстки. Табличная структура применима там, где по смыслу необходимы таблицы.
3. Файлы верстки должны нести в себе лишь семантическое содержание, то есть в *.html файлах может быть только структура DOM, в *.css файлах – стилевые таблицы, в *.js – только JavaScript код.
4. Страницы сайта должны быть выполнены в соответствии с последними действующими версиями стандартов HTML 4, 5 и CSS 2, 3. При проверке валидатором w3c (http://www.w3.org/) не должно выявляться серьезных ошибок, допускаются предупреждения.
5. Сайт должен одинаково отображаться во всех современных браузерах. В старых версиях браузеров допустимы небольшие различия в оформлении блоков, без потери их структуры и функциональности.
6. Структура вёрстки должна сохраняться при выключенных стилях, JavaScript, отсутствующих картинках.
7. Сайт должен корректно отображаться при запущенном программном обеспечении, блокирующем отображение рекламной информации.
8. При использовании нестандартных шрифтов обязательно должны присутствовать их аналоги для платформ Win/Mac/Linux. Нестандартные шрифты следует подключать с помощью @font-face или cufon.
9. Должна присутствовать favicon.ico.
10. Страница обязательно должна помещаться без горизонтальных полос прокрутки в развернутое на весь экран окно браузера при горизонтальной составляющей разрешения экрана 1024px.
11. Обязательно наличие атрибута title у элементов навигации и атрибута alt у картинок.
12. Для верстки под мобильные устройства обязательно использования тега <meta name="viewport" content="width=device-width”>, рекомендуется также использовать дополнительные атрибуты initial-scale, minimum-scale, maximum-scale.
13. Верстка под мобильные устройства должна быть резиновой. Ширина всех блоков должна задаваться в процентах.
14. В верстке должны быть заданы линейные параметры изображений (высота, ширина). Допускается не задавать линейные параметры у изображений, которые используются в динамических элементах.

4.1.2 Рекомендации

1. На внутренних страницах логотип сайта рекомендуется делать ссылкой на главную страницу.
2. Рекомендуется не использовать технологии Flash, QuickTime и Silverlight. При их использовании должно быть обеспечено корректное отображение сайта на устройствах, не поддерживающих данные технологии.
3. Рекомендуется верстку страниц начинать с указания браузеру того, как правильно отображать документ. Для этого следует использовать тег <!DOCTYPE html> или <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">.
4. Рекомендуется страницы сайта делать в кодировке UTF-8.
5. Рекомендуется не оставлять в вёрстке закомментированных кусков кода.
6. Рекомендуется делать различное оформление ссылок в обычном состоянии и при наведении.
7. Корректность заполнения форм рекомендуется проверять средствами браузера (HTML5 и JavaScript валидации), и средствами сервера.
8. Рекомендуется делать так, чтобы обработчики событий возвращали false или href='javascript:void(0)' вместо href='#', чтобы страница не прокручивалась наверх.
9. Рекомендуется использовать свойства CSS3 (например, border-radius, box-shadow) вместо использования графических элементов.
10. Верстку страниц для печати рекомендуется реализовывать средствами CSS.
11. Для страниц с резиновой версткой рекомендуется задавать минимальную и максимальную ширину.
12. Изображения в информационное содержание страниц рекомендуется вставлять с помощью тега <img>.
13. Рекомендуется не использовать фреймы.
14. Рекомендуется использовать микроформаты. Например, рекомендуется использовать микроформат hCard для разметки контактной информации в структурированном виде.

4.2 Протоколы и форматы передачи данных

4.2.1 Требования

1. Сайт должен отдавать контент конечным пользователям по протоколу HTTP(S).
2. Недопустима передача контента анонимным пользователям по протоколу FTP.
3. В случае интеграции с внешними системами – передача данных должна осуществляться по стандартизированным протоколам.
4. При передаче пользовательских данных должен использоваться защищенный протокол HTTPS. На сервере должен быть действующий SSL-сертификат, подписанный удостоверяющим центром. Все используемые средства защиты персональных данных должны быть сертифицированы.
5. Протокол передачи данных между системами должен журналироваться с фиксацией того, какие данные переданы, а какие получены.
6. Новостные материалы должны выгружаться в формате RSS.

4.2.2 Рекомендации

1. Рекомендуется передавать данные в формате XML или JSON.
2. Рекомендуется шифровать данные по алгоритму RSA с длиной ключа не менее 256 бит.

4.3 URL материалов

4.3.1 Требования

1. Каждая страница сайта должна иметь уникальный URL.
2. URL каждой страницы должен быть постоянным.
3. Страницы должны иметь понятные URL, например, www.site.mos.ru/about/contacts/.
4. URL не должны содержать информацию о сеансе работы пользователя с сайтом.
5. Адреса страниц должны указываться в кодировке, соответствующей кодировке сайта. Кириллические доменные имена и адреса страниц должны указываться в закодированном виде. Для кодирования следует использовать Punycode.

4.3.2 Рекомендации

1. Не рекомендуется включать в URL динамические параметры.
2. Динамические параметры в URL допускается и рекомендуется включать только для страниц, сформированных с использованием фильтров, правил сортировки и т.п.
3. URL страниц рекомендуется формировать путем транслитерации заголовков (без их перевода).

4.4 Доступность

4.4.1 Требования

1. Отклик сайта на запросы пользователей должен быть не более 3 секунд для статического контента и кэшированных страниц при одновременной работе 100 пользователей.
2. Вес страницы не должен превышать одного мегабайта.
3. Сайт должен быть доступен для пользователей 99,4% времени каждый месяц.
4. Все корректно функционирующие страницы должны отдавать код 200 ОК.
5. Все несуществующие или неработающие ссылки должны отдавать код ошибки 404. Для этой ошибки должна функционировать специальная страница, содержащая ссылку на главную страницу.
6. Сайт и все его информационные материалы должны быть доступны всем пользователям без прохождения процедуры аутентификации.
7. Административный интерфейс должен быть доступен только определенной группе пользователей после прохождения процедуры авторизации.

4.4.2 Рекомендации

1. Все основные сервисы и функциональные возможности сайта рекомендуется делать доступными без использования манипулятора типа «мышь».
2. Для авторизации и аутентификации рекомендуется использовать такие характеристики пользователя, как адрес электронной почты и пароль.
3. Рекомендуется наличие возможности быстрой регистрации и аутентификации при помощи учетной записи пользователя в едином веб-пространстве города Москвы.
4. Рекомендуется не использовать функциональные возможности автоматической загрузки дополнительного информационного содержания на страницу при наступлении определенного события.
5. Автоматическое перенаправление пользователя на страницу рекомендуется сопровождать выводом текстовой ссылки на соответствующую страницу.
6. Рекомендуется не использовать всплывающие окна для предоставления пользователям информации по их запросу.

4.5 Надежность

4.5.1 Требования

1. Сайт должен выдерживать пиковые нагрузки в четырехкратном размере от средней месячной посещаемости.
2. При сбоях и непредвиденных перезагрузках программного и технического обеспечения сервера должна быть обеспечена сохранность информации, благодаря автоматическому резервному копированию данных.
3. Сайты должны быть спроектированы таким образом, чтобы минимизировать возникновение ошибок по вине пользователя.

4.5.2 Рекомендации

1. В случае возникновения сбоя или непредвиденной перезагрузки программного и технического обеспечения сервера рекомендуется автоматически рассылать уведомления администраторам сайта.
2. Рекомендуется делать резервное копирование не реже одного раза в день.
3. Рекомендуется проводить резервное копирование в период наименьшей активности на сайте.
4. Рекомендуется хранить данные резервных копий на внешнем по отношению к основному серверу источнике.
5. Данные резервных копий рекомендуется хранить не менее трех месяцев.

4.6 Безопасность

4.6.1 Требования

1. Должен быть установлен лицензионный антивирус, настроенный на проверку как файловой системы сайта, так и всего обслуживающего программного обеспечения. На *nix системах допускается использование решений с открытым исходным кодом для организации антивирусной защиты.
2. Все порты, к которым есть доступ из глобальной сети Интернет, должны тщательно фильтроваться с помощью брандмауэра.
3. Обслуживающие порты системы (22 – ssh, 21 – ftp и др.) должны иметь доступ только с определенных IP-адресов.
4. Доступ извне к БД недопустим.
5. Все данные, вводимые пользователем, должны проходить проверку на соответствие формату
6. Данные с высоким уровнем секретности (например, пароль) при вводе пользователями должны экранироваться.
7. Не допускается прямая работа с БД – это должно обеспечиваться соответствующей прослойкой API системы управления сайтом либо используемого фреймворка.
8. Сайт должен быть доступен для работы сканеров безопасности.
9. Авторизационные и аутентификационные данные пользователей не должны храниться в файлах cookies.
10. Количество символов для задания пароля от учетной записи пользователя должно быть не менее 6 символов. В числе данных символов должны быть строчные и прописные буквы, цифры и специальные символы.
11. Должно осуществляться подтверждение регистрации пользователей через электронную почту или номер мобильного телефона.
12. Все события, связанные с созданием и изменением контента, регистрацией пользователей и изменением их данных в системе управления сайтом, работой на серверном уровне, должны журналироваться.
13. Отчет о критичных событиях должен быть доступен администратору сайта на уровне системы управления сайтом.
14. Журналирование изменений должно включать сведения о пользователя, внесшем изменения, в том числе его логин и IP-адрес.
15. Доступ к журналам должен быть только у лиц со специальными правами.
16. Не допускается редактирование записей журналов.

4.6.2 Рекомендации

1. Рекомендуется автоматически блокировать IP-адреса, с которых поступает неоправданно большое количество однотипных запросов к сайту.
2. Рекомендуется автоматически рассылать уведомления администраторам сайта о подозрительных событиях и действиях пользователей.
3. Сессию пользователя рекомендуется хранить в базе данных. Идентификатор сессии рекомендуется обновлять каждые 60 секунд.
4. Рекомендуемое время жизни сессии – 60 минут.
5. Срок хранения журналов рекомендуется делать не менее 3 месяцев.

5. Размещение на аппаратных средствах

5.1 Требования

1. Допускается размещение сайта на собственных аппаратных средствах, а также использование услуг специализированных организаций.
2. Специализированная организация, осуществляющая размещение на аппаратных средствах, должна иметь лицензии:
   1. на предоставление телематических услуг связи;
   2. на предоставление услуг связи по передаче данных, за исключением услуг связи по передаче данных для целей передачи голосовой информации.
3. Специализированная организация, осуществляющая размещение на аппаратных средствах должна осуществлять круглосуточную техническую поддержку.
4. Сервер, на котором происходит размещение сайта, должен располагаться на территории Российской Федерации.
5. Сервер, на котором происходит размещение сайта, должен быть обеспечен каналом связи с сетью Интернет. Пропускная способность канала связи должна быть не менее 10 мбит/сек.
6. Сервер, на котором происходит размещение сайта, должен быть обеспечен устойчивым бесперебойным электропитанием.

5.2 Рекомендации

1. Рекомендуется размещать сайт на сервере со следующими минимальными характеристиками:
   1. Операционная система *nix или Windows.
   2. Веб-сервер Apache Software Foundation Server версии 2.2.
   3. Процессор с тактовой частотой 2.66 GHz.
   4. Объем оперативной памяти 2 Гб RAM.
   5. Объем дискового пространства для сайта, превышающий трехкратный фактический размер сайта (размер файлов и базы данных).
2. Доступ к серверу рекомендуется осуществлять по протоколам SSH и FTP. 

6. Оптимизация под поисковые системы

6.1 Требования

1. Сайт должен быть доступен для поисковых роботов.
2. Сайт должен быть зарегистрирован в поисковых системах «Яндекс» и «Google».
3. Сайт должен быть включен в систему «Яндекс.Каталог», с указанием соответствующей категории,  географической принадлежностью к Москве и описанием, отражающем суть деятельности органа исполнительной власти.
4. Должна сохраняться правильная структура заголовков (TITLE и H1, H2 и т.д.). На странице должен быть только один заголовок H1, содержащий продвигаемые ключевые слова.
5. У каждой страницы должен быть свой уникальный TITLE, характеризующий ее информационное содержание и включающий продвигаемые ключевые слова. Рекомендуемое количество ключевых слов в TITLE не более 8.
6. На страницах сайта должны быть заполнены мета-теги keywords и description.
7. Дублирующие страницы (например, версии для печати), служебные разделы и автоматически сгенерированные, служебные изображения должны быть закрыты от индексации в robots.txt.
8. Должен генерироваться файл sitemap.xml, содержащий перечень страниц к индексации, в форматах, принимаемых поисковыми системами Google и Яндекс.
9. В файле robots.txt должно содержаться указание пути к файлу sitemap.xml.
10. Сайт должен продвигаться по запросам, характеризующим его информационное содержание и не вводящим в заблуждение пользователя.

6.2 Рекомендации

1. Не рекомендуется размещать неоправданно большое количество ключевых слов на странице с целью ее продвижения. Рекомендуемая плотность ключевых слов находится в диапазоне от 3 до 7 процентов.
2. Не рекомендуется размещать на страницах блоки текста, недоступные пользователям.
3. Рекомендуется в информационном содержании страниц делать ссылки на другие страницы сайта.
4. Ссылки рекомендуется делать текстовыми. Текст ссылки рекомендуется делать соответствующим странице, на которую ведет ссылка.
5. Ссылки рекомендуется делать средствами HTML. При использовании дополнительных технологий (например, JavaScript) должна быть обеспечена доступность соответствующих страниц по обычным текстовым ссылкам.
6. Рекомендуется информационное содержание страниц делать уникальным, не встречающимся на других сайтах сети Интернет.
7. Информационное содержание страниц рекомендуется логически разделять заголовками H2, H3 и т.д., содержащими ключевые слова.
8. Рекомендуется смысловые акценты текста и ключевые слова выделять тегом <strong> или <b>.
9. Рекомендуется содержание мета-тегов keywords и description писать для людей, нормальным человеческим языком – развернуто, правильно выстроенными предложениями, без злоупотреблений ключевыми словами, заглавными буквами, рекламными лозунгами и пр.
10. Рекомендуется в мета-тегах keywords и description описывать конкретную страницу сайта, а не сайт в целом.
11. Содержимое мета-тегов keywords и description следует писать на языке, соответствующем информационному содержанию страницы.
12. Рекомендуемая длина мета-тега keywords находится в диапазоне от 50 до 100 символов.
13. Рекомендуемая длина мета-тега description находится в диапазоне от 200 до 250 символов.
14. Рекомендуется вставлять ключевые слова в атрибут alt у картинок.
15. Рекомендуется занести информацию об организации в Справочник Яндекса (http://sprav.yandex.ru) с указанием URL сайта и представительств организации в социальных сетях.
16. При изменении URL страницы рекомендуется для сохранения внешних ссылок на страницу применять 301 редирект со старого URL на новый.
17. Отдельные блоки текста, не несущие смысловой нагрузки и не желательные для появления в поисковых системах, рекомендуется скрывать от индексации при помощи тега <!--noindex-->.
18. Рекомендуется управлять отображаемыми быстрыми ссылками на разделы сайта в результатах поиска на страницах поисковых систем. Для этого следует использовать специализированный интерфейс, предоставляемый поисковыми системами Яндекс и Google, а также следовать их рекомендациям.
19. Рекомендуется настроить сервер таким образом, чтобы он отдавал HTTP-заголовок Last-Modified. Данный заголовок должен содержать корректную дату последнего изменения страницы.

7. Информационное наполнение

7.1 Текстовые материалы

7.1.1 Требования

1. У всех текстовых материалов сайта должны быть заголовки.
2. Большие по объему текстовые материалы должны разбиваться на логические блоки и размечаться подзаголовками.
3. Текстовые материалы должны разбиваться на абзацы для облегчения их восприятия.
4. Должны соблюдаться требования типографики и правил русского языка.
5. Текстовые материалы должны быть достоверными, объективными, политически корректными.
6. Запрещено размещение и распространение информации, оскорбляющей человеческое достоинство, пропагандирующей насилие или экстремизм, разжигающей расовую, национальную или религиозную вражду, преследующей хулиганские или мошеннические цели, а также противоречащей российскому федеральному или московскому законодательству, а также международному законодательству.
7. Должны соблюдаться требования 12 и 13 статьи Федерального закона Российской Федерации от 9 февраля 2009 г. N 8-ФЗ «Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления» в части раскрытия информации.
8. Текстовые материалы должны быть доступны на государственном языке Российской Федерации.

7.1.2 Рекомендации

1. Рекомендуется избегать употребления жаргонизмов, профессионализмов и прочих слов, не являющихся общеупотребительными. Их употребление рекомендуется сопровождать пояснением, указывающим на смысл соответствующего слова.
2. Рекомендуется не ставить точку в конце заголовков, подписей к рисункам и в таблицах.
3. Первое употребление на страницы аббревиатуры или акронима должно сопровождаться выводом пояснения, расшифровывающего смысл аббревиатуры или акронима.

7.2 Изображения

7.2.1 Требования

1. Рекомендуется графические файлы хранить в форматах, рекомендуемых W3C для использования в интернете и обеспечивающих наименьший объем передеваемых пользователю данных при допустимом уровне качества.
2. Изображения на сайте должны быть максимально уменьшены для быстрой загрузки.
3. Запрещается необоснованная публикация текстовых материалов в графическом виде.

7.2.2 Рекомендации

1. Множество фотографий по одной теме рекомендуется объединять в фотогалерею и снабжать элементами навигации по фотогалерее.

7.3 Видеоматериалы

7.3.1 Требования

1. Допускается размещение видеороликов только по тематике сайта.

7.3.2 Рекомендации

1. Рекомендуется размещать видеоролики в формате mp4.
2. Видеоролики рекомендуется сжимать кодеком H.264.
3. Рекомендуется в видеоролики включать субтитры.
4. Рекомендуется наличие возможности включения и отключения вывода субтитров в видеоплеере.

7.4 Юридическая информация

7.4.1 Требования

1. На сайте, созданном за счет средств государственного бюджета, не должно быть явного указания на то, что размещенные материалы защищены авторским правом.
2. При размещении материала внешнего информационного источника, должна быть указана ссылка на него.
3. При сборе персональных данных пользователя должна быть явно указана цель, для достижения которой они собираются.

7.4.2 Рекомендации

1. Для сайта и отдельных его сервисов рекомендуется размещать справочную информацию, содержащую соответствующие условия использования.

7.5 Контактная информация

7.5.1 Требования

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

7.5.2 Рекомендации

1. Указание полного адреса рекомендуется сопровождать выводом схемы проезда с использованием интегрированной автоматизированной информационной системы «Единое геоинформационное пространство города Москвы». Использование других картографических сервисов допускается только по согласованию с Департаментом информационных технологий города Москвы.
2. Рекомендуется размещать на сайте контактную информацию ответственных специалистов для облегчения связи с ними граждан.
3. В адресе электронной почты специалиста должна быть указана его фамилия и инициалы.

7.6 Частота обновления

7.6.1 Требования

1. Информация на сайте должна поддерживаться в актуальном состоянии.
2. Не допускается публикация анонса уже прошедших мероприятий – в этих случаях должен сразу публиковаться пост-релиз о прошедшем мероприятии.

7.6.2 Рекомендации

1. Рекомендуется разработать и принять локальный нормативно-правовой акт, определяющий ответственность должностных лиц и содержащий план-график размещения информации на сайте.
2. Рекомендуется внести изменения в положения о структурных подразделениях, наделить их полномочиями и ответственностью за предоставление информационных материалов для публикации на сайте.
3. Рекомендуется определить ответственных должностных лиц в каждом структурном подразделении, внести изменения в их должностные инструкции, наделить полномочиями и ответственностью за сбор, систематизацию и предоставление информации для публикации на сайте.
4. Рекомендуется назначить должностное лицо в целом ответственное за организацию работ по плану-графику размещения информации на сайте.

8. Визуальное оформление и эргономика

8.1 Требования

1. При использовании герба или флага Москвы не допускается их геометрическое и цветовое искажение.
2. Все страницы сайта должны быть оформлены в едином стиле.
3. Визуальное оформление страниц должно способствовать правильному восприятию размещённой на них информации.
4. На всех страницах сайта должен быть установлен единый верхний и нижний колонтитулы.
5. Единый верхний колонтитул предоставляет доступ к функциональности унифицированных программно-интегрируемых решений «Единый классификатор сайтов», «Единый поиск», «Личный кабинет», «Единые информеры».
6. Единый нижний колонтитул состоит из трех уровней:
   1. Карта сайта, включающая разделы 1 и 2 уровней вложенности.
   2. Основные официальные сайты города Москвы.
   3. Основные федеральные сайты.
7. Навигация по сайту и его структура должны быть продуманы и логичны. С главной страницы сайта должны быть доступны ссылки на все ключевые разделы и страницы сайта.
8. Всё информационное наполнение и все интерактивные сервисы сайта должны быть доступны посетителям через ссылку или пункт навигационного меню. Число переходов, необходимых для получения доступа к запрашиваемой пользователем информации, не должно превышать пяти.
9. Оформление элементов навигации, ссылок, изображений, кнопок и прочих интерактивных элементов страниц должно способствовать быстрой и простой идентификации пользователями.
10. Каждый навигационный и управляющий элемент должен быть рабочим и приводить пользователя к ожидаемому результату.
11. Все возникающие ошибки должны сопровождаться понятными текстовыми сообщениями, которые содержат описание проблемы и способы её решения.
12. Должна быть обеспечена возможность перемещения между полями формы с помощью клавиши Tab.
13. В форме, предназначенной для сбора личной информации о пользователях, должно быть пояснение о целях сбора этой информации.

8.2 Рекомендации

1. Следует избегать эффектов, затрудняющих восприятие информации или отвлекающих пользователя от содержания страницы: мигания, мерцания, движущихся строк.
2. Текст рекомендуется отображать с соответствующим уровнем контраста по отношению к используемому цвету фона (не менее 50 %).
3. Рекомендуется использовать не более 2 разных гарнитур шрифтов.
4. Рекомендуется использовать стандартные гарнитуры шрифта для набора основного информационного содержания страниц.
5. Размер шрифта основного текста рекомендуется делать не менее 12 пунктов и не более 14 пунктов.
6. Заголовки различного уровня рекомендуется делать различными друг относительно друга на одинаковую величину. Размер заголовка самого низшего уровня допускается делать равным размеру основного текста, но с изменением насыщенности в большую сторону.
7. Рекомендуется использовать темный шрифт на светлом фоне.
8. Основная суть информационного содержания страницы должна быть понятна уже на первом экране браузера.
9. Рекомендуется располагать не более 9 пунктов в главном навигационном меню сайта.
10. Рекомендуется использовать вертикальный вид главного навигационного меню сайта при наличии в нем более 7 пунктов.
11. Рекомендуется выстраивать структуру и навигацию по сайту таким образом, чтобы число переходов, необходимых для получения доступа к запрашиваемой пользователем информации, не превышало трех.
12. Рекомендуется делать навигационные цепочки, содержащие путь следования по разделам от главной до текущей страницы.
13. Ссылки на файлы для загрузки рекомендуется сопровождать указанием типа и размера файла.
14. При размещении на странице большого объема текстовой информации рекомендуется использовать внутренние ссылки (якоря) на различные разделы страницы. В свою очередь, в каждом разделе страницы рекомендуется размещать ссылку «Вернуться в начало», позволяющую пользователю вернуться к началу страницы.
15. Названия страниц рекомендуется делать короткими, понятными и точно отражающими их информационное содержание.
16. Рекомендуется использовать не более 2 слов в обозначении пункта навигационного меню.
17. Формы, состоящие из большого количества полей, рекомендуется разделять на смысловые блоки. Смысловые блоки в свою очередь рекомендуется визуально и логически разделять друг от друга.
18. В формах рекомендуется запрашивать у пользователя только ту информацию, которая действительно нужна для продолжения совершаемой операции.
19. Поля в формах рекомендуется размещать друг под другом.
20. Обязательные для заполнения поля рекомендуется помечать специальным знаком. Расшифровку специального знака следует располагать над формой.
21. Подписи к полям для ввода рекомендуется размещать слева или сверху, единообразно во всей форме.
22. Рекомендуется основную, наиболее важную кнопку на странице делать самой заметной.
23. Рекомендуется придерживаться следующей логики работы ссылок:
    1. Ссылка со сплошным подчеркиванием приводит к открытию новой страницы в текущем окне браузера.
    2. Ссылка со сплошным подчеркиванием, помеченная специальным значком или надписью, приводит к открытию новой страницы в новом окне браузера, либо к загрузке файла.
    3. Ссылка с пунктирным подчеркиванием приводит к открытию всплывающего окна поверх основного содержимого текущей страницы или обновлению содержания страницы без ее перезагрузки.
24. Наиболее часто используемые элементы списков для выбора рекомендуется размещать в его начале.
25. Надписи на кнопках следует писать в инфинитивной форме глагола (показать, загрузить, восстановить). Не следует использовать другую часть речи либо форму глагола.
26. Поля ввода данных определенного формата рекомендуется сопровождать объяснениями или подсказками.
27. В многостраничных формах рекомендуется указывать текущий экран и общее количество экранов (шагов).
28. В формах ввода рекомендуется делать проверку корректности вводимых значений прямо во время ввода.
29. Не рекомендуется использовать элементы оформления, делающие неочевидным доступ к тексту для пользователей – окна прокрутки, скрытые выпадающие блоки и т.п.
30. Рекомендуется заголовок страницы делать информативным и актуальным, а не просто содержащим ключевые слова.

Рекомендуется автоматически рассылать уведомления администраторам сайта о подозрительных событиях и действиях пользователей./li /li

Артем Геллер
Руководитель в Лаборатория Артема Геллера

Пожалуй, для начала обратим внимание на заголовок документа — он очень хороший, единственным моментом является необходимость исправления фразы «города Москвы» на «Российской Федерации» и переписать все то, что написано ниже заголовка.

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

1. Кто это написал? Почему мы не в курсе и не могли предотвратить безумие?

2. Глупость, абсурд и спорность, вытекающая из не профессионализма «писателей».

Кратко об ощущениях. Все это напоминает учебник «веб-сайт для чайников» c амбициозным неизвестным автором, который «требует» и «рекомендует». Учитывая, что основная часть мыслей несет как раз рекомендательный характер, то не очевидным становится смысл существования самого документа. Все мы помним федеральное законодательство, которое покрывает практически все стороны документа несущего гриф «требования», а не «рекомендации».

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

Скажу как всегда честно, можно остановиться на каждом пункте, но мне трогательными показались несколько и именно их бессистемно озвучу, начав с любимого и «говорящего»:

— Сайты должны быть спроектированы таким образом, чтобы минимизировать возникновение ошибок по вине пользователя.

По вине простите кого? 0_о

Любая вина (даже не связанная с проектированием) может лежать только на ваших плечах и плечах ваших подрядчиков.

— Размер шрифта основного текста рекомендуется делать не менее 12 пунктов и не более 14 пунктов.

Дизайнеры, знающие перевод термина readability (Бог с ним, с пониманием), похоже, при составе этого документа уехали в летние отпуска из нашей страны.

— «Все элементы визуального оформления должны быть отключены в версии для слабовидящих.»

Глупость. Тут сказано про слабовидящих, а не слепых людей, которым многие визуальные элементы необходимы как и нам для того чтобы ориентироваться. Когда уже возьмут в голову, что сайты должны быть доступны не для слабовидящих, а для людей с ограниченными возможностями:

Слабовидящие, незрячие, когнитивные расстройства, глухие, глухонемые, нарушения памяти, нарушения опорно — двигательного аппарата, нарушение моторики, повышенная фоточувствительности и все это только слету. В технических частях документа рекомендуется обращаться к W3C, ну так и обратитесь к WCAG от W3С.

Ну а вердикт прост, все что писали про «доступность» для слабовидящих делали некомпетентные в этой области люди. Последнее предложение относится и к рассуждениям о мобильной версии.

— Рекомендуется не использовать технологии Flash

Я не адепт конкретных технологий (особенно flash), но для всего есть свои цели, и запрещать/не рекомендовать технологии — это довольно интересный прецедент. Департамент правительства Москвы совсем не apple, чтобы лоббировать форматы, которые используются в разработке. Если мы упремся в «доступность» и ее контекст, а именно это слово является подзаголовком раздела, разжигающего огонь войны Adobe vs департамент Москвы то flash доступен на более чем 90% десктопов, в отличие от HTML5. Еще раз поставлю акцент на то, что у всех технологий — свои цели, задачи, плюсы и минусы.

— Каждая страница сайта должна иметь уникальный URL.

А могут быть две страницы с уникальным URL? Что такое страница? Прощай ajax и динамическая подгрузка данных? Может не каждая? Почему вы тогда пишете в требованиях cлово «каждая»? Если вы это утвердите, они ведь все буквально воспримут.

— URL каждой страницы должен быть постоянным.

Даже в ленте новостей? Нет? А зачем требуете? Или контент может меняться, а URL — постоянный? Тогда какой смысл?

— «Сайт и все его информационные материалы должны быть доступны всем пользователям без прохождения процедуры аутентификации.»

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

Может хватит городить свои огороды? Есть федеральный портал gosuslugi.ru, через который можно полноценно авторизоваться, не говоря уже про популярные социальные сервисы.

и т.д. и т.п. и бесконечно и по всем пунктам :( Грустно.

Программист Никита Кузнецов, сидящий недалеко от меня, сейчас спросил: «Артем, почему ты так тяжко вздыхаешь?»

Внимание! Самое важное!

Итог: Документ не профессиональный и очень сырой, как лужа.

Рекомендации:

1. Информационному департаменту Москвы необходимо перевести на русский язык документы, находящиеся по этим ссылкам:

https://www.gov.uk/designprinciples

https://www.gov.uk/designprinciples/styleguide

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

— Сделать татуировки на тыльной стороне кисти руки всем сотрудникам пресс-служб и информационных департаментов с надписью «User first» или «User needs» хельветикой, так уж и быть размером от 12 до 14 пунктов.

Юрий Солодовников
Эксперт в Webquality

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

Это очередной шаг к унификации и стандартизации требований к созданию единой цифровой инфраструктуры столицы. Радует появление профессиональных экспертов со стороны правительства Москвы. Правда, хотелось бы большей конкретики в описании «единого веб-пространства», как такового.

Артур Кротов
Технический директор в Nimax

 

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

Многие требования из этого документа я бы порекомендовал применять не только к государственным, но и коммерческим сайтам. Естественно, делать это надо с умом, т.к. почти каждое из указанных в документе правил имеет свои исключения или оговорки, про которые можно написать не менее объемный документ. Но на данный момент важно, что такие требования появляются и, очень надеюсь, будут развиваться, что естественно положительно скажется не только на гос. сайтах, но и в целом на рунете.

 

Юрий Новосад
Директор в Jeton

Мне приятно видеть текст для чиновников, который создавался с целью не «отписаться», а качественно и доступно донести техническую информацию. Считаю, что это действительно рабочий документ, достаточно подробный и в то же время легкий для восприятия. Позволю себе немного дополнений:

I. Первое, на что я обратил внимание — необходимость проинформировать об использовании PDF формата в документации и заполняемых формах (как, например, это сделано для загран. паспортов), потому что в тексте документа этот вопрос абсолютно не освящен.

II. Видеоматериалы
Требования
Допускается размещение видеороликов только по тематике сайта.

Что же касается различных площадок видеохостинга (например, youtube.com), их сегодня существует множество, поэтому данный пункт требует конкретики: допускается ли размещение видеоинформации на сторонних ресурсах в целях продвижения или оптимизации сайтов?

III.

7.5.2 пункт 2 и 3
Рекомендуется размещать на сайте контактную информацию ответственных специалистов для облегчения связи с ними граждан.
В адресе электронной почты специалиста должна быть указана его фамилия и инициалы.

Размещая контактные данные чиновника (e-mail), мы автоматически обрекаем его на обилие рекламных рассылок (спама). А, как известно, спам-фильтры не всегда срабатывают корректно, зачастую «отсеивая» нужные письма. На мой взгляд, в рекомендациях следует указать, что приоритетны формы обратной связи с защитой от спама. В этом случае контакт граждан со специалистами будет более эффективным.

IV. 
5.2 Рекомендации

Рекомендуется размещать сайт на сервере со следующими минимальными характеристиками: Операционная система *nix или Windows, веб-сервер Apache Software Foundation Server версии 2.2, процессор с тактовой частотой 2.66 GHz, объем оперативной памяти 2 Гб RAM, объем дискового пространства для сайта, превышающий трехкратный фактический размер сайта (размер файлов и базы данных).

Я считаю нецелесообразным устанавливать технические требования к серверам: они быстро устаревают и становятся неактуальными. Также, не до конца раскрыт вопрос облачного хостинга: доступен ли он для использования? Кроме того, я опубликовал бы список рекомендуемых провайдеров.

V. 
3.1 Система управления сайтом

Говоря об управлении сайтом, добавил бы, что приоритет стоит отдавать тем системам, которые поддерживаются сообществами разработчиков, а не развиваются под управлением всего одной студии (одного разработчика). А также, предоставил бы список всех рекомендованных CMS. (например, Netcat, Bitrix).

VI.
3.3 Статистика 

Относительно сбора статистических данных с сайта, наиболее целесообразным будет использование единого формата. Например, очень хорошо себя зарекомендовали системы статистики Яндекс.Метрика или Google.Analytics.

VII.

8.2 пункт 22

Рекомендуется основную, наиболее важную кнопку на странице, делать самой заметной.

Данное действие может привести к тому, что вслед за появлением Первой важной информации и большой кнопки последует возникновение еще более значимого содержания, а, следовательно, Второй большой кнопки и так далее.

Я бы переформулировал данный совет, к примеру, следующим образом: рекомендуется основные наиболее важные ссылки на странице делать более приоритетными и заметными. Учитывая стили, заложенные при разработке дизайна.

 

В завершении, хочется поблагодарить за создание такого, поистине, нужного рабочего документа и пожелать успехов в его реализации.

 

Владимир Синельников
Совладелец в Aero

Вообще ДИТ — странное место. С одной стороны — непонятно чем ребята занимаются. С другой, как выясняется — молодая, компетентная команда, большие деньги и хорошие задумки — можно ждать интересных городских веб-проетов.

Ок, читаем документ: название (единые принципы единого веб-пространства) говорит само за себя. Непонятно, ни что такое «единое веб-пространство» (Интернет??), ни кому он вообще адресован.

По сути, похоже на попытку сделать русский ГОСТ для интернета при живом w3c, что очень хорошо ложится на наш технологический ура-патриотизм.

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

В нюансах, конечно, тоже есть особенно интересные места. Необходимость мобильной версии на отдельном домене, категорический отказ от flash (ну это ладно), отказ от использования любых карт, кроме неких «единого геоинформпространства Москвы» (лолшто?). При этом техтребования явно даны с запасом: отклик 3 секунды, аптайм 99.4%, и почти все рекомендации вообще плохо поддаются расшифровке.

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

Алексей Симоненко
Технический директор в Serenity

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

Я не совсем согласен с созданием отдельной версии для мобильных устройств. Мне кажется, стратегически было бы верно создавать сайты по принципу «mobile first» и с помощью адаптивной вёрстки подстраивать сайт под разные экраны. Это должно уменьшить стоимость разработки такого сайта, упростить поддержку и заранее начать поддерживать те мобильные устройства, которые выйдут в будущем.

К микроформатам я бы добавил альтернативный вариант: http://schema.org/docs/schemas.html (его тоже поддерживают поисковые системы).

Документ кажется цельным и проработанным.

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

Ольга Русакович
Заместитель директора в Webway

imho, ЦА данного документа должны быть все-таки IT-шники, а не «нормальные» люди, потому что для «пресс-служб» там много непонятного и ненужного. Например, «Рекомендуется ограничивать средства форматирования информационного содержания страниц через административный интерфейс». Мы-то с Вами знаем, почему, а сотрудник пресс-службы, наоборот, будет хотеть максимально возможные способы форматирования :).

Некоторые вещи описаны слишком подробно. В частности целая страница отведена определениям, которые, если IT-шник не знает, то его надо в шею гнать :).

С другой стороны длинное описание правил о том, как называть домены и поддомены, действительно нужно. Ибо если их до последней буквы не описать, то всегда найдется олух, который придумает что-нибудь не к месту креативное.

Я бы еще дописала, что сотрудникам категорически запрещается заводить на гос. доменах свои собственные сайты :). Вроде очевидно, но в нашей практике есть два примера, когда у очень солидных организаций находились домены типа vasya.domen.ru, а на нем личный сайт Васи.

Сложилось ощущение, что значительную часть Регламента писал SEO-шник. Другая причина, по которой столько места, в сравнении с остальным, отведено оптимизации, не приходит мне в голову. Если взять главу о требованиях к CMS, то там куча про оптимизацию для поисковика, но ничего про то, что CMS-ка должна быть удобна даже для тети Глаши, которая в департаменте работает с середины прошлого века и должна иметь понятный учебник для этой же тети Глаши (и не говорите мне, что заполнением контентом не занимаются тети Глаши, еще как бывает). В связи с этим, было бы хорошо в рекомендациях написать, что очень приветствуется (или даже обязательна) разработка юзергида для каждого конкретного сайта.

Если прямо по тексту, то вот вещи, которые я не очень поняла.

1. «Использование готовых решений рекомендуется при наличии на стороне производителя гарантированной технической поддержки, обеспечивающей оперативное решение всех вопросов». А почему это относится только к готовым решениям? Наоборот, казалось бы, использование эксклюзивных решений должно обеспечиваться техподержкой производителя, а в случае готовых решений можно найти поддержку у многих, не только у производителя.
2. «На всех страницах сайта должен быть установлен счетчик, выдаваемый в Департаменте информационных технологий города Москвы». Кто, кому, и при каких обстоятельствах его должен выдавать?
3. Что значит «должна собираться статистика»? Как собираться, куда собираться? Сама-то она не соберется. Вообще, желательно пояснить, планируется ли установка готовых систем статистики типа Гугла (если да, то и требования к нему писать не надо), или речь идет о собственных счетчиках (тогда это уже вопрос требований к CMS).
4. «Рекомендуется не использовать тяжелые изображения». Что значит «тяжелые»? Такие рекомендации лучше давать для контент-менеджеров, а не для разработчиков, причем указывать конкретные правила создания изображений, т.к. у всех разные представления о тяжести.
5. За слова «во всех современных браузерах» вообще захотелось бросить чашкой кофе в монитор :).

Надо как-то определиться, либо в документе общие слова, либо конкретика. Если общие, то не нужно писать «разрешения экрана 1024», а просто «современные разрешения экрана» :). Иначе очень странно выходит — некоторые пункты сформулированы вплоть до версий, вплоть до тэгов и программных операторов, а другие рассчитаны исключительно на здравый смысл читающего.

6. Пункты о безопасности тоже показались слишком общими. Если взять, например, описание безопасности в стандартной документации по Битриксу, то там изложено более четко и более по делу.
7. Не поняла, как можно написать требования к серверной части без привязки к конкретному проекту. Аппаратные мощности должны формироваться только на этапе составления ТЗ на проект, либо в тот момент, когда хотя бы приблизительно понятно, о чем он. Абстрактно сказать, что нужен сервер с таким-то объемом памяти, невозможно и непонятно зачем.
8. «Объем дискового пространства для сайта, превышающий трехкратный фактический размер сайта». Фактический объем — это что? Если у нас сайт, предназначен для хранения документов или видео, его фактический объем будет стремительно расти и вовсе не в три раза.
9. Для кого приведены требования к текстовому наполнению? Для разработчика? Они ему не очень нужны. Для составителя текстов? Ему не нужен весь остальной документ.
10. На фоне нескольких страниц про оптимизацию забавно смотрится микроскопичность раздела об изображениях — W3C и все :). То есть опять же некоторая часть излишне подробна, другая максимально сжата.
11. Слова «продуманы и логичны» странновато видеть в таком документе? Как их использовать на практике? :).

«Указание полного адреса рекомендуется сопровождать выводом схемы проезда с использованием интегрированной автоматизированной информационной системы «Единое геоинформационное пространство города Москвы». Вот оно! Наконец-то нужная информация для разработчика, который все знает про W3C и SEO, но может не знать о наличии такой системы. Куда более ценная информация, чем, что такое домен.

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

Для гос. организаций надо учредить чуть ли не одно единственное требование — ОБЯЗАТЕЛЬНОЕ составление ТЗ по ГОСТу 34.602-89 для каждого проекта, а уже в нем будет и список ответственных лиц, и план-график, и серверная база, и все-все-все. А то ГОСТ для слабовидящих, являющийся исключительно частным случаем, упомянут, а отец всех ГОСТов отсутствует. Вообще, все изучали ГОСТ 34.602-89? Для сайта-визитки — большой перебор, для гос. сайта очень полезная штука — ничего важного невозможно забыть. И только после того, как ТЗ будет утверждено, можно приступать к разработке.

Более того, сам Регламент, на мой взгляд, хорошо оформлять исходя из этого ГОСТа. Т.е. сделать как ТЗ на, своего рода, абстрактный сайт, начиная с банальных целей и задач самого Регламента (для кого, для чего), круга ответственных лиц (которые будут его проводить в жизнь), и заканчивая требованиями к вводу в эксплуатацию (чтобы не выложили кривой и пустой сайт случайно) и документированию (чтобы государство не осталось без инструкции по применению :)).

Что с того, что сайт на правильном домене, соответствует W3C и т.п., если контента на нем нет, за него никто не отвечает, перед выкладкой не провели нормальное тестирование.

Не сомневаюсь, что мне писать подобный документ никогда не доверят, но раз уж спрашивают мнения, то я бы уделила больше внимания организационной части в строгом соответствии с вышеупомянутым ГОСТом, и совсем мало внимания технической, заменив техническую часть на требование о том, что компания-разработчик должна быть «опытной». Разумеется, с указанием критериев опытности (их можно измерять возрастом, количеством проектов, оборотом и т.п.) К большому сожалению никакой обязательной сертификации и лицензирования разработчиков у нас нет. Это хорошо для начинающих студий, но плохо для клиентов, которые не могут разобраться, кто профи, а кто вчера только выучил html. Госорганам лицензирование помогло бы выбирать подрядчиков.

Если подводить какое-то «итого», то мне показались полезными конкретные вещи, связанные именно с гос. сайтами Москвы:

• правила оформления доменов
• пункт про использование флагов и гербов
• пункт про использование карт.

Общие вещи, ссылки на W3C и описание SEO мне не кажутся полезными, потому что если разработчик про них не знает, так рано ему еще гос. сайты делать.

Сам Регламент уместно было бы составить с учетом всех пунктов, имеющихся в ГОСТ 34.602-89 и включить в него требование о составлении ТЗ по тому же ГОСТу.