Комментарии 70
Забыли упомянуть: прикрепить сайт к Яндекс.Вебмастер и Google Webmaster Tools
Если сайт компании:
Зарегистрировать в Яндекс.Адресах и Гугл.Адресах, добавить на Wikimapia.org
В принципе это подпадает под «Проверить форматирование сайта в результатах выдачи поисковиков», но, думаю что тут стоит расшифровать поподробнее
Если сайт компании:
Зарегистрировать в Яндекс.Адресах и Гугл.Адресах, добавить на Wikimapia.org
В принципе это подпадает под «Проверить форматирование сайта в результатах выдачи поисковиков», но, думаю что тут стоит расшифровать поподробнее
Первым пунктом я бы написал «Подумать, нужен ли этот сайт кому то, кроме меня», после этого остальной чеклист может оказаться ненужным, за одно избавимся от кучи ежедневно захламляющих интернет "СуперМегаВебДваНульСоциальныхСетейДляСамыхКрутых" :)
Думаю стоит заменить предложений пункт тем что — «Будет ли он кому то полезен вообще, хо тебе тебе»…
Иногда ресурс который делаешь только для себя, сначала становится интересным для твоих друзей, а потом и для масс интернета приходится открывать )))
Иногда ресурс который делаешь только для себя, сначала становится интересным для твоих друзей, а потом и для масс интернета приходится открывать )))
Я не отрицаю, тут вкусы людей решают, а они у всех разные. А вообще я считаю не стоит каждый раз надеяться на случай — «а вдруг понравиться!», и не полениться подумать, а «нужно ли». Ведь экономите не только пространство на хостинге, но и в первую очередь свое время, которое вы смогли бы потратить на более полезные/нужные вещи.
Насколько я понял это регламент перед непосредственным запуском — думать нужен ли этот ресурс или нет надо было на этапах планирования, утверждения, финансирования.
Может быть, но некоторые пункты все же, наводят на мысль, что тут смешаны эти этапы.
Да и «чеклист запуска сайта», я лично для себя, могу растолковать в нескольких контекстах.
Ну и если даже так, может этапы «планирования, утверждения и финансирования» прошли на бодром дыхании энтузиазма и радости от идеи, а в таком состоянии люди иногда не видят/не хотят видеть свои ошибки, а посмотреть назад никогда не было зазорным, вдруг все таки всё это было ошибкой? :)
Да и «чеклист запуска сайта», я лично для себя, могу растолковать в нескольких контекстах.
Ну и если даже так, может этапы «планирования, утверждения и финансирования» прошли на бодром дыхании энтузиазма и радости от идеи, а в таком состоянии люди иногда не видят/не хотят видеть свои ошибки, а посмотреть назад никогда не было зазорным, вдруг все таки всё это было ошибкой? :)
Кратко этот пункт называется «Определить целевую аудиторию». Делается это, кстати, ещё на этапе проектирования сайта, определения его видения, но никак не создания.
Судя по тому, что сейчас происходит в рунете, я сомневаюсь что кто то знает про этот пункт, и этапы планирования видимо у них тоже галопом пробегают :)
Я чуть выше и написал, что у нас почему то, почти у всех, принято делать «на эмоциях», а не по-плану.
Я чуть выше и написал, что у нас почему то, почти у всех, принято делать «на эмоциях», а не по-плану.
Ну почему-же :-)
Я вообще не понимаю когда мне приводят в доводы запрос в поисковике на «данную фразу», если там есть ответ, это совсем не значит что «вся та масса людей о которой я говорил выше», читает это, и блюдет :)
Я могу привести в пример запрос на тексты из латыни, это же не значит что вся страна у нас знает латынь и интересуется ею :)
В общем мы уже от темы отходим, так что если желаете продолжить полемику на данную тематику, то пишите в личку ;)
Я могу привести в пример запрос на тексты из латыни, это же не значит что вся страна у нас знает латынь и интересуется ею :)
В общем мы уже от темы отходим, так что если желаете продолжить полемику на данную тематику, то пишите в личку ;)
А что места в Интернете уже не хватает?
ну этот пункт больше подходит для момента проектирования сайта, а не запуска. Я так понял, что автор описывает как-раз тот момент, когда крутость проекта и его нужность уже была определена ранее. Этот список может служить как частичный ориентир в плане проведения завершающих работ по сайту, а то о чем говорите Вы, это делается на этапе проектирования еще или даже на этапе осмысления идеи :)
этот вопрос нужно задавать перед началом разработки ТЗ на сайт (или самого сайта, если разработчик надеется обойтись без ТЗ).
кучу времени сэкономит :)
кучу времени сэкономит :)
Интересная идея, можно еще добавить поля с датой начала и датой когда поставил галочку )
НЛО прилетело и опубликовало эту надпись здесь
Это скорее ради интереса, проверить будет ли оно хоть как-то смотреться. Кроме того, иногда на таком тесте видно, что в резине не выставлена минимальная ширина, что делает из сайта уродство на низких разрешениях. А так хоть скрол.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А пользователей нетбуков вы как таргет аудиторию не рассматриваете?
Небольшая опечатка, эту статью по этому списки не прогонял )
● Заголовки страниц очень важны; убедиться, что они осмысленны и содержат важныЕ ключевые слова
● ПрОверить и реализовать кеширование где это необходимо
ну и возможно еще есть
● Заголовки страниц очень важны; убедиться, что они осмысленны и содержат важныЕ ключевые слова
● ПрОверить и реализовать кеширование где это необходимо
ну и возможно еще есть
Такое ощущение, что я это уже читал где-то с месяц назад…
Спасибо за рерайт, но — ё-маё, ну не на хабре же!
НЛО прилетело и опубликовало эту надпись здесь
Пардон, того топика я не видел в апреле. Что ж, если вылезет на главную, значит не я один его не читал. Кроме того, здесь есть PDF-ка.
А ссылка на источник и автора?
Присутствует в конце статьи. Это не rewrite вышеназванного топика, а самостоятельная версия.
Мне больше кажется, что это самостоятельная версия на основе оригинала. На вашем сайте даже стиль таблицы такой же, как на сайте оригинала: www.boxuk.com/blog/the-ultimate-website-launch-checklist VS drupaldance.com/blog/website-launch-checklist
НЛО прилетело и опубликовало эту надпись здесь
ff → ff, ffi → ffi, ffl → ffl и т.д. (http://en.wikipedia.org/wiki/Typographic_ligature)
Я так и знал, что будет упрек на счет точек в конце, но они не поставлены специально, ибо от них рябит в данном конкретном списке.
Я так и знал, что будет упрек на счет точек в конце, но они не поставлены специально, ибо от них рябит в данном конкретном списке.
Безопасно использовать только fi и fl, они вроде бы есть во всех системных шрифтах (по крайней мере в Windows). ff, ffi и прочие ffl могут отображаться совсем не тем шрифтом, которым планировалось, или вообще квадратиками.
Черт, меня таращит от этой картинки — ручка, пишущая в воздухе.
Вы это все делаете прямо перед запуском?
Это как Дед Мороз — добрая сказка для детей младшего школьного возраста =) Все понимают, что выдумка, но послушать новогодние истории любят ;))
Суть даже не в том что все это хорошо бы сделать перед выгрузкой, просто многое из перечисленного стоит делать в процессе разработки, а некоторое и на ее ранних этапах.
Расставлять индексы в базе потому что так положено по чеклисту, ну извините. Если сайт не держит планируемую нагрузку то и так задумаешься о их расставлении, а если держит то смысл?
Тестировать на совместимость в браузерах и под разными разрешениями перед самой выгрузкой? А может это стоит сделать сразу после разработки верстки?
И такого много.
Расставлять индексы в базе потому что так положено по чеклисту, ну извините. Если сайт не держит планируемую нагрузку то и так задумаешься о их расставлении, а если держит то смысл?
Тестировать на совместимость в браузерах и под разными разрешениями перед самой выгрузкой? А может это стоит сделать сразу после разработки верстки?
И такого много.
Конечно =) Я, например, во время верстки по частям просматриваю сайт во всех браузерах и сразу все выверяю — как стоит шапка, как сайдбары держатся… а то в конце потом полная каша в ИЕ6 вылезает! Но, согласитесь, заголовок «То, что нужно делать во время проектирования и разработки сайта» не столь громкий, как «Чеклист запуска сайта». Не хватает только тега «сенсация!» =)
Интересно было сравнить с webmascon.com/topics/tools/09a.asp (статья от 31.10..2004)
Отличная ссылка! Спасибо! Что особенно нужное в статье на Webmascon-е, так это ссылки на онлайн сервисы для проверки чеклиста. Приведу сразу и оригинал той статьи на Webmascon-е: www.maxdesign.com.au/presentation/checklist.htm (англ.)
Хорошо подборка, но мало кто этим будет пользоваться. Наверное даже никто.
В большинстве случаев связность, корректность и орфография Lorem ipsum… не подлежит сомнению =)
добавил страницу в закладки!
Я раньше так глобально разными проверками сайта не занимался, скоро запуск — скоро и опробую)
По времени это затянется — но в будущем должно быть намного меньше проблем!
Я раньше так глобально разными проверками сайта не занимался, скоро запуск — скоро и опробую)
По времени это затянется — но в будущем должно быть намного меньше проблем!
Интересно было бы прикинуть бюджет на все перечисленные операции и сопоставить его с бюджетом на непосредственную реализацию фич. Склоняюсь к паритету :)
Несколько вопросов:
1. Что такое «Добавить сайт в социальные медиа: Twitter, ВКонтакте, LinkedIn, Facebook, и т.д.»? Куда их там добавлять?
2. Почему бы не проверить сайт при выключенных картинках?
3. Чем проверять валидность Javascript?
1. Что такое «Добавить сайт в социальные медиа: Twitter, ВКонтакте, LinkedIn, Facebook, и т.д.»? Куда их там добавлять?
2. Почему бы не проверить сайт при выключенных картинках?
3. Чем проверять валидность Javascript?
Ну, например FireBug
Что касается лигатур.
Как они влияют на индексацию контента поисковыми системами?
Как она поведёт себя, когда встретит лигатуру fi вместо двух букв fi? Тем более, текст в заголовке — крайне важен для индексации.
Как они влияют на индексацию контента поисковыми системами?
Как она поведёт себя, когда встретит лигатуру fi вместо двух букв fi? Тем более, текст в заголовке — крайне важен для индексации.
Где настройки веб-сервера? Где watchdog? Где автоматическое тестирование? Упущено очень многое…
С очень многими пунктами не согласен:
> ● Вычитать тексты и проверить правописание
> ● Связность текстов
Это нужно делать при приемке контента, но никак не перед запуском.
> ● Проверить нет ли на сайте вшитых ссылок на dev-сервер (т.е. после запуска ссылки должны вести на сайт «в миру»)
А это вообще вопиющая халатность: все ссылки должны генерироваться автоматически, в крайнем случае быть относительными. В любом случае, контент со ссылками — худшее и непереносимое решение. Удачи при создании вап-версии.
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
> ● Привести формат ссылок к читабельному виду (напр. site.ru/blog/how-to-make-coffee, site.ru/user/vasya и т.д.)
Задача для ранней стадии, скорее для разработчика движка (или настройщика готового)
> ● Проверить весь заказанный/особый/сложный функционал
> ● Проверить работу поиска (включая релевантность)
> ● Протестировать все формы (контактов, комментариев, фидбека, ...), поставить на них капчу или другую защиту
>…
Все это должно тестироваться не руками, а юнит-тестами в автоматическом режиме. Формы отдельно тестировать не нужно, проверять нужен сам движек сайта на корректность обработки форм. Капча должна расставляться в полуавтоматическом режиме, причем далеко не везде (например, в формах для связи ее делать не следует: лучше пропустить 20 спам-сообщений, чем упустить 1 баг-репорт)
> ● Проверить нет ли у посетителей доступа к служебным/секретным/закрытым страницам
> ● Закрыть поисковикам доступ к служебным/секретным/закрытым разделам сайта, используя robots.txt
Если такое допускается, то автора надо без зазрения совести увольнять с заключением о проф.непригодности.
> ● Проверить и реализовать кэширование где это необходимо
Какое кеширование? Средствами вебсервера? Средствами движка? Нужно ли кеширование байт-кода? Тема кеширования не раскрыта, а это порой очень большая часть при разработке.
> ● Создать свои страницы 404/403
А где 500/503? Где был автор в момент отладки?
Да и 403 — это как плевок в пользователя, «страница есть, но не для тебя, пшел вон отсюда»
С очень многими пунктами не согласен:
> ● Вычитать тексты и проверить правописание
> ● Связность текстов
Это нужно делать при приемке контента, но никак не перед запуском.
> ● Проверить нет ли на сайте вшитых ссылок на dev-сервер (т.е. после запуска ссылки должны вести на сайт «в миру»)
А это вообще вопиющая халатность: все ссылки должны генерироваться автоматически, в крайнем случае быть относительными. В любом случае, контент со ссылками — худшее и непереносимое решение. Удачи при создании вап-версии.
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
> ● Привести формат ссылок к читабельному виду (напр. site.ru/blog/how-to-make-coffee, site.ru/user/vasya и т.д.)
Задача для ранней стадии, скорее для разработчика движка (или настройщика готового)
> ● Проверить весь заказанный/особый/сложный функционал
> ● Проверить работу поиска (включая релевантность)
> ● Протестировать все формы (контактов, комментариев, фидбека, ...), поставить на них капчу или другую защиту
>…
Все это должно тестироваться не руками, а юнит-тестами в автоматическом режиме. Формы отдельно тестировать не нужно, проверять нужен сам движек сайта на корректность обработки форм. Капча должна расставляться в полуавтоматическом режиме, причем далеко не везде (например, в формах для связи ее делать не следует: лучше пропустить 20 спам-сообщений, чем упустить 1 баг-репорт)
> ● Проверить нет ли у посетителей доступа к служебным/секретным/закрытым страницам
> ● Закрыть поисковикам доступ к служебным/секретным/закрытым разделам сайта, используя robots.txt
Если такое допускается, то автора надо без зазрения совести увольнять с заключением о проф.непригодности.
> ● Проверить и реализовать кэширование где это необходимо
Какое кеширование? Средствами вебсервера? Средствами движка? Нужно ли кеширование байт-кода? Тема кеширования не раскрыта, а это порой очень большая часть при разработке.
> ● Создать свои страницы 404/403
А где 500/503? Где был автор в момент отладки?
Да и 403 — это как плевок в пользователя, «страница есть, но не для тебя, пшел вон отсюда»
Действительно, 403 не нужна. А группы пользователей и всякие админки — пережиток тоталитаризма и расовой сегрегации.
> А группы пользователей и всякие админки — пережиток тоталитаризма и расовой сегрегации.
На хорошем сайте не должно быть ссылок, которые ведут на «закрытые» разделы сайта (разные админки), а если пользователь начал перебирать урлы и пытается зайти куда-то вроде example.com/admin/, то ему лучше показать 404, форму авторизации (когда к админке имеет доступ большое количество пользователей), на худой конец просто кинуть редирект на главную. Но не 403.
В случае групп, у которых разные права доступа, лучше показать форму авторизации, где предложить ввести логин/пароль пользователя, имеющего доступ а этот раздел. Причем указать, почему появилась такая форма, дабы пользователь не вводил свое имя еще раз, тем самым запутываясь. Но не 403.
403 — это оплеуха в чистом виде. Уж лучше 500.
На хорошем сайте не должно быть ссылок, которые ведут на «закрытые» разделы сайта (разные админки), а если пользователь начал перебирать урлы и пытается зайти куда-то вроде example.com/admin/, то ему лучше показать 404, форму авторизации (когда к админке имеет доступ большое количество пользователей), на худой конец просто кинуть редирект на главную. Но не 403.
В случае групп, у которых разные права доступа, лучше показать форму авторизации, где предложить ввести логин/пароль пользователя, имеющего доступ а этот раздел. Причем указать, почему появилась такая форма, дабы пользователь не вводил свое имя еще раз, тем самым запутываясь. Но не 403.
403 — это оплеуха в чистом виде. Уж лучше 500.
>все ссылки должны генерироваться автоматически
как все попривыкали к CMS. а бывают ещё и самописные сайты…
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
>При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
и главное забыло — обвешать сайт всплывающими порно-банерами и партнерскими ссылками, чтобы webmoney капали :)))) (разумеется уместно не на всех проектах.
как все попривыкали к CMS. а бывают ещё и самописные сайты…
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
>При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
и главное забыло — обвешать сайт всплывающими порно-банерами и партнерскими ссылками, чтобы webmoney капали :)))) (разумеется уместно не на всех проектах.
> как все попривыкали к CMS. а бывают ещё и самописные сайты…
Это которые в ворде или notepad.exe делают? Без слез на них смотреть нельзя, а если и можно, то строятся такие сайты слишком долго. В остальных случаях используют CMS в той или иной степени, даже если в итоге на хост заливается статический HTML.
> это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
А что в этом сложного? Грамотный подход к разработке — это даже скорее облегчение труда, а если профильная фирма не может обеспечить инструменты для работы, то я бы очень сильно задумался о профильности этой конторы.
про вебмани не понял юмору.
Это которые в ворде или notepad.exe делают? Без слез на них смотреть нельзя, а если и можно, то строятся такие сайты слишком долго. В остальных случаях используют CMS в той или иной степени, даже если в итоге на хост заливается статический HTML.
> это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
А что в этом сложного? Грамотный подход к разработке — это даже скорее облегчение труда, а если профильная фирма не может обеспечить инструменты для работы, то я бы очень сильно задумался о профильности этой конторы.
про вебмани не понял юмору.
сами мы не местные, но интересуемся.
XML Sitemap — это что?
XML Sitemap — это что?
Это список всех URLов сайта в специальном xml-формате.
Создаётся для того, чтобы скормить поисковой системе — указать его в robots.txt или в вебмастерах. Так поисковики знают, какие страницы на сайте у вас есть, и сразу качают их все, а не проходят несколькими волнами по ссылкам. Более того, там, в сайтмепе, указывается параметр last-modified: время последнего изменения страницы. Теоретически поисковики учитывают этот параметр. Например, если ластмодифаеды в сайтмепе обновились, то у поисковика есть ещё один повод скачать ваши страницы заново.
Так-то.
Создаётся для того, чтобы скормить поисковой системе — указать его в robots.txt или в вебмастерах. Так поисковики знают, какие страницы на сайте у вас есть, и сразу качают их все, а не проходят несколькими волнами по ссылкам. Более того, там, в сайтмепе, указывается параметр last-modified: время последнего изменения страницы. Теоретически поисковики учитывают этот параметр. Например, если ластмодифаеды в сайтмепе обновились, то у поисковика есть ещё один повод скачать ваши страницы заново.
Так-то.
Ваш топик как раз к месту. Запускаем новый дизайн сайта.
Полезная напоминалка. Можно обернуть все это в небольшой стартап в виде «онлаин чеклиста по моим проектам».
Много полезного, спасибо…
Когда читал, обратил внимание на то, что существуют пункты разного рода. Что-то важное, что делается на этапе дизайна или на этапе проектирования, соседствует с тем, что вообще далеко не обязательно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чеклист запуска сайта