Pull to refresh

Веб-интерфейсы: развитие или наоборот?

Reading time 9 min
Views 18K
Уже давно крутятся мысли по поводу пользовательских интерфейсах и о их деградации развитии конечно же, ими то я и хочу сегодня поделиться. Многие помнят старые интерфейсы с псевдографикой в текстовом режиме со скупым функционалом и ограниченным юзабилити. Потом им на смену пришли оконные интерфейсы в графическом режиме и теперь уже веб-интерфейсы. Но повысилась ли скорость работы потребителей прикладных программ, пользователей и операторов ввода? Повысилась ли скорость разработки экранов и отчетов? Многие скажут Вам твердое «нет» — средняя производительность программистов и пользователей снижалась с каждым новым шагом технологий вперед. И для этого есть ряд объективных причин. Кроме них мы сегодня остановимся и на том, как же все-таки поднять сею производительность.

Текстовый режим


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

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

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

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

Оконные интерфейсы


Графический пользовательский интерфейс, применение ООП и оконных систем, основаны на передаче сообщений между визуальными контролами, использование мыши и тачскрина, дали нам много, но забрали еще больше.
Положительных моменты в оконных приложениях:
  • Контекст интерфейса в пользовательском приложении существуют достаточно долго, чтобы развернуть объектную модель, машину состояний, служебные структуры данных для ускорения процессов (кеш, индексы или ассоциативные массивы, деревья и т.д.). Это же справедливо и на счет сервера, если приложение клиент-серверное.
  • Есть возможность выводить богатую графику с аппаратной акселерацией и управлять графическими объектами непосредственно передвигая их по экрану мышью. Это незаменимо для программ работающих с графикой и игр, но для прикладных приложений баз данных — это излишество.
  • На экране можно поместить гораздо больше информации, сгруппировать и подсвечивать ее визуальными элементами (с помощью цвета, шрифта, пиктограмм и т.д.). Доступны различные динамические эффекты, как то: всплывающие подсказки, контекстные меню, графические маркеры для полей при валидации.
  • Таблицы стали гораздо удобнее: изменение ширины колонок, множественное выделение, контролы в ячейках, прокрутка, сортировка кликом по заголовку и даже возможность вывести дерево в таблице. Кое что из этого было доступно и в текстовом режиме, но в GUI есть для всего готовые решения, реализованные на уровне ОС или инструмента разработки.

Теперь критика:
  • Правая рука на мышке (а ввод как, левой рукой что-ли?). Поэтому правая рука постоянно двигается между мышью и клавиатурой. Например: вместо нажатия на F4 или комбинации клавиш мы берем мышь, двигаем ее через весь экран к тулбару и там наживает экранную кнопку небольшого размера.
  • Разработка и тестирование усложнилось, появилось много асинхронных событий, таймерных, серверных, сигналов от других окон и приложений. Среда (окружение) информационной системы стало менее стабильным и предсказуемым.
  • Программный код стал часто «завязан» на интерфейсах, в ООП произошло смешение в системной функциональности с логикой предметной области и с логикой визуализации, т.к. возможности увеличились, свободы в средствах реализации стало гораздо больше, а формирование подходов и архитектур запоздало.

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

Веб-приложения


И наступило всем счастье, больше не нужно инсталлировать клиенты на компьютеры к пользователям, не нужно париться по поводу версий DLL, версий .NET и множества настроек на их машинах и заботиться о конфликтах ПО на пользовательских компьютерах. Все происходит в браузере и даже стандарты уже к текущему моменту вполне сносно поддерживаются всеми браузерами. Обновлять софт не нужно. Аспект безопасности данных: все хранится на сервере и централизовано бекапится и защищается. По поводу протоколов не паримся имеем HTTPS и JSON, все и удобно и защищено. Нелегальный версий прикладного ПО скоро вообще не будет, т.к. оно не ставится на компьютеры, а используется в модели SaaS по сети.

Но все ли так хорошо?
При отсутствии сети не можем работать, ну это еще как-то терпимо, сеть должна быть всегда, иначе нет групповой работы и коммуникации. Если что-то зависло во время ввода или сеть пропала — теряются введенные данные, отправить по сети нельзя, а локально сохранить негде (локальный сторидж и Web SQL пока не везде доступны). На всем печать идеологии REST, полное отсутствие состояния. Отсутствие средств Разные браузеры, а них особенности, требуется дополнительное тестирование и отладка. Верстку иногда делаем отдельно для IE (реже возникают версии для других браузеров), но это при очень хитрой разметке.

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

Переосмыслили ООП и паттерны лишь единицы, другие взяли бездумно. А специфика веба в том, что серверные приложения живут доли секунды, при этом они стейтлесс и пользовательский интерфейс при рефреше страниц не сохраняет ни свое состояние (значения в формах, переменные, объекты). В общем, REST — это не наш путь, для пользовательских интерфейсов и приложений баз данных состояние нужно как воздух, и решение многими уже найдено, это механизм сессий и куки, «всеми так любимый» viewstate и устаревший способ передачи состояния в урлах, грядущие стандарты Local Storage и Web SQL от HTML5, key-value СУБД на стороне сервера.

Тенденции развития веб-интерфейсов


С учетом всех проблем и новых возможностей, сформировался мейнстрим, активно поддерживаемой всей передовой частью сети, а именно:
  • Минимализм и простота — и сайты и приложения становятся сложнее внутри и проще снаружи, этому нас учит все передовые игроки и больше всего — Гугл, мы стараемся. Пользователь должен произвести минимум действий и выбора для получения желаемого результата.
  • Интерактивность и асинхронность — интерфейсы становятся динамическими, пропадает перезагрузка страниц и смена экранов, подгрузка происходит постепенно, фрагментами. Приложение постепенно модифицирует экран, откликаясь на действия пользователя.
  • Контекстность — вывод информации и контролы для вызова операций появляются там, где это логически ожидается и показываются только пока это необходимо. Мы экономим экран и внимание пользователя.
  • Синхронизация и комет — все чаще появляются приложения, в которых сервер генерирует события по своей инициативе, это позволяет синхронизировать экран пользователя с текущим состоянием данных в БД или в памяти сервера.
  • Полноэкранный лэйаут — не во всем вебе, а именно в веб-приложениях, есть тенденция к максимальному заполнению экрана с перераспределением размеров и границ между элементами интерфейса в зависимости от разрешения.
  • Упрощенный мобильны интерфейс — с распространением мобильных устройств, снабженных нормальными браузерами, появилась необходимость отдельно разрабатывать интерфейсы для малых разрешений и с поддержкой тачскрина.
  • Поддержка стандартов — входит в моду решать задачи с применением новых возможностей и спецификаций но с фэлбэком к старым технологиям, например звук и видео уже хочется проигрывать через html5, но флэш нас страхует, или при отсутствии Local Storage мы храним состояние на сервере, просто будет больше запросов, визуализация так же упрощается при показе в старом браузере, но приложение продолжает работать, а выглядит проще.


Рассмотрим подробнее визуальные контролы и решения


Зона прокрутки — для сайтов типична прокрутка полноэкранная, когда весь контент с элементами управления прокручивается разом одним трекбаром справа (или слева для right-to-left). Однако, для веб-приложений это не удобно и гораздо более адекватным решением будет принцип «прикрепления панелей» (как это принято в оконных приложениях), например, инструменты находятся на панели, которая прикреплена к верхней границе окна браузера и растянута на всю ширину, а слева может размещаться панель с динамически подгружаемым деревом, приклеенная к левому краю окна, снизу — строка состояния, справа — панель с контекстными задачами, всю же центральную часть экрана занимает объект работы: документ, карта, таблица, изображение и т.д. Каждая зона имеет свою прокрутку. Конечно идеально, чтобы прокрутку имела только зона в центральной части, а все остальные панели были без прокрутки или прокрутка бы осуществлялась не в трекбаром и только по одной оси.

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

Гриды — таблицы и более сложные композитные гриды. С ними есть ряд проблем:
  • Очень плохо смотрится, если таблица имеет отдельный от всей страницы скроллинг, то есть, получается, что у нас скролинг в скролинге. Это актуально и для textarea.
  • Дублирование кнопок действия для каждой строки грида — это общая проблема всех веб-интерфейсов старого поколения — в глазах рябит.
  • Уезжают кнопки с действиями: поясню как — как в GMail, то есть, страница имеет общую прокрутку, которая прокручивает и грид и все разом с тулбаром вместе. Получается, что мы прокрутили грид на середину и хотим что-то сделать со строками в середине, а для доступа к тулбару нужно крутить экран вниз или вверх (как это и в редакторе статей Хабра).
  • И пейджинг (пусть меня осудят, но я скажу все, что об этом думаю) — далее третьей страницы мало кто заходит; длинные списки пользователи не браузят — это бессмысленно, если где-то они организовались, то только для того, чтобы отфильтровать их более подробно, а листать — лишнее; особо весело, когда вся страница перегружается при перелистывнии пейджинга; с сортировкой не всегда удобно; не все СУБД оптимизированы для отбора данных для пейджинга, при больших наборах данных это в любом случае повышает нагрузку на сервер. Что же вместо? Виртуальные гриды — см. ниже.

Что же хочется иметь в гридах:
  • Виртуализация грида — скролинг сразу большой (по количеству записей), а подгружаются только видимые, ни или еще небольшой запас (упреждающее чтение). Есть варианты, старые записи можно копить, пока весь набор данных не перекачаем в клиента или выделяется определенный буфер в 100-200 записей с вытесняющей подгрузкой строк, при прокрутке старые блоки удаляются.
  • Формирование на стороне сервера или на стороне браузера — решить эту проблему навсегда и кардинально нельзя. Спорить можно долго, кто-то привык пересылать данные JSON через AJAX и выводить в подготовленный грид на клиенте, а кто-то пересылает записи через AJAX сразу в HTML. Есть еще вариант предзаполненных гридов (это оправдано, если записей не много). Как правильно — определяется спецификой задачи и хороший грид должен реализовывать все три варианта.
  • Работа с клавиатуры — уже много об этом говорили, но уж очень мне не хватает во всех современных веб-приложения полноценной работы с клавиатуры, это альтернативный способ, но он должен быть, и навигация курсорами и горячие комбинации и функциональные клавиши.
  • Инлайн редактирование — то есть правка значений по месту, без вызова форм с AJAX/JSON отправкой на сервер отредактированного значения или накопления буфера и отправкой при нажатии «сохранить» сразу целой пачки.


Дерево — для полного счастью дерево должно удовлетворять почти тому же перечню, что и грид: подгружаться динамически, управляться мышью и с клавиатуры, редактироваться по месту и т.д.

Главное меню — забыть как страшный сон! Этот атавизм от оконных приложений в вебе не имеет права на жизнь.

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

Комбобокс — cтандартный html-ный комбо-бокс ужасен и по дизайну, который нельзя полностью переопределить и по функционалу, который ограничен банаьным выпадающим списком строк. Нам нужен комбо-бокс с многими режимами, с инкрементным поиском, позволяющим выбирать из больших справочников, с возможногстью выбирать несколько значений, с группами, с картинками (и вообще с элементами с богатым html+css оформлением).

Заключение


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

Добавлено: картинку для медитаций убрал, она Вам не нравится, я чувствую.
А иллюстрации попробую все же собрать в ближайшие дни.

Рис 1: Как некрасиво делать уезжающие тулбары на примере GMail


Рис 2: Как красиво делать лэйаут, тулбары и прокрутку на примере GoogleDocs


Рис 3: Несколько вариантов дефолтных комбобоксов


Рис 4: Виртуальный скроллинг и пейджинг — кому что?


Рис 5: Скроллинг внутри скроллинга — плохо


Рис 6: А грид растянутый на всю доступную зону (так, чтобы прокрутка была одна) — хорошо
Tags:
Hubs:
+44
Comments 93
Comments Comments 93

Articles