Комментарии 98
Самый главный вопрос: какая практическая польза этого?
Ну не валиден сайт, не печатается и, тем более, никакой заботы об инвалидов нет. А ссылок на нем — миллион, ибо новостной портал. И, что, сайт сразу не качественный?
А как оценивать «адаптацию под аудиторию сайта»?
Ну не валиден сайт, не печатается и, тем более, никакой заботы об инвалидов нет. А ссылок на нем — миллион, ибо новостной портал. И, что, сайт сразу не качественный?
А как оценивать «адаптацию под аудиторию сайта»?
// Ну не валиден сайт, не печатается и, тем более, никакой заботы об инвалидов нет. А ссылок на нем — миллион, ибо новостной портал. И, что, сайт сразу не качественный? //
Сайт значит не максимально качественный. Методика не говорит, что все пункты обязательны, она просто заранее освещает ВСЕ пункты. Чтобы знали, что не так.
// А как оценивать «адаптацию под аудиторию сайта»? //
Если ваша аудитория — пожилые бухгалтеры, то вряд ли стоит использовать в тексте гиковские термины, например. Если у вас развлекательный сайт то никто не будет заполнять форму регистрации на 20 пунктов.
Такие ошибки много кто делает, на самом деле.
Сайт значит не максимально качественный. Методика не говорит, что все пункты обязательны, она просто заранее освещает ВСЕ пункты. Чтобы знали, что не так.
// А как оценивать «адаптацию под аудиторию сайта»? //
Если ваша аудитория — пожилые бухгалтеры, то вряд ли стоит использовать в тексте гиковские термины, например. Если у вас развлекательный сайт то никто не будет заполнять форму регистрации на 20 пунктов.
Такие ошибки много кто делает, на самом деле.
А практическая польза, как выше написано, скорость и универсальность. Т. е. методика позволяет БЫСТРО протестировать ПРАКТИЧЕСКИ ВСЕ важные моменты качества сайта. Она не о целях заказчика, но о целях пользователя на сайте, а именно о сайте как таковом.
Практической пользы так и не увидел. Это просто список важных по вашему мнению пунктов? Зачем он кому-то? Какую пользу из него можно извлечь?
Мне надо по каждому пункту расписать контр-примеры, чтобы вы поняли, что ни слово «все», ни слово «важные» тут не применимо? Что в для каждого типа сайтов будут свои приоритеты.
Мне надо по каждому пункту расписать контр-примеры, чтобы вы поняли, что ни слово «все», ни слово «важные» тут не применимо? Что в для каждого типа сайтов будут свои приоритеты.
Как можно привести контрпримеры, если это только список пунктов, а не набор утверждений по каждому из них?
Практическая польза, если совсем уж на примере, то такая. Если вы заказчик, то перед приемом сайта можно пройтись по этим пунктам и найти десяток вещей, которые веб-студия просто пропустила. Они всегда пропускают что-то.
Если вы веб-студия то внести в свою методику разработки сайта автоматическое достижение качества по всем этим пунктам — дело самоуважения. Это же так просто.
Практическая польза, если совсем уж на примере, то такая. Если вы заказчик, то перед приемом сайта можно пройтись по этим пунктам и найти десяток вещей, которые веб-студия просто пропустила. Они всегда пропускают что-то.
Если вы веб-студия то внести в свою методику разработки сайта автоматическое достижение качества по всем этим пунктам — дело самоуважения. Это же так просто.
Да не нужны все эти пункты. Нужны некоторые из них. В каждом типе сайтов свои. Это во-первых.
Во-вторых, есть такая штука, как приоритеты и ограниченный бюджет. Мы живем в реальном мире.
Если заказчик сошлется на валидность, то будет отослан к договору и ТЗ, где ничего об этом не сказано. Аналогично и с правилом 7±2. Аналогично и со многими другими пунктами. Если он попытается согласовывать ТЗ на основании таких пунктов, то для начала, чтобы оценить адекватность заказчика, ему будет задан вопрос: «какова цель сайта? чтобы прибыль приносил или чтобы каким-то пунктам удовлетворял?»
Этот чек-лист не нужен ни веб студии, ни заказчику.
Во-вторых, есть такая штука, как приоритеты и ограниченный бюджет. Мы живем в реальном мире.
Если заказчик сошлется на валидность, то будет отослан к договору и ТЗ, где ничего об этом не сказано. Аналогично и с правилом 7±2. Аналогично и со многими другими пунктами. Если он попытается согласовывать ТЗ на основании таких пунктов, то для начала, чтобы оценить адекватность заказчика, ему будет задан вопрос: «какова цель сайта? чтобы прибыль приносил или чтобы каким-то пунктам удовлетворял?»
Этот чек-лист не нужен ни веб студии, ни заказчику.
Мне не очень нравятся студии, которые вещи типа валидности не предусматривают сами, а ждут ТЗ заказчика. И если с самой валидностью еще ладно, то не сделать например 404-ю страницу даже если ее нет в ТЗ — это гон.
Еще раз: мы живем в реальном мире. Если заказчик готов заплатить только 20-30к, то ни о каких плюшках и речи идти не будет. Если там договор от 150к, то и отношение совсем другое.
Причем я не говорю о случаях обмана. Все это объясняется заказчику. Очень часто им это и надо, т.к. они сами не знают нужен ли им вообще сайт. В этом случае вкладывается небольшая сумма, а если дальше будет понятно, что проект стоит развивать, то тогда уже идет другой разговор.
Понятия «качественный сайт» не существует вообще. Существует понятие «выполняющий цели заказчика». От этого и надо плясать.
Причем я не говорю о случаях обмана. Все это объясняется заказчику. Очень часто им это и надо, т.к. они сами не знают нужен ли им вообще сайт. В этом случае вкладывается небольшая сумма, а если дальше будет понятно, что проект стоит развивать, то тогда уже идет другой разговор.
Понятия «качественный сайт» не существует вообще. Существует понятие «выполняющий цели заказчика». От этого и надо плясать.
Если студии сложно реализовать перечисленный моменты не сильно поднимаю цену — то ей следует добровольно самоустраниться из рынка.
Я работаю техническим директором небольшой веб студии. В курсе не только про технические моменты, но и финансовые. Так вот говорю вам: хватит смотреть на мир через розовые очки.
Делать только хорошо, качественно и отказываться от тех проектов, что в принципе невозможно так сделать — отлично. Это очень хорошо повлияет на репутацию студии и ее портфолио. Это — работа на будущее. Но финансовые вопросы, к сожалению, бывают важнее. Приоритеты надо расставлять.
Делать только хорошо, качественно и отказываться от тех проектов, что в принципе невозможно так сделать — отлично. Это очень хорошо повлияет на репутацию студии и ее портфолио. Это — работа на будущее. Но финансовые вопросы, к сожалению, бывают важнее. Приоритеты надо расставлять.
Я это отлично понимаю, сам большинство своих проектов никому не покажу :) Ну так эта методика не для того делалась. Она для стимулирования роста над собой.
Что значит «сложно»? Есть задачи, есть ресурсы. Есть выгода. Именно этим должна руководствоваться студия, а не какими-то идеалистическими представлениями о том, «что обязательно должно войти в ТЗ».
Ваше личное дело добиваться ли выполнения всех пунктов или нет. Но скорее речь идет о том что если вы хотите создать сайт высокого качества, вам нужно просмотреть эти пункты.
Сайт может быть успешным и без выполнения этих пунктов. Но высокое качество исполнения этих параметров неизбежно приведет к увеличению лояльности пользователей, ну и как следствие трафика.
Сайт может быть успешным и без выполнения этих пунктов. Но высокое качество исполнения этих параметров неизбежно приведет к увеличению лояльности пользователей, ну и как следствие трафика.
Ну, парни, устроили спор из ничего. Автор выложил чек-лист готовности сайта с точки зрения юзабилиста. Мне, например, понравилось. Спасибо.
Были на хабре и до этого разного рода чек-листы — в каждом из них, обычно, находилось как и что-то совсем ненужное (с моей точки зрения), так и что-то полезное. Peace out!
Были на хабре и до этого разного рода чек-листы — в каждом из них, обычно, находилось как и что-то совсем ненужное (с моей точки зрения), так и что-то полезное. Peace out!
Это как общий чек-лист, что бы ничего не забыть.
И все достаточно красиво структурировано.
Можно даже при заказчике показывать и говорить «Вот по всем этим критериям Вы сможете проверить Ваш будущий сайт — и все будет сделано».
Можно даже при заказчике показывать и говорить «Вот по всем этим критериям Вы сможете проверить Ваш будущий сайт — и все будет сделано».
И при исполнителе тоже показывать и говорить — вот так я буду проверять вашу работу.
Лично я откажусь от такого заказчика. Если заказчик считает, что валидация сайта и его доктайп важнее продаж с него (реальный случай из моей практики), то работать с ним — огромные риски. Надо понимать цели заказчика и фокусировать на них.
Любая работа в IT — это решение конкретных бизнес задач. Не процесс решения, а именно сам факт решения. Это должны понимать все — от заказчика до конечного исполнителя.
Безусловно, задачи можно решать и хорошо, и плохо. Это скажется в будущем. Но их надо прежде всего решать.
Любая работа в IT — это решение конкретных бизнес задач. Не процесс решения, а именно сам факт решения. Это должны понимать все — от заказчика до конечного исполнителя.
Безусловно, задачи можно решать и хорошо, и плохо. Это скажется в будущем. Но их надо прежде всего решать.
Если сайт не какой-то мега-сложный технологически то обеспечение валидности обычно не представляет сложности какой-либо.
Валидность придумали две группы людей:
1)w3c. Для того, чтобы можно было сказать «страница валидна, а браузер показывает криво»
2)Бездарные верстальщики, которые пытаются набить себе цену
Про вторых стоит сказать отдельно.
Не существует профессии «верстальщик». Существует «разработчик интерфейсов» и «программист» (назвал очень примерно). Первый должен владеть html, css, javascript, xml, xslt, знать основы usability и т.п. Ему не нужна в резюме строчка «валидность». Его портфолио говорит за него.
Грамотный верстальщик же в душе должен быть программистом. Только такой человек может делать семантичную и хорошо структурированную верстку. А если у него есть задатки программиста, то что он делает верстальщиком? Лень обучаться? А зачем такие вообще нужны?
Программист (под веб), который не умеет верстать — глуп. И заслуживает должности максимум junior'а. Ибо все программисты ленивы, но только глупые не пытаются упростить себе жизнь. Умному программисту надоест верстать и он сделает себе css-, html-, js-фреймворки. Он придумает как можно стандартизировать элементы верстки внутри фирмы и введет этот стандарт.
1)w3c. Для того, чтобы можно было сказать «страница валидна, а браузер показывает криво»
2)Бездарные верстальщики, которые пытаются набить себе цену
Про вторых стоит сказать отдельно.
Не существует профессии «верстальщик». Существует «разработчик интерфейсов» и «программист» (назвал очень примерно). Первый должен владеть html, css, javascript, xml, xslt, знать основы usability и т.п. Ему не нужна в резюме строчка «валидность». Его портфолио говорит за него.
Грамотный верстальщик же в душе должен быть программистом. Только такой человек может делать семантичную и хорошо структурированную верстку. А если у него есть задатки программиста, то что он делает верстальщиком? Лень обучаться? А зачем такие вообще нужны?
Программист (под веб), который не умеет верстать — глуп. И заслуживает должности максимум junior'а. Ибо все программисты ленивы, но только глупые не пытаются упростить себе жизнь. Умному программисту надоест верстать и он сделает себе css-, html-, js-фреймворки. Он придумает как можно стандартизировать элементы верстки внутри фирмы и введет этот стандарт.
Если мы хотим говорим, что используем язык Х для страниц сайта, мы должны придерживаться его правил. Иначе получается, что мы делаем сайт под последние версии браузеров, а когда через месяц выходят новые — делаем его под них заново.
Люблю этот аргумент:)
Браузеры имеют обратную совместимость. Никто не будет пользоваться браузером, который после апдейта перестанет корректно показывать 90% сайтов в интернете.
Опытный в html+css человек, верстая понимает, что «вот эта конструкция шаткая и может сломаться в старых/новых браузерах». А надежные конструкции еще много лет будут работать как и планировалось. И опять же, валидность тут не причем.
Фиксить мелкие баги в новых браузерах, делать редизайн раз в N лет — нормальный рабочий процесс.
Браузеры имеют обратную совместимость. Никто не будет пользоваться браузером, который после апдейта перестанет корректно показывать 90% сайтов в интернете.
Опытный в html+css человек, верстая понимает, что «вот эта конструкция шаткая и может сломаться в старых/новых браузерах». А надежные конструкции еще много лет будут работать как и планировалось. И опять же, валидность тут не причем.
Фиксить мелкие баги в новых браузерах, делать редизайн раз в N лет — нормальный рабочий процесс.
«Надежные конструкции» читай «валидные современному стандарту конструкции».
Я устал с вами спорить и не вижу смысла. Свое отношение я высказал. Формировалось оно не за один день и пока еще ни одна статья о валидации не смогла его покалебать.
Если же кто-то приведет аргументы, которые помогут изменить мне свою точку зрения, то я скажу спасибо. Но пока таких, к сожалению, не было.
А в те немногие моменты, когда мне приходиться верстать, мой код «почему-то» корректно отображается сразу во всех браузерах. Ну или требует совсем небольших доработок.
Мне и самому не нравиться делать закругленные уголки 9 дивами (именно так не делаю, просто описал суть), но работать оно будет везде. Гарантированно. И в IE6, и в IE10.
Если же кто-то приведет аргументы, которые помогут изменить мне свою точку зрения, то я скажу спасибо. Но пока таких, к сожалению, не было.
А в те немногие моменты, когда мне приходиться верстать, мой код «почему-то» корректно отображается сразу во всех браузерах. Ну или требует совсем небольших доработок.
Мне и самому не нравиться делать закругленные уголки 9 дивами (именно так не делаю, просто описал суть), но работать оно будет везде. Гарантированно. И в IE6, и в IE10.
> А как оценивать «адаптацию под аудиторию сайта»?
У Нильсена в алертбоксе были старые, но не потерявшие актуальность статьи о специфических возрастных категориях аудитории:
Kids' Corner: Website Usability for Children
Usability of Websites for Teenagers
Usability for Senior Citizens
У Нильсена в алертбоксе были старые, но не потерявшие актуальность статьи о специфических возрастных категориях аудитории:
Kids' Corner: Website Usability for Children
Usability of Websites for Teenagers
Usability for Senior Citizens
чуть бы доработать в сторону измеряемых результатов. довольно тяжело проверить «солидность» или «заметность меню» сайта. попробуйте переформулировать это в вопросы, на которые можно ответить только да/нет.
в целом, хорошая идея и подход.
в целом, хорошая идея и подход.
) ну нельзя за час оценить качество текста и медиа материала
по этой схеме невозможно оценить качество сайта, как минимум потому, что не даны критерии оценки и неясна интерпретация конечного результата
по этой схеме невозможно оценить качество сайта, как минимум потому, что не даны критерии оценки и неясна интерпретация конечного результата
По правилу 7±2 уже давно писали что это правило не совсем корректно для веб. Вот например статья: www.webmascon.com/topics/navigation/25a.asp
«Правило 7±2» означает скорее, что если оно не соблюдается, то у этого должны быть объяснения, а не что такого вообще быть не должно.
В статье которую я привел говорится о том что нет магического числа 7±2 и что правило Миллера нельзя применять для веб. Если вы берете 7±2 не из правила Миллера, то откуда?
Цитата: «Проблема с путаницей и информационной перегруженностью разумеется существует, и наверняка есть определенное число пунктов меню, которые можно показать посетителю на странице, при этом не вызывав у него паники. Но число это никоим образом не вытекает из правила Миллера.»
и
«Исследования показывают, что в общем случае „широкие“ структуры работают лучше, чем „глубокие“. Как оказалось, пользователи лучше работают и быстрее находят информацию в „неглубоких“ структурах.»
Цитата: «Проблема с путаницей и информационной перегруженностью разумеется существует, и наверняка есть определенное число пунктов меню, которые можно показать посетителю на странице, при этом не вызывав у него паники. Но число это никоим образом не вытекает из правила Миллера.»
и
«Исследования показывают, что в общем случае „широкие“ структуры работают лучше, чем „глубокие“. Как оказалось, пользователи лучше работают и быстрее находят информацию в „неглубоких“ структурах.»
Я бы сказал, что правило 7±2 для веб является просто аналогией правила Миллера, а не следует из него.
В плане широких структур, я бы сказал, что если число пунктов сильно больше 7, то это уже получается не меню, а просто список ссылок. Его уже нельзя назвать меню, пользователь работает с ним как с контентом, а не как с меню.
В плане широких структур, я бы сказал, что если число пунктов сильно больше 7, то это уже получается не меню, а просто список ссылок. Его уже нельзя назвать меню, пользователь работает с ним как с контентом, а не как с меню.
Было-бы шикарно, если-бы это была не просто картинка, а некая динамическая страничка, где можно было-бы тыкнуть на каждый пункт и получить подробную подсказку, с примерами, скриншотами, советами, как максимально эффективно сделать.
Взять туже адаптацию для инвалидов. Тыкаем на ссылку «Адаптация для инвалидов» и получаем полезный совет, как лучше адаптировать сайт под инвалидов. И так во всем.
Взять туже адаптацию для инвалидов. Тыкаем на ссылку «Адаптация для инвалидов» и получаем полезный совет, как лучше адаптировать сайт под инвалидов. И так во всем.
Вот спрятав у себя за спиной именно такие бумажки, маркетологи, менеджеры, юристы, бухгалтеры, кондитеры с известным именем, модельеры, предприниматели и прочие потенциальные заказчики начинают умничать =)
Не знаю, почему всем не нравится — мне очень и очень по душе, действительно быстро и полезно.
Отлично, спасибо. Еще одна неплохая иллюстрация «ничего не забыть». =)
Здравствуй, робот. Вместо того, чтобы взяться за ум (о чем тебе около года назад рассказали в ru_ucdesign), ты опять пытаешься составлять чек-листы и измерять гаечным ключем силу эмоций влюбленного в ежа дикобраза. Что ж, удачного брутфоса.
Почему «пытаюсь»? Я по этой схеме провел десятки анализов, все довольны.
Если в зараженные эболой районы Африки завезти лейкопластыри, они тоже будут в восторге, потому что у них и этого нет. Впрочем, тебе обо всем уже давным-давно рассказали.
НЛО прилетело и опубликовало эту надпись здесь
Почему жаль? Действительно интересно. Почти никто не соблюдает все эти пункты, и совсем не потому, что приняли такое сознательное решение.
Жаль потому, что им придется много поработать чтобы удовлетворить всем требованиям? Ну так зато клиенту будет польза.
жаль потому что если разработчик будет удовлетворять ВСЕМ требованиям, то клиенту будет польза в виде десятикратного увеличения стоимости услуги)
Это какие же именно требования из мной перечисленных вообще влияют на стоимость?
вы будете смеяться. но все)))
То есть если заказчик не попросит специально — студия готова сделать говносайт?
хм… чтобы ответить на ваш вопрос позвольте сначала поинтересоваться что в вашем понимании «качественный». а что «не качественный» сайт? и сразу вопрос — вы занимались когда-нибудь заказом или разработкой сайта?
Например сайт, в котором все страницы имеют одинаковый title типа «магазин купить кондиционер купить москва кондиционер» — типичный говносайт.
с нетерпением жду ответа на 1 и 3 часть моего вопроса)))
1) В котором все пункты из списка выше продуманы, и способ реализации-нереализации каждого эффективен для целей сайта.
2) Да.
2) Да.
спасибо. поясните пожалуйста что вы имеете ввиду: «способ реализации-нереализации каждого эффективен для целей сайта»
Например если инновационный технологически сервис не поддерживает ИЕ6, то это нормально, а если портал анекдотов — то не очень.
то есть вы согласны с тем. что далеко не всегда необходимо учитывать все параметры указанные в методичке?
Какие параметры? Это не параметры, это список групп параметров. А о значениях ничего не говорится вообще.
будьте добры, не примете за грубость но ответьте на вопрос, пожалуйста. и если не секрет в роли кого вы занимались разработкой?
Да наверное во всех ролях выступал, какие только есть :) От заказчика до LAMP-программиста :)
Вы упорно игнорируете мой вопрос)) воля Ваша.
Если Вы были в роли программиста то должны понимать, что каждый пункт несете за собой дополнительные затраты времени, а как следствие — дополнительные затраты средств. И далеко не все параметры (если угодно — группы параметров))) являются необходимыми и обязательными для каждого проекта. Впрочем, об этом я уже писал комментом ниже. Дальнейшая дискуссия — переливание из пустого в порожнее)))
Если Вы были в роли программиста то должны понимать, что каждый пункт несете за собой дополнительные затраты времени, а как следствие — дополнительные затраты средств. И далеко не все параметры (если угодно — группы параметров))) являются необходимыми и обязательными для каждого проекта. Впрочем, об этом я уже писал комментом ниже. Дальнейшая дискуссия — переливание из пустого в порожнее)))
Все перечисленные пункты реализуются элементарно. 404-ю страницу создать — это что, работа? Да 5 минут на саму простую. Валидность обеспечить? Ну если что-то конкретное не выйдет то к черту, но такие вещи как незакрытые теги — это брак производства и его в любом случае нужно исправлять. И так далее.
забавно. на картинке у вас написано одно, а вы говорите совершенно другое))) в методичке у вас — «поддержка инвалидов», «вывод на печать». «подписка» итд а пишите о незакрытых тегах… вы батенька, сами запутались))) я рекомендую Вам еще раз как следует изучить методичку, которую Вы выложили, а потом уже спорить со всеми (судя по комментам))).
и опять же. если Вы действительно занимались разработкой, то прекрасно понимаете, что в этом процессе есть куча мелочей, все из которых иногда нет времени предусмотреть. иногда — необходимости. предвижу Ваше возражение и сразу отвечу — «незакрытые теги это не мелочь, а досадная ошибка которую необходимо избегать». а вот вывод на печать это мелочь, в большинстве своем ненужная))
надеюсь, я Вас не обидел. но на будущее внимательно изучайте материал, под которым подписываетесь, а то смешно получается, очень смешно)))
и опять же. если Вы действительно занимались разработкой, то прекрасно понимаете, что в этом процессе есть куча мелочей, все из которых иногда нет времени предусмотреть. иногда — необходимости. предвижу Ваше возражение и сразу отвечу — «незакрытые теги это не мелочь, а досадная ошибка которую необходимо избегать». а вот вывод на печать это мелочь, в большинстве своем ненужная))
надеюсь, я Вас не обидел. но на будущее внимательно изучайте материал, под которым подписываетесь, а то смешно получается, очень смешно)))
Идея сама по себе очень хорошая. Но я бы не стал рассматривать эту схему как жесткую доктрину. Скорее это эталон, на который необходимо равняться разработчикам. Говорить что «все пункты обязательны к выполнению» это неразумно, потому что есть ряд ограничивающих факторов. Например целесообразность (например вывод на печать игрового сайта нецелесообразно), ограниченность в бюджете как уже говорилось, ограниченность во времени (если соблюдать абсолютно ВСЕ пункты, то процесс разработки проекта может изрядно затянуться и соответственно увеличиться его бюджет).
Заказчикам эта схема вряд ли поможет. Хорошо если они понимают само значение слово «валидность» (что кстати им абсолютно не нужно). Проблема может крыться даже в таком пункте как дизайн. В подавляющем большинстве случаев, качество дизайна определяется как понравилось\не понравилось, критерии типа «современность», «соответствие стилю» уходят на десятый план. Для заказчиков я бы посоветовал выпустить гораздо более упрощенную версию, но в которой они бы могли разобраться не имея ни малейшего представления о веб-технологиях или хотя бы полиграфии.
Заказчикам эта схема вряд ли поможет. Хорошо если они понимают само значение слово «валидность» (что кстати им абсолютно не нужно). Проблема может крыться даже в таком пункте как дизайн. В подавляющем большинстве случаев, качество дизайна определяется как понравилось\не понравилось, критерии типа «современность», «соответствие стилю» уходят на десятый план. Для заказчиков я бы посоветовал выпустить гораздо более упрощенную версию, но в которой они бы могли разобраться не имея ни малейшего представления о веб-технологиях или хотя бы полиграфии.
Не думаю, что это для клиента пригодится больше, чем для предварительного планирования разработки и её последующего анализа самим разработчиком на отведённом ему этапе.
Если только клиент детально подкован.
Вот мне лично как памятка пригодится, я рассеян, что-то могу забыть в процессе работы.
Если только клиент детально подкован.
Вот мне лично как памятка пригодится, я рассеян, что-то могу забыть в процессе работы.
Мы в студии используем Mind Manager для предпроектного проектирования. При определенных условиях (в основном это — сложность логических связей и количество программных модулей) программа очень полезна.
Хотя в дальнейшем порекомендовал бы использовать Axure или Visio.
Хотя в дальнейшем порекомендовал бы использовать Axure или Visio.
нет скорости загрузки — одного из основных показателей качества сайта
Как же нет, скорость доступа.
может быть, вы полагаете, что скорость доступа, время ответа сервера, скорость загрузки и скорость повторной загрузки страницы — это одно и то же?
Имхо, параметры приведены с точки зрения специалиста, а не владельца сайта, и не важности влияния параметров на его бизнес-процесс.
Имхо, параметры приведены с точки зрения специалиста, а не владельца сайта, и не важности влияния параметров на его бизнес-процесс.
// может быть, вы полагаете, что скорость доступа, время ответа сервера, скорость загрузки и скорость повторной загрузки страницы — это одно и то же? //
Я полагаю логичным совместить это в одном пункте. Вы против?
Я полагаю логичным совместить это в одном пункте. Вы против?
лично я — да. Точно также весь SEO можно в одном пункте совместить :)
Просто доступность (accessibility) имеет намного меньшее значение, чем та же скорость загрузки. А по соответствию сайта стандартам обычно оочень много можно сказать об остальном качестве (стандартные сайты склонны быть более качественными своих нестандарьных коллег).
Просто доступность (accessibility) имеет намного меньшее значение, чем та же скорость загрузки. А по соответствию сайта стандартам обычно оочень много можно сказать об остальном качестве (стандартные сайты склонны быть более качественными своих нестандарьных коллег).
У меня вообще-то таки весь SEO в одном пункте :)
а юзабилити — в 10? :)
Я почему так придираюсь: просто последние полгода тусовался в среде заказчиков, которым была бы весьма интересна адекватная оценка качества сайта. Особенно автоматизированная. Тут несколько докладов на тему
webo.in/articles/site2009/website-quality/
webo.in/articles/oborot2009/faster-means-better/
webo.in/articles/riw2009/quality-becomes-quantity/
Конечно, там все однобоко, но нужны четкие критерии, которые можно понятно оценить. Например, солидность / современность оценить тяжело. Но их косвенная оценка будет следовать из других, чисто технических вещей.
Если интересно, то готов пообщаться. Но не в комментариях. Контакты здесь есть
www.web-optimizer.us/ru/about/
Я почему так придираюсь: просто последние полгода тусовался в среде заказчиков, которым была бы весьма интересна адекватная оценка качества сайта. Особенно автоматизированная. Тут несколько докладов на тему
webo.in/articles/site2009/website-quality/
webo.in/articles/oborot2009/faster-means-better/
webo.in/articles/riw2009/quality-becomes-quantity/
Конечно, там все однобоко, но нужны четкие критерии, которые можно понятно оценить. Например, солидность / современность оценить тяжело. Но их косвенная оценка будет следовать из других, чисто технических вещей.
Если интересно, то готов пообщаться. Но не в комментариях. Контакты здесь есть
www.web-optimizer.us/ru/about/
Ну-ка, а солиден ли мой сайт? (прищурив глаз) дааа, пожалуй, солиден. А взвешен? Хм, и взвешен неплохо. А достаточно ли пространства? (открыл на мониторе 1920х1600) Да, пространства просто навалом! Что там ещё? Ссылки есть, ввод поддерживает, пользователя к себе развернул… Ну, мечта, а не сайт! Супер!
www.babushka-on-line.ru/ — у вас на главной странице title «Главная страница».
А можно x-mind схему в паблик?
Что за правило такое «7+2 пункта»?
Вы могли бы прокомментировать пункт Интеграция -> SEO\SMO, каков критерий оценки в данном случае?
Это два разных пункта.
На таком элементарном уровне SEO — это наличие плана по продвижению по ключевым словам, наличие этих слов в тексте, внутренних ссылках и заголовках, корректная html-стурктура документов, внутренняя перелинковка, добавление сайта в различные системы типа Google Webmaster позволяющие выявить ошибки индексации, файл robots.txt,…
А SMO тут наличие трансляций в популярные блогсервисы, возможность подписки на контент с помощью RSS и. т. п. возможность удобно распространить контент в блоги, удобная возможность комментирования, трекбеки, отслеживания отзывов на сайт,…
На таком элементарном уровне SEO — это наличие плана по продвижению по ключевым словам, наличие этих слов в тексте, внутренних ссылках и заголовках, корректная html-стурктура документов, внутренняя перелинковка, добавление сайта в различные системы типа Google Webmaster позволяющие выявить ошибки индексации, файл robots.txt,…
А SMO тут наличие трансляций в популярные блогсервисы, возможность подписки на контент с помощью RSS и. т. п. возможность удобно распространить контент в блоги, удобная возможность комментирования, трекбеки, отслеживания отзывов на сайт,…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Экспресс-анализ качества сайта