Я создаю веб-приложение с Zend Framework. Я хотел включить некоторые формы типа AJAX и модальные поля, но я также хочу, чтобы мое приложение было как можно более доступным. Я хочу, чтобы мое приложение было усилено AJAX, но также полностью функционально без AJAX.
Итак, как общее руководство... когда я не должен использовать AJAX? Я имею в виду, должен ли я беспокоиться о том, чтобы приложение можно было использовать без AJAX? Или у всех есть браузеры с поддержкой AJAX в наши дни?
Если вы имеете в виду "доступный" в смысле ADA, AJAX обычно не-нет - ваш сайт должен предоставлять весь свой контент и основные функции, используя только стандартные (X) HTML и CSS. Любой используемый javascript должен просто расширить функциональность ядра, и ваш сайт должен быть закодирован для элегантной работы при отсутствии браузера с поддержкой javascript.
Примеры: если вы хотите, чтобы пользователь нажимал на миниатюру и в результате получал полноразмерную версию изображения, вы можете сделать миниатюру ссылкой. Затем событие onclick запускает метод JQuery, который отменяет навигационное поведение ссылки и всплывает плавающий div JQuery для отображения изображения на текущей странице. Если браузер пользователя не поддерживает JavaScript, событие onclick никогда не будет запускаться, и пользователю будет предоставлено изображение на новой странице. Основные функциональные возможности совпадают с сценариями или без них.
EDIT: Пример скелета, без JQuery-специфического кода.
<html>
<body>
<a href="some.url" onclick="JQueryToOpenPopupImage(); return false;">Some URL</a>
</body>
</html>
Чтобы отменить операцию навигации, просто убедитесь, что метод, вызываемый событием onclick, возвращает значение false в конце.
Яркий пример всплывающего окна JQuery, который я описал, можно найти здесь .
Используйте ajax, если он добавляет значение для пользователя.
Если версия ajax добавляет намного больше значения, чем версия без аякса, тогда это может оправдать затраты на разработку решения, которое обслуживает обоих клиентов. В общем, я бы не рекомендовал делать дополнительную работу (помните, что больше кода приводит к большему количеству обслуживания).
Я думаю, что здесь не хватает одного пункта: используйте Ajax только для контента, который любая поисковая система не должна знать.
98% пользователей будут иметь браузеры с поддержкой AJAX.
Значительный процент этих людей не будет включен, когда они впервые посещают ваш сайт (или вообще, когда-либо возможно).
Я видел веб-сайты, которые выглядят как пустая страница без javascript. Не будь одним из них. Javascript для исправления проблем с макетами - это ужасная идея, на мой взгляд. Удостоверьтесь, что он загружается и выглядит нормально без Javascript. Если люди могут по крайней мере видеть то, что им не хватает, они, вероятно, включат его, но если ваш сайт выглядит как просто сломанный, то...
У меня часто есть блок noscript Flash и JavaScript, пока я не приму решение, что ваш сайт достоин.
Поэтому не забудьте сообщить мне, что мне не хватает, если у меня отключен JavaScript.
Это зависит от сложности вашего веб-приложения.
Если вы можете, если он работает с отключенным javascript, это здорово, потому что это делает ваше приложение пригодным для использования не только пользователями в js-отключенных браузерах, но и роботами. В тот день, когда вы решите написать приложение для автоматического заполнения форм, например, вам не нужно писать API с нуля.
В любом случае, не пользователь AJAX для ВСЕГО! Я только что унаследовал проект, который в основном состоит из одной страницы, заполненной тонны вызовов AJAX, и я могу сказать, что вы просто думаете об этом, это дает мне физическую боль. Я думаю, что оригинальному разработчику не понравилась концепция использования кнопки "назад/вперед" в браузере как средство навигации.
Если вы не настроите таргетинг на мобильные устройства или других нестандартных веб-пользователей, вы можете быть уверены, что подавляющее большинство имеет Javascript, потому что большинство основных сайтов (включая SO) в значительной степени зависят от него.
Мой опыт: мы должны использовать ajax после его работы без него. По нескольким причинам. Во-первых, если что-то ломается в ajax, и у вас нет работы без него, сайт просто не работает. Например, список продуктов с разбиением на страницы. Он должен работать только с ссылками, а затем использовать ajax, когда это возможно. Во-вторых, для индексации и доступности сайта. Если он работает без ajax, это лучше.
И проще сломать что-то (пусть даже на несколько мгновений). Плохая часть кода, неперехваченное исключение, внешняя библиотека, не загруженная, блокирующее расширение браузера,...
После того, как все работает без ajax, его довольно просто добавить ajax. Просто запустите ajax действие, добавьте ajax = 1 и при возврате результата верните только то, что вам нужно, если ajax = 1, иначе верните все. В примере списка продуктов я бы только вернул продукты и pagination html и добавлю в правильный div. Если ajax перестает работать, вся страница загружается, и клиент видит вторую страницу при ее загрузке.
Ajax добавляет большую ценность для UX. Если все сделано правильно, пользователь получает отличное ощущение при использовании сайта и лучшее использование данных, потому что он не загружает всю страницу каждый раз.
Но вопрос "когда не использовать ajax", я бы сказал, всегда должен рассчитывать на это, чтобы улучшить UX, но не полагаться на него, чтобы сайт работал (как упомянули другие пользователи). И в наши дни нам нужны оба, отличный код и отличный пользовательский интерфейс.
Я хочу, чтобы мое приложение было как можно более доступным.
Вы можете делать такие вещи, как рендеринг ваших модалов и форм как страницы, которая может работать автономно.
Я хочу, чтобы мое приложение было расширено AJAX, но также полностью функциональный без AJAX.
Размышление о структуре ваших URL-адресов и шаблонов может пройти долгий путь к этому, если вы сделаете большую часть своих запросов AJAX в полностью обработанных шаблонах (в отличие от просто данных), вы можете обычно использовать один и тот же URL-адрес для обслуживания обе версии. Вы просто обслуживаете только кишки модального/форма запроса AJAX и всю страницу к регулярному запросу.
Когда я не должен использовать AJAX?
Я имею в виду, должен ли я беспокоиться о том, чтобы приложение можно было использовать без AJAX? Или у всех есть браузеры с поддержкой AJAX в наши дни?
Я бы сказал, что много времени это не нужно, поскольку подавляющее большинство пользователей будут иметь браузеры с поддержкой AJAX, но есть сценарии, где это критично, например оптимизация SEO или когда большая часть вашей пользовательской базы может использовать браузеров, которые с меньшей вероятностью поддерживают Javascript, а также, где они, вероятно, отключены Javascript/AJAX.
Несколько примеров этих сценариев:
Итак, что мне делать?
Моя практика заключается в использовании двух основных страниц, скажем, index.py и ajax.py. Первый отвечает за создание полного веб-сайта и по умолчанию предназначен для форм. Другой генерирует только выходные данные для адекватного запроса ajax. Логика позади обоих из них одна и та же, только способ генерации вывода немного отличается. В jquery я просто изменяю параметр действия при отправке запроса. Он работает как с ajax, так и без него, хотя долгое время я не видел кого-то с отключенными js и ajax.
Мне нравится мысль о кодировании вашего приложения без JavaScript/Ajax, а затем добавление его позже для улучшения пользовательского интерфейса, не лишая пользователей функциональности только потому, что у них нет JavaScript. Я читал об этом в Pro ASP.NET MVC, но я думаю, что видел его в другом месте в чтении о ненавязчивом JavaScript.
Вы не должны раздувать ваш сервис с эффектами web 2.0, такими как аккордеон, модальные/etc-формы, масштабирование изображений и т.д.
Используйте современные технологии умнее (AJAX - один из них), и ваши пользователи будут довольны. Не бойтесь AJAX - это очень хорошая вещь, чтобы сделать жизнь пользователя гладкой. Но не делайте ничего, потому что вам это нравится - делайте их, потому что вам это нужно пользователю;)
Если вы хотите создать веб-сайт, похожий на веб-сайт, а не искусственное подражание настольному приложению?
Вы не должны использовать AJAX или JavaScript в случаях, когда:
Однако, используя современную структуру JS с некоторыми простыми "ненавязчивыми" практиками, вы можете постепенно улучшать страницы, чтобы они оставались доступными и удобными для поиска, предлагая пользователям пользовательский интерфейс.
Это полностью зависит от типа приложения или функции, которую вы разрабатываете. Если крайне важно, чтобы приложение было доступно, несмотря на отсутствие Javascript, то это помогло бы использовать методы резервного копирования (то есть альтернативные формы), чтобы позволить вашему пользователю использовать указанную функциональность/функцию. Для этого вам потребуется инвестировать некоторые из ваших методов разработки времени для сбора информации, а не только на клиентских сценариях, но также и на стороне сервера.
Для разных функций, которые служат только для улучшения пользовательского интерфейса, в основном не стоит разрабатывать резервные методы.
Нет причин полностью не использовать AJAX. AJAX помогает минимизировать ваш трафик в конце концов.
Вы можете, если хотите, всегда использовать AJAX и обновлять состояние истории с помощью Push State или для большей совместимости использовать хеш без каких-либо HTML5-совместимых браузеров.
с этим вы можете загрузить свой сервер на страницу, затем javascript прочитает document.hash и возобновит состояние базы приложений в состоянии хеша.
например, я попал в /index.html, чтобы щелкнуть что-нибудь, например, клиенту, чтобы открыть клиент просмотра, вы можете изменить хеш на #/view/client/{client_id}/, а затем перезагрузить или вернуться с помощью браузера хеш с изменением, и вы может использовать событие onhashchanged для его захвата и сопоставления состояниям состояний с новым хешем, тогда же, если любимым является определенное состояние
Несколько других сценариев, где может быть лучше НЕ использовать AJAX:
Позвольте кому-то войти в веб-приложение. Вместо этого используйте традиционную форму submit.
Поиск и возврат более чем нескольких строк из базы данных. Либо разбить процесс, либо позволить серверному языку его обрабатывать.