[Rich-клиент] Html vs WinForms(и т.д.)
это просто хост для HTML-я? И почему?масшабируется хреново.
табличку на 10 тыс элементов в html-е мне представить тяжело, а в winforms для virtual grid будет все летать.
и кстати непонятно, как быть, например, с custom контролами? рисовать в изображение, а потом его выводить?
У меня давно сложилось мнение, что таблички на столько элементов не должны использоваться в качестве элемента интерфейса. Если у нас много элементов, первой операцией всегда идет поиск — либо глазами (в случае виртуального грида либо по ключевому слову/префиксу. Второе, как мне кажется, удобнее.
и кстати непонятно, как быть, например, с custom контролами? рисовать в изображение, а потом его выводить?Например, какими?
Довольно часто оказывается, что такие custom control-ы не нужны. Если же нужны, есть сразу несколько ответов, как их делать.
Если у нас много элементов, первой операцией всегда идет поиск — либо глазами (в случае виртуального грида либо по ключевому слову/префиксу. Второе, как мне кажется, удобнее.правильная сортировка + скроллер быстрее выполнить, чем ввод поискового слова
и кстати над вторым надо больше думать, чем над первым.
как минимум:
- windows forms элемент управления, который помещен внутрь html. Таким образом почти все делается на html (в частности, layout). "Магия" делается windows forms
- flash (я знаю, что бяка. Но для некоторых редких случаев (какая-нить сложная мегаанимация, управляемая скриптами и зависящая от действий пользователя) он самый удобный.
- windows forms элемент управления, который помещен внутрь html. Таким образом почти все делается на html (в частности, layout). "Магия" делается windows forms
- flash (я знаю, что бяка. Но для некоторых редких случаев (какая-нить сложная мегаанимация, управляемая скриптами и зависящая от действий пользователя) он самый удобный.
правильная сортировка + скроллер быстрее выполнить, чем ввод поискового словаты когда в Visual Studio пишешь, доволен auto-complete-ом? А это ведь поиск + листинг 2-3 элементов. Предлагается похожая схема вместо скроллинга на 10000 элементов.
и кстати над вторым надо больше думать, чем над первым.
ты когда в Visual Studio пишешь, доволен auto-complete-ом?доволен, но в языке программирования - есть формализованные связи между разными частями информации
в бизнес-приложениях - такие связи редко поддерживаются самим приложением
например, поиском в google docs не доволен, т.к. приходится руками организовывать взаимосвязи между документами.
т.е. даже простейшую каталогизацию приходится делать через явные жесткие префиксы в названиях документов, чтобы потом было можно что-то найти
Paging?
Бенефиты?
правильная сортировка + скроллер быстрее выполнить, чем ввод поискового словаЭто на самом деле не совсем так
и кстати над вторым надо больше думать, чем над первым.
Т.е. Последнее утверждение верно - кликнуть быстрее потому что привычнее. Но по времени будет дольше. Весь вопрос - в переучивании пользователя от привычного интерфейса к новому.Paging?paging по сравнению со скроллером - это уж точно хрень какая-то.
virtual grid фактически и есть тот самый paging, только нормально сделанный
По мне так книги удобнее свитков.
По мне так книги удобнее свитков.аналогия не совсем верная
в свитке нельзя перейти сразу в середину
в виртуал гриде - можно, и даже проще чем в paging-е
если задуматься, то номера страниц в paging-е - это и есть тот же самый скролбар грида, только не стандартный.
если задуматься, то номера страниц в paging-е - это и есть тот же самый скролбар грида, только не стандартный.Скорее дискретный.
Ты считаешь что на форумах виртуальные гриды были бы удобнее страниц?
Ты считаешь что на форумах виртуальные гриды были бы удобнее страниц?да, если бы это не тормозило.
кстати карты в инете сейчас же тоже делают как виртуал, а изначально был тоже paging.
но на картах, конечно, удобство виртуал намного более заметно, чем на гриде
в бизнес-приложениях - такие связи редко поддерживаются самим приложениемРассмотрим конкретный пример: у нас есть список пользователей интернета Корбины. Примерно 500k человек. Есть два варианта:
- список на 500k (таблица, если у пользователей есть атрибуты).
- список с результами поиска, 10 штук. Если больше — уточняй запрос.
Оператор начинает набирать код абонента или его фамилию. Список быстро начинает сокращаться и в некоторый момент становится совсем короткий, он жмет вниз-вниз-вниз-энтер.
Т.е. что-то типа: Карама-вниз-вниз-enter. Открывается карточка клиента.
Листать же 500k фамилий отсортированных по алфавиту — это высокое мастерство, оттачиваемое годами.
Оператор начинает набирать код абонента или его фамилию.так даже в этом случае, если я написал фамилию Иванов, то я все равно хочу увидеть всех 10 тыс. Ивановых, а не первых 10 или там ответ типа "запрос слишком большой"
Бенефиты?1. стили
2. умение динамически поменять интерфейс (например, загрузить с сервера новый html)
3. скриптинг (по крайней мере, простых вещей, которые лень тащить в код)
4. Относительно легко делать резиновые интерфейсы (см тему zok)
5. понятный и стандартный layout: много специалистов, большое community, много редакторов html (для тех, кто любит).
6. Быстрый. Нет, на 100k элементах списка будет тормозить. Зато если экстремальными видами проектирования интерфейса не заниматься, будет быстрее. Например, xaml, который вроде бы тоже для всех вышеописанных благ спроектирован, тормозит. Да и контролы .net тоже местами тормозят (вспоминаем radiobutton-ы и ряд других проблем).
так даже в этом случае, если я написал фамилию Иванов, то я все равно хочу увидеть всех 10 тыс. Ивановых, а не первых 10 или там ответ типа "запрос слишком большой"эээ, зачем? Лично пройдешь по списку и каждому увеличишь скорость интернета в два раза? Или все-таки тебе нужен один конкретный Иванов, только ты еще допишешь С.К. 1981?
Лично пройдешь по списку и каждому увеличишь скорость интернета в два раза?допустим нажму ctrl-a и скажу всем выделенным увеличить скорость интернета в два раза
а не первых 10 или там ответ типа "запрос слишком большой"ты увидишь первые 10, количество результатов и несколько страниц, чтобы не возникало проблемы 11 результатов. При этом страницами предполагается пользоваться очень редко (10-15% случаев идем на вторую что и показывает опыт приложений, спроектированных в этом стиле
допустим нажму ctrl-a и скажу всем выделенным увеличить скорость интернета в два разазамечательно. Кто тебе мешает не делать Ctrl-A, а сделать так:
Иванов<tab>Увеличить скорость в два раза<enter>
А вот если тебе надо что-то сделать с половиной списка, то тут лучше уточнить запрос. Например, Иванов из Бирюлево
ты увидишь первые 10, количество результатов и несколько страниц, чтобы не возникало проблемы 11 результатовсм. выше про paging vs virtual
имхо, paging делается ради программистов (им так дешевле чем ради пользователей(для которых paging менее удобнее)
Paging делается для того, чтобы увидев строчку "найдено 11 человек" и поняв, что тебе нужен 11-ый, не материться. Но это нужно редко. Распределение примерно такое: 15% человек/случаев полезут на вторую страницу и меньше 5% на третью. Т.е. фактически, paging не используется. И сигнал, что ты идешь на третью страницу говорит о том, что тебе стоит запрос поточнее сделать, а не тупняком страдать.
Кто тебе мешает не делать Ctrl-A, а сделать так:тем что визуально не контролируется на сколько человек(строк) это кнопка применится
зы
например, я бы перед тем как нажимать кнопку, еще бы на всякий случай покрутил бы скроллер, чтобы посмотреть что вообще нашлось, и увидел что еще попали всякие Ивановские, и соответственно перед тем как нажимать кнопку, надо поиск поправить, чтобы было только точное совпадение
Т.е. задачу выбора одного/всех элементов будем считать решенной (вернемся потом, если возникнут сомнения).
Теперь мы имеем задачу анализа, "что попало в результаты запроса". Очевидное решение — список на 10k. Есть ли другое решение? Навскидку — облако слов. Ненавскидку тоже можно подумать.
Теперь мы имеем задачу анализа, "что попало в результаты запроса". Очевидное решение — список на 10k. Есть ли другое решение? Навскидку — облако слов. Ненавскидку тоже можно подумать.
Т.е. задачу выбора одного/всех элементов будем считать решенной (вернемся потом, если возникнут сомнения).т.е. ты задачу выбора одного отделяешь от задачи выбора нескольких?
Оператор начинает набирать код абонента или его фамилию. Список быстро начинает сокращаться и в некоторый момент становится совсем короткий, он жмет вниз-вниз-вниз-энтер.
Т.е. что-то типа: Карама-вниз-вниз-enter. Открывается карточка клиента.
Листать же 500k фамилий отсортированных по алфавиту — это высокое мастерство, оттачиваемое годами.
грида с прокруткой+поиск+сортировка лучше, чем грида с пейджингом+поиск+сортировка. Пейджин, действительно, пришел к нам из веба, поскольку нормальную гриду там сложно реализовать.
Прокрутка — фундаментальное зло по трем причинам:
1. Человек легко теряет контекст, особенно при более чем одной прокрутке на экране.
2. Почти всегда это означает переключение на мышь (потеря времени для пользователя, который работает с этим интерфейсом постоянно)
3. Способствует появлению убогих интерфейсов со списками на 100k.
Paging — это тоже хак. Его делать надо только для обработки психологически важного момента: не поместилось 1-2 элемента на экран. Пользоваться paging-ом хардкорный пользователь не будет. Новичок тоже быстро поймет, что надо искать, а не скролить/ходить по страницам.
1. Человек легко теряет контекст, особенно при более чем одной прокрутке на экране.
2. Почти всегда это означает переключение на мышь (потеря времени для пользователя, который работает с этим интерфейсом постоянно)
3. Способствует появлению убогих интерфейсов со списками на 100k.
Paging — это тоже хак. Его делать надо только для обработки психологически важного момента: не поместилось 1-2 элемента на экран. Пользоваться paging-ом хардкорный пользователь не будет. Новичок тоже быстро поймет, что надо искать, а не скролить/ходить по страницам.
т.е. ты задачу выбора одного отделяешь от задачи выбора нескольких?я считаю, что есть три задачи:
1. Выборка одного элемента из возможно очень большого множества (пример: поиск абонента по базе)
2. Выборка всех элементов, удовлетворяющих запросу (пример: все абоненты из Бирюлево, подключеных больше года)
3. Выборка нескольких элементов из небольшого множества (условно говоря, не больше 10). Пример: премирование непосредственных подчиненных, в связи с подключением района Бирюлево.
Все остальные задачи выбора, похоже, сводятся к этим трем. Если я что-то пропустил, буду рад посмотреть на контрпример.
Прокрутка — фундаментальное зло по трем причинамЯ сейчас работаю с аналитиками, им удобна прокрутка с сортировкой.
Если честно, я совсем не понимаю, почему это зло. Безусловно, качественные spreadsheets надо реализовать и с фильтрацией, и с поиском строки при наборе на клавиатуре. Ведь бывают задачи поиска не по подстроке или регулярному выражению, а по стоящим рядом строкам. Проглядеть их при страничном разбиении очень тяжело, и тогда в дело идёт прокрутка.
Хм. А почему на Google до сих пор страницы?
Я сейчас работаю с аналитиками, им удобна прокрутка с сортировкой.предлагалось ли им что-то другое?
я не являюсь знатоком по задаче, которая решается у тебя на работе и не готов сейчас начать предлагать варианты. Но в тех задачах, что попадались мне, немного подумав, можно было уйти от списка и сделать людям удобнее.
Я сейчас работаю с аналитиками, им удобна прокрутка с сортировкой.А вот трейдера по всему миру работают с блумберг-терминалом.
А он - хтмлный - это раз(я конечно не поручусь что на сто процентов)
Рендерится ОЧЕНЬ быстро - это два.
Интрефейс взаимодействия описывается примерно так:
Иванов<tab>Увеличить скорость в два раза<enter>
Т.е. ввод команд с клавы. Плюс команды вынесены прямо на клавишы - работать очень быстро.
Другое дело, к такому УИ надо привыкать и учится им пользоваться. Интуитивность ниже. Тут либо вводить систему обучения, либо нужно, чтобы сменился мейнстрим от кликов-скроллов-баттонов(что вряд ли) А еще такой УИ должен быть продуманный - студент на коленке не склепает(если склепает - юзать будет невозможно, в то время как стандартный можно хоть как то это да. Тот же пейджинг в вебе меня раздражает сильно, т.к. сделан неудобно. Зато читать книжку читальщиком перекючая страницы - одно удовольствие, в то время как двигать сколом - адовы муки.
Т.е. ввод команд с клавы. Плюс команды вынесены прямо на клавишы - работать очень быстро.Хмм, я не нашёл в твоей задаче ничего, что требовало бы постраничной разбивки; или чему мешал бы полный список.
Хмм, я не нашёл в твоей задаче ничего, что требовало бы постраничной разбивки; или чему мешал бы полный список.Какой задаче? Я задачу не ставил, я описал как работает один из программных продуктов
И работает продуктивно.Я задачу не ставил, я описал как работает один из программных продуктовПросто в теме в том числе идёт спор, являются ли плохим стилем списки большого размера. Я аргументировал в пользу того, что не являются. Ты мне ответил, что есть какая-то программа, где выполняется навигация и поиск с помощью клавиатуры. Но это никак не противоречит наличию или отсутствию объёмного списка всех позиций.
Просто в теме в том числе идёт спор, являются ли плохим стилем списки большого размера. Я аргументировал в пользу того, что не являются. Ты мне ответил, что есть какая-то программа, где выполняется навигация и поиск с помощью клавиатуры. Но это никак не противоречит наличию или отсутствию объёмного списка всех позиций.Наличие большого списка неудобно в принципе(вспоминаем про то, что человек в среднем может работать с 7 предметами - т.е. держать их в поле зрения).
Т.е. работать однозначно неудобно, для этого используют всякие фильтрации и т.д. Вот предлагается вместо содержания большого(виртуально большого) списка в ГУИ иметь маленький с возможностью работы с данными через команды, а не дергания скролла.
Наличие большого списка неудобно в принципе(вспоминаем про то, что человек в среднем может работать с 7 предметами - т.е. держать их в поле зрения).
Я пока что не встречал людей, у которых большой список вызывает проблемы. Зато встречал тех, кому удобно иногда пробежаться по отсортированному списку, пусть даже очень большому.
списка в ГУИ иметь маленький с возможностью работы с данными через команды, а не дергания скролла.Никто не говорил про обязятельное дёрганье скролла. Наличие команд, поиска и фильтров обязательно, этого никто не отрицает.
Я пока что не встречал людей, у которых большой список вызывает проблемы. Зато встречал тех, кому удобно иногда пробежаться по отсортированному списку, пусть даже очень большому.Ты знаешь, я видел как люди работали с конкретно неудобными приложениями и не жаловались
Никто не говорил про обязятельное дёрганье скролла. Наличие команд, поиска и фильтров обязательно, этого никто не отрицает.
Ну так сам то список никто не ограничивает. Просто скролл можно сделать вполне себе ненужным - и отпадет проблема построения виртуальных списков.
Ты знаешь, я видел как люди работали с конкретно неудобными приложениями и не жаловалисьНу и что? Я тоже как бы не первый год работаю, и с пользователями общался достаточно много. Но на большой список никто никогда не жаловался, при условии наличия фильтрации и автоматического поиска. Да и у меня такие списки не вызывали бы никаких проблем.
Просто скролл можно сделать вполне себе ненужным - и отпадет проблема построения виртуальных списков.У меня, например, на сегодня есть конкретная задача, оформленная в виде требования от клиента: скролл по списку из 10^6 позиций. Так что я не могу сделать его ненужным. Кроме того, если результатом фильтрации будет 35 строк, из которых только 25 помещается на экране, то мне кажется, что скролл будет 100% удобнее, чем две страницы.
При поиске одного-двух элементов большой список+постоянный скролинг, ровно как и привычка пробежаться по списку - это трата времени и привычка не убирать руку с мышки. Людям лень набить три-четыре буквы получить максимально приближенную к поиску выборку. Офисом-то мало кто по сути умеет эффективно пользоваться.
Скажи, ты в записной книжке мобильника скролишь до буквы "Ф" или предпочитаешь пользоваться поиском по вхождению, набрав "фед" (допустим ищем редкий контакт "Федор")?
Скажи, ты в записной книжке мобильника скролишь до буквы "Ф" или предпочитаешь пользоваться поиском по вхождению, набрав "фед" (допустим ищем редкий контакт "Федор")?
Я пока что не встречал людей, у которых большой список вызывает проблемы. Зато встречал тех, кому удобно иногда пробежаться по отсортированному списку, пусть даже очень большому.
Людям лень набить три-четыре буквы по получить максимально приближенную к поиску выборку. Офисом-то мало кто по сути умеет эффективно пользоваться.
Прочитай мои посты внимательнее. Я нигде не отрицаю наличия type-and-search подхода (когда фокус клавиатуры находится на списке и при нажатии клавиш происходит автоматическая фильтрация или поиск). Но так же я нигде не вижу проблем с тем, чтобы список был объёмным.
Если нет проблем реализовать удобный интерфейс без необходимости списков на 100k, можно понять, что исходный посыл, что десктопные программы сейчас удобнее всего делать как формочка, внутри которой html, становится окончательно ясным.
Что и требовалось показать.
Еще какие-то сомнения, кроме озвученного ДаркГреем, есть?
Что и требовалось показать.
Еще какие-то сомнения, кроме озвученного ДаркГреем, есть?
Проблемы прогрузить в грид данные (если ничего не тормозит) конечно же нет. Но я бы всегда давал возможность пользователю "начать работать более эффективно"
Проблемы прогрузить в грид данные (если ничего не тормозит) конечно же нет. Но я бы всегда давал возможность пользователю "начать работать более эффективно"И что ему не даёт начать работать более эффективно? Методы интерфейса, которые ему более понятны или просты? Многим людям быстрее повернуть колесо мышки и найти глазами нужную строчку, потому что на клавиатуру им тоже придётся смотреть. Другие могут быстрее набрать две-три буквы левой рукой. Если мы поддерживаем оба варианта, то интерфейс будет более понятен и приемлем для большего числа пользователей.
Имелось ввиду, что скрол скролом, но возможность фильтрации и поиска по вхождению должна быть практически всегда. Мне это кажется более правильным подходим с точки зрения комфортной работы пользователей.
Если мы поддерживаем оба варианта, то интерфейс будет более понятен и приемлем для большего числа пользователей.это, конечно же, неверно. Потому что (я не видел вашего интерфейса и не могу судить, разумеется скорее всего получится перегруженный интерфейс, от которого у человека, который видит его в первый раз, глаза разбегаются.
Да просто над этим интерфейсом нужно будет чуть дольше подумать и подготовить его максимально удобно для решения требуемых задач.
http://zhelezona.ru/post/147/
http://zhelezona.ru/post/147/
Если нет проблем реализовать удобный интерфейс без необходимости списков на 100k, можно понять, что исходный посыл, что десктопные программы сейчас удобнее всего делать как формочка, внутри которой html, становится окончательно ясным.Интересный посыл. А чего тогда Sun решили продвигать Java для Rich Desktop Applications? Даже рендеринг swing на DirectX написали, и новый look and feel.
Кстати, html интерфейсы не всегда удобны. Часто встречается ситуация, когда из-за невозможности решить все задачи с помощью html, возникают какие-то неприятные смеси, в которых окна реализованы по-разному: одни сделаны в виде html в формах со скруглёнными краями, а какие-нибудь меню или окна настроек - стандартные виндовые. (Ничего не напоминает?
)Не спорю, что у html интерфейсов есть своё применение. Но если честно, не замечал, что они вытесняют rich client. Мало того, в моей практике есть реальный пример, когда отказались от html+javascript интерфейса и стали переделывать его на rich client. (Стоимость проекта в то время уже превышала 10 миллионов рублей.)
Apple рулит
Кстати, html интерфейсы не всегда удобны. Часто встречается ситуация, когда из-за невозможности решить все задачи с помощью html, возникают какие-то неприятные смеси, в которых окна реализованы по-разному: одни сделаны в виде html в формах со скруглёнными краями, а какие-нибудь меню или окна настроек - стандартные виндовые. (Ничего не напоминает? )Примеры?
Не спорю, что у html интерфейсов есть своё применение. Но если честно, не замечал, что они вытесняют rich client. Мало того, в моей практике есть реальный пример, когда отказались от html+javascript интерфейса и стали переделывать его на rich client. (Стоимость проекта в то время уже превышала 10 миллионов рублей.)Возможно, проблема была не в технологиях, а в том, как их применяли?
Второй вопрос — был web интерфейс, стали переделывать на десктоп? Если да, то в этом треде я рассматриваю способ построения интерфейса десктопной программы. Вполне очевидно, что web довольно часто ограничен.
А чего тогда Sun решили продвигать Java для Rich Desktop Applications? Даже рендеринг swing на DirectX написали, и новый look and feelДля чего Sun купил MySQL, потратив 20% оставшихся денег? Почему он катастрофически убыточен? Ответ: потому что это компания, которая, похоже, постепенно разоряется.
Информация от бывших сотрудников MySQL, поимевших неплохое количество денег с покупки их компании Саном.
это, конечно же, неверно. Потому что (я не видел вашего интерфейса и не могу судить, разумеется скорее всего получится перегруженный интерфейс, от которого у человека, который видит его в первый раз, глаза разбегаются.Это почему? Действия могут и должны дублироваться, с этим обычно не возникает никаких проблем: тулбар, меню по правому клику, меню главного окна, хоткеи. При этом интерфейс внешне может оставаться таким же. Фильтр может быть вообще не виден до начала ввода с клавиатуры, хотя при таком подходе лучше иметь tooltips. (А то я встречался с ситуацией, когда был реализован поиск по подстроке, а пользователи думали, что можно искать только сначала слова, и из-за этого месяц вручную перебирали список из 10 тысяч позиций.)
Это почему? Действия могут и должны дублироваться, с этим обычно не возникает никаких проблем: тулбар, меню по правому клику, меню главного окна, хоткеиСогласен. Это хороший пример обоснованного дублирования.
Примеры?
Возможно, проблема была не в технологиях, а в том, как их применяли?Я больше склонен думать, что проблема была и в том, и в другом. Но если бы я начинал подобный проект с нуля, то сразу выбрал бы rich client, без html контента вообще. Зачем смешивать html и контролы на другой технологии, если сразу понятно, что вторые точно понадобятся? Чтобы нанимать спеца не по одному направлению, а сразу по двум?
Если да, то в этом треде я рассматриваю способ построения интерфейса десктопной программы.Возможно, что все реализации html рендеринга ограничены.
В правильной версии, Google Talk Labs Edition, все правильно:Признаюсь, я скачал, что дали.
Видимо, не всё так просто с html интерфейсами, если такие простые окна были сначала сделаны в виде стандартных win32?Кстати, вот... Он что, сделан на чём-то вроде Adobe Air? У меня стоит flash вообще-то, и даже автообновляется регулярно.
Кстати, вот... Меню до сих пор не оформлены.
1. стилиКстати, вот... Custom стили на Java swing, look and feel там тоже меняется динамически.
2. умение динамически поменять интерфейс (например, загрузить с сервера новый html)
> Кстати, вот... Custom стили на Java swing, look and feel там тоже меняется динамически.
А я больше скажу - в обычном win32 тоже легко меняются динамически (см. например skinengine.com).
А я больше скажу - в обычном win32 тоже легко меняются динамически (см. например skinengine.com).
Наличие большого списка неудобно в принципе(вспоминаем про то, что человек в среднем может работать с 7 предметами - т.е. держать их в поле зрения).Наличие большого списка может быть удобнее чем группировка его на подгруппы. Все зависит от задачи.
Например выбрать свой город из большого списка, отсортированного по алфавиту - удобнее и быстрее чем выбрать свой город сначала выбрав область.
Ботаем закон Хика, к примеру.
Ты выбрал мой пост и ответил только на него.
В твоем примере куда как удобней найти город, вводя его по буквам в поле поиска и одновременно фильтруя БОЛЬШОЙ список по вводу пользователя. Таким образом можно даже найти город(слово если не знаешь точно как оно пишется(реализовав поиск ближайших слов). А не дергая судорожно скролл БОЛЬШОГО списка, особенно если твой город в середине.
Это все было уже в треде, так что мимо.
В твоем примере куда как удобней найти город, вводя его по буквам в поле поиска и одновременно фильтруя БОЛЬШОЙ список по вводу пользователя. Таким образом можно даже найти город(слово если не знаешь точно как оно пишется(реализовав поиск ближайших слов). А не дергая судорожно скролл БОЛЬШОГО списка, особенно если твой город в середине.
Это все было уже в треде, так что мимо.
Например выбрать свой город из большого списка, отсортированного по алфавиту - удобнее и быстрее чем выбрать свой город сначала выбрав область.Город надо выбирать c помощью текстового поля с автодописыванием. Типа Сан<tab> или Ту<tab> или Боро<tab>
Ага, особенно людям, которые плохо умеют набирать.
Особенно, если список экспортировался не из справочника и не содержит всех населенных пунктов РФ.
Такие списки хороши в двух случаях:
1. Элементов ну оочень много. Хотя бы 1к.
2. Заранее известно, что искомое точно есть в списке.
Особенно, если список экспортировался не из справочника и не содержит всех населенных пунктов РФ.
Такие списки хороши в двух случаях:
1. Элементов ну оочень много. Хотя бы 1к.
2. Заранее известно, что искомое точно есть в списке.
Ага, особенно людям, которые плохо умеют набирать.ну вот про это я тоже писал вначале - что сколать-кликать это более интуитивно для неподготовленного человека(не будем сейчас вдаваться в причины этого).
Однако же гугл люди осиливают, да и ворд тоже.
Ты выбрал мой пост и ответил только на него.
В твоем примере куда как удобней найти город, вводя его по буквам в поле поиска и одновременно фильтруя БОЛЬШОЙ список по вводу пользователя. Таким образом можно даже найти город(слово если не знаешь точно как оно пишется(реализовав поиск ближайших слов). А не дергая судорожно скролл БОЛЬШОГО списка, особенно если твой город в середине.
Это все было уже в треде, так что мимо.
На самом деле на твой пост я ответил только из-за фразы о том, что человек может работать одновременно только с 7ю объектами.
Он конечно может работать только с ограниченным кол-м объектов и большинство людей попадает в диапазон 5-7 штук. Но. Речь идет о том, чтобы держать в памяти одновременно 7 объектов. Т.е. человек не ищет нужное из списка, а сравнивает элементы списка друг с другом и определяет, какой ему больше подходит. Или переключается между ними постоянно.
Это правило прокатывает в навигации по всяким системам для неопытных пользователей, но совершенно не работает в случае как-нибудь аналитиков или операторов, которые ищут нужное им по точному соответствию.
P.S. А по существу ответа (забыл сразу ответить как показыает практика - поиск по ближайшим словам дорогая штука и не у всех на нее есть деньги. Плюс он не позволяет посмотреть несколько городов и выбрать нужный. Плюс доступ к списку не обязательно организовывать через немерянные скроллируемые области.
P.S. А по существу ответа (забыл сразу ответить как показыает практика - поиск по ближайшим словам дорогая штука и не у всех на нее есть деньги.самое простое как тут писали - это апвтодописывание с несколькими вариантами по части слова. Варианты в бокс выбираются как %часть_слова% - не сильно дорого.
Поиск ближайших - это конечно посложнее.
Хз, аналитики разные бывают. Я вот видел, как аналитики активно используют фильтры в екселе, чтобы как можно сильней ограничить количество вариантов.
Ситуации вообще бывают разные.
Есть, например, одноклассники, где все области выводятся простым списком. И если кто-то попробует заменить их подобным полем, то проекту он нож в спину воткнет.
Есть люди, использующие эклипс с идеей и без этих автокомплитов они жизнь просто не смыслят.
Все зависит от задач, контекста и самих пользователей. Рассуждать в категориях, это гавно и всегда должно быть так, в принципе не верно.
Есть, например, одноклассники, где все области выводятся простым списком. И если кто-то попробует заменить их подобным полем, то проекту он нож в спину воткнет.
Есть люди, использующие эклипс с идеей и без этих автокомплитов они жизнь просто не смыслят.
Все зависит от задач, контекста и самих пользователей. Рассуждать в категориях, это гавно и всегда должно быть так, в принципе не верно.
Оставить комментарий
Helga87
У меня возник вопрос к общественности: а кто еще _не_ использует подход форма — это просто хост для HTML-я? И почему?