Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
Сори, первые несколько минут статья опубликовалась в несколько порванном формате, без части абзацев, из-за форматирования. Сейчас все ок.
Сегодня я сломал мышь. Не могу не согласиться с некоторыми пунктами.
Я бы не был так категоричен, все зависит от конкретной реализации интерфейса и задач. Тот же пейджинг в приложениях подобных твиттеру, где данные представляют из себя поток, вполне можно заменить скроллингом с подгрузкой, но в приложениях для бизнеса, где таблица — это просто какой-то набор данных — пэйджинг будет лучшим вариантом. Инлайн редактирование часто невозможно, или еще больше нагромождает интерфейс таблицы. Свой скролбар у некоторых элементов вполне оправдан и при грамотном оформлении не вызывает отвращения.
Если в выборке для бизнес-приложения более 200 записей с цифрами и подробностями, то человек не сможет их вычитать все равно, это значит, что нужно давать человеку количество и какие-то статистические характеристики, например: найдено 9201 продуктов таког-то бренда и 6288 другого, в таком-то ценовом диапазоне 2503 экземпляров, в такой-то области 71022 объекта и т.д. Потом человек нажмет там уточнения и получит фильтр более узкий, вот пример — www.alibaba.com/products/hdd/--711001.html
>>Если в выборке для бизнес-приложения более 200 записей с цифрами и подробностями, то человек не сможет их вычитать все равно
Много раз слышал это мнение, тем не менее уверился в обратном. Типовой кейс таков: огромная таблица, хоть на 100 000 записей. Юзеру удобнее отсортировать ее кликом по заголовку грида а затем быстренько пролистать в нужное место чем что-то вбивать в фильтры.
Много раз слышал это мнение, тем не менее уверился в обратном. Типовой кейс таков: огромная таблица, хоть на 100 000 записей. Юзеру удобнее отсортировать ее кликом по заголовку грида а затем быстренько пролистать в нужное место чем что-то вбивать в фильтры.
Тоже к этому пришел. Особенно это касается тач-интерфейсов: никого не испугать длинной портянкой с информацией — человеку гораздо проще промотать до нужного места, нежели тыкать по кнопкам или в экранную клавиатуру или пробираться сквозь десять экранов.
Наверно я лентяй, но меня постоянно охватывает чувство впустую растрачиваемого времени когда приходится что-то искать глазами. А когда таблица не умещается на страницу — вообще кошмар.
При использовании фильтров в разы сокращается расход времени на то чтобы убедиться в отсутствии в таблице какой-либо информации.
При использовании фильтров в разы сокращается расход времени на то чтобы убедиться в отсутствии в таблице какой-либо информации.
Вы человек и вам так удобнее (: В справочнике своей компании я тоже использую фильтр, но когда мы его (справочник) создавали и тестировали — почти 300 человек и камера — оказалось что 86% людей сортируют его как им удобно и просто проматывают. И это при том, что фильтр находился в верху в самом видном месте и назывался «Быстрый поиск по справочнику». Цифра, я помню, меня тогда поразила… Правда потом мы проводили опрос и уже только 38% процентов сотрудников ответило, что не пользуются быстрым поиском.
Дайте догадаюсь — наверное вам лень отрывать руки от клавиатуры, чтобы кликать сортировку и скроллить мышью на скроллбаре? :)
Фильтры можно подсказывать, а не набирать руками, я давал ссылку с примером, который мне понравился (Alibaba.com), вот скриншот: 
Вот «быстренько пролистать в нужное место» среди 100 000 записей как-то не верится. Сортировка — согласен, она тут очень даже причем. Может быть реальный случай, когда в выборке из 100 000 записей одним кликом по заголовку (с целью сортировки) мы сразу получаем несколько интересующих нас записей в зоне видимости (10-20 записей). Но пейджинг то тут не особо нужен. Можно из больших выборок показывать первые 50-100 записей и давать возможность сортировки ASC/DESC.
да запросто. PageUp/PageDown отлистывает очень быстро. Лишь бы софт не подтормаживал.
да, это кажется странным и неудобным, но действительно так делают многие. Я тоже как-то анализировал логи своего софта, в котором достаточно много работы с большими справочниками. Так вот фильтрами пользуются очень редко.
Делать пэйджинг в табличноориентированном софте — значит профакапить часть рынка конкуррентам с более привычным интерфейсом
вообще пэйджинг был придуман для экономии ресурсов веб-серверов, но никак не для повышения юзабилити
да, это кажется странным и неудобным, но действительно так делают многие. Я тоже как-то анализировал логи своего софта, в котором достаточно много работы с большими справочниками. Так вот фильтрами пользуются очень редко.
Делать пэйджинг в табличноориентированном софте — значит профакапить часть рынка конкуррентам с более привычным интерфейсом
вообще пэйджинг был придуман для экономии ресурсов веб-серверов, но никак не для повышения юзабилити
Если софт не тормозит, записи расположены, например, по алфавиту или дате-времени более-менее равномерно, то в нужное место при 100 000 записях при некоторой сноровке попадаешь быстро, просто перетаскивая ползунок скроллбара в нужное место.
По виртуальному скролу пример:
www.trirand.com/blog/jqgrid/jqgrid.html
-> New in version 3.7 -> Virtual scrolling
Ну чем не решение для бизнесапликейшенов?
www.trirand.com/blog/jqgrid/jqgrid.html
-> New in version 3.7 -> Virtual scrolling
Ну чем не решение для бизнесапликейшенов?
если кому-то интересно
Конечно!
В общем, REST — это не наш путь, для пользовательских интерфейсов и приложений баз данных состояние нужно как воздух
А когда состояние интерфейса хранится локально, а данные для отображения в нём на сервере, стэйтлесс? Ну, максимум, 304 Not Modified?
Мне кажется, HTML рано или поздно отомрет для интерактивных приложений: слишком много сложностей при подгоне под разные браузеры. Постоянно что-то разъезжается, слетает выравнивание и маржины, тормозит на ие7, 8 и айпаде. 50% процентов времени проводишь за проверкой и поднманием отломавшегося. Тестирование нетривиально и требует виртуальных машин, чтобы держать разные версии браузеров.
Предсказуемость обеспечивает только flex, sl и java. На них и нужно ориентироваться.
Предсказуемость обеспечивает только flex, sl и java. На них и нужно ориентироваться.
Да ладно: HTML только начинает набирать обороты =)
А «вольности», которые доступны разработчикам интерфейсов на fl/sl, иногда играют против пользователя.
А «вольности», которые доступны разработчикам интерфейсов на fl/sl, иногда играют против пользователя.
Я могу ошибаться, но ИМХО пока «набирание» идёт в сторону «хотим всё, что есть в окошках но в браузере»: доступ к клавиатуре, local storage, попиксельный доступ, звук, видео и т.д. В свете этого непонятны выпады про «свобода играет против» и «слишком большие возможности — зло».
При этом имеется зоопарк броузеров, каждая версия со своим мнением по рендерингу и, извините, весьма небыстрый js.
Имеем то, что имеем: разработка более трудоёмка в разы, в doom погонять можно, но на строго определённых версиях строго определнных браузеров и на 30fps в малюсеньком окошке, что является большим достижением для веб-приложений.
При этом имеется зоопарк броузеров, каждая версия со своим мнением по рендерингу и, извините, весьма небыстрый js.
Имеем то, что имеем: разработка более трудоёмка в разы, в doom погонять можно, но на строго определённых версиях строго определнных браузеров и на 30fps в малюсеньком окошке, что является большим достижением для веб-приложений.
Судя по оформлению статьи, автор все же поклоник текстового интерфейса.
это просто взгляд «не дизайнера»
«Многие скажут Вам твердое «нет» — средняя производительность программистов и пользователей снижалась с каждым новым шагом технологий вперед.»
Можно увидеть не голословное утверждения никому неизвестных МЫ, а хоть какое-то подобие исследований? Спасибо.
Можно увидеть не голословное утверждения никому неизвестных МЫ, а хоть какое-то подобие исследований? Спасибо.
В последнее время реально отдыхаю от ООП — взял Arduino и вспоминаю старые добрые времена, когда мало памяти и обычные процедурные программы…
Ой, пожалуйййййста.
Как будет время.
Добавьте в статейку схемы, картинки, образы, примеры.
Заранее спасибо. )
Как будет время.
Добавьте в статейку схемы, картинки, образы, примеры.
Заранее спасибо. )
Софизм и вода. Одни голословные утверждения.
В статье не вижу голословность.
Многие скажут Вам твердое «нет» — средняя производительность программистов и пользователей снижалась с каждым новым шагом технологий вперед.
И для этого есть ряд объективных причин. [далее не раскрывается каких]
Разработка и тестирование усложнилось, появилось много асинхронных событий, таймерных, серверных, сигналов от других окон и приложений. Среда (окружение) информационной системы стало менее стабильным и предсказуемым.
Переосмыслили ООП и паттерны лишь единицы, другие взяли бездумно.
Да, стиль изложения у него такое. Но автор конкретно сказал, в чем чего не хватает, где какие неудобства. Грид без пейджинга, динамический комбо-бокс с картинками, главное меню, и многое другое. Я не утверждаю что автор во всем прав. Просто он, как любой другой индивидуум, сказал свое мнение, и не надо его винить для этого.
«конкретно сказал» === «голословные утверждения».
Так а зачем автор выложил это сюда, если он просто сказал «своё мнение», не желая услышать ничего в ответ? Выложил бы у себя в уютненькой и отключил комментарии тогда.
Просто он, как любой другой индивидуум, сказал свое мнение, и не надо его винить для этого.
Так а зачем автор выложил это сюда, если он просто сказал «своё мнение», не желая услышать ничего в ответ? Выложил бы у себя в уютненькой и отключил комментарии тогда.
А какое мнение кроме своего я должен выражать? Если бы «не желал слушать ничего в ответ», то как раз выложил бы в уютненькой. Но я хочу услышать конкретику: приведите пример, где нельзя обойтись от гридов с пейджингом, как разработать интерактивный GUI на базе REST? и так далее.
Вы выстроили у себя в голове определённые стереотипы в рамках которых, действительно, пейджеры в гридах есть зло коих мало. И сейчас вы считаете, что у меня есть пример, который бы в тар-тарары опровергал идею того, что с гридом нужно использовать только автопогружаемый контент.
Эй-ей-ей! Подождите! Что-то не то… Так ведь это же не я должен приводить пример, когда от чего-то нельзя отказаться, да это же Вы должны показать целесообразность использования нового подхода и определить нишу его использования! Ведь Ваше предложение голословно, а я только указываю на это!
По GUI тоже самое. Я знаю уйму приложений на основе REST. И они успешны. Даже очень. На сколько они подходят под ваше понимание «интерактивности», я не знаю. Я бы предложил Вам показать примеры «интерактивных GUI на базе RPC», и сравните оба подхода, чтобы стало видно плюсы и синусы соответствующих технологий в разрезе создания «Интерактивных GUI».
Эй-ей-ей! Подождите! Что-то не то… Так ведь это же не я должен приводить пример, когда от чего-то нельзя отказаться, да это же Вы должны показать целесообразность использования нового подхода и определить нишу его использования! Ведь Ваше предложение голословно, а я только указываю на это!
По GUI тоже самое. Я знаю уйму приложений на основе REST. И они успешны. Даже очень. На сколько они подходят под ваше понимание «интерактивности», я не знаю. Я бы предложил Вам показать примеры «интерактивных GUI на базе RPC», и сравните оба подхода, чтобы стало видно плюсы и синусы соответствующих технологий в разрезе создания «Интерактивных GUI».
Все современные широко используемые GUI так или иначе имеют состояние, на примерах всем известных: GMail, GoogleDocuments, Office360, Facebook, Амазон и т.д.
Почти на голом REST работает Википедия, ЖЖ, ну и блоги в общем. А прикладные приложения ориентированные на работу с данными, о которых я и пишу, и на этом несколько раз акцентировал, не могут обойтись без состояний. Ну сами подумайте, жесткий REST требует отсутствие зависимости каждого следующего вызова от предыдущих, состояние не должно сохраняться ни на клиенте (между страницами), ни на сервере (между http запросами). Единственный выход в этом случае — гонять состояние в качестве параметра формы, как это в ASP.NET сделал Майкрософт, но любителей Viewstate я встречаю все меньше и меньше.
Почти на голом REST работает Википедия, ЖЖ, ну и блоги в общем. А прикладные приложения ориентированные на работу с данными, о которых я и пишу, и на этом несколько раз акцентировал, не могут обойтись без состояний. Ну сами подумайте, жесткий REST требует отсутствие зависимости каждого следующего вызова от предыдущих, состояние не должно сохраняться ни на клиенте (между страницами), ни на сервере (между http запросами). Единственный выход в этом случае — гонять состояние в качестве параметра формы, как это в ASP.NET сделал Майкрософт, но любителей Viewstate я встречаю все меньше и меньше.
Смысл авторского сообщения до меня не дошел. Может стоит читать статью наоборот?
Главное меню — забыть как страшный сон! Этот атавизм от оконных приложений в вебе не имеет права на жизнь.
Не могу согласиться, оно нужно. Я имею в виду обязательные 3-5 пунктов. Пользователь должен знать, что есть простое основное меню, откуда он попадёт куда ему нужно.
Если Вы имели в виду, что куча разрозненных меню лучше, это не самый хороший вариант. Пользователь не может привыкнуть к куче разбросанных менюшек по хэдеру, сайдбарам, футеру. Особенно, если там пара десятков пунктов.
Очень хочется увидеть в статье скриншоты, схемы.
Имеется в виду «Файл, Правка, Вид, Инструменты, Помощь...». МсОфис отказался от главного меню, и многие оконные приложения следуют его примеру, т.к. найти что-то в трехуровневых списках из десятков пунктов очень сложно. Гугл почти везде обошелся без них, ну в гугл-документсах, правда осталось, но ни кто им там не пользуется, все функции доступны более простыми способами. В вебе это не прижилось потому, что всегда кнопки с функциями, применимыми к каждому конкретному месту, находятся прямо рядом с местом применения.
Вода. Так долго рассказывали про историю, проблемы и перспективы экранных интерфейсов. А в заключении вы нарисовали цветные кнопочки, табы, и комбобоксы. И что это было? Причём здесь развитие экранных веб-интерфейсов?
Так вот и я подумал про Web-интерфейсы, про что и написал выше.
> а многие программисты, вслед за ними, отучились от реализации полноценного управления приложением с помощью клавиатуры.
Да, это трагедия. До сих пор пишу один за другим фичреквесты в пробегавший дней пять назад на Хабре wordsteps.com. Мышиный интерфейс сразу сделали, а клавиатурный всё до ума не доведут. Надо им каждую мелочь подсказывать, как будто сами клавиатуру никогда не видели и не знают как с ней работать, а сайт пишут мышкой.
Да, это трагедия. До сих пор пишу один за другим фичреквесты в пробегавший дней пять назад на Хабре wordsteps.com. Мышиный интерфейс сразу сделали, а клавиатурный всё до ума не доведут. Надо им каждую мелочь подсказывать, как будто сами клавиатуру никогда не видели и не знают как с ней работать, а сайт пишут мышкой.
а что за интерфейс на картинке?
Честно говоря, мне заметка не очень понравилась. Как-то всё в одной куче: дизайн, ООП, Rest, HTML, компоненты, размышления о свободе. Каждая из затронутых тем достаточно сложна, чтобы рассматривать её отдельно.
Если и хотелось говорить обо всём сразу, то, мне кажется, стоило соблюсти разделение:
1. Юзабилити продукта: методы определения необходимых функций продукта, особенноси использования (знакомы ли пользователи с мышью), методы тестирования готового интерфейса.
2. Эстетические особенности интерфейса: что сейчас модно, какие решения популярны.
3. Обзор компонентов интерфейса: чем вредно главное меню, в чём плюсы комбо-бокса, в чём минуса «горячих клавиш» и т. п.
4. Выбор технологи: особенности Flash, HTML, Swing, Qt и т.п.
5. Выбор деталей реализации: особенности Rest, особенности SWT и Swing, особенности viewstate и т. д.
6. Выбор языка и стиля программирования: особенности Java, C#, Ruby, критерии применимости ООП и ФП.
Ну и, конечно, очень не хватает ссылок на исследования. Заявления вроде «комбо-бокс ужасен и по дизайну», «атавизм от оконных приложений» — голословны. У всех свои вкусы. Если хочется сделать настолько общее утверждение, то стоит либо провести исследование, либо сослаться на чью-либо работу.
Если и хотелось говорить обо всём сразу, то, мне кажется, стоило соблюсти разделение:
1. Юзабилити продукта: методы определения необходимых функций продукта, особенноси использования (знакомы ли пользователи с мышью), методы тестирования готового интерфейса.
2. Эстетические особенности интерфейса: что сейчас модно, какие решения популярны.
3. Обзор компонентов интерфейса: чем вредно главное меню, в чём плюсы комбо-бокса, в чём минуса «горячих клавиш» и т. п.
4. Выбор технологи: особенности Flash, HTML, Swing, Qt и т.п.
5. Выбор деталей реализации: особенности Rest, особенности SWT и Swing, особенности viewstate и т. д.
6. Выбор языка и стиля программирования: особенности Java, C#, Ruby, критерии применимости ООП и ФП.
Ну и, конечно, очень не хватает ссылок на исследования. Заявления вроде «комбо-бокс ужасен и по дизайну», «атавизм от оконных приложений» — голословны. У всех свои вкусы. Если хочется сделать настолько общее утверждение, то стоит либо провести исследование, либо сослаться на чью-либо работу.
По комбобоксу — это вроде-бы общеизвестно, под разными браузерами и разными ос он показывается очень по-разному и CSS-ом его не отстилизовать как хочется.
С комбобоксом остается одно — написать его с помощью DIV, CSS и JS
С комбобоксом остается одно — написать его с помощью DIV, CSS и JS
Думаю для большого приложения стилизация комбобокса не сильно повлияет на удобство.
В статье написано, что в комбобоксе нельзя выбрать несколько значений.
Можно: Конечно это уже не будет выпадающий список, но возможность выбрать несколько элементов все же есть.
И группы тоже есть: ...
Может я не прав, но мне кажется, что хороший, удорбный и понятный интерфейс можно сделать и из стандартных контролов. Бывает так, что прототип приложения в Axura, Visio,… выглядит гораздо приятнее, понятнее и лаконичнее чем в финальном виде, когда вместо стандартных элементов появились кастомные.
В статье написано, что в комбобоксе нельзя выбрать несколько значений.
Можно: Конечно это уже не будет выпадающий список, но возможность выбрать несколько элементов все же есть.
И группы тоже есть: ...
Может я не прав, но мне кажется, что хороший, удорбный и понятный интерфейс можно сделать и из стандартных контролов. Бывает так, что прототип приложения в Axura, Visio,… выглядит гораздо приятнее, понятнее и лаконичнее чем в финальном виде, когда вместо стандартных элементов появились кастомные.
Попробуйте открыть для себя extjs. Штука не совсем простая (точнее, непривычная после обычных сайтов), но отлично справляется с реализацией десктопных контролов (гридам уделено особое внимание, в том числе и в плане редактирования на лету)
Вот за использование extjs с его типа десктопными rich элементами надо бить канделябром. Веб это не десктоп. Использование в нем таких элементов тупик в чистом виде.
Почему тупик? Если речь о приложении, которое должно быть похоже на десктопный аналог, то использование подобных библиотек — самый простой и, в принципе, правильный путь.
Понятно, что на классических страницах, контролы extjs стоит использовать осторожно, но если изначально строить приложение, заменяющее десктоп, то максимальная близость к виндовм компонентам это только плюс. Представьте аналог 1с бухгалтерии или какой-то десктопной crm, что работает на тонком клиенте. Веб это ж не только сайты.
Понятно, что на классических страницах, контролы extjs стоит использовать осторожно, но если изначально строить приложение, заменяющее десктоп, то максимальная близость к виндовм компонентам это только плюс. Представьте аналог 1с бухгалтерии или какой-то десктопной crm, что работает на тонком клиенте. Веб это ж не только сайты.
Потому что это неродная для веба парадигма.
Не для веба, а для сайтов. А для SaaS решений вполне нормальное решение делать софт с интерфейсом от десктопного, чтобы разница для пользователей была минимальная.
Из вики
Подавляющее большинство сайтов/веб-приложений используют неродную для веба парадигму?
Изначально язык HTML был задуман и создан как средство структурирования и форматирования документов без их привязки к средствам воспроизведения (отображения).… Однако современное применение HTML очень далеко от его изначальной задачи.… С течением времени, основная идея платформонезависимости языка HTML была отдана в своеобразную жертву современным потребностям в мультимедийном и графическом оформлении.
Подавляющее большинство сайтов/веб-приложений используют неродную для веба парадигму?
Веб-приложения по своей сути stateless. Добавление туда элементов statefull приложения и поведения ломает это.
Когда-то они были стейтлесс из-за сильного несовершенства технологий (рич-приложения в вебе невозможно было создать ни программно, ни аппаратно), сейчас они с элементами (иногда и полностью) стейтфулл из-за совершенствования программных технологий, но недостаточного совершенства аппаратных — гонять по сети полное состояние заметно медленнее и дороже, чем локально. Возможно, когда-то разница на практике заметна не будет и мы опять перейдём к тру стейтлесс. Но сейчас такое приложение будет либо малофункционально, либо сложно в разработке и медленно в работе.
Кстати, да. Посмотрел я этот ExtJS и решил, что постараюсь всячески избегать его и обходиться без него как можно дольше.
Щупали. ExtJS не единственный, есть еще библиотеки DHTMLX и другие. Авторы поработали конечно много и тяжко, это видно. Но в вебе есть все же своя специфика, уж слишком они косят под винформз. Ну и еще не маловажный фактор — оно же и весит прилично, и все это мелкие файлы. Грузится весь этот табун ресурсов не на один комп еще терпимо, но когда один сервер начинают атаковать по 100 http гетов при открытии каждой страницы, это не очень приятно.
Та ну, 100 запросов это отладочная версия. На продакшене используется собранную в 1-2 файла версию с теми компонентами, что реально используете и хорошо это дело кешируете. Получается очень быстро, времени потребует разве что стартовая загрузка (но если сжать js, то там не такие и страшные объемы).
Да и на сайтах этого применять не стоит, только в веб-приложениях, которые практически всегда какое-то время тратят на загрузку.
Да и на сайтах этого применять не стоит, только в веб-приложениях, которые практически всегда какое-то время тратят на загрузку.
Для веб-приложений можно согласиться, но с оговоркой, чтобы библиотека контрллов не навязывала нам форматы данных. Например, грид или комбик жестко хочет серверную сторону, т.к. JSON или XML у них специфический, а если я хочу запитывать грид с помощью CSV — то уже не могу. Хочется, чтобы контролы поддерживали оба случая: и родной серверный хендлер и локальное API, если я передал данные в своем JSON формате и из них уже в браузере хочу популировать грид.
Вроде как наоборот, стандартизация это хорошо. Я, например, благодарен, что нельзя кормить контролы через csv или вообще свой формат. Вернее можно, но с кучей велосипедов. Благодаря этому, разработчиков не нужно отдельно пинать на предмет следования общепринятым стандартам. И еще json и xml в данном случае это ограничения языка.
Так если контролы напрямую обращаются на сервер обходя js-приложение, запущенное в браузере, то очень затруднена пред- и пост- обработка, навешивание бизнес-логики и многое другое. Некоторые такие библиотеки еще и структуру базы данных навязывают, это не так уж плохо, но приемлемо только в случаях, когда мы гоним типовые решения, а специальный/уникальный софт на таком не написать.
Не понимаю, в чем сложность сформировать на сервере ответ в нужном формате? Когда обычный html на сервере генерите, тоже расстраиваетесь что там какие-то теги надо использовать, а не ваш собственный формат?
Поясню на примере, когда контрол инкрементного поиска хочет передать строку на сервер и получить варианты ответов, то серверный хендлер этого контрола генерирует, например [«Казань»,«Киев»,«Красноярск»...], а мне теперь нужно возвращать еще и население в каждом городе и идентификатор [{«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}… ]} Приучить комбобокс к такому формату сложно, лучше, если наша программа будет его получать и популировать комбобокс уже на клиенте.
В extjs есть хуки=) Получили от сервера данные, вызвали функцию обработки, чтобы данные преобразовала как нужно и все нормально. А еще можно повесить обработчики на отрисовку, т.е. получаете данные, и при отображении каждой ячейки/элкмента можете их как-то преобразовать.
А собирать справочники с нескольких хендлеров? Или, для уменьшения количества AJAX-обращений, склеить несколько хендлеров, например все справочники присылаются одним запросом, а на клиенте разбрасываются по контролам. Ну есть много вещей, в которых нужна гибкость. Хорошо, когда есть готовый формат, он покроет 80% задач, но при необходимости нужно иметь возможность отойти от принятого подхода, например, на клиенте популировать гриды и комбобоксы.
В extjs можно не пользоваться стандартными запросами для контролов. Можно сделать просто ajax запрос, получить нужные данные, растасовать по контролам и вызвать функции перерисовки. Но так делать строго не рекомендуется.
Отдельные запросы для отдельных кусов данных это важное преимущество систем, подобных extjs и этим нужно пользоваться, чтобы минимизировать ожидание пользователя. Т.е. Один ajax вызов на один контрол это правильно и так по-умолчанию, без костылей и работает. Для того, чтобы при первой загрузке приложения уменьшить число запросов, можно нужный json прямо в теле страницы передать. Если в рамках одной формочки несколько выпадающий списков, которые имеет смысл генерировать на основе данных, получаемых одним запросом, то имеет смысл использовать хуки, как я описал выше. Главное, без фанатизма (например, пропускания всех получаемых данных через функцию распределения по контролам, даже если они логически не связаны).
Отдельные запросы для отдельных кусов данных это важное преимущество систем, подобных extjs и этим нужно пользоваться, чтобы минимизировать ожидание пользователя. Т.е. Один ajax вызов на один контрол это правильно и так по-умолчанию, без костылей и работает. Для того, чтобы при первой загрузке приложения уменьшить число запросов, можно нужный json прямо в теле страницы передать. Если в рамках одной формочки несколько выпадающий списков, которые имеет смысл генерировать на основе данных, получаемых одним запросом, то имеет смысл использовать хуки, как я описал выше. Главное, без фанатизма (например, пропускания всех получаемых данных через функцию распределения по контролам, даже если они логически не связаны).
Статья напоминает треп на лавочке… Затронуто много всего, но ничего конкретно. Прочитал, а ощущение пустоты осталось.
Проблема человеко-машинных интерфейсов — это такаааая проблема. Про нее стоооолько книг написано. А перенос десктопных интерфейсов в веб — вообще беда. И альтернативы интерфейсов приживаются сложно, ибо привычка. Посмотрите, например, Zoom world, Ubiquity, старинный Canon Cat. Пока у нас есть клавиатура и мышь, будут одни проблемы. Когда появится нормальный голосовой интерфейс, будут другие проблемы. Мозговой — третьи… Но так как человек — существо высокоадаптивное, он будет пользоваться тем, что есть, стараться делать что-то лучшее, иногда иное, и все время будут проблемы.
Проблема человеко-машинных интерфейсов — это такаааая проблема. Про нее стоооолько книг написано. А перенос десктопных интерфейсов в веб — вообще беда. И альтернативы интерфейсов приживаются сложно, ибо привычка. Посмотрите, например, Zoom world, Ubiquity, старинный Canon Cat. Пока у нас есть клавиатура и мышь, будут одни проблемы. Когда появится нормальный голосовой интерфейс, будут другие проблемы. Мозговой — третьи… Но так как человек — существо высокоадаптивное, он будет пользоваться тем, что есть, стараться делать что-то лучшее, иногда иное, и все время будут проблемы.
Поддержу. Не надо придумывать сферический интерфейс в вакууме, ибо его удобство зависит от кучи факторов. На вскидку:
1) используемое железо (тачскрин, клавиатура, разрешение экрана и тп)
2) привычный стиль работы пользователя
3) решаемая задача
Я бы все-таки предпочел, чтобы высоко адаптивным был интерфейс.
1) используемое железо (тачскрин, клавиатура, разрешение экрана и тп)
2) привычный стиль работы пользователя
3) решаемая задача
человек — существо высокоадаптивное, он будет пользоваться тем, что есть
Я бы все-таки предпочел, чтобы высоко адаптивным был интерфейс.
В статье есть ряд полезных замечаний, но: «повысилась ли скорость работы потребителей прикладных программ, пользователей и операторов ввода?» — да, повысилась. Следует также иметь в виду, что меньшей «кровью» пользователи теперь решают более сложные задачи.
Таки ссылки на исследования будут или так же как в самом топике?
Вот я соглашусь с автором. Скорость работы пользователей снизилась, а для решения более сложных задач теперь нужно пол часа вместо пары минут именно из-за графического интерфейса.
Кто рассудит?
Вот я соглашусь с автором. Скорость работы пользователей снизилась, а для решения более сложных задач теперь нужно пол часа вместо пары минут именно из-за графического интерфейса.
Кто рассудит?
Заказываю исследование в специальной конторе, не шучу.
Будь у меня исследование, я бы написал топик. Говорю по личному опыту и опыту знакомых, а также из эмпирических соображений. Если бы можно было повысить производительность труда, выбросив из офиса все мышки, уже нашлась бы фирма, которая за несколько лет не стала бы вторым «Майкрософтом» только потому, что эту идею трудно запатентовать и её переняли бы все остальные.
Критика статьи:
— При чем тут ООП?
— REST — это не просто хорошо, а сверх-хорошо. Только надо уметь его применять
— При чем тут ООП?
— REST — это не просто хорошо, а сверх-хорошо. Только надо уметь его применять
C автором полностью согласен. В єтом направлении движемся товарищи. Я думал я один такой, а оказывается нет =)
Пост написан так, что и без картинок понятен, ну может, понятен тем кто создает интерфейсы…
Пост написан так, что и без картинок понятен, ну может, понятен тем кто создает интерфейсы…
Дублирование кнопок действия для каждой строки грида — это общая проблема всех веб-интерфейсов старого поколения — в глазах рябит.
Согласен. А что вместо этого?
Согласен. А что вместо этого?
Рябит страшно, занимает экран, отвлекает внимание пользователя. Ну почему бы не сделать в гриде «фокус» для строки и прикрутить тулбар?
Всплывающий тулбар при наведении курсора на строку/ячейку или их выделении, обычный тулбар, контекстное меню (дополняющее хотя бы дефолтное браузерное), хоткеи — много вариантов.
Основная причина появления «ряби в глазах» — необходимость определения номера или ид строки над которой совершается действие для передачи его серверу. Раньше определить его динамически было затруднительно (машины слабые, js вообще и работа с dom в частности медленные, кроссбраузерность не на высоте и т. п.), приходилось привязывать статически. Сейчас (почти всегда) это особого труда не составит.
Основная причина появления «ряби в глазах» — необходимость определения номера или ид строки над которой совершается действие для передачи его серверу. Раньше определить его динамически было затруднительно (машины слабые, js вообще и работа с dom в частности медленные, кроссбраузерность не на высоте и т. п.), приходилось привязывать статически. Сейчас (почти всегда) это особого труда не составит.
> картинку для медитаций убрал, она Вам не нравится, я чувствую
А я думал меня проглючило… Медитировал себе, медитировал… Моргнул глазом, а картинку как ветром сдуло.
А я думал меня проглючило… Медитировал себе, медитировал… Моргнул глазом, а картинку как ветром сдуло.
Раньше сидело 0.1% человечества, а уже 50%, вот и все.
Всё, теперь гмеёл залипает свою панельку ;)
И при просмотре писем справа список адресатов залепает, но таким же образом им нужно прилеплять еще левое меню ярлыков (Inbox, Drafts, Sent). Если уж так все начнет залипать, то не проще ли прокрутку сделать только для рабочей области (таблица и тело писем). Они занимаются латанием дыр, интерфейс gmail давно устарел и пришел в бессистемность.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Веб-интерфейсы: развитие или наоборот?