Riak — веб-ориентированная система хранения данных. Процесс разработки веб-ориентированной информационной системы

Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.

Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим.

Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Веб-сервера Apache также имеется возможность выполнять Веб-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects ).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Веб-странице присутствуют фрагменты кода, который интерпретируется Веб-сервером и вместо которого пользователь получает результат выполнения этих фрагментов кода.

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений.

В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки ( WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Веб-сайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений , поддерживающим спецификаци ю J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" ( B2C – business-to-consumer). Не менее важными становятся и задачи интеграции Веб-приложений c данными и приложениями партнеров с целью реализации схемы "предприятие-предприятие" ( B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

Отметим, что, будучи составной частью подобного решения, Веб-сервер должен уметь не только выполнять приложения и взаимодействовать с сервером приложений , но и использовать сервисы интеграции, сервисы управления приложениями и данными, а также сервисы для разработчиков.

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

Нередко частью портального решения являются средства управления информационным наполнением Веб-сайта – ведь объем данных, доступных пользователям с помощью сайтов крупных компаний и порталов, сейчас таков, что управление этими данными "вручную" не представляется возможным.

Обобщая вышесказанное можно выделить основные особенности веб-архитектуры [ , ]:

• отсутствие необходимости использовать дополнительное ПО на стороне клиента – это позволяет автоматически реализовать клиентскую часть на всех платформах;
• возможность подключения практически неограниченного количества клиентов;
• благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются минимальные требования для поддержания целостности данных;
• доступность при работоспособности сервера и каналов связи;
• недоступность при отсутствии работоспособности сервера или каналов связи;
• достаточно низкая скорость Веб сервера и каналов передачи данных;
• относительно объема данных – архитектура Веб систем не имеет существенных ограничений.

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рис. 5.9 .

Рис. 5.9.

5.1.8. Сервис-ориентированная архитектура

Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP . Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс UDDI .

Поддержка Веб-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске серверов приложений , систем управления базами данных и средств разработки приложений.

(SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами .

OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом ( OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.

В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции.

Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)

Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).

Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются :

• сокращение издержек при разработке приложений, за счет упорядочивания процесса разработки;
• расширение повторного использования кода;
• независимость от используемых платформ, инструментов, языков разработки;
• повышение масштабируемости создаваемых систем;
• улучшение управляемости создаваемых систем.

Принципы SOA:

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

Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.

Главное, что отличает SOA, это использование независимых сервисов, с четко определенными интерфейсами, которые, для выполнения своих задач, могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путем комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определенного платформо-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах.Net и сервисы на Java, работающие на платформах Java EE , могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

, , Терминал , Сервер приложений , Сервер базы данных , Архитектура распределенных систем , , Сервис-ориентированная архитектура .

В настоящее время стремительно увеличивается число веб-сайтов, предоставляющих различные сервисы доступа к динамическим данным. Такие веб-сайты представляют собой уже не просто структурированный набор статической информации, а информационные системы разной степени сложности, которые мы будем называть веб-ориентированными, т.е. использующими веб-интерфейс в качестве основного средства взаимодействия с пользователем.

Целю данной работы явлется анализ веб-ориентированных информационных систем для выделения общих подходов к их разработке.

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

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

Первичная аутентификация пользователя выполняется пользователем, путем ввода своего имени и пароля.

Автоматическая аутентификация. После первичной аутентификации пользователю передается идентификатор сессии (токен). При последующих запросах этот токен автоматически аутентифицирует пользователя.

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

Определение прав текущего пользователя;

Становка прав пользователей;

Автоматическое изменение прав при возникновении определенных событий.

В настоящее время для реализации подсистемы разграничения доступа в основном применяется комбинация функционального и модульного подходов. Различные категории информации из предметной области обрабатываются отдельными скриптами (модулями) системы и реализуют весь необходимый набор функций для манипулирования данными одной категории. В этом случае, подсистема разграничения доступа, реализующая определенную политику безопасности «размазана» по исходным кодам информационной системы.

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

Для решения указанной проблемы предлагается следующий подход. Введем понятие информационного объекта, представляющего собой совокупность данных и методов, относящихся к одному экземпляру некоторого класса (информационной категории) и являющимся единицей применения правил политики безопасности, т.е. информационный объект является базовой единицей уровня разграничения доступа, реализуемого в информационной системе. Тогда все остальные компоненты веб-ориентированной системы можно отнести к подсистеме управления информацией, представлненной в виде информационных объектов.

Данная концепция закладывает мощный фундамент саморазвития информационной системы.

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

1. Брауде Э. Д Технология разработки программного обеспечения. – С-Пб.: Питер, 2004, – 656 с.

От Web-сайтов к Web-приложениям

Часть 1. Web-сайт или Web-приложение?

Принимайте правильные решения, проанализировав свое присутствие в Web

Серия контента:

В нашем мире iPad-ов, iPhone-ов, Android-ов и устройств, сфокусированных на приложениях, уже несовременно говорить: «у меня статический Web-сайт». Если у вас нет механизма для сложного поиска, хотя бы трех способов оплаты покупок и пары страниц с хитрыми Ajax-взаимодействиями, вас могут назвать «застрявшими в 1990-ых». Многим разработчикам приходится ухищряться, чтобы удовлетворить запросы руководства: Добавьте немного интерактивности! Не отставайте от Amazon.com или Bing, или IBM! Сделайте Web-сайт... Web-приложением. Однако если вы расширяете уже существующие сайты, в результате может получиться недостаточно сфокусированное, а иногда и менее функциональное присутствие в Web.

Web-сайты фундаментально отличаются от Web-приложений. Если вы создаете Web-приложения, вам нужно знать, что отличает их от Web-сайтов среднего уровня. А если вы привыкли создавать статические страницы без использования JavaScript, то, возможно, вас будут подталкивать к тому, чтобы сделать из вашего сайта Web-приложение.

В этой статье вы научитесь принимать обоснованные решения, которые помогут вашим Web-проектам достичь поставленных целей. Вы узнаете о разнице между Web-сайтами и Web-приложениями и о том, насколько эти две концепции отличаются друг от друга. Поняв главные различия, вы будете готовы к тому, чтобы принять решение (или хотя бы повлиять на него) о том, каким должно быть ваше присутствие в Web.

Web-сайты не обязательно должны быть Web-приложениями

Бывают ситуации, когда у вас имеется Web-сайт и нет весомой причины конвертировать его в Web-приложение. Или же, иногда люди проводят много времени над созданием и совершенствованием Web-приложения, но вместо его улучшения просто бегают по кругу. Возможно, лучше было бы не делать всю эту работу, а ограничиться довольно простым Web-сайтом. В этом разделе мы обозначим различия между Web-сайтами и Web-приложениями.

Web-сайты в основном служат для информационных целей

Простейшим определением полностью статического Web-сайта является слово информационный . Классическим примером такого сайта является Википедия, которая задумывалась исключительно как информационный сайт. Внешний вид Википедии не бросается в глаза, не восхищает, она не усыпана всплывающими картинками и картами с полосами прокрутки. Как показано на рисунке 1, ее содержимое – это просто информация, представленная в чуть более сложной форме, чем словарь с гиперссылками.

Рисунок 1. Пример страницы из Википедии

Часто наилучшим способом передачи информации являются простые статические Web-сайты. Если вашей целью является распространение информации о продукте, услуге, или о самой информации, то Web-сайт является хорошей отправной точкой. Конечно же, Web-сайтам приходится сталкиваться с неприятием. Они не бросаются в глаза, они никак не связаны с миром Twitter. Однако большинство людей при знакомстве с новой темой по-прежнему обращаются к Википедии, поэтому статические сайты могут представлять ценность.

Web-сайты могут быть динамическими

Большинство блогов на самом деле являются Web-сайтами. Хотя блоги управляются такими программами, как WordPress или Movable Type, их результатом являются информационные сайты, состоящие в основном из простых неинтерактивных страниц. Это говорит о важном различии: Web-сайт определяется не тем, как он сгенерирован, а тем, как предоставляемыми им информацией и функциями пользуются его посетители. Понимание этого различия может помочь вам сфокусироваться на том, как выглядит ваше присутствие в Web с точки зрения пользователя.

На ранних стадиях следует сосредоточиться на восприятии сайта пользователем. Пользователю неинтересно, на каких технологиях построен ваш сайт: HTML и CSS, ColdFusion, PHP или Perl. Пользователи просто оценивают сайт, основываясь на том, что они видят. Чтобы понять, сайт какого типа вы создаете или исследуете, нужно немного отвлечься от программирования. Просто откройте браузер, зайдите на свой сайт и оцените его.

Web-приложения, как правило, являются интерактивными

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

Эталоном интерактивности можно считать компьютерную игру. В игре пользователи постоянно взаимодействуют с компьютером. Стреляют ли они в зомби или идут по минному полю - игроки все время нажимают кнопки и принимают решения, в результате которых нужно снова нажимать кнопки и т.д. Конечно же, большинство сайтов не достигают такого уровня интерактивности.

Большинство Web-сайтов являются в некоторой степени гибридами. Например, взгляните на домашнюю страницу сайта Amazon.com, показанную на рисунке 2. Amazon.com – это гибрид, который однако, является информационным сайтом.

Рисунок 2. Amazon.com

На показанном выше экране представлено много информации. Книги, авторы, цены и категории – все это является разными видами информации. Однако, на этой странице главной целью пользователя является взаимодействие. Пользователь может перейти в какую-нибудь категорию товаров. Или он может подробно ознакомиться с какой-нибудь книгой и купить ее. Пользователь может выполнить поиск или посмотреть, что находится у него/нее в корзине. Все это – разные виды взаимодействий.

Так как любой Web-сайт представляет какую-либо информацию, нужно определить баланс между информацией и интерактивностью. Что вы больше делаете: читаете или взаимодействуете? Вы проводите на одной странице 30 секунд или 10 минут? Если вы много взаимодействуете и проводите мало времени на каждой странице, перед вами интерактивный сайт.

Чем отличаются информационные и интерактивные сайты

До сих пор мы обсуждали довольно простой способ оценки сайтов. Сайт является либо информационным, либо интерактивным. Черным или белым.

Большинство интерактивных сайтов на самом деле являются гибридами. Если нет информации, то получается, что нет ничего, с чем можно было бы взаимодействовать . Представьте, что было бы, если бы на Amazon.com не было ничего, кроме кнопок - ни книг, ни DVD-дисков. Сайт не имел бы смысла. Необходимо иметь какую-либо информацию, с которой можно работать. Таким образом, даже интерактивные сайты в действительности являются гибридами: комбинацией информации и взаимодействий.

Вы можете задать вопрос: зачем вообще задумываться о различиях интерактивных и информационных сайтов? Важно по-разному видеть для себя сайт, через который вы хотите предоставить пользователям информацию и сайт, на котором вы хотите обеспечить интерактивность. Эти различия в видении фактически будут определять большинство ваших серьезных дизайнерских решений. Даже несмотря на то, что вы редко будете создавать исключительно информационные или исключительно интерактивные сайты, важно определить, к чему больше тяготеет ваш сайт.

Информацию лучше всего подавать без обработки

Если ваш сайт скорее является информационным, это определяет сценарий его использования: донесите с его помощью информацию до своей аудитории. После этого остается лишь определить средства реализации. С учетом того, что пользователям нужна информация, как эту информацию лучше всего донести? Как лучше всего представить данные, имеющиеся, как правило, в большом количестве, для чтения онлайн?

В этом момент ребята, занимающиеся электронными книгами, дополненными изданиями (enhanced editions) и следующим поколением издательских продуктов начинают взволнованно махать руками. До нового поколения читателей следует доносить информацию современными средствами, верно? Есть новые способы представления информации: плавающие аннотации, всплывающие окна с дополнительной информацией и встроенные видео.

Да, для расширенной информации есть свое место

Я не хочу сказать, что нужно избегать дополненных изданий или не следует пытаться расширить границы возможного с помощью подхода к информации в стиле Web 2.0/3.0.. Однако, подобные средства служат не совсем для того, чтобы получать информацию быстро и эффективно. Большинство новых способов представления информации используются в иммерсивных и даже развлекательных приложениях. Эти способы не просто передают информацию, они изменяют механизм ее восприятия.

Информационный сайт не пытается быть экспериментальным. Если целью вашего сайта являются развлечения, значит вам нужен интерактивный сайт.

Проблема подобного мышления в том, что оно предполагает, будто история мало что значит, и что в пользователях нет определенной степени инерции. Люди привыкли читать книги, читать словари, читать Википедию. Они читают, перемещаясь глазами с верха страницы вниз и, во многих языках, слева направо. Они читают большое количество текста и, как правило, читают его, не отвлекаясь. Фактически, они хотят читать эту информацию, не отвлекаясь.

Информационные сайты не должны стремиться к тому, чтобы быть самыми яркими, привлекательными и полнофункциональными сайтами. В то же время есть широкие возможности для использования изображений для иллюстрации, в качестве примеров можно посмотреть на такие популярные сайты, как dictionary.com, Wikipedia и другие сайты с большим количеством текста. Несомненно, стоит рассмотреть возможность использования различных визуальных элементов: пробуйте использовать различные шрифты и поработайте над легкой и понятной навигацией по сайту. Вы предоставляете доступ к информации, поэтому все, что отвлекает от ее восприятия, в конце концов сыграет против вас.

Интерактивность основана на прерывистой работе

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

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

Еще одним подходом к решению задачи встраивания интерактивности в сайт является построение карты следования. Сделайте скриншот определенной страницы, а затем определите, какой бы вы хотели видеть следующую страницу вашего сайта. Сделайте еще один скриншот, затем еще, и так далее, до тех пор, пока у вас не получится четыре или пять (или десять) скриншотов, иллюстрирующих шаги для перехода пользователя из точки A в точку B.

Определите, как пользователь перемещается от экрана к экрану. Нажимает ли он на обыкновенную ссылку? Нажимает ли он кнопку? Как много он двигает мышью? Как много действий происходит на экране? Что пользователь делает ? Это отличный способ определить, какими должны быть прерывания. Как часто пользователь должен привлекаться к принятию решения о том, куда перейти дальше? Как много способов для прерывания вы предоставляете в случае, если пользователь не привлекается к принятию решения?

Пример интерактивного сайта: Audi.com

Чтобы увидеть, насколько полезной может быть карта следования, давайте рассмотрим пример. Взгляните на последовательность экранов Web-сайта одного из ведущих производителей дорогих автомобилей. Так как на этом сайте предлагаются очень дорогие покупки, сайт должен заманивать и удивлять пользователя.

На рисунке 3 показана стартовая страница, Web-сайта Audi.com. Сайт выглядит глянцево даже до начала взаимодействия с ним.

Рисунок 3. Стартовая страница сайта Audi.com

Пользователь может сразу начать взаимодействовать с сайтом. На рисунке 4 показано, как выглядит сайт после щелчка мышью. Ниже автомобиля находится несколько цветных кусочков, нажатие на любом из которых моментально изменяет цвет машины. Без поиска по меню или где-нибудь еще, пользователь может моментально начать взаимодействовать со страницей.

Рисунок 4. Изображение на стартовой странице сайта Audi изменяется по щелчку мыши

На данном этапе на сайте Audi.com применяется много относительно старых технологий. Меню выпадающие при наведении на них мыши, не являются чем-либо новым, это давным-давно можно было делать с помощью DreamWeaver. Однако сайт Audi пытается быть интерактивным. Поэтому вместо отображения пунктов меню и нажатия мышью на каком-либо из них, они выводят полноценные изображения, таблицы со спецификациями, а также встроенные страницы.

Рисунок 5 больше напоминает внутреннюю, а не стартовую страницу сайта. Audi.com использует меню гораздо шире, чем просто для навигации. При наведении мыши на меню появляются не просто пункты, на которые можно нажать, полноценные изображения и списки опций автомобиля.

Рисунок 5. При наведении мыши на меню появляются полноценные изображения и списки опций

Это умный подход к интерактивности. Пользователи не должны много щелкать мышью, однако этот сайт предоставляет им богатую обратную связь, выраженную визуально. Пользователю кажется, что на сайте много чего происходит. Взаимодействие не всегда включает в себя сложную Flash-анимацию или работу с джойстиком. Иногда совершенно достаточно удачно расположенного изображения, как на сайте Audi.

На рисунке 6 раскрывается еще один аспект интерактивности: простота. Это обычное текстовое меню, во внешнем виде которого нет ничего экстраординарного. Однако меню выпадает очень четко, а текущий пункт в нем выделен цветом. В этом нет ничего революционного, но с учетом того, как работает весь сайт, получается, что на чтение и поиск интересующих вас вещей вы тратите минимальное время. Вы просто наводите мышь на меню, перемещаете ее к нужному пункту и нажимаете. Тут просто негде запутаться. Вы всегда уверены, что получите то, что хотите.

Рисунок 6. Навигационные меню просты и сами просят на них нажать

На рисунке 7 показана внутренняя страница. Несомненно, внутренняя страница несколько слабее и не так иммерсивна, чем хорошо проработанная стартовая страница. Здесь есть гораздо больше опций, нажатие каждой из которых изменяет находящееся в центре изображение машины. На странице каждой модели имеется множество изображений, которые изменяются в соответствии с действиями пользователя. Выбор цвета, типа колес или салона моментально изменяет изображение.

Рисунок 7. На внутренних страницах нужно больше нажимать мышью, чем читать

Очевидно в этот сайт вложено много труда дизайнеров и программистов. Он не является образцом интерактивности, который смогут использовать многие сайты. Однако ключевым здесь является то, что пользователи должны взаимодействовать с сайтом, чтобы перейти дальше. Большая интерактивность позволяет получить от сайта больше информации.

Распечатав скриншоты, можно легко увидеть, как пользователи взаимодействуют с сайтом, и что они получают в результате этих взаимодействий. Выделите время на выполнение этого упражнения. Возможно, кому-то покажется глупым рассматривать разложенные на полу скриншоты, однако это лучше, чем иметь сайт, зайдя на который пользователь начинает скучать и быстро покидает его.

Добавить интерактивность не так просто

При интерактивном подходе главным становится вопрос где именно на экране должно происходить взаимодействие. Это не только рассуждения типа "Этот виджет нужно поместить в левом верхнем углу? А может быть справа?" Есть два базовых подхода (один из которых не очень хорош):

• Интерактивность не обязательно должна физически находитьcя в центре. Она должна быть там, куда устремлено внимание пользователя. Пользователь должен взаимодействовать с сайтом, чтобы перейти дальше.
• Интерактивность размещена повсюду, где есть информация. Интерактивность впечатляет, однако она не обязательна для перехода дальше.

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

Перемешиваем информацию и взаимодействия

Возвращаясь к идее гибридизации: даже самые интерактивные сайты должны в определенный момент представить информацию. Рассмотрим, например, видеоигры. То тут, то там в играх встречаются паузы, во время которых игрок является пассивным зрителем сцен, дающих необходимую для игрока информацию.

С другой стороны, большинство информационных сайтов в определенный момент должны позволить пользователю что-то нажать или поискать. Представьте, если бы вся информация Википедии хранилась на одной странице! И даже в этом случае, пользователь должен прокручивать страницу; а это тоже является взаимодействием. Все сайты являются гибридами. На большинстве сайтов нет подавляющего перевеса одной из этих сторон, например, 90% информации и только 10% интерактивности (или наоборот). На большинстве сайтов это соотношение составляет примерно 75/25. Вам нужно будет принять решение о количестве информации на вашем интерактивном сайте, либо о количестве взаимодействий на вашем информационном сайте. Конечно же, это должны быть хорошие решения.

Вы можете создавать потрясающие способы интерактивного взаимодействия, однако, тем не менее, вам также нужно суметь предоставить хорошую информацию. У вас может быть замечательная информация, однако в какой-то момент вам нужно будет обеспечить некоторое интерактивное взаимодействие.

Создавать гибриды гораздо сложнее

Суть проблемы в следующем: как бы хорошо вы ни создавали интерактивные взаимодействия, вам также нужно хорошо проектировать информацию. Если вы лучше всех проектируете информацию, вам все равно нужно научиться создавать интерактивные взаимодействия. Нелегко одновременно делать хорошо и то, и другое. Большинство людей хорошо разбираются в чем-то одном, вследствие чего их сайты выделяются тем, в чем они сильны. Странность и ирония здесь в том, что если сайт действительно хорош в чем-то одном (интерактивности или информации), то, как правило, другая сторона в нем проработана плохо. Конечно же, целью является делать и то и другое хорошо, чтобы получить очень сильный сайт или приложение.

Первое и самое главное правило – не следует работать исключительно над интерактивностью в ущерб информации или наоборот. Скорее всего, у вас будет хорошо получаться что-то одно, а другое – плохо. Старайтесь упорно работать над одним и по мере необходимости работайте над другим. Если вы приняли правило 75/25 (о соотношении информационного и интерактивного контента на сайте), возможно вам также в той же пропорции следует распределять свое время. Определенно это хороший ориентир для начала работы.

Следующим шагом является повторное выполнение задач. Проектируйте сайты и конструируйте взаимодействия непрерывно. Дизайнеры, которые в свободное от работы время продолжают создавать Web-сайты, как правило, со временем становятся лучшими дизайнерами, чем те, кто в свободное время учится играть на гитаре.

И, наконец, нужно упражняться и укреплять свои слабые места. Если вы проводите дни, работая над сайтами, заполненными информацией, поищите, где на сайте вы могли бы добавить немного интерактивности. Создайте с помощью JavaScript или jQuery сворачиваемые области. Расширьте свой информационный сайт, чтобы на нем соотношение между информацией и интерактивностью составляло 60/40. Также верно и обратное. Ищите способы увеличить количество информации на своем интерактивном сайте. Создайте боковые панели с информацией, появляющиеся в нужное время, на которых будет выведено больше информации, чем вы обычно предоставляете. Укрепляйте свои слабые места.

Используйте свои сайты

Здесь вы можете сделать круглые глаза и решить, что вам говорят совершено очевидную вещь. Не торопитесь удивляться.

Используйте свои сайты. Часто и много.

Звучит просто, не правда ли? Однако, так же, как актеры не хотят смотреть представления со своим участием, как многие музыканты не слушают свои собственные CD-диски, так и многие Web-дизайнеры практически не посещают сайты, которые они разрабатывали. Они пишут код, делают дизайн, выгружают сайт и забывают о нем. Они не имеют представления о дальнейшей судьбе сайта. Они стремятся как можно скорее закончить работу над вымышленным сценарием использования с участием невидимого и несуществующего пользователя. Это нельзя назвать хорошей привычкой.

Итак, нужно использовать свой сайт. Если он не нравится вам, он может не понравиться и вашим пользователям. Не торопитесь отмахиваться от проблем: "ну, это просто потому, что я знаю, как это работает" или "ни один из пользователей не похож на меня". Гораздо лучше задать себе вопрос: "как я могу улучшить восприятие сайта, независимо от того, похожи ли пользователи сайта на меня или нет"? Подобный способ мышления может коренным образом изменить ваши представления о своем сайте.

Заключение

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

В этой статье мы познакомились с принципами, руководствуясь которыми можно определить на что больше похоже ваше присутствие в Web: на Web-сайт или Web-приложение. Решите ли вы, что ваше присутствие в Web должно быть более информационным или более интерактивным или оно хорошо так, как оно есть - важно обдумать то, что вы собираетесь делать. Теперь вы можете принимать осознанные информированные решения.

Теперь пора нарушать правила или спорить с авторами, которых вы читали. Это означает, что вам нужно понять, что лучше всего подходит именно вам. Ваша ситуация отличается от моей или чьей-либо другой. Вам нужно "написать свою собственную статью" о том, что подходит именно вам. Это хорошее дело. А сейчас, я надеюсь, что эта статья натолкнет вас на хорошие мысли. Оставьте внизу статьи комментарий и дайте мне знать, в чем я прав, а в чем я ошибаюсь. Мне интересно узнать о вашей ситуации и о том, как ваше присутствие в Web развивается с учетом этого.

А функции его обновления и сопровождения лежат на поставщике операционной системы. Логика приложения сосредотачивается на сервере, а функция браузера заключается в основном в отображении информации, загруженной по сети с сервера, и передаче обратно данных пользователя. Одним из преимуществ такого подхода является тот факт, что клиенты не зависят от конкретной операционной системы пользователя, и веб-приложения, таким образом, являются межплатформенными сервисами. По причине этой универсальности и относительной простоты разработки веб-приложения стали широко популярными в конце 1990-х - начале 2000-х годов.

Технические особенности

Существенное преимущество построения Web приложений для поддержки стандартных функций браузера заключается в том, что функции должны выполняться независимо от операционной системы данного клиента. Вместо того чтобы писать различные версии для Microsoft Windows , Mac OS X, GNU/Linux и других операционных систем, приложение создается один раз для произвольно выбранной платформы и на ней разворачивается. Однако различная реализация CSS, или Java-апплетов для полной или частичной реализации пользовательского интерфейса. Поскольку большинство браузеров поддерживает эти технологии (как правило, с помощью плагинов), Flash- или Java-приложения могут выполняться с легкостью. Так как они предоставляют программисту больший контроль над интерфейсом, они способны обходить многие несовместимости в конфигурациях браузеров, хотя несовместимость между Java или Flash реализациями на стороне клиента может приводить к различным осложнениям. В связи с архитектурным сходством с традиционными клиент-серверными приложениями, в некотором роде «толстыми» клиентами, существуют споры относительно корректности отнесения подобных систем к веб-приложениям; альтернативный термин «Богатое Интернет приложение» (англ. Rich Internet Applications ).

Устройство веб-приложений

Веб-приложение получает запрос от клиента и выполняет вычисления, после этого формирует веб-страницу и отправляет её клиенту по сети с использованием протокола базы данных или другого веб-приложения, расположенного на другом сервере. Ярким примером веб-приложения является система управления содержимым статей Википедии : множество её участников могут принимать участие в создании сетевой энциклопедии, используя для этого браузеры своих операционных систем (будь то Microsoft Windows , GNU/Linux или любая другая операционная система) и не загружая дополнительных исполняемых модулей для работы с базой данных статей.

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

Для создания веб-приложений на стороне сервера используются разнообразные технологии и языки программирования

На стороне клиента используется:

• Flash
• ActiveX

См. также Ссылки

• How Microsoft lost the API war - Обсуждение замены традиционных приложений Windows на веб-приложения
• Web Applications 1.0 документирование работы веб-приложений.
• The Other Road Ahead - Статья где утверждается что будущее за серверными, а не за клиентскими приложениями

Литература

• Марко Беллиньясо Разработка Web-приложений в среде ASP.NET 2.0: задача - проект - решение = ASP.NET 2.0 Website Programming: Problem - Design - Solution. - М.: «Диалектика» , 2007. - С. 640. - ISBN 0-7645-8464-2
• Олищук Андрей Владимирович Разработка Web-приложений на PHP 5. Профессиональная работа. - М.: «Вильямс» , 2006. - С. 352. - ISBN 5-8459-0944-9

Wikimedia Foundation . 2010 .

Смотреть что такое "Web-ориентированный интерфейс" в других словарях:

Возможно, эта статья содержит оригинальное исследование. Добавьте ссылки на источники, в противном случае она может быть выставлена на удаление. Дополнительные сведения могут быть на странице обсуждения. (25 мая 2011) … Википедия

Интерфейс пользователя (UI англ. user interface) совокупность средств, при помощи которых пользователь общается с различными устройствами, чаще всего с компьютером или бытовой техникой, либо иным сложным инструментарием (системой). Интерфейс… … Википедия

Недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

JavaScript бесспорно стал незаменимым инструментом для разработчиков фронтенда. Сейчас сфера его применения расширяется на другие области, такие как серверы и микроконтроллеры. Этот язык программирования выбрали престижные университеты, чтобы обучать студентов основам информатики.

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

Далее последуют мои попытки ответить на эти вопросы. Я попытался исследовать, как использовать JavaScript с точки зрения пользователя (UX). В частности, уделил особое внимание идее минимизации времени, которое требуется пользователю для получения интересующих его данных. Начиная с основ сетевых технологий и заканчивая предсказанием будущего поведения юзера.1. Рендеринг страниц на сервереtl;DR : Рендеринг на сервере осуществляется не ради SEO, а для производительности. Принимайте в расчёт дополнительные запросы для получения скриптов, стилей и последующие запросы к API. В будущем, принимайте в расчёт использование метода HTTP 2.0 Push.
Прежде всего, я вынужден обратить внимание на общепринятую ошибку разделять «приложения с рендерингом на сервере» и «одностраничные приложения». Если мы хотим добиться наилучшего восприятия с точки зрения пользователя, то не должны ограничивать себя такими рамками и отказываться от одной альтернативы в пользу другой.

Причины вполне очевидны. Страницы передаются по интернету, у которого есть физические ограничения, что незабвенно проиллюстрировал Стюарт Чешир в знаменитом эссе «Это latency, дурачок» :

Расстояние между Стэнфордом и Бостоном 4320 км.
Скорость света в вакууме 300 x 10^6 м/с.
Скорость света в оптоволокне составляет примерно 66% скорости света в вакууме.
Скорость света в оптоволокне 300 x 10^6 м/c * 0,66 = 200 x 10^6 м/c.
Односторонняя задержка при передаче в Бостон 4320 км / 200 x 10^6 м/c = 21,6 мc.
Задержка при передаче туда и обратно 43,2 мc.
Пинг из Стэнфорда в Бостон в интернете современного образца около 85 мс (…)
Итак, современное оборудование интернета передаёт сигнал со скоростью 0,5 от скорости света.
Указанный результат 85 мс можно улучшить (и уже сейчас он чуть лучше), но важно понять, что существует физическое ограничение на задержку при передаче информации через интернет, как бы не увеличивалась полоса пропускания на компьютерах пользователей.

Это особенно важно в связи с ростом популярности JavaScript-приложений, которые обычно содержат только разметку и рядом с пустым полем . Так называемые одностраничные приложения (Single Page Applications, SPA) - сервер возвращает одну страницу, а всё остальное вызывается кодом на клиентской стороне.

Представьте сценарий, когда пользователь напрямую заходит по адресу аpp.com/orders . К моменту, когда ваше приложение получает и обрабатывает этот запрос, у него уже есть важная информация о том, что нужно показывать на странице. Оно может, например, подгрузить заказ из базы данных и добавить его в ответ. А вот большинство SPA в такой ситуации возвращает пустую страницу и тег . Потом придётся ещё раз обменяться запросами для получения содержимого скрипта, и ещё раз - для получения контента.

Анализ HTML, отправляемого сервером для каждой страницы SPA

Многие разработчики сознательно идут на такую жертву. Они стараются гарантировать, что дополнительные сетевые хопы для пользователя произойдут только один раз, отправляя правильные заголовки для кеширования в ответах со скриптами и CSS. Общепринятое мнение состоит в том, что это приемлемая сделка, потому что после загрузки всех файлов на компьютер большинство действий пользователя (как переходы в другие разделы) осуществляются без запросов дополнительных страниц или скриптов.

Однако, даже с учётом кеша, имеется определённый проигрыш в производительности, если учесть время на парсинг и выполнение скрипта. В статье «jQuery слишком большой для мобильника?» говорится, как один только jQuery может тормозить некоторые мобильные браузеры на сотни миллисекунд.

Что ещё хуже, обычно пользователь не получает никакого фидбека в то время, как загружаются скрипты. Результат - чистая страница на экране, которая потом внезапно превращается в полностью загруженную страницу.

Самое главное, мы обычно забываем, что наиболее распространённые транспорт для передачи интернет-данных (TCP) стартует медленно. Это почти наверняка гарантирует, что большинство комплектов со скриптами не будут переданы за один раз, делая вышеописанную ситуацию ещё хуже.

TCP-соединение начинается с обмена пакетами для рукопожатия. Если вы используете SSL, что важно для безопасной передачи скриптов, происходит два дополнительных обмена пакетами (один, если клиент восстанавливает сессию). Только после этого сервер может начать отправку данных, но практика показывает, что он делает это медленно и порционно.

Механизм контроля заторов под названием Slow Start встроен в протокол TCP, чтобы отправлять данные, постепенно наращивая количество сегментов . Это имеет два серьёзных вывода для SPA:

1. Большие скрипты загружаются гораздо дольше, чем кажется. Как объясняется в книге "High Performance Browser Networking" Ильи Григорика, требуется «четыре обмена пакетами (…) и сотни миллисекунд задержки, чтобы выйти на 64 КБ обмена данными между клиентом и сервером». Например, в случае быстрого интернет-соединения между Лондоном и Нью-Йорком, требуется 225 мс, прежде чем TCP сможет выйти на максимальный размер пакета.

2. Поскольку это правило действует также для первоначальной загрузки страницы, то очень важно, какой контент грузится для рендеринга на странице в первую очередь. Как заключает Пол Ириш в своей презентации «Доставка товаров» , критически важны первые 14 КБ . Это понятно, если посмотреть на график с указанием объёмов передачи между клиентом и сервером на первых этапах установки соединения.

Сколько КБ сервер может отправить на каждом этапе соединения, по сегментам

Веб-сайты, которым удаётся доставить контент (пусть даже базовую разметку без данных) в этом окне, кажутся исключительно отзывчивыми. На самом деле, многие авторы быстрых серверных приложений воспринимают JavaScript как нечто ненужное или что нужно использовать с большой осторожностью. Такое отношение ещё больше усиливается, если у приложения быстрые бэкенд и база данных, а его серверы находятся возле пользователей (CDN).

Роль сервера в ускорении представления контента напрямую зависит от веб-приложения. Решение не всегда сводится к «рендерингу целых страниц на сервере».

В некоторых случаях, неактуальную в данный момент для пользователя часть страницы лучше исключить из первоначального ответа и оставить на потом. Некоторые приложения, например, предпочитают осуществить рендеринг только «ядра» страницы для обеспечения немедленного отклика. Затем они запрашивают разные части страницы параллельно. Это обеспечивает лучшую отзывчивость даже в ситуации с медленным устаревшим бэкендом. Для некоторых страниц хорошим вариантом будет рендеринг только видимой части страницы.

Исключительно важна качественная оценка скриптов и стилей с учётом информации, которая у сервера есть о сессии, клиенте и URL. Скрипты, которые осуществляют сортировку заказов, очевидно будут важнее для /orders , чем логика страницы настроек. Может быть, не настолько очевидная, но есть разница в загрузке «структурного CSS» и «CSS для оформления». Первый может понадобиться для кода JavaScript, так что требуется блокировка , а второй загружается асинхронно.

Хороший пример SPA, которое не приводит к излишнему обмену пакетами, - концептуальный клон StackOverflow в 4096 байтах , он теоретически может загружаться с первым же пакетом после рукопожатия на TCP-соединении! Автор умудрился добиться такого за счёт отказа от кеширования, используя inline для всех ресурсов в ответе с сервера. Применив SPDY или HTTP/2 server push , теоретически возможно передать весь кешируемый клиентский код за один хоп. Ну а в настоящее время, рендеринг частей или всей страницы на стороне сервера остаётся самым популярным способом избавиться от лишних раундов обмена пакетами.

Proof-of-concept SPA с использованием inline для CSS и JS, чтобы избавиться от лишних roundtrip’ов

Достаточно гибкая система, которая разделяет рендеринг между браузером и сервером и предоставляет инструменты для постепенной загрузки скриптов и стилей, вполне может стереть грань между веб-сайтами и веб-приложениями . И то, и другое использует URL’ы, навигацию, демонстрирует данные пользователю. Даже приложение с электронными таблицами, которое традиционно полагается на функциональность с клиентской стороны, сначала должно показать клиенту информацию, которую требуется редактировать. И сделать это за наименьшее количество roundtrip’ов первостепенно важно.

С моей точки зрения, самый большой недостаток производительности во многих популярных системах в наше время объясняется прогрессивным накоплением сложности в стеке. Со временем добавлялись технологии вроде JavaScript и CSS. Их популярность тоже постепенно росла. Только сейчас мы можем оценить, как их можно использовать по-другому. Речь идёт и об улучшении протоколов (это показывает нынешний прогресс SPDY и QUIC), но наибольшую выгоду несёт всё-таки оптимизация приложений.

Полезно будет вспомнить некоторые исторические дискуссии вокруг дизайна ранних версий HTML и WWW. Например, этот список рассылки от 1997 года предлагает добавить тег в HTML. Марк Андрессен повторяет, насколько важно быстро доставлять информацию:

«Если документ нужно составлять в единое целое на лету, то это может быть сколь угодно сложным, и даже если сложность ограничить, у нас всё равно возникнут крупные проблемы с производительностью из-за структуризации документов подобным способом. Прежде всего, это сразу нарушает принцип одного хопа в WWW (ну, IMG тоже его нарушает, но по очень специфической причине и в очень ограниченном смысле) - уверены ли мы, что хотим этого?» 2. Немедленный ответ на действия пользователяtl;DR : JavaScript позволяет вообще спрятать сетевую задержку. Используя это как принцип дизайна, мы можем даже убрать из приложения почти все индикаторы загрузки и сообщения “loading”. PJAX или TurboLinks упускают возможности по увеличению субъективной скорости интерфейса.
Наша задача состоит в максимальном ускорении реакции на действия пользователя. Сколько бы усилий мы не вкладывали в уменьшение числа хопов при работе с веб-приложением, но есть вещи вне нашего контроля. Это теоретический предел скорости света и минимальный пинг между клиентом и сервером.

Важный фактор - непредсказуемое качество связи между клиентом и сервером. Если качество связи плохое, то будет происходить повторная передача пакетов. Там, где контент должен загружаться за пару roundtrip’ов, может понадобиться гораздо больше.

В этом главное преимущество JavaScript для улучшения UX. Если на клиентской стороне интерфейс управляется с помощью скриптов, мы можем спрятать сетевую задержку. Мы можем создать впечатление высокой скорости. Мы можем искусственно достигнуть нулевой задержки.

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

JavaScript позволяет реагировать немедленно и оптимистично на действия пользователя. Нажатие на ссылку или кнопку приводит к немедленной реакции, без обращения в Сеть. Известный пример - это интерфейс Gmail (или Google Inbox), в котором архивация почтового сообщения происходит немедленно, тогда как соответствующий запрос к серверу отправляется и обрабатывается асинхронно.

В случае с формой, вместо ожидания какого-то кода HTML в качестве ответа на её заполнение, мы можем реагировать сразу, как только пользователь нажал “Enter”. Или даже лучше, как делает поиск Google, мы можем реагировать ещё раньше, готовя разметку для новой страницы заблаговременно.

Такое поведение - пример того, что я называю адаптацией разметки . Основная идея состоит в том, что страница «знает» свою будущую разметку, так что может переключиться на неё тогда, когда ещё нет данных для указания на это. Это «оптимистичное» поведение, потому что всё ещё остаётся риск, что данные никогда не поступят, и придётся выводить сообщение об ошибке, но это, очевидно, случается редко.

Заглавная страница Google вполне подходит в качестве примера, потому что она очень чётко демонстрирует первые два принципа из нашей статьи.

В конце 2004 года, компания Google стала пионером в использовании JavaScript для выдачи подсказок в реальном времени в процессе набора поискового запроса (интересно, что эту функцию сотрудник разработал в свободные от основной работы 20% времени, так же как и Gmail). Это даже стало фундаментом для появления Ajax :

Посмотрите на Google Suggest. Наблюдайте, как обновляются поисковые термины по мере набора текста, практически мгновенно… без задержки на перезагрузку страницы. Google Suggest и Google Maps - это два примера нового подхода к созданию веб-приложений, которые мы в Adaptive Path назвали “Ajax”
И в 2010 они представили Instant Search, в котором JS играет центральную роль, вообще исключая обновление страницы вручную и переключаясь на разметку «поисковые результаты» при первом же нажатии клавиши, как видно на иллюстрации вверху.

Другой видный пример адаптации разметки, возможно, лежит у вас в кармане. С первых же дней iPhone OS требовала от авторов приложений предоставить картинку default.png , которое можно сразу вывести на экран во время загрузки самого приложения.

iPhone OS принудительно загружает default.png перед запуском приложения

Другим типом действий, кроме кликов и отправки форм, которые отлично улучшаются с помощью JavaScript, является рендеринг загрузки файла .

Мы можем зарегистрировать попытку пользователя загрузить файл разными способами: drag-n-drop, вставка из буфера, выбор файла. Затем, благодаря новым HTML5 APIs , мы можем отобразить контент, как будто он уже загружен. Пример такого рода интерфейса - наша работа с загрузками в Cloudup. Обратите внимание, как миниатюра изображения генерируется и рендерится мгновенно:

Изображение рендерится и отображается до окончания загрузки

Во всех этих случаях мы улучшаем восприятие скорости . К счастью, существует много доказательств полезности такого подхода. Взять хотя бы пример , как увеличение расстояния до багажного конвейера в Хьюстонском аэропорту уменьшило количество жалоб на потерянный багаж, без необходимости ускорять обработку багажа.

Эта идея должна серьёзно повлиять на UI наших приложений. Я считаю, что индикаторы загрузки должны стать редкостью, особенно если мы переходим на приложения с информацией в реальном времени, которые описываются в следующем разделе.

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

Но даже в этих случаях, отображение на экране спиннеров или индикаторов загрузки следует прекратить. Их нужно отображать только после того, как пользователь считатиает отклик не мгновенным. В соответствии с часто цитируемым исследованием Nielsen :

Базовый совет по времени отклика остаётся неизменным уже тридцать лет Miller 1968; Card et al. 1991 :
* 0,1 секундs является лимитом, чтобы пользователь воспринимал отклик как немедленный, здесь не требуется отображение никакой дополнительной информации, кроме результата операции.
* 1,0 секунды является лимитом на непрерывность потока мысли у пользователя, даже хотя он заметит задержку. Обычно, не требуется никакой дополнительной индикации при задержки более 0,1 секунды, но менее 1,0 секунды , но у пользователя пропадает ощущение прямой работы с данными.
* 10 секунд является лимитом удерживания внимания пользователя на диалоге. При большей задержке пользователи захотят выполнить другую задачу, ожидая отклика от компьютера.
Техники вроде PJAX или TurboLinks, к сожалению, упускают большинство возможностей, описанных в данном разделе. Код на клиентской стороне не «знает» о будущем состоянии страницы до тех пор, пока не состоится обмен данными с сервером.3. Реакция на изменение данныхtl;DR : Когда на сервере обновляются данные, клиента следует уведомлять без задержки. Это такая форма повышения производительности, когда пользователя освобождают от необходимости совершать дополнительные действия (нажимать F5, обновлять страницу). Новые проблемы: управление (повторным) соединением, восстановление состояния.
Третий принцип относится к реагированию UI на изменение данных в источнике, обычно, в одном или нескольких серверах баз данных.

Уходит в прошлое модель передачи по HTML данных, которые остаются статичными до тех пор, пока пользователь не обновит страницу (традиционные веб-сайты) или не взаимодействует с ней (Ajax).

Ваш UI должен обновляться автоматически .

Это критически важно в мире с нарастающим потоком информации из разных источников, включая часы, телефоны, планшеты и носимые устройства, которые появятся в будущем.

Представьте новостную ленту Facebook сразу после её появления, когда информацию публиковали, в основном, с персональных компьютеров пользователей. Статичный рендеринг нельзя было назвать оптимальным, но он имел смысл для людей, которые обновляли ленту, скажем, раз в день.

Сейчас мы живём в мире, когда ты загружаешь фотографию - и почти немедленно получаешь лайки и комментарии от друзей и знакомых. Необходимость в мгновенном отклике стала естественной необходимостью в конкурентном окружении других приложений.

Было бы неверным, однако, предположить, что преимущества мгновенного обновления UI ограничиваются только многопользовательскими приложениями. Вот почему я люблю говорить о согласованных дата-поинтах , вместо пользователей . Возьмём типичный сценарий синхронизации фотографии между телефоном и ваши собственным ноутбуком:

Однопользовательское приложение тоже может получить пользу от «реактивности»

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

Каждая страница реагирует на состоянии сессии и статус авторизации

Как только вы установили правило, что информация на экране обновляется автоматически, важно поработать над новой задачей: восстановление состояния.

При отправке запросов и получении атомарных обновлений легко забыть, что ваше приложение должно нормально обновляться даже после долгого отсутствия связи. Представьте, что вы закрываете крышку ноутбука и открываете её через несколько дней. Как будет вести себя приложение?

Пример того, что происходит в случае некорректного обновления связи

Способность приложения нормально восстанавливать связь взаимодействует с принципом № 1. Если вы выбрали отправлять данные при первой же загрузке страницы, вы должны учитывать и время, которое прошло перед загрузкой скриптов. Это время, по существу, эквивалентно времени дисконнекта, так что первоначальное подключение ваших скриптов является возобновлением сессии.

4. Контроль обмена данными с серверомtl;DR : Теперь мы можем тонко настраивать обмен данными с сервером. Убедитесь в обработке ошибок, повторных запросах в пользу клиента, синхронизации данных в фоновом режиме и сохранении кеша в офлайне.
Когда появился веб, обмен данными между клиентом и сервером был ограничен несколькими способами:

Нажатие на ссылку отправит GET для получения новой страницы и её рендеринга.

Отправка формы отправит POST или GET с последующим рендерингом новой страницы.

Внедрение изображения или объекта отправит GET асинхронно с последующим рендерингом.

Простота такой модели очень привлекательна, и сейчас всё определённо усложнилось, когда речь идёт о понимании, как получать и отправлять информацию.

Главные ограничения касаются второго пункта. Невозможность отправить данные без обязательной загрузки новой страницы было недостатком с точки зрения производительности. Но самое главное, что это полностью ломало кнопку «Назад»:

Вероятно, самый раздражающий артефакт старого веба

Именно поэтому веб как платформа для приложений оставался неполноценным без JavaScript. Ajax представлял собой огромный скачок вперед с точки зрения удобства в части публикации информации пользователем.

Сейчас у нас есть множество API (XMLHttpRequest, WebSocket, EventSource, это лишь некоторые из них), которые дают полный и чёткий контроль над потоком данных. Кроме возможности публиковать пользовательские данные через форму, у нас появились новые возможности по улучшению UX.

Прямое отношение к предыдущему принципу имеет показ состояния соединения . Если мы ожидаем, что данные будут обновляться автоматически, то обязаны информировать пользователя о фактах потери связи и попытках её восстановления .

При обнаружении дисконнекта, полезно сохранить данные в памяти (а ещё лучше, в localStorage), так что их можно отправить позднее. Это особенно важно в свете будущего использования ServiceWorker , который позволяет приложениям JavaScript работать в фоновом режиме . Если ваше приложение не открыто, вы всё ещё можете продолжать попытки синхронизировать данные с сервером в фоновом режиме.

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

Некоторые ошибки нужно обрабатывать особенно внимательно. Например, неожиданная 403 может означать, что пользовательская сессия признана недействительной. В таких случаях, есть возможность восстановить сеанс, если показать пользователю окно для ввода логина и пароля.

Важно ещё убедиться, что пользователь случайно не прервёт поток данных. Это может случиться в двух ситуациях. Первый и самый очевидный случай - закрытие браузера или вкладки, что мы пытаемся предотвратить обработчиком beforeunload .

Предупреждение beforeunload

Другой (и менее очевидный) случай - попытка перехода на другую страницу, например, нажатие на ссылку. В этом случае приложение может остановить юзера иными методами, на усмотрение разработчика.

5. Не ломай историю, улучшай еёtl;DR : Если браузер не будет управлять URL’ами и историей, у нас возникнут новые проблемы. Убедитесь, что вы соответствуете ожидаемому поведению в отношении прокрутки. Сохраняйте собственный кеш для быстрого фидбека.
Если не считать отправки форм, то при использовании в веб-приложении одних только гиперссылок у нас будет полностью функциональная навигация «Вперёд/Назад» в браузере.

К примеру, типичную «бесконечную» страницу обычно делают с помощью кнопки на JavaScript, которая запрашивает дополнительные данные/HTML и вставляет их. К сожалению, немногие при этом помнят о необходимости вызова history.pushState или replaceState как обязательного шага.

Вот почему я использую слово «ломать». С простой моделью первоначального веба такая ситуация была невозможна. Каждое изменение состояния основывалось на изменении URL.

Но есть и обратная сторона медали - возможность улучшать историю сёрфинга, которую мы теперь контролируем средствами JavaScript.

Одну такую возможность Дэниел Пипиус назвал Fast Back :

Кнопка «Назад» должна работать быстро; пользователи не ожидают слишком большого изменения данных.
Это как рассматривать кнопку «Назад» в качестве кнопки из веб-приложения и применить к ней принцип № 2: немедленно реагировать на действие пользователя . Главное, что у вас есть возможность решить, как организовать кеширование предыдущей страницы и мгновенно вывести её на экран. Вы можете затем применить принцип № 3, а потом информировать пользователя о поступлении новых данных на эту страницу.

Всё ещё остаётся несколько ситуаций, когда вы не можете контролировать поведение кеша. Например, если вы отрендерили страницу, затем ушли на сторонний сайт, а потом пользователь нажал «Назад». Этому маленькому багу особенно подвержены приложения, которые рендерят HTML на стороне сервера, а потом модифицируют его на стороне клиента:

Некорректная работа кнопки «Назад»

Ещё один способ сломать навигацию - игнорирование памяти о состоянии прокрутки. Ещё раз, страницы, которые не используют JS и ручное управление историей, скорее всего, не будут иметь тут проблем. Но динамические страницы будут. Я протестировал две самые популярные новостные ленты на основе JavaScript в интернете: Twitter и Facebook. У обоих обнаружилась амнезия на прокрутку.

Бесконечное листание страниц - обычно, признак скроллинг-амнезии

В конце концов, опасайтесь таких изменений состояния, которые релевантны только при просмотре истории. Например, этот случай с изменением состояния поддеревьев с комментариями.

Изменение вида комментариев нужно сохранять в истории

Если страница была заново отрисована после нажатия ссылки внутри приложения, пользователь может ожидать, что все комментарии будут развёрнуты. При изменении состояния его нужно сохранить в истории.

6. Обновление кода через push-сообщенияtl;DR : Недостаточно отправлять через push-сообщения только данные, нужно ещё и код. Избегайте ошибок API и повышайте производительность. Используйте stateless DOM для безболезненной перелицовки приложения.
Исключительно важно, чтобы ваше приложение реагировало на изменения в коде.

Во-первых, это уменьшает количество возможных ошибок и повышает надёжность. Если вы сделали важное изменение в API бэкенда, то должны обновить код клиентских программ. В противном случае, клиенты могут не воспринять новые данные или могут прислать данные в несовместимом формате.

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

Имейте в виду, что у обычного сайта обновление страницы инициирует две вещи: перезагрузка данных и перезагрузка кода. Организация системы с push-обновлениями данных без push-обновлений кода неполноценна, особенно в мире, где одна вкладка (сессия) может оставаться открытой очень долгое время.

Если серверный push-канал работает, то пользователю можно выслать уведомление о доступности нового кода. Если нет, то номер версии можно добавить в заголовок исходящих HTTP-запросов. Сервер может сравнить его с последней известной версией, согласиться на обработку запроса или нет, и выдать задание для клиента.

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

Ещё лучший подход - «горячая» замена кода . Это значит, что не придётся осуществлять полную перезагрузку страницы. Вместо этого, определённые модули заменяются на лету, а их код повторно отправляется на выполнение.

Во многих существующих приложениях довольно сложно осуществить «горячую» замену кода. Для этого нужно изначально придерживаться архитектуры, которая разделяет поведение (код) от данных (состояние). Такое разделение позволит нам довольно быстро накатывать много разных патчей.

Например, в нашем веб-приложении есть модуль, который устанавливает шину для передачи event’ов (как socket.io). Когда событие наступает, состояние определённого компонента меняется и это отражается в DOM. Затем вы изменяете поведение этого компонента, например, так, что он генерирует разные разметки DOM для существующего и нового состояний.

В идеале у нас должна быть возможность менять код помодульно. Не нужно будет заново устанавливать соединение с сокетом, например, если есть возможность просто обновить код нужного компонента. Идеальная архитектура для push-обновлений кода, таким образом, является модульной.

Но сразу возникает проблема с тем, как оценить модули без нежелательных побочных эффектов. Здесь лучше всего подходит архитектура вроде той, которую предлагает React . Если код компонента обновляется, его логика может быть просто повторно исполнена, и DOM обновляется. Объяснение этой концепции от Дэна Абрамова читай .

По существу, идея заключается в том, что вы обновляете DOM (или перекрашиваете его), что существенно помогает в замене кода. Если состояние сохранено в DOM или обработчики event’ов установлены приложением, то обновление кода может стать намного более сложной задачей.

7. Предсказание поведенияtl;DR : Отрицательная задержка.
У современного JavaScript-приложения могут быть механизмы для предсказания действий пользователя.

Наиболее очевидным применением этой идеи является заблаговременное скачивание данных с сервера, прежде чем пользователь их запросил. Скачивать веб-страницу, когда над ней появился курсор мыши, так что по нажатию на ссылки она отображается мгновенно, - это простой пример.

Немного более продвинутый метод мониторинга отслеживания движения мыши анализирует её траекторию на предмет будущего «столкновения» с интерактивными элементами, как кнопки. :

Плагин jQuery предугадывает траекторию мыши

Заключение Веб остаётся самой многогранной средой передачи информации. Мы продолжаем добавлять динамику на наши страницы и перед их внедрением должны убедиться, что сохраним важные принципы веба, доставшиеся нам в наследство.

Страницы, связанные между собой гиперссылками, - хорошие строительные блоки для любого приложения. Поступательная загрузка кода, стилей и разметки по мере действий пользователя гарантирует отличную производительность без отказа от интерактивности.

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

Теги: Добавить метки