, и возникла мысль. При использовании Ajax запросы не сохраняются в history. Таким образом, у нас нет идентифицируемости страниц. Мы не можем нажать назад, не можем обновить по нормальному, не можем сохранить ссылку или переслать ее по мылу.
Вопрос: кто нибудь может сформулировать принцип когда Ajax возможен, а когда он вреден.
, и возникла мысль. При использовании Ajax запросы не сохраняются в history. Таким образом, у нас нет идентифицируемости страниц. Мы не можем нажать назад, не можем обновить по нормальному, не можем сохранить ссылку или переслать ее по мылу. GZ>Вопрос: кто нибудь может сформулировать принцип когда Ajax возможен, а когда он вреден.
Навигация в подобных приложениях не только необходима, но и возможна.
Вопрос границы ее необходимости, наверное, решается с помощью определения понятия "действия пользователя", но, отнюдь, не реакции интерфейса.
Здравствуйте, caston, Вы писали:
C>Навигация в подобных приложениях не только необходима, но и возможна. C>Вопрос границы ее необходимости, наверное, решается с помощью определения понятия "действия пользователя", но, отнюдь, не реакции интерфейса.
C>стоит продолжать?
Да. Но все же, в некотором контексте это все таки вопрос usability.
, и возникла мысль. При использовании Ajax запросы не сохраняются в history. Таким образом, у нас нет идентифицируемости страниц. Мы не можем нажать назад, не можем обновить по нормальному, не можем сохранить ссылку или переслать ее по мылу. GZ>Вопрос: кто нибудь может сформулировать принцип когда Ajax возможен, а когда он вреден.
Я могу. Но не уверен, что получится достаточно коротко и ясно:
Аякс 100% подходит тогда, когда происходит изменение UI.
Аякс 100% не подходит тогда, когда происходит навигация.
Примеры 100% привести легко:
— схлопывающиеся/раскрывающиеся панельки и деревья — аякс.
— переход от "списка товаров" к "деталям товара" — честная навигация
Проблемы начинаются в двух случаях:
1. Навигация осуществляется через модификацию UI. Пример: раскрывание деталей товара прямо в списке товаров.
2. Присутствует плавная, а не скачкообразная навигация. Примеры: скроллинг длинннннннного документа; Google Maps
Первый случай рекомендую в топку. Как несоответствующий идее гипермедиа.
Второй случай сложнее. Google Maps предлагает отдельную ссылочку Get Link, которую можно ткнуть (и остаться на той же странице), а можно добавить в фаориты, отправить другу и т.п.
Я вынашиваю смутную идею автоматической навигации в таких случаях. Типа поскроллил-поскроллил, пару секунд потупил — оп, оно перескочило. Должно быть удобно в том смысле, что сайт сам запоминает более-менее привлекшие внимание места в хистори. Тем не менее, я пока ее не обкатывал и не уверен. Ведь гугл этого не сделал... А может быть, и они не 100% гении
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я могу. Но не уверен, что получится достаточно коротко и ясно:
+100
Есть еще один случай. Когда формы являются сценарием одного прецедента и безсмысленны друг без друга. Например, выбор из справочник(не показ а именно выбор). Или при создании объекта — важна только первая страница. Тады возможна полная выгрузка форм с переключением на клиенте, или Ajax.
S>Я вынашиваю смутную идею автоматической навигации в таких случаях. Типа поскроллил-поскроллил, пару секунд потупил — оп, оно перескочило. Должно быть удобно в том смысле, что сайт сам запоминает более-менее привлекшие внимание места в хистори. Тем не менее, я пока ее не обкатывал и не уверен. Ведь гугл этого не сделал... А может быть, и они не 100% гении
Должно быть достаточно специфичное решение. Иначе по history мы будем вспоминать только когда мы завтракали, обедали и ужинали.
, и возникла мысль. При использовании Ajax запросы не сохраняются в history. Таким образом, у нас нет идентифицируемости страниц. Мы не можем нажать назад, не можем обновить по нормальному, не можем сохранить ссылку или переслать ее по мылу.
Есть способы решения и этой проблемы. Дело в том, что ссылка может иметь вид: http://site/link#hash
Hash в любом случае сохраняется в адресной строке, ее можно копировать и передавать другому. Правда, для этого надо очень грамотно организовывать работу
Пример:
<script>
// Для облегчения работы используется jQuery, http://jquery.comfunction checkURL()
{
if(!location.hash) return;
doAction(location.hash);
}
$(document).ready(
function()
{
checkURL();
$("a").click(
function()
{
return false;
}
);
}
);
</script>
<a href="#nav1" onclick>Nav link 1</a>
<a href="#nav2">Nav link 1</a>
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
S>>Я могу. Но не уверен, что получится достаточно коротко и ясно: GZ>+100 GZ>Есть еще один случай. Когда формы являются сценарием одного прецедента и безсмысленны друг без друга. Например, выбор из справочник(не показ а именно выбор).
Совершенно верно. Визард является частным случаем. Хотя я также не уверен и в том, что визард суть 100% правильный руль. Для выполнения пощаговой задачи может оказаться более эффективной какая-нибудь другая система построения навигации. В частности, IUI критикует классические визарды за неочевидность для пользователя его текущего положения в наборе шагов
S>>Я вынашиваю смутную идею автоматической навигации в таких случаях. Типа поскроллил-поскроллил, пару секунд потупил — оп, оно перескочило. Должно быть удобно в том смысле, что сайт сам запоминает более-менее привлекшие внимание места в хистори. Тем не менее, я пока ее не обкатывал и не уверен. Ведь гугл этого не сделал... А может быть, и они не 100% гении GZ>Должно быть достаточно специфичное решение. Иначе по history мы будем вспоминать только когда мы завтракали, обедали и ужинали.
Поэтому идея и сырая. Другой ее вариант — делать location.replace, чтобы в адрес баре почти всегда была ссылка в корректное место. Т.е. хистори автоматически не загаживаем, зато у нас есть соответствие адреса содержимому.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали: M>Есть способы решения и этой проблемы. Дело в том, что ссылка может иметь вид: http://site/link#hash
M>Hash в любом случае сохраняется в адресной строке, ее можно копировать и передавать другому. Правда, для этого надо очень грамотно организовывать работу
Здравствуйте, Sinclair, Вы писали:
S>Я вынашиваю смутную идею автоматической навигации в таких случаях. Типа поскроллил-поскроллил, пару секунд потупил — оп, оно перескочило. Должно быть удобно в том смысле, что сайт сам запоминает более-менее привлекшие внимание места в хистори. Тем не менее, я пока ее не обкатывал и не уверен. Ведь гугл этого не сделал... А может быть, и они не 100% гении
Здравствуйте, Miroff, Вы писали:
M>Посмотри wikimapia.org, ребята сделали.
О! Кстати, они пользуют location.reload. Ну, значит и нам будет кошерно. Прекрасно, запланируем на версию 5.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Да, я тоже об этом думал. Google зачем-то использует Query, а не Hash, хотя загрузка выполняется отложенным скриптом. Т.е. они вполне могли зарулить адреса типа http://maps.google.com/?ie=UTF8&z=18&ll=54.853449,83.047366&spn=0.002282,0.004989&t=h&om=1 через hash. S>Прикол hash в том, что переход на него стоит $0.00: клиент просто попытается отнавигироваться в якорь с соответствующим ID. Без обращения к серверу.
Хеш не передаётся по сети, и доступен только в браузере. Соответственно навигация через хеш не работает c отключённым джаваскриптом.
А текущий гуглмапс вполне сносно работает и без js.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Kirillov Sergey, Вы писали: KS>>А текущий гуглмапс вполне сносно работает и без js. S>sure? Пробовал отключать?
По-моему еще важную AJAX-проблему упустили из обсуждения, впрочем она скорее вытекает из тех же проблем навигации.
Это — индексация AJAX-ресурсов поисковиками. Кроме как решения на основе "спам-страниц" ничего больше особо мне и не встречалось
Лично для себя я определил такой "отправной" алгоритм выбора:
AJAX-для интранет (внутренних) ресурсов
без AJAX — для внешних информационных. + во внешних, AJAX оправдан в плане ускорения работы контролов которые не являются средствами отражения информационного контента.
Естественно, это не какое то жесткое правило и компроммисы, в принципе, вполне возможны.
p/s/
news по теме :
Yahoo не стал сайтом-лидером США по количеству запросов интернет-страниц в ноябре. Причина этого – внедрение технологии AJAX, позволяющей обновлять веб-страницы без перезагрузки.
Забавно. Видимо в Yahoo начали искать крайних за маркетинговые провалы, и нашли их среди разработчиков. Хотя выглядит это не очень убедительно. Я, специально походил по Yahoo и нашел AJAX-овые компоненты только на главной странице. Вряд ли они могли кардинально повлиять на статистику сайта, которая насчитывает десятки миллиардов посещений.
С другой стороны проблема все-же существует. При использовании AJAX запросы на сервер все равно идут, но посколько они направлены не к обычным web страницам а к web сервисам, разместить на них обычные счетчики невозможно. И этот трафик действительно оказывается не охвачен статистикой.
Я думаю системы оценки и ранжирования сайтов ждут большие премены. Ведь место в рейтинге это большие деньги и их никто не хочет терять.
Здравствуйте, снежок, Вы писали:
С>По-моему еще важную AJAX-проблему упустили из обсуждения, впрочем она скорее вытекает из тех же проблем навигации. С>Это — индексация AJAX-ресурсов поисковиками. Кроме как решения на основе "спам-страниц" ничего больше особо мне и не встречалось
Если на сайте контент затаскивается в страницы через AJAX, то в целях доступности сайта для клиентов, у которых Javascript отключен, должен быть предусмотрен некий fallback (например, через традиционные параметры query string’а). Вот через него и будет индексироваться.
C>Если на сайте контент затаскивается в страницы через AJAX, то в целях доступности сайта для клиентов, у которых Javascript отключен, должен быть предусмотрен некий fallback (например, через традиционные параметры query string’а). Вот через него и будет индексироваться.
Много ли таких сейчас клиентов, которые отключают JS?
И много ли будет заходов по таким url?
И соответственно как при отсутствии заходов это будет ранжироваться поисковиками?
Здравствуйте, снежок, Вы писали:
C>>Если на сайте контент затаскивается в страницы через AJAX, то в целях доступности сайта для клиентов, у которых Javascript отключен, должен быть предусмотрен некий fallback (например, через традиционные параметры query string’а). Вот через него и будет индексироваться. С>Много ли таких сейчас клиентов, которые отключают JS?
GoogleBot.
Впрочем, тут вариантов особых нет. Если fallback’а нет, то встаёт та самая проблема неадресуемого контента, и, как следствие, неиндексируемость. Потому что, даже если поисковик найдёт на сайте контент, он не сможет дать на него ссылку.
Поэтому для каждого блока контента, который хочется находить через поиск, нужно генерировать тупую GET-ссылку. А раз она есть, то не так сложно сделать и fallback для не-JS-пользователей.
C>Поэтому для каждого блока контента, который хочется находить через поиск, нужно генерировать тупую GET-ссылку. А раз она есть, то не так сложно сделать и fallback для не-JS-пользователей.
Причем такое легко реализуется в большинстве современных веб-фреймворков на основе MVC (те же Ruby-on-Rails, Django, CFWheels, CakePHP и прочие)
1.2.0 alpha rev. 655
