livedev.org

Последний год я стал замечать что слово «юзабилити» стало проскакивать все чаще во всякого рода компьютерных публикациях рунета. Сейчас особо часто это слово замечается рядом с более нашумевшим «Веб 2.0». Все чаще слышатся оптимистичные заявления о переходе на приложения с веб-интерфейсом и в большинстве случаев имеются ввиду приложения Гугл.

И, как разработчик, я хотел бы представить читателю (который скорее всего является подобным мне разработчиком) свой взгляд на проблемы и решения создания веб-приложений и их интерфейсов.

Веб живет своей жизнью и жизнь эту можно отметить достаточно бурной эволюцией и развитием. Особенно последнии годы в период раздувания «Веб 2.0 пузыря». И самое интересное в этом развитии, то, что «атовизмы» отсыхают и отпадают не так быстро, как хотелось бы. А новые способности и возможности адаптируются и применяются наоборот достаточно медленно. Именно с этого я хочу начать свое рассуждение, т.к. считаю вопрос совместимости основным для успешного развития веб-интерфейсов. Я не буду приводить множество примеров о глючном IE или отличным рендерингом css-свойств в разных браузерах. Или взять тот-же флеш от Адоби, который, несмотря на долгую историю развития и мажорную версию 9, все еще преподносит немало сюрпризов.

Цель этой заметки — небольшая аналитка, собранная из личного опыта. Как построить удобный пользовтельский интерфейс для веба. Итак, мои советы.

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

2. Не пугайтесь невалидного кода. Да, если можно делайте код красивым, но помните что код читают роботы, а сайтом пользуются люди. Поэтому чаще полезнее провести время в проектировании, тестировнии интерфейса или еще что вы посчитаете более важным.

3. Меньше используйте мешанины flash-html. Если вы хотите использовать флеш, сделайте на нем отдельную часть сайта, чтобы пользователь варился в ней как в отдельном приложении. Все дело в том, что флеш не учитывает особенностей исполнения интерфейса платформы на которой работает конечный пользователь. Поэтому контролы будут сильно отличаться внешне и по принципу работы, что будет раздражать пользователя. Пользователю легче привыкнуть к одному месту на сайте где все по другому, чем постоянно переключать внимание.

4. При использовании Ajax старайтесь всегда делать версию сайта, работающую в стиле old-school. Формы, поля, ссылки. В случае глюков или тормозов JS опытные пользователи всегда смогут перейти к обыкновенному режиму работы.

5. Используйте готовые JS/Ajax библиотеки. В них учтены уже кросс-браузерность и неровности работы JS. Писать «с нуля» свое слишком дорого и не оправдано.

6. Делайте сайты похожими на другие. Не надо клонировать дизайн или идеи. Я имею ввиду функциональные решения. Если есть тенденции их надо учитывать. Пользователю будет проще разобраться со всеми активными элементами сайта, если он их уже несколько раз встречал.

7. Пробуйте самые последнии и современные технологии веб, в которых уже учтены многие недостатки прошлых лет. На данный момент я имею ввиду декстопно ориентированные фреймвоки MS Silverlight и Adobe Air. Не обязательно вы их будете использовать в своих решениях, но быть «на коне» очень важно.

Хочется высказать свою активную позицию насчет форматов передачи сообщений между приложениями в веб-среде. Или можете считать это просто настойчивым советом, особенно относящемуся к начинающим веб-разработчикам. Итак, что использовать? XML или JSON?

Общение (обмен сообщениями, если хотите) современных веб-приложений очень актуальная тема. В связи с появлением веб-сервисов в прошлом и огромным ростом популярности сложных (rich) интерфейсов в настоящем, появляется потребность в удобном и легком способе передачи данных между приложениями. Чаще всего подразумевается общение клиента и сервера. Частные случаи: всем полюбившийся Ajax, Flash/Flex приложения с динамическим контентом, API для публичных сервисов.

Так вот исторически сложилось что для этих задач использовался изначально XML, как универсальный способ описания любых данных. Но позже появился новый (популярный сегодня) формат – JSON. Про сам формат вы можете почитать в инете, благо информации достаточно. А вот свои субъективные плюсы и минусы я напишу ниже.

Плюсы JSON по сравнению с XML:

• быстрее парситься;
• легче визуально воспринимается;
• нативно интегрирован в JavaScript (читай Ajax);

К этому списку могу добавить отрывки личного опыта. С парсингом и валидацией XML есть достаточно много проблем, зависящих от библиотеки с которой вы работаете. Сериализация данных в JSON обычно в коде занимает меньше места, чем кодирование сериализации в XML. Интересным практичным моментом есть именно разработка Ajax интерфейсов, где JSON сокращает JS код. Большим плюсом к этому является возможность использования того-же протокола не только Ajax-ом, но и например Flash/Flex приложением или сторонним сервисом как API.

Вывод. Я считаю, что XML на самом деле не так уж плох и для общения между приложениями, но он лучше подходит для хранения сложно структурированных данных. А вот большим плюсом JSONа как раз является сокращение времени на разработку базового веб-приложения и его дальнейшей быстрой интеграции с другими разнородными приложениями. Еще проще говоря, если вы собираетесь заняться изучением или сразу использованием Ajax в своих проектах, обратите внимание на JSON и сэкономьте свое время.

PS о недостатках. Посмотрите статью Tim Bray и Don Box по теме.

При написании приложения по принципам MVC с использованием Ajax, часто для одного и того же запроса нужно получить данные в двух отличных друг от друга вариантах—в чистом HTML и в XML/json для Ajax запроса. А т.к. один и тот же контроллер в MVC обрабатывает оба типа запроса и скорее всего было бы удобно для его обработки использовать один и тот же URL, надо как-то отличать их, чтоб знать в каком формате отдать данные. Если это POST-запрос то можно просто создать дополнительное поле/переменную в запросе, а если GET, то нужно или отдельный URL для каждого типа данных или дополнительный заголовок в запросе (см. ниже почему).

Проблема мне кажется больше именно в GET запросе. Если следовать правилам ReST, то контент полученный по URL должен быть кеширован, а в нашем случае будет кеширован первый формат, в котором контроллер отдаст контент. Было бы удобно чтоб контроллер делал проверку на наличие каких-то заголовков и отдавал в зависимости от них ответ в нужном виде, но вот кеширование этому помешает. Т.к. кеш скеширует контент на первый попавшийся запрос (Ajax/HTML) и для следующего отличного запроса может быть отдан контент в неверном формате. Конечно можно с помощью заголовков вообще отключить кеширование, но это неоправдано, т.к. в протоколе HTTP не зря предусмтрена такая функциональность.

В общем решением была бы возможность реагирования кеша на определенные заголовки от сервера. И да, это указано в стандарте HTTP и реализовано как клиентами так и серверами. Есть такой заголовок в стандарте HTTP—Vary:, обычно его называют Vary Header. Он необходим как раз для осуществления правильного кеширование в зависимости от его значения. По большому счету он нужен чтоб указать кешу для какого заголовка запроса скеширован данный URL. Т.е. контент в кеше теперь будет идентифицироваться не только по URL, но по URL + заголовок указанный директивой Vary. Например, если пользователь залогинен на сайт с использованием Cookie, тогда заголовок Vary должен выглядеть так Vary: Cookie. URL в это случае, например, будет /profile/ (профиль пользователя) и два разных пользователя, попав на страницу из одного кеша будут проверены с помощью директивы Vary на предмет Cookie и получат разный контент. Или например кеширование должно производиться с учетом языка пользователя, тогда директива будет выглядить так Vary: Content-Language.

Зачем это нужно в нашем случае? Все просто—практически все Javascript Toolkits используют заголовок HTTP_X_REQUESTED_WITH со значением ‘XMLHttpRequest’. Так что если мы поставим Vary: HTTP_X_REQUESTED_WITH, то оба запроса к одному URL но от разных инициаторов (сам браузер или javascript/ajax код) будут скешированы отдельно.

Вот такой интересный нюанс. Может кому-то пригодится в деле.