Xpoint
   [напомнить пароль]

Технические нормы

Метки: [без меток]
2004-05-31 12:43:34 [обр] Алексей Серебряков(0/10)[досье]
Вот уже давно сталкиваюсь с тем, что технического задания, как правило, не хватает, чтобы доходчиво объяснить разработчику, что от него нужно (для справки: я - консультант, работаю на заказчиков). Ведь даже с установленными рамками у тех же самых верстальщиков или горе-дизайнеров остается еще пространство для совершенно ненужного полета их мысли.
По поводу разработки сайтов сайтов иногда говорят: "Есть некий свод правил, которых придерживаться считается хорошим тоном." Причем правила могут оказаться как довольно сложными, так и невероятно смешными. К примеру: на некоторых корпоративных (!) сайтах блокируется правая кнопка мыши, или в содержании <title> есть и другие теги, типа <b>. Согласитесь, довольно глупо, хотя иногда такие ляпы допускают далеко не самые, скажем грубо, отсталые разработчики.
Собственно возвращаясь к теме, я принялся составлять свод вот таких "технических норм", которые можно будет представлять как приложение к техническому заданию. Интересно было бы услышать как мнения по этому поводу, так и дельные предложения (может быть что-то подобное уже существует). Насколько это будет интересно?
P.S. посмотреть на уже готовый вариант можно здесь: professionalconsulting.ru/documents/techstandards.pdf
спустя 3 часа 16 минут [обр] Юрий Щапов(0/114)[досье]

Странно, что в общих нормах Вы не упомянули "корректно отображался при разрешении экрана от ... до... + при цветовой палитре в X, Y и Z битов".

практически любой сайт можно, к примеру, сверстать в соответствии со спецификацией XHTML strict DTD, а не так, как привык верстальщик.

Не могу с Вами согласиться. Далеко не любой.

Пункт 5. Доктайп требуете на HTML 4.01, а до того требовали XHTML only... Неясно.

В общем идея сбора в одном месте подобных правил неплоха. Ещё подумаю над добавками.

спустя 48 минут [обр] Алексей Рюмин aka Dwarf(0/864)[досье]

Алексей Серебряков[досье]

5.9 Оъекты IMG и OBJECT должны обязательно содержать ненулевые атрибуты
WIDTH и HEIGHT.

При CSS-верстке - не нужны. По крайней мере для IMG.

А так - очень неплохо. Возьму на вооружение, если позволите :)

спустя 1 день 1 час [обр] Tony(4/52)[досье]

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

Вот у Вас раздел "Типографика" занимает одну страничку и не раскрывает ровным счетом ничего, кроме обсосаной темы кавычек, которую так любит Лебедев.

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

Например, кто из неглупых разработчиков допускает подобные ляпы?

спустя 1 день 5 часов [обр] Алексей Серебряков(0/10)[досье]
Tony[досье]
Думаю, если мы начнем обсуждать, кто из разработчиков допускает ошибки, ни к чему хорошему это все равно не приведет. А что касается лишней траты средств и времени, мне было бы крайне интересно узнать (честно, без издевки), как вы улаживаете вопрос технических требований со своими клиентами: что вы закрепляете в договоре, что - в техническом задании. И вообще... какая часть этих самых технических требований остается на бумаге, а какая - на словах. Если вам не нравится оговаривать все условия до начала проекта - мы просто придерживаемся разного подхода.
А что касается типографики, то я сторонник "правильного решения". Если об этом впервые сказал Лебедев, вовсе не значит, что этих простых правил не стоит придерживаться. Да, с любым текстом обязательно должен поработать редактор и исправить все ошибки. Мне грустно видеть, когда на сайтах есть орфографические и пунктуационные ошибки, когда кавычки ставятся неправильно, когда не выдержан единый стиль (например, он-лайн, онлайн, on-line, "через сеть" используются все вместе на одной странице). Да о чем можно говорить, когда на некоторых страницах сайта Нескафе кофе среднего рода. Я бы это раздел переименовал и первой нормой поставил "соответствие правилам русского языка", а вы говорите "не раскрывает ровным счетом ничего". Нету, прошу прощения за грубость, нихрена этих ваших хваленых "опытных" людей, которые не делают ляпов. Кругом - сплошная халтура. Не согласны? Дайте адрес сайта, на котором нет ошибок (скажем, орфографических и пунктуационных). Я настаиваю именно на этом виде ошибок: ведь неправильные кавычки многие ошибкой не считают.
спустя 13 часов [обр] Tony(4/52)[досье]
А что касается лишней траты средств и времени, мне было бы крайне интересно узнать (честно, без издевки), как вы улаживаете вопрос технических требований со своими клиентами: что вы закрепляете в договоре, что - в техническом задании. И вообще... какая часть этих самых технических требований остается на бумаге, а какая - на словах. Если вам не нравится оговаривать все условия до начала проекта - мы просто придерживаемся разного подхода.

Не понял, Вы документ сделали для заказчиков или для разработчиков? Но если уж на то пошло, то ТЗ НАДО составлять до того уровня, где заканчивается компетенция заказчика и начинается компетенция разработчика. То есть, заказчику не должно быть интересно, какие кавычки правильные. Вы интересуетесь технологическим процессом упаковки сырков в шоколадной глазури? Я тоже нет. Но меня крайне бесят сырки, которые сложно открывать.

Нету, прошу прощения за грубость, нихрена этих ваших хваленых "опытных" людей, которые не делают ляпов. Кругом - сплошная халтура. Не согласны?

Нет, не согласен. Такие люди есть, они просто не попадались на Вашем пути. Они работают в компаниях Лебедева, 37 Signals, Elro и других. В качестве примера — сайт lukoil.ua.

Алексей, Вы хотите создать универсальное руководство "ПРАВИЛЬНОГО" веб-разработчика?

спустя 3 часа 11 минут [обр] Алексей Серебряков(0/10)[досье]
Tony[досье]
Конечно для заказчиков. Разработчики же "умные", им вообще все по барабану, и поэтому писульки мои они читать не будут, как вы правильно заметили. Но работа у меня такая: я - консультант. По большей части у меня заказчики, которые нанимают меня, чтобы я вел проект от начала и до самого конца, но иногда попадаются черти, которые хотят получить только проектную документацию, а потом идут искать, где бы подешевле сделать. Вот для них этот документ и нужен: по крайней мере он позволяет избавиться от некоторой части технических проблем.
А что касается опытных... ну это уж вы загнули ("не попадались"). Очень даже попадались, но не попадались слаженные команды, в которых каждый участник - вот такой самородок. А всего из-за одного, прошу прощения, %%%%%, весь проект как бочка меда с мале-е-енькой, но противной ложкой дегтя. А обычно в команде такой не один, и дегтя становится больше.
Посмотрел я сайт. Про фоновую музыку буду молчать как рыба =) А грамматические ошибки есть. Могу рассказать по e-mail, чтобы не засорять форум. И на сайте, кстати говоря, стоят именно те кавычки и тире, против которых вы выступаете.
И вообще, давайте не превращать это в злостный флейм. Я бы с радостью выслушал какие-нибудь дельные предложения, а возгласы вроде "фигней страдаете, товарищ" прошу отложить на потом.
спустя 20 дней [обр] Кусо Мендокуси(0/2)[досье]
Поглядите на рекомендации, что я составлял для своей группы на базе нашего опыта и опыта коллег по цеху: http://kee.sharpdesign.ru/NashiStandarty
спустя 20 часов [обр] Алексей Рюмин aka Dwarf(0/864)[досье]
Not Found
The requested URL /NashiStandarty was not found on this server.

Apache/1.3.27 Server at kee.sharpdesign.ru Port 80
спустя 2 часа 56 минут [обр] Александр Сытник(0/54)[досье]
Алексей Рюмин aka Dwarf[досье] Поищите от корня сайта, там ссылочка есть...
спустя 3 месяца 22 дня [обр] Sergei Erjemin (webdragon)(18/182)[досье]

Если бы я был консультантом, я бы требовал чтобы документв подобные "Нашим стандартам" Алексей Рюмин aka Dwarf[досье] были в студии подрядчике.

На самом деле не важно какие станадрты. Если я как консультатн со стороны заказчика, буду навязывать испольнителю исключительно детально проработанные стандарты, то с 99% вероятностью вступлю в конфликт со стандартами студии (например, по наименованию классов, внутренней документации, именованию переменых и пр. пр. пр.). Если же стандарты будут поверхностными то можно такое наколбасить не нарушая и буквы такого стандарта.

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

спустя 2 месяца 10 дней [обр] Кусо Мендокуси(0/2)[досье]
Алексей Рюмин aka Dwarf[досье]
Виноват. Вот рабочая ссылка:
http://kee.sharpdesign.ru/wacko/NashiStandarty
спустя 47 секунд [обр] Кусо Мендокуси(0/2)[досье]
Возможно, вас также заинтересует http://in.jetstyle.ru/standards как пример.
спустя 23 часа [обр] Евгений Петров(0/1055)[досье]

Алексей Серебряков[досье]
Впечатлен проделанной работой. Откровенно говоря, трудно представить заказчика, согласующего все моменты, указанные в документе, с интернет-компанией, веб-студией и т.д. Грамотные работы студии больше говорят сами за себя.
В качестве ознакомления новых работников компании пригодится. Что-то типа "стайлера". Чтобы учить их и "воспитывать"...
Ну, или в качестве Вашего отчета перед заказчиком о проделанной работе:)

Теперь по существу:

3.9 ...эти данные должны идти в обратном порядке: название страницы, название раздела, название веб-сайта.

Не по-русски, да и с точки зрения продвижения сайта не имеет преимущества перед обычной схемой конкретизации: Общее - Частное - Детальное.

3.12. На любой странице веб-сайта не следует размещать ссылку на эту же страницу...

Хм... Вопрос столь часто и безрезультатно обсуждался, что все уже махнули рукой.
И можно рассматривать в этом контексте случай, когда в форме поиска автоматом заполняются поля и при нажатии на кнопку я попаду именно на эту же страницу?

5.7 ... Использование этих тегов в финальной версии веб-сайта не допускается.
<ins> <del> <base> <pre> <center> <font>

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

5.11. На каждой странице сайта должен быть обязательно указан цвет ее фона.

Зачем? Ведь в CSS это должно быть четко прописано.

7.3. Следует разделять ошибки на штатные и непредвиденные. Штатные ошибки по умолчанию не протоколируются, если в Техническом Задании не указано иное.

С ошибками на стороне сервера запутано. Поскольку ВСЕ ошибки HTTP и скриптов должны протоколироваться, то что имеется ввиду?

7.4. При возникновении непредвиденных ошибок страница в браузере посетителя должна отобразиться корректно.

Ошибка она и в Африке... В скрипте, собирающем страницу, произошел сбой. Что должно вывестись?

8.6 ... не рекомендуется использовать скрипты на стороне браузера для создания динамического HTML кода.

Далеко не всегда. Пример: есть механизм, значительно упрощающий заполнение сложной формы, использующийя JS. Сделав запись <script ...>контент в случае поддержки JS-сценариев</script><noscript>контент в случае отсутствия поддержки</noscript> я могу направить посетителей на разные страницы. Тем самым, не обделяя никого, сокращаем время для тех, у кого не отключен JS.

спустя 21 минуту [обр] Евгений Петров(0/1055)[досье]

Кусо Мендокуси[досье]
Раздел про стилистику не мешает поправить...

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

Аспект - точка зрения, с которой рассматривается какое-либо явление, понятие, перспектива (от лат. aspectus вид). Теперь попробуйте расшифровать эту фразу.

... либо иметь обоснование всех тех моментов, где они отступают от данного стандарта.

IMHO более по-русски "либо иметь обоснование всех отступлений от данного стандарта".

Это то, что касается стилистики.

Все страницы должны тестироваться в браузерах ... и по возможности MS IE 6 на полную идентичность оформления и функциональности...

А ничего, что по Hotlog более 63% аудитории рунета пользуются именно этим браузером???

В контент-поле не должен использоваться тег <span> (используйте <div>) и аттрибут style.

"The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents."???

И такого хватает. Знаков препинания в том числе:).

спустя 2 часа 6 минут [обр] Кусо Мендокуси(0/2)[досье]

Евгений Петров[досье]
Спасибо за комментарии.
Если обратите внимание, стандарты outdated. Сейчас я там более явно об этом напишу.
Например, в начале года MSIE6 пользовались далеко не 60% пользователей.

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

Очень долго искал в поднадзорных мне стандартах упоминания про контент-поле. В итоге нашёл их в других стандартах, к которым отношения не имею. Пожалуйста, будьте точны. Кстати, контент-поле — это, как я смог понять, довольно специфическое понятие, слабо относящееся ко всему возможному богатству XHTML.

Буду рад предоставить вам доступ для выправления знаков препинания как на http://kee.sharpdesign.ru, так и на http://in.jetstyle.ru/standards. Впрочем, там для разбора и комментирования есть комментарии и дальнейшее обсуждение тех документов предлагаю перенести туда, чтобы не засорять здесь дискуссию оффтопиком.

спустя 12 часов [обр] Алексей Серебряков(0/10)[досье]

Евгений Петров[досье]
Согласен с тем, что грамотные работы говорят сами за себя... с той лишь оговоркой, что говорят они что-то только для других разработчиков, таких же как все мы. Для клиентов - это темный лес и выводить их из него не надо. Возможно Вы видели по ТВ новую рекламу Лексуса, в которой ничего не говорится о машине кроме того, что "на днище прикреплены специальные пластины для снижения уровня шума". И все. Ничего об удобстве, красоте и пр. Этот документ - по сути то же самое. Его главная задача - дать понять заказчику, что созднаие веб-сайта - это чертовски сложное мероприятие.
А теперь по сути:

  1. Страница - раздел - сайт (или страница - сайт) имеет несколько весьма существенных преимуществ: во-первых, в заголовке окна браузера (в свернутом виде) будет видна именно текущая страница, во-вторых, в результатах поиска в поисковой службе - тоже видно название страницы, в-третьих, при добавлении в избранное, естественно, лучше пусть будет видно название страницы, а не сайта. Я исхожу из предположения, что посетителю сайта глубоко наплевать, что за сайт он просматривает в данный момент, ему важней информация, поэтому название страницы имеет явный приоритет над названием сайта.
  2. По поводу ссылок на саму себя, вопрос действительно обсуждается долго. Но из-за этого он не потерял актуальности по крайней мере для меня. Это грубое нарушение правил навигации (за редкими исключениями). И этот пункт, естественно, не относится к формам.
  3. По поводу тегов - согласен. В новой версии этого уже нет. Хотя такое "масло масляное" не совсем бесполезно по той простой причине, что разработчик вряд ли будет скачивать себе спецификацию XTHML и действительно кропотливо изучать ее. Поэтому изначально была мысль оставить наиболее существенные положения (отличающиеся от обычных) для особо ленивых.
  4. Да где угодно. Главное - чтобы указывалось.
  5. Возможно, из этого пункта не совсем ясно, что имелось ввиду. Поясню на примере: после отсылки данных формы (если они не проверяются на клиенте), скрипт может посчитать некоторые данные некорректными и опять выдать форму с ошибкой. Это штатная ошибка (то есть предусмотренная при создании скрипта). Или скрипт начинает разрываться на куски из-за того, что в присланных данных есть кавычки, спецсимволы или что-нибудь еще, а в скрипте такая ошибка не предусмотрена. Тогда она "непредвиденная". И возникает эта ошибка уже не в скрипте, а на уровне интерпретатора. Лог нужен для вторых, а не для первых.
  6. Если уж сбой в скрипте произошел можно минимизировать последствия. Как я уже писал: "ошибка не должна повлиять на

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

  1. Формы - это отдельная песня. Тут прежде всего имелось ввиду, что Яваскрипт ни под каким предлогом нельзя использовать для создания непосредственного контента страницы.
спустя 55 минут [обр] Евгений Петров(0/1055)[досье]

Алексей Серебряков[досье]
Особенно для заказчика с любимым "а вот здесь красненьким подкрасить":)
По поводу навигации... Не пойму никак, что так сильно вцепились в эту позицию? Есть более важные моменты, на которые нужно обратить внимание.

  1. Четкая логическая структура сайта и заранее определенная реакция на возможные действия пользователя, включая отправку форм. Продуманная система вертикальных и горизонтальных ссылок.
  2. Некая "классификация" сайтов, позволяющая более подробно описать требования к графике, включению объектов, использующих плагины, использованию сценариев JS, ActiveX, апплетов и т.п.
  3. Требования к "весу" страниц и графических элементов.
  4. Возможный переход на другой хостинг.
  5. Выбор (или создание) CMS, отвечающей потребностям в создании и редактировании контента. Возможность развития ее функциональности. Требует отдельного ТЗ, как минимум...
  6. Ну и, наконец, то, с чего следует начать - какие функции будет выполнять сайт? Его цель, увязывание с остальными бизнес-процессами, оффлайн-мероприятиями и т.д.

IMHO можно погрязнуть в составлении такого расширенного документа...
А все стандарты и рекомендации можно сделать в виде приложений...

спустя 36 минут [обр] Евгений Петров(0/1055)[досье]

Алексей Серебряков[досье]

подключение к БД вообще обычно не проверяется

Это действительно так?

спустя 1 час 43 минуты [обр] Алексей Серебряков(0/10)[досье]

Евгений Петров[досье]
Про "красненькое" - это как серпом по больному месту. Да уж. А к навигации я не "прицеплялся", это все лишь один из более чем 180 пунктов (в новой версии). Просто Вы спросили - я ответил. Ничего личного =))

Что же касается других более важных моментов, то некоторые из них я отсек еще в момент определения идеологии этого документа. А именно: рассматриваются только стандартные копоративные сайты, не промо-, не урезанные, не электронные магазины в чистом виде, а обычный корпоративный сайт. Поэтому вопросы ActiveX, Java (не Javascript), всевозможных апплетов и плугинов (включая Flash, Shockwave) в большинстве своем отпадают сразу, потому что на корпоративном сайте, если они и есть, то должны использоваться крайне редко. Хотите презентацию намутить? - Пожалуйте Флеш. Но никакого флеша для навигации, простого оформительства, сплеш-страниц и прочего и прочего. Никаких тебе Java-апплетов для отображения идущих часов (сколько раз меня клиенты из финансовой сферы просили об этом).

"Вес" страниц регламентировать сложно. Это должно регулироваться ТЗ, но никак не сводом общих норм. Единственное, что можно добавить - это рекомендацию, что все должно быть оптимизировано. То же относится и к хостингу. Меня, равно как и клиента, мало волнует, что где-то есть хостинг, что сайт должен быть где-то размещен. Клиенту на это н.а.п.л.е.в.а.т.ь. Важно, как сайт работает, а не перемещается, поэтому из общих норм этот пункт тоже надо исключить. CMS - тоже удел ТЗ. Если пытаться в общих нормах описать все программные механизмы, то тогда действительно погрязнуть в этом. Вспомним о статистике, форумах, голосованиях и собственных баннерных системах =)). Опять же последний пункт тоже должен укзываться в ТЗ.

Этот документ - лишь сборник того, что является общим практически для любого ТЗ. Это ни в коем случае не попытка заменить ТЗ, а просто сделать его чуть короче за счет того, что некоторые технические и "идеологические" моменты будут описаны в нормах. А ОБЩЕГО не так уж и много, как может показаться, поэтому и документ "расширенным" вряд ли получится.

спустя 43 минуты [обр] Евгений Петров(0/1055)[досье]

По поводу CMS не могу согласиться. Часто и густо вопрос звучит так: "а сколько будет стоить разработать сайт, чтоб не хуже, чем... (и еще масса других уточнений)" О том, что контент надо добавлять, менять и т.д. нет даже малейшего представления. Поэтому наличие этого пункта в документе для заказчика просто необходимо.

Вес до байта регламентировать сложно. Но планку установить надо. Для корпоративного, скажем, 70-80 кило. И то много. Тут много аспектов.

Теперь некоторые корпоративные сайты уже не сильно отличаются от интернет-магазинов. Каталожная структура, тот же набор полей, ситема заказа и т.д. Есть, безусловно, и "сайты-визитки" (терпеть не могу это название:). Для них будут совершенно другие требования. Как по наличию CMS, так и по весу, включению "неродных для браузера объектов" и функциональность, конечно. Безусловно, все должно быть в ТЗ.

Что касается хостинга... Например, у того, где расположен сайт, одна структура и ПО, у другого может отличаться. Не дай бог, конечно, но вдруг захотите переехать (связь стала отвратной, по цене не устраивает, техподдержка хромает...)? Что менять, перенастраивать и в каких объемах? Я видел такие ситуации.

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

спустя 7 минут [обр] Евгений Петров(0/1055)[досье]
Кусо Мендокуси[досье]
Хм, если позволит время - чем смогу:)
Зарегистрировался. Предоставляйте:)
спустя 8 месяцев [обр] z...(25/47)[досье]

М Алексей Серебряков[досье],
тема все еще актуальна?

Как поживают ваши "Технические нормы"? Есть что еще обсудить или тему можно закрыть?

Powered by POEM™ Engine Copyright © 2002-2005