Здравствуйте, Andrbig, Вы писали:
A>Здравствуйте, Max.Subpixel, Вы писали:
A>Я и не говорил, что список надо перебирать глазами. Я говорил о фильтрации.
Я тоже об этом говорил — для фильтрации не надо поднимать в память все объекты...
A>OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции.
A>Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться.
A>Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз.
A>Что удобнее юзеру и где меньше возможностей запутаться?
Я что-то вообще не пойму о чем речь. Что удобнее??
Можно как угодно сделать и не поднимать ВСЕ объекты разом в воздух. КАК УГОДНО
Здравствуйте, Andrbig, Вы писали:
A>Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?
Вообще-то смысла в поисках в результате нет вообще. Есть смысл в уточнении запроса. А "поиск в результате" легко эмулируется путем добавления подзапроса (по AND).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, RuneLord, Вы писали:
RL>Выводить все 10000 договоров — это преотличнейшее юзабилити, пускай юзера, вместо того чтобы пасьянсы расскладывать, тренируют свои глаза бегая по гриду из 10000 строк. Правильно работать надо, а не фигней страдать.
RL>Объясните откуда такое бредовое требование все и сразу?
Обычно это результат долгого общения с ISAM СУБД вроде BBASE, Paradox. Там частенько применялись "активизации индекса" или как их там назвать. При этом можно было перебирать записи в соотвествии с индексом и даже искать по первым буквам. Люди переходя на серверные приложения с ISAM СУБД просто по привычке пытаются использовать старый опыт. А он уже никуда не годится.
Ну, а в этом случае ко всему еще прибавились накладные расходы нового грида работающего с памятью в невиртуальном режиме довольно вольготно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Artem_, Вы писали:
_A_>Например у нас _A_>Есть база из договоров и ее надо просмтаривать, так есть контекстное меню в котором выбираются различные действия с ними. Специфика такая что пляшем от договоров, поэтому основная работа ведется именно с этим окном.
Ребат, вы меня извините, но ваша программа никуда не годна если она заставляет пользователя просматривать тысячи записей.
Зачем пользователю читать все подряд? Ему же найти что-то нужно. Так? А раз так, то дайте ему сделать это удобно, а не перебором.
Если же ему нужно просто просматривать тысячи договоров по очереди, то зачем список? Ведь он их все равно по одному смотреть будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, RuneLord, Вы писали:
RL>Выводить все 10000 договоров — это преотличнейшее юзабилити, пускай юзера, вместо того чтобы пасьянсы расскладывать, тренируют свои глаза бегая по гриду из 10000 строк. Правильно работать надо, а не фигней страдать.
RL>Объясните откуда такое бредовое требование все и сразу?
А что делать, если никакое регулярное выражение для поиска нужной строки юзер подобрать не может
Вот и маются бедолаги прибегая к своим критериям поиска во всем потоке данных.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Andrbig, Вы писали: A>OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции.
Ой, как интересно.
Ребята, вот вам пример, как делать НЕ НАДО. А именно, берем некую готовую реализацию некоторой функциональности, и пытаемся механическим способом приделать к ней новую фичу. Безо всякой оглядки на то, зачем и что нужно делать. Сказали надевать седло — надеваем седло.
Объясняю: в жизни задача "надо выделить N записей и у всех заменить определенное поле на какое-то значение" может возникнуть только в воспаленном мозгу программиста. Для пользователя нету ни записей, ни полей, ни задачи абстрактно заменить что-то на что-то.
Есть реальный бизнес сценарий. И задача разработчика — идентифицировать бизнес сценарий, и сделать к нему нормальный пользовательский интерфейс. Нормальный = такой, который снисходительно относится к пользователю и не требует от него сверхъестественных усилий.
Процитируем оба предложения начинающего проектировщика: A>Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться. A>Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз.
A>Что удобнее юзеру и где меньше возможностей запутаться?
Удобнее пристрелить тех, кто придумал эти варианты, и нанять на сэкономленные деньги одного специалиста по проектированию интерфейсов.
В данном примере, как всегда, произошла кошмарная потеря информации. А именно, Andbrig легким манием руки выкинул самое важное из того, что ему рассказал бедный пользователь:
— что это за список, какие сущности в него попадают.
— Сколько их всего
— Какой процент сущностей нуждается в модификации
— Что за поле меняет свое значение
— Частью какого сценария является эта мини-задача
— Насколько часто она выполняется
— Каков наиболее вероятный ход событий
— Насколько часто происходят отклонения от этого хода событий
— Чем вызваны эти отклонения.
Весь этот кладезь информации был заменен одной универсальной фразой. Хинт: если описание задачи начинается словами "Вываливается список", то надо сразу бить описателя логарифмической линейкой по пальцам.
Попробуем поспекулировать на эту тему и угадать, что иименно было выплеснуто из ванны.
Итак, задача:
Распределение заказов по менеджерам.
Мы имеем приложение веб-магазина. Покупатели делают заказы в свободной форме. Заказов поступает достаточно большое количество, и их не может курировать один менеджер. Поэтому был придуман механизм распределения заказов по менеджерам: с каждым заказом ассоциируется менеджер-куратор.
Есть несколько сценариев:
— распределение вновь поступивших заказов по менеджерам
— переназначение заказов, курируемых определенным менеждером, в случае его отпуска или болезни.
— обратное переназначение заказов, курируемых определенным менеждером, после возврата из отпуска или болезни.
— переназначение индивидуального заказа на другого менеджера, по произвольным причинам
Andbrig — программист, поэтому он мгновенно увидел самое, как он считает, существенное в этом описании: 90% случаев покрываются приемом "выпадает список, сортируем по критерию, ...". Действительно, программисту очень удобно это делать. Более того, вся прелесть в том, что на самом деле вообще ничего программироваться не будет, потому что в проекте уже давно есть библиотечка, которая показывает любые списки и позволяет пользовательскую сортировку, фильтрацию, и групповые операции типа заменить значение поля.
Не стоит обольшаться — с точки зрения пользователя, эта библиотечка решает любые его задачи одинаково хреново.
Каково правильное решение?
Продолжить опрос пользователей. Это приведет к тому, что
- при начальном назначении куратора, начальник отдела старается отдавать заказы каждого клиента одному и тому же менеджеру — потому, что менеджер помнит "своих" клиентов и может использовать накопленный опыт общения. Впрочем, начальник часто ошибается, потому что заказы идут валом, и иногда он не совсем точно выделяет диапазон строк в гриде (несмотря на фильтр по статусу "новые заказы" и сортировку по полю "ФИО клиента"). Решение: каждому зарегистрированному покупателю назначается его куратор. Все заказы от этого покупателя по умолчанию направляются этому менеджеру. Таким образом, мы вообще выкинули обязанность начальника отдела продаж по ручной раздаче этих заказов.
— когда менеджер уходит в отпуск, все его заказы перенаправляются как правило одному и тому же менеджеру-заместителю. Начальник иногда ошибается и ему приходится сделать операцию повторно, потому что ему нужно а) сделать сложный фильтр по куратору, ушедшему в отпуск и статусу "в процессе", б) выделить все строки, в) пойти в диалог свойств г) выбрать из дроп-дауна правильного заместителя и г) нажать Apply. К счастью, это бывает относительно редко.
— обратное переназначение практически никогда не делается просто потому, что нет способа отфильтровать заказы, которые были временно назначены на заместителя от тех, которые и были ему назначены изначально. Пользователи даже и не заикаются об этой возможности, потому что не видят способа получить ее в рамках существующей архитектуры. Поэтому когда менеджер уходит на больничный, переназначения не делаются вообще (больничные у них короткие, и большинство заказов пришлось бы перекидывать обратно, а этого делать никто не хочет). Поэтому в таких случаях заместитель просто отвечает на телефонные запросы к заболевшему, но в основном тянет время и отмазывается — ведь система ориентирована на того куратора, который приписан к заказу. Поэтому заместитель не может нормально отслеживать статус заказа и корректно им управлять. Такая практика приводит к росту недовольства покупателей, но об этом не любят говорить. Решение: Каждому менеджеру ставится в соответствие его заместитель. В системе реализуются две операции, разрешенные только начальнику отдела продаж:
. "временно переназначить заказы на заместителя", которая автоматически применяется ко всем соответствующим заказам выбранного куратора, а также модифицирует поведение процедуры автоматического назначения новых заказов.
. "вернуть временно переназначенные заказы основному куратору".
Я не буду вдаваться в детали реализации этих операций. Главное — что начальник отдела получает возможность делать свою работу.
— процедура ручного переназначения конкретного заказа разделяется на "Поиск заказа" и "Переназначение". Для поиска самый неэффективный способ — это скроллинг списка. Поскольку в системе и так есть интерфейс поиска конкретного заказа (который возвращает не более 10 найденных заказов и предлагает уточнить поиск, если показаны не все), мы просто добавляем в карточку заказа кнопку "переназначить".
А куда же делась многостраничная сетка ? Ой, оказывается она нам не понадобилась. И это не случайно — она неудобна для выполнения поставленных перед пользователем задач.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Обычно это результат долгого общения с ISAM СУБД вроде BBASE, Paradox. Там частенько применялись "активизации индекса" или как их там назвать. При этом можно было перебирать записи в соотвествии с индексом и даже искать по первым буквам. Люди переходя на серверные приложения с ISAM СУБД просто по привычке пытаются использовать старый опыт. А он уже никуда не годится.
VD>Ну, а в этом случае ко всему еще прибавились накладные расходы нового грида работающего с памятью в невиртуальном режиме довольно вольготно.
А вот и не угаадли , база у нас стоит Oracle 9i. А что такое ISAM СУБД я даже на знаю, не застал.
Здравствуйте, VladD2, Вы писали:
VD>Ага. Да и с 500-ами, то делать уже нечего. Рельно пользователь плюнет на 20-ой.
А вот это не надо, я например, иногда весь просматривал и еще бы смотрел, если бы были результаты!
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, VladD2, Вы писали:
VD>>Ага. Да и с 500-ами, то делать уже нечего. Рельно пользователь плюнет на 20-ой. _A_>А вот это не надо, я например, иногда весь просматривал и еще бы смотрел, если бы были результаты!
Это уже садомазохизм какой-то!
(робким дрожащим голосом)Может все-таки лучше уточнить критерии поиска?
Здравствуйте, FonBalroG, Вы писали:
FBG>Это уже садомазохизм какой-то! FBG>(робким дрожащим голосом)Может все-таки лучше уточнить критерии поиска?
Это если знаешь, что конкретно нужно найти, а если только ключевое слово и еще типа example, то может много всякой чуши вывести, которую нужно отфильтровать.
Здравствуйте, FonBalroG, Вы писали:
VD>>>Ага. Да и с 500-ами, то делать уже нечего. Рельно пользователь плюнет на 20-ой. _A_>>А вот это не надо, я например, иногда весь просматривал и еще бы смотрел, если бы были результаты! FBG>Это уже садомазохизм какой-то! FBG>(робким дрожащим голосом)Может все-таки лучше уточнить критерии поиска?
Типа лошадинная фамилия
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, _Artem_, Вы писали:
_A_>А вот и не угаадли , база у нас стоит Oracle 9i. А что такое ISAM СУБД я даже на знаю, не застал.
Это очень похоже на старый детский прикол когда мальчик подходит к другому со всей дури лупит ему по ноге крича — "дрынь...ды...ды-дынь..." — и заверсшает сие действо пояснением "мотоцикл продал, а привычка осталась". То есть БД то новая, а привычки у вас кто-то явно принес из прошлых веков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _Artem_, Вы писали:
_A_>>Это если знаешь, что конкретно нужно найти,
VD>А если не знашь, то нужно не искать, а сосредоточиться на формулировании вопроса. Можно еще у других спросить.
У меня народ активно применяет регулярные выражения и то бывает в затыке.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Ребята, вот вам пример, как делать НЕ НАДО.
Ребята, вот вам пример того, как делать НЕ НАДО — вещать выводы, не разобравшись в ситуации.
S>Объясняю: в жизни задача "надо выделить N записей и у всех заменить определенное поле на какое-то значение" может возникнуть только в воспаленном мозгу программиста. Для пользователя нету ни записей, ни полей, ни задачи абстрактно заменить что-то на что-то.
Пойду расскажу нашим пользователям, какого ты мнения об их мозге — именно они предложили данный способ работы. Кстати, про пользователей — откуда уверенность, что у них нет ни записей, ни полей? У наших пользователей есть записи (они называются позициями), есть поля и это им понятно и привычно. Заменить что-то абстрактно — да, этого нет, есть задачи заменить что-то конкретно. Но об этом дальше — в бизнес-сценарии.
S>Есть реальный бизнес сценарий. И задача разработчика — идентифицировать бизнес сценарий, и сделать к нему нормальный пользовательский интерфейс. Нормальный = такой, который снисходительно относится к пользователю и не требует от него сверхъестественных усилий.
Вот мы добрались и до бизнес-сценария. Опытный проектировщик предложил идентифицировать бизнес-сценарий и под него написать UI. Видимо обилие опыта заслонило проектировщику тот маленький факт, что бизнес-сценарий может быть просто неизвестен на момент разработки программы.
S>В данном примере, как всегда, произошла кошмарная потеря информации. А именно, Andbrig легким манием руки выкинул самое важное из того, что ему рассказал бедный пользователь:
В данном примере произошло кошмарное предположение о сути задачи. А именно, Sinclair решил, что прользователь что-то рассказал о своей бизнес-задаче на этапе разработки программы. Это неверно и потому весь вал последующих рассуждений можно выбрасывать в мусорку, как основанный на неверных предпосылках.
S>Весь этот кладезь информации был заменен одной универсальной фразой.
Весь этот кладезь информации отсутствует.
S>Попробуем поспекулировать на эту тему и угадать, что иименно было выплеснуто из ванны.
Ты не один старался или это мы, Николай II? Увы, не угадал.
S>А куда же делась многостраничная сетка ? Ой, оказывается она нам не понадобилась. И это не случайно — она неудобна для выполнения поставленных перед пользователем задач.
Конечно не случайно — ведь пример был выбран такой чтобы она не понадобилась.
Sinclair, раз уже ты сказал "А", я хочу узнать у тебя про "Б": готов ли ты обсудить архитектурные решения, если я опишу задачу?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrbig, Вы писали:
A>>Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?
VD>Вообще-то смысла в поисках в результате нет вообще. Есть смысл в уточнении запроса. А "поиск в результате" легко эмулируется путем добавления подзапроса (по AND).
Ну и я о том же. "Поиск в результатах" в том виде как он есть сейчас — фигня.
Я говорил о фильтрации.
Что даст поиск по нему? 
1.1.4 stable rev. 510
