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

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

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


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

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

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

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

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


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

    Подробнее
    Реклама

    Комментарии 93

      +1
      Сори, первые несколько минут статья опубликовалась в несколько порванном формате, без части абзацев, из-за форматирования. Сейчас все ок.
        +6
        Сегодня я сломал мышь. Не могу не согласиться с некоторыми пунктами.
          +1
          Я бы не был так категоричен, все зависит от конкретной реализации интерфейса и задач. Тот же пейджинг в приложениях подобных твиттеру, где данные представляют из себя поток, вполне можно заменить скроллингом с подгрузкой, но в приложениях для бизнеса, где таблица — это просто какой-то набор данных — пэйджинг будет лучшим вариантом. Инлайн редактирование часто невозможно, или еще больше нагромождает интерфейс таблицы. Свой скролбар у некоторых элементов вполне оправдан и при грамотном оформлении не вызывает отвращения.
            0
            Если в выборке для бизнес-приложения более 200 записей с цифрами и подробностями, то человек не сможет их вычитать все равно, это значит, что нужно давать человеку количество и какие-то статистические характеристики, например: найдено 9201 продуктов таког-то бренда и 6288 другого, в таком-то ценовом диапазоне 2503 экземпляров, в такой-то области 71022 объекта и т.д. Потом человек нажмет там уточнения и получит фильтр более узкий, вот пример — www.alibaba.com/products/hdd/--711001.html
              +1
              >>Если в выборке для бизнес-приложения более 200 записей с цифрами и подробностями, то человек не сможет их вычитать все равно

              Много раз слышал это мнение, тем не менее уверился в обратном. Типовой кейс таков: огромная таблица, хоть на 100 000 записей. Юзеру удобнее отсортировать ее кликом по заголовку грида а затем быстренько пролистать в нужное место чем что-то вбивать в фильтры.
                +1
                Тоже к этому пришел. Особенно это касается тач-интерфейсов: никого не испугать длинной портянкой с информацией — человеку гораздо проще промотать до нужного места, нежели тыкать по кнопкам или в экранную клавиатуру или пробираться сквозь десять экранов.
                  0
                  Наверно я лентяй, но меня постоянно охватывает чувство впустую растрачиваемого времени когда приходится что-то искать глазами. А когда таблица не умещается на страницу — вообще кошмар.

                  При использовании фильтров в разы сокращается расход времени на то чтобы убедиться в отсутствии в таблице какой-либо информации.
                    +1
                    Вы человек и вам так удобнее (: В справочнике своей компании я тоже использую фильтр, но когда мы его (справочник) создавали и тестировали — почти 300 человек и камера — оказалось что 86% людей сортируют его как им удобно и просто проматывают. И это при том, что фильтр находился в верху в самом видном месте и назывался «Быстрый поиск по справочнику». Цифра, я помню, меня тогда поразила… Правда потом мы проводили опрос и уже только 38% процентов сотрудников ответило, что не пользуются быстрым поиском.
                      0
                      Дайте догадаюсь — наверное вам лень отрывать руки от клавиатуры, чтобы кликать сортировку и скроллить мышью на скроллбаре? :)
                      0
                      Фильтры можно подсказывать, а не набирать руками, я давал ссылку с примером, который мне понравился (Alibaba.com), вот скриншот: alibaba
                      0
                      Вот «быстренько пролистать в нужное место» среди 100 000 записей как-то не верится. Сортировка — согласен, она тут очень даже причем. Может быть реальный случай, когда в выборке из 100 000 записей одним кликом по заголовку (с целью сортировки) мы сразу получаем несколько интересующих нас записей в зоне видимости (10-20 записей). Но пейджинг то тут не особо нужен. Можно из больших выборок показывать первые 50-100 записей и давать возможность сортировки ASC/DESC.
                        0
                        да запросто. PageUp/PageDown отлистывает очень быстро. Лишь бы софт не подтормаживал.

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

                        Делать пэйджинг в табличноориентированном софте — значит профакапить часть рынка конкуррентам с более привычным интерфейсом

                        вообще пэйджинг был придуман для экономии ресурсов веб-серверов, но никак не для повышения юзабилити
                          0
                          Виртуальный грид мне как-то больше по душе, экономия та же, не все сразу подгружается, а вот возвращаться пейджингом сложнее и в веб-интерфейсах подтормаживания иногда чувствуются, особенно если при пейджинге полностью перегружают страницы.
                          0
                          Если софт не тормозит, записи расположены, например, по алфавиту или дате-времени более-менее равномерно, то в нужное место при 100 000 записях при некоторой сноровке попадаешь быстро, просто перетаскивая ползунок скроллбара в нужное место.
                    +1
                    По виртуальному скролу пример:
                    www.trirand.com/blog/jqgrid/jqgrid.html
                    -> New in version 3.7 -> Virtual scrolling
                    Ну чем не решение для бизнесапликейшенов?
                      +3
                      если кому-то интересно

                      Конечно!
                      В общем, REST — это не наш путь, для пользовательских интерфейсов и приложений баз данных состояние нужно как воздух

                      А когда состояние интерфейса хранится локально, а данные для отображения в нём на сервере, стэйтлесс? Ну, максимум, 304 Not Modified?
                        –4
                        Мне кажется, HTML рано или поздно отомрет для интерактивных приложений: слишком много сложностей при подгоне под разные браузеры. Постоянно что-то разъезжается, слетает выравнивание и маржины, тормозит на ие7, 8 и айпаде. 50% процентов времени проводишь за проверкой и поднманием отломавшегося. Тестирование нетривиально и требует виртуальных машин, чтобы держать разные версии браузеров.

                        Предсказуемость обеспечивает только flex, sl и java. На них и нужно ориентироваться.
                          +4
                          Да ладно: HTML только начинает набирать обороты =)
                          А «вольности», которые доступны разработчикам интерфейсов на fl/sl, иногда играют против пользователя.
                            +2
                            Я могу ошибаться, но ИМХО пока «набирание» идёт в сторону «хотим всё, что есть в окошках но в браузере»: доступ к клавиатуре, local storage, попиксельный доступ, звук, видео и т.д. В свете этого непонятны выпады про «свобода играет против» и «слишком большие возможности — зло».
                            При этом имеется зоопарк броузеров, каждая версия со своим мнением по рендерингу и, извините, весьма небыстрый js.

                            Имеем то, что имеем: разработка более трудоёмка в разы, в doom погонять можно, но на строго определённых версиях строго определнных браузеров и на 30fps в малюсеньком окошке, что является большим достижением для веб-приложений.
                              +2
                              Имеем то, что веб-приложения доступны (с оговорками) на любых, в том числе экзотических платформах, лишь бы был подходящий браузер: win/mac/linux/bsd/ios/android/symbian/… какой еще есть вариант запустить один и тот же код на всем этом зоопарке? :)
                                0
                                Очень хорошая оговорка «лишь бы был подходящий браузер». ".net программы могут быть запущены на любых платформах, лишь-бы был подходящий CLR" :)
                                  0
                                  CLR это только часть .NET, есть аналогичные CLI для других платформ, но нет библиотек
                          +2
                          Судя по оформлению статьи, автор все же поклоник текстового интерфейса.
                            0
                            это просто взгляд «не дизайнера»
                              +2
                              Это была добрая ирония.
                                0
                                Та понимаю, но картинок пока малеха не хватает, сейчас покопаю что-то в эскизах, может на днях выложу
                                0
                                Да нормальное оформление статьи. Введение, разбиение на главы, пункты, и заключение. Спасибо вам за это, всем бы так оформлять.
                                Картинки конечно не помешали бы, о графике ж речь. Но всем, кому не нравится такое изложение — не место на айтишном ресурсе.
                                  0
                                  За исключением пожалуй вот этого:
                                  • 1. Контекст интерфейса в пользовательском интерфейсе …
                                  • 2. Есть возможность выводить богатую графику …
                                  • 3. На экране можно поместить гораздо больше информации …
                              +5
                              «Многие скажут Вам твердое «нет» — средняя производительность программистов и пользователей снижалась с каждым новым шагом технологий вперед.»
                              Можно увидеть не голословное утверждения никому неизвестных МЫ, а хоть какое-то подобие исследований? Спасибо.
                                +3
                                В последнее время реально отдыхаю от ООП — взял Arduino и вспоминаю старые добрые времена, когда мало памяти и обычные процедурные программы…
                                  +2
                                  Ой, пожалуйййййста.
                                  Как будет время.
                                  Добавьте в статейку схемы, картинки, образы, примеры.
                                  Заранее спасибо. )
                                    0
                                    Немного добавил, но если честно, то уже надоело искать как НЕ НУЖНО и обсасывать плохие методы и хочется сосредоточиться на том, как нужно. Чем и займемся.
                                    +11
                                    Софизм и вода. Одни голословные утверждения.
                                      –4
                                      В статье не вижу голословность.
                                        +2
                                        Многие скажут Вам твердое «нет» — средняя производительность программистов и пользователей снижалась с каждым новым шагом технологий вперед.

                                        И для этого есть ряд объективных причин. [далее не раскрывается каких]

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

                                        Переосмыслили ООП и паттерны лишь единицы, другие взяли бездумно.



                                          0
                                          Да, стиль изложения у него такое. Но автор конкретно сказал, в чем чего не хватает, где какие неудобства. Грид без пейджинга, динамический комбо-бокс с картинками, главное меню, и многое другое. Я не утверждаю что автор во всем прав. Просто он, как любой другой индивидуум, сказал свое мнение, и не надо его винить для этого.
                                            0
                                            «конкретно сказал» === «голословные утверждения».

                                            Просто он, как любой другой индивидуум, сказал свое мнение, и не надо его винить для этого.

                                            Так а зачем автор выложил это сюда, если он просто сказал «своё мнение», не желая услышать ничего в ответ? Выложил бы у себя в уютненькой и отключил комментарии тогда.
                                              0
                                              А какое мнение кроме своего я должен выражать? Если бы «не желал слушать ничего в ответ», то как раз выложил бы в уютненькой. Но я хочу услышать конкретику: приведите пример, где нельзя обойтись от гридов с пейджингом, как разработать интерактивный GUI на базе REST? и так далее.
                                                0
                                                Вы выстроили у себя в голове определённые стереотипы в рамках которых, действительно, пейджеры в гридах есть зло коих мало. И сейчас вы считаете, что у меня есть пример, который бы в тар-тарары опровергал идею того, что с гридом нужно использовать только автопогружаемый контент.

                                                Эй-ей-ей! Подождите! Что-то не то… Так ведь это же не я должен приводить пример, когда от чего-то нельзя отказаться, да это же Вы должны показать целесообразность использования нового подхода и определить нишу его использования! Ведь Ваше предложение голословно, а я только указываю на это!

                                                По GUI тоже самое. Я знаю уйму приложений на основе REST. И они успешны. Даже очень. На сколько они подходят под ваше понимание «интерактивности», я не знаю. Я бы предложил Вам показать примеры «интерактивных GUI на базе RPC», и сравните оба подхода, чтобы стало видно плюсы и синусы соответствующих технологий в разрезе создания «Интерактивных GUI».
                                                  0
                                                  Все современные широко используемые GUI так или иначе имеют состояние, на примерах всем известных: GMail, GoogleDocuments, Office360, Facebook, Амазон и т.д.
                                                  Почти на голом REST работает Википедия, ЖЖ, ну и блоги в общем. А прикладные приложения ориентированные на работу с данными, о которых я и пишу, и на этом несколько раз акцентировал, не могут обойтись без состояний. Ну сами подумайте, жесткий REST требует отсутствие зависимости каждого следующего вызова от предыдущих, состояние не должно сохраняться ни на клиенте (между страницами), ни на сервере (между http запросами). Единственный выход в этом случае — гонять состояние в качестве параметра формы, как это в ASP.NET сделал Майкрософт, но любителей Viewstate я встречаю все меньше и меньше.
                                                    0
                                                    Отказаться от соответствия «страница» = «отображение объекта или их списка». Можно даже без аяксов — через фреймы. Нарушит ли это REST?
                                      +1
                                      Смысл авторского сообщения до меня не дошел. Может стоит читать статью наоборот?
                                        +2
                                        Главное меню — забыть как страшный сон! Этот атавизм от оконных приложений в вебе не имеет права на жизнь.

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

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

                                        Очень хочется увидеть в статье скриншоты, схемы.
                                          –1
                                          Имеется в виду «Файл, Правка, Вид, Инструменты, Помощь...». МсОфис отказался от главного меню, и многие оконные приложения следуют его примеру, т.к. найти что-то в трехуровневых списках из десятков пунктов очень сложно. Гугл почти везде обошелся без них, ну в гугл-документсах, правда осталось, но ни кто им там не пользуется, все функции доступны более простыми способами. В вебе это не прижилось потому, что всегда кнопки с функциями, применимыми к каждому конкретному месту, находятся прямо рядом с местом применения.
                                          +2
                                          Вода. Так долго рассказывали про историю, проблемы и перспективы экранных интерфейсов. А в заключении вы нарисовали цветные кнопочки, табы, и комбобоксы. И что это было? Причём здесь развитие экранных веб-интерфейсов?
                                            0
                                            Так вот и я подумал про Web-интерфейсы, про что и написал выше.
                                            +2
                                            > а многие программисты, вслед за ними, отучились от реализации полноценного управления приложением с помощью клавиатуры.

                                            Да, это трагедия. До сих пор пишу один за другим фичреквесты в пробегавший дней пять назад на Хабре wordsteps.com. Мышиный интерфейс сразу сделали, а клавиатурный всё до ума не доведут. Надо им каждую мелочь подсказывать, как будто сами клавиатуру никогда не видели и не знают как с ней работать, а сайт пишут мышкой.
                                              0
                                              Многие (включая меня) клавиатурой пользуются только для ввода текста/кода, а не управления (за редким исключением). Одна из причин — мышкой владеют «слепо», а клавиатурой — нет.
                                              0
                                              а что за интерфейс на картинке?
                                                0
                                                Это просто эскиз, кое-какие контролы там могут быть иллюстративны к статье, но более точные иллюстрации готовлю.
                                                +2
                                                Честно говоря, мне заметка не очень понравилась. Как-то всё в одной куче: дизайн, ООП, Rest, HTML, компоненты, размышления о свободе. Каждая из затронутых тем достаточно сложна, чтобы рассматривать её отдельно.

                                                Если и хотелось говорить обо всём сразу, то, мне кажется, стоило соблюсти разделение:

                                                1. Юзабилити продукта: методы определения необходимых функций продукта, особенноси использования (знакомы ли пользователи с мышью), методы тестирования готового интерфейса.

                                                2. Эстетические особенности интерфейса: что сейчас модно, какие решения популярны.

                                                3. Обзор компонентов интерфейса: чем вредно главное меню, в чём плюсы комбо-бокса, в чём минуса «горячих клавиш» и т. п.

                                                4. Выбор технологи: особенности Flash, HTML, Swing, Qt и т.п.

                                                5. Выбор деталей реализации: особенности Rest, особенности SWT и Swing, особенности viewstate и т. д.

                                                6. Выбор языка и стиля программирования: особенности Java, C#, Ruby, критерии применимости ООП и ФП.

                                                Ну и, конечно, очень не хватает ссылок на исследования. Заявления вроде «комбо-бокс ужасен и по дизайну», «атавизм от оконных приложений» — голословны. У всех свои вкусы. Если хочется сделать настолько общее утверждение, то стоит либо провести исследование, либо сослаться на чью-либо работу.
                                                  +1
                                                  По комбобоксу — это вроде-бы общеизвестно, под разными браузерами и разными ос он показывается очень по-разному и CSS-ом его не отстилизовать как хочется.
                                                  комбобокс
                                                  С комбобоксом остается одно — написать его с помощью DIV, CSS и JS
                                                    0
                                                    Думаю для большого приложения стилизация комбобокса не сильно повлияет на удобство.

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

                                                    И группы тоже есть: ...

                                                    Может я не прав, но мне кажется, что хороший, удорбный и понятный интерфейс можно сделать и из стандартных контролов. Бывает так, что прототип приложения в Axura, Visio,… выглядит гораздо приятнее, понятнее и лаконичнее чем в финальном виде, когда вместо стандартных элементов появились кастомные.
                                                  0
                                                  Попробуйте открыть для себя extjs. Штука не совсем простая (точнее, непривычная после обычных сайтов), но отлично справляется с реализацией десктопных контролов (гридам уделено особое внимание, в том числе и в плане редактирования на лету)
                                                    +4
                                                    Вот за использование extjs с его типа десктопными rich элементами надо бить канделябром. Веб это не десктоп. Использование в нем таких элементов тупик в чистом виде.
                                                      +1
                                                      Почему тупик? Если речь о приложении, которое должно быть похоже на десктопный аналог, то использование подобных библиотек — самый простой и, в принципе, правильный путь.
                                                      Понятно, что на классических страницах, контролы extjs стоит использовать осторожно, но если изначально строить приложение, заменяющее десктоп, то максимальная близость к виндовм компонентам это только плюс. Представьте аналог 1с бухгалтерии или какой-то десктопной crm, что работает на тонком клиенте. Веб это ж не только сайты.
                                                        0
                                                        Потому что это неродная для веба парадигма.
                                                          +2
                                                          Не для веба, а для сайтов. А для SaaS решений вполне нормальное решение делать софт с интерфейсом от десктопного, чтобы разница для пользователей была минимальная.
                                                            0
                                                            Плохое это решение. Как правило люди не переосмысляют интерфейс. А у нас тут было так в десктопе, пусть тут так же будет, работает же. А между тем можно сделать лучше и удобнее именно под веб.
                                                            0
                                                            Из вики
                                                            Изначально язык HTML был задуман и создан как средство структурирования и форматирования документов без их привязки к средствам воспроизведения (отображения).… Однако современное применение HTML очень далеко от его изначальной задачи.… С течением времени, основная идея платформонезависимости языка HTML была отдана в своеобразную жертву современным потребностям в мультимедийном и графическом оформлении.

                                                            Подавляющее большинство сайтов/веб-приложений используют неродную для веба парадигму?
                                                              0
                                                              Веб-приложения по своей сути stateless. Добавление туда элементов statefull приложения и поведения ломает это.
                                                                +1
                                                                Когда-то они были стейтлесс из-за сильного несовершенства технологий (рич-приложения в вебе невозможно было создать ни программно, ни аппаратно), сейчас они с элементами (иногда и полностью) стейтфулл из-за совершенствования программных технологий, но недостаточного совершенства аппаратных — гонять по сети полное состояние заметно медленнее и дороже, чем локально. Возможно, когда-то разница на практике заметна не будет и мы опять перейдём к тру стейтлесс. Но сейчас такое приложение будет либо малофункционально, либо сложно в разработке и медленно в работе.
                                                          0
                                                          Кстати, да. Посмотрел я этот ExtJS и решил, что постараюсь всячески избегать его и обходиться без него как можно дольше.
                                                          0
                                                          Щупали. ExtJS не единственный, есть еще библиотеки DHTMLX и другие. Авторы поработали конечно много и тяжко, это видно. Но в вебе есть все же своя специфика, уж слишком они косят под винформз. Ну и еще не маловажный фактор — оно же и весит прилично, и все это мелкие файлы. Грузится весь этот табун ресурсов не на один комп еще терпимо, но когда один сервер начинают атаковать по 100 http гетов при открытии каждой страницы, это не очень приятно.
                                                            0
                                                            Та ну, 100 запросов это отладочная версия. На продакшене используется собранную в 1-2 файла версию с теми компонентами, что реально используете и хорошо это дело кешируете. Получается очень быстро, времени потребует разве что стартовая загрузка (но если сжать js, то там не такие и страшные объемы).
                                                            Да и на сайтах этого применять не стоит, только в веб-приложениях, которые практически всегда какое-то время тратят на загрузку.
                                                              0
                                                              Для веб-приложений можно согласиться, но с оговоркой, чтобы библиотека контрллов не навязывала нам форматы данных. Например, грид или комбик жестко хочет серверную сторону, т.к. JSON или XML у них специфический, а если я хочу запитывать грид с помощью CSV — то уже не могу. Хочется, чтобы контролы поддерживали оба случая: и родной серверный хендлер и локальное API, если я передал данные в своем JSON формате и из них уже в браузере хочу популировать грид.
                                                                0
                                                                Вроде как наоборот, стандартизация это хорошо. Я, например, благодарен, что нельзя кормить контролы через csv или вообще свой формат. Вернее можно, но с кучей велосипедов. Благодаря этому, разработчиков не нужно отдельно пинать на предмет следования общепринятым стандартам. И еще json и xml в данном случае это ограничения языка.
                                                                  0
                                                                  Так если контролы напрямую обращаются на сервер обходя js-приложение, запущенное в браузере, то очень затруднена пред- и пост- обработка, навешивание бизнес-логики и многое другое. Некоторые такие библиотеки еще и структуру базы данных навязывают, это не так уж плохо, но приемлемо только в случаях, когда мы гоним типовые решения, а специальный/уникальный софт на таком не написать.
                                                                    0
                                                                    Не понимаю, в чем сложность сформировать на сервере ответ в нужном формате? Когда обычный html на сервере генерите, тоже расстраиваетесь что там какие-то теги надо использовать, а не ваш собственный формат?
                                                                      0
                                                                      Поясню на примере, когда контрол инкрементного поиска хочет передать строку на сервер и получить варианты ответов, то серверный хендлер этого контрола генерирует, например [«Казань»,«Киев»,«Красноярск»...], а мне теперь нужно возвращать еще и население в каждом городе и идентификатор [{«Id»: 37, «Name»: «Казань», «Population»: 1143}, {«Id»: 59, «Name»: «Киев», «Population»: 2800}, {«Id»: 12, «Name»: «Красноярск», «Population»: 974}] или из городов на «К» мы возвращаем первых 10 с наибольшим населением, и передаем еще общее количество начинающихся на «К», да еще и сгруппированных по каждой стране: {«TotalCount»: 432, «Top10»: [{«Id»: 37, «Name»: «Казань», «Population»: 1143}, {«Id»: 59, «Name»: «Киев», «Population»: 2800}, {«Id»: 12, «Name»: «Красноярск», «Population»: 974},… ], «GroupedByCountry»: [{«Country»: «Россия», «Count»: 42}, {«Country»: «Украина», «Count»: 21}, {«Country»: «Уругвай», «Count»: 3}… ]} Приучить комбобокс к такому формату сложно, лучше, если наша программа будет его получать и популировать комбобокс уже на клиенте.
                                                                        0
                                                                        В extjs есть хуки=) Получили от сервера данные, вызвали функцию обработки, чтобы данные преобразовала как нужно и все нормально. А еще можно повесить обработчики на отрисовку, т.е. получаете данные, и при отображении каждой ячейки/элкмента можете их как-то преобразовать.
                                                                          0
                                                                          А собирать справочники с нескольких хендлеров? Или, для уменьшения количества AJAX-обращений, склеить несколько хендлеров, например все справочники присылаются одним запросом, а на клиенте разбрасываются по контролам. Ну есть много вещей, в которых нужна гибкость. Хорошо, когда есть готовый формат, он покроет 80% задач, но при необходимости нужно иметь возможность отойти от принятого подхода, например, на клиенте популировать гриды и комбобоксы.
                                                                            0
                                                                            В extjs можно не пользоваться стандартными запросами для контролов. Можно сделать просто ajax запрос, получить нужные данные, растасовать по контролам и вызвать функции перерисовки. Но так делать строго не рекомендуется.
                                                                            Отдельные запросы для отдельных кусов данных это важное преимущество систем, подобных extjs и этим нужно пользоваться, чтобы минимизировать ожидание пользователя. Т.е. Один ajax вызов на один контрол это правильно и так по-умолчанию, без костылей и работает. Для того, чтобы при первой загрузке приложения уменьшить число запросов, можно нужный json прямо в теле страницы передать. Если в рамках одной формочки несколько выпадающий списков, которые имеет смысл генерировать на основе данных, получаемых одним запросом, то имеет смысл использовать хуки, как я описал выше. Главное, без фанатизма (например, пропускания всех получаемых данных через функцию распределения по контролам, даже если они логически не связаны).
                                                                              0
                                                                              Если возможность есть, то это правильно, ведь случаи разные бывают, еще пример: контролы, которые реагируют на серверные события, то есть — данные меняются на сервере и приходит по комету уведомление и новый кусок данных — нужно сразу перерисовать грид или комбобокс перезаполнить.
                                                          +4
                                                          Статья напоминает треп на лавочке… Затронуто много всего, но ничего конкретно. Прочитал, а ощущение пустоты осталось.

                                                          Проблема человеко-машинных интерфейсов — это такаааая проблема. Про нее стоооолько книг написано. А перенос десктопных интерфейсов в веб — вообще беда. И альтернативы интерфейсов приживаются сложно, ибо привычка. Посмотрите, например, Zoom world, Ubiquity, старинный Canon Cat. Пока у нас есть клавиатура и мышь, будут одни проблемы. Когда появится нормальный голосовой интерфейс, будут другие проблемы. Мозговой — третьи… Но так как человек — существо высокоадаптивное, он будет пользоваться тем, что есть, стараться делать что-то лучшее, иногда иное, и все время будут проблемы.
                                                            +1
                                                            Поддержу. Не надо придумывать сферический интерфейс в вакууме, ибо его удобство зависит от кучи факторов. На вскидку:
                                                            1) используемое железо (тачскрин, клавиатура, разрешение экрана и тп)
                                                            2) привычный стиль работы пользователя
                                                            3) решаемая задача
                                                            человек — существо высокоадаптивное, он будет пользоваться тем, что есть

                                                            Я бы все-таки предпочел, чтобы высоко адаптивным был интерфейс.
                                                              0
                                                              О! Я бы тоже. Но таких, к сожалению, пока не встречал…
                                                            +2
                                                            В статье есть ряд полезных замечаний, но: «повысилась ли скорость работы потребителей прикладных программ, пользователей и операторов ввода?» — да, повысилась. Следует также иметь в виду, что меньшей «кровью» пользователи теперь решают более сложные задачи.
                                                              0
                                                              Таки ссылки на исследования будут или так же как в самом топике?

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

                                                              Кто рассудит?
                                                                0
                                                                Заказываю исследование в специальной конторе, не шучу.
                                                                  0
                                                                  Будь у меня исследование, я бы написал топик. Говорю по личному опыту и опыту знакомых, а также из эмпирических соображений. Если бы можно было повысить производительность труда, выбросив из офиса все мышки, уже нашлась бы фирма, которая за несколько лет не стала бы вторым «Майкрософтом» только потому, что эту идею трудно запатентовать и её переняли бы все остальные.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  +2
                                                                  Критика статьи:

                                                                  — При чем тут ООП?
                                                                  — REST — это не просто хорошо, а сверх-хорошо. Только надо уметь его применять
                                                                    0
                                                                    C автором полностью согласен. В єтом направлении движемся товарищи. Я думал я один такой, а оказывается нет =)
                                                                    Пост написан так, что и без картинок понятен, ну может, понятен тем кто создает интерфейсы…
                                                                      0
                                                                      Дублирование кнопок действия для каждой строки грида — это общая проблема всех веб-интерфейсов старого поколения — в глазах рябит.

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

                                                                          Основная причина появления «ряби в глазах» — необходимость определения номера или ид строки над которой совершается действие для передачи его серверу. Раньше определить его динамически было затруднительно (машины слабые, js вообще и работа с dom в частности медленные, кроссбраузерность не на высоте и т. п.), приходилось привязывать статически. Сейчас (почти всегда) это особого труда не составит.
                                                                            0
                                                                            Теперь вопрос в том, что некоторые личности имеют наработки и не хотят их переделывать.
                                                                              +1
                                                                              Так этим надо пользоваться и выводить на рынок свои ;)
                                                                          0
                                                                          > картинку для медитаций убрал, она Вам не нравится, я чувствую
                                                                          А я думал меня проглючило… Медитировал себе, медитировал… Моргнул глазом, а картинку как ветром сдуло.
                                                                            0
                                                                            Раньше сидело 0.1% человечества, а уже 50%, вот и все.
                                                                              +1
                                                                              Всё, теперь гмеёл залипает свою панельку ;)
                                                                                0
                                                                                И при просмотре писем справа список адресатов залепает, но таким же образом им нужно прилеплять еще левое меню ярлыков (Inbox, Drafts, Sent). Если уж так все начнет залипать, то не проще ли прокрутку сделать только для рабочей области (таблица и тело писем). Они занимаются латанием дыр, интерфейс gmail давно устарел и пришел в бессистемность.

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

                                                                              Самое читаемое