Здравствуйте, Andrbig, Вы писали: A>OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции.
Ой, как интересно.
Ребята, вот вам пример, как делать НЕ НАДО. А именно, берем некую готовую реализацию некоторой функциональности, и пытаемся механическим способом приделать к ней новую фичу. Безо всякой оглядки на то, зачем и что нужно делать. Сказали надевать седло — надеваем седло.
Объясняю: в жизни задача "надо выделить N записей и у всех заменить определенное поле на какое-то значение" может возникнуть только в воспаленном мозгу программиста. Для пользователя нету ни записей, ни полей, ни задачи абстрактно заменить что-то на что-то.
Есть реальный бизнес сценарий. И задача разработчика — идентифицировать бизнес сценарий, и сделать к нему нормальный пользовательский интерфейс. Нормальный = такой, который снисходительно относится к пользователю и не требует от него сверхъестественных усилий.
Процитируем оба предложения начинающего проектировщика: A>Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться. A>Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз.
A>Что удобнее юзеру и где меньше возможностей запутаться?
Удобнее пристрелить тех, кто придумал эти варианты, и нанять на сэкономленные деньги одного специалиста по проектированию интерфейсов.
В данном примере, как всегда, произошла кошмарная потеря информации. А именно, Andbrig легким манием руки выкинул самое важное из того, что ему рассказал бедный пользователь:
— что это за список, какие сущности в него попадают.
— Сколько их всего
— Какой процент сущностей нуждается в модификации
— Что за поле меняет свое значение
— Частью какого сценария является эта мини-задача
— Насколько часто она выполняется
— Каков наиболее вероятный ход событий
— Насколько часто происходят отклонения от этого хода событий
— Чем вызваны эти отклонения.
Весь этот кладезь информации был заменен одной универсальной фразой. Хинт: если описание задачи начинается словами "Вываливается список", то надо сразу бить описателя логарифмической линейкой по пальцам.
Попробуем поспекулировать на эту тему и угадать, что иименно было выплеснуто из ванны.
Итак, задача:
Распределение заказов по менеджерам.
Мы имеем приложение веб-магазина. Покупатели делают заказы в свободной форме. Заказов поступает достаточно большое количество, и их не может курировать один менеджер. Поэтому был придуман механизм распределения заказов по менеджерам: с каждым заказом ассоциируется менеджер-куратор.
Есть несколько сценариев:
— распределение вновь поступивших заказов по менеджерам
— переназначение заказов, курируемых определенным менеждером, в случае его отпуска или болезни.
— обратное переназначение заказов, курируемых определенным менеждером, после возврата из отпуска или болезни.
— переназначение индивидуального заказа на другого менеджера, по произвольным причинам
Andbrig — программист, поэтому он мгновенно увидел самое, как он считает, существенное в этом описании: 90% случаев покрываются приемом "выпадает список, сортируем по критерию, ...". Действительно, программисту очень удобно это делать. Более того, вся прелесть в том, что на самом деле вообще ничего программироваться не будет, потому что в проекте уже давно есть библиотечка, которая показывает любые списки и позволяет пользовательскую сортировку, фильтрацию, и групповые операции типа заменить значение поля.
Не стоит обольшаться — с точки зрения пользователя, эта библиотечка решает любые его задачи одинаково хреново.
Каково правильное решение?
Продолжить опрос пользователей. Это приведет к тому, что
- при начальном назначении куратора, начальник отдела старается отдавать заказы каждого клиента одному и тому же менеджеру — потому, что менеджер помнит "своих" клиентов и может использовать накопленный опыт общения. Впрочем, начальник часто ошибается, потому что заказы идут валом, и иногда он не совсем точно выделяет диапазон строк в гриде (несмотря на фильтр по статусу "новые заказы" и сортировку по полю "ФИО клиента"). Решение: каждому зарегистрированному покупателю назначается его куратор. Все заказы от этого покупателя по умолчанию направляются этому менеджеру. Таким образом, мы вообще выкинули обязанность начальника отдела продаж по ручной раздаче этих заказов.
— когда менеджер уходит в отпуск, все его заказы перенаправляются как правило одному и тому же менеджеру-заместителю. Начальник иногда ошибается и ему приходится сделать операцию повторно, потому что ему нужно а) сделать сложный фильтр по куратору, ушедшему в отпуск и статусу "в процессе", б) выделить все строки, в) пойти в диалог свойств г) выбрать из дроп-дауна правильного заместителя и г) нажать Apply. К счастью, это бывает относительно редко.
— обратное переназначение практически никогда не делается просто потому, что нет способа отфильтровать заказы, которые были временно назначены на заместителя от тех, которые и были ему назначены изначально. Пользователи даже и не заикаются об этой возможности, потому что не видят способа получить ее в рамках существующей архитектуры. Поэтому когда менеджер уходит на больничный, переназначения не делаются вообще (больничные у них короткие, и большинство заказов пришлось бы перекидывать обратно, а этого делать никто не хочет). Поэтому в таких случаях заместитель просто отвечает на телефонные запросы к заболевшему, но в основном тянет время и отмазывается — ведь система ориентирована на того куратора, который приписан к заказу. Поэтому заместитель не может нормально отслеживать статус заказа и корректно им управлять. Такая практика приводит к росту недовольства покупателей, но об этом не любят говорить. Решение: Каждому менеджеру ставится в соответствие его заместитель. В системе реализуются две операции, разрешенные только начальнику отдела продаж:
. "временно переназначить заказы на заместителя", которая автоматически применяется ко всем соответствующим заказам выбранного куратора, а также модифицирует поведение процедуры автоматического назначения новых заказов.
. "вернуть временно переназначенные заказы основному куратору".
Я не буду вдаваться в детали реализации этих операций. Главное — что начальник отдела получает возможность делать свою работу.
— процедура ручного переназначения конкретного заказа разделяется на "Поиск заказа" и "Переназначение". Для поиска самый неэффективный способ — это скроллинг списка. Поскольку в системе и так есть интерфейс поиска конкретного заказа (который возвращает не более 10 найденных заказов и предлагает уточнить поиск, если показаны не все), мы просто добавляем в карточку заказа кнопку "переназначить".
А куда же делась многостраничная сетка ? Ой, оказывается она нам не понадобилась. И это не случайно — она неудобна для выполнения поставленных перед пользователем задач.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Выводить все 10000 договоров — это преотличнейшее юзабилити, пускай юзера, вместо того чтобы пасьянсы расскладывать, тренируют свои глаза бегая по гриду из 10000 строк. Правильно работать надо, а не фигней страдать.
Объясните откуда такое бредовое требование все и сразу?
Здравствуйте, kirya_kg, Вы писали:
_>Тот же MSDN выдает только первые 500 найденных результатов
Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?
Здравствуйте, Sinclair, Вы писали:
S>Ребята, вот вам пример, как делать НЕ НАДО.
Ребята, вот вам пример того, как делать НЕ НАДО — вещать выводы, не разобравшись в ситуации.
S>Объясняю: в жизни задача "надо выделить N записей и у всех заменить определенное поле на какое-то значение" может возникнуть только в воспаленном мозгу программиста. Для пользователя нету ни записей, ни полей, ни задачи абстрактно заменить что-то на что-то.
Пойду расскажу нашим пользователям, какого ты мнения об их мозге — именно они предложили данный способ работы. Кстати, про пользователей — откуда уверенность, что у них нет ни записей, ни полей? У наших пользователей есть записи (они называются позициями), есть поля и это им понятно и привычно. Заменить что-то абстрактно — да, этого нет, есть задачи заменить что-то конкретно. Но об этом дальше — в бизнес-сценарии.
S>Есть реальный бизнес сценарий. И задача разработчика — идентифицировать бизнес сценарий, и сделать к нему нормальный пользовательский интерфейс. Нормальный = такой, который снисходительно относится к пользователю и не требует от него сверхъестественных усилий.
Вот мы добрались и до бизнес-сценария. Опытный проектировщик предложил идентифицировать бизнес-сценарий и под него написать UI. Видимо обилие опыта заслонило проектировщику тот маленький факт, что бизнес-сценарий может быть просто неизвестен на момент разработки программы.
S>В данном примере, как всегда, произошла кошмарная потеря информации. А именно, Andbrig легким манием руки выкинул самое важное из того, что ему рассказал бедный пользователь:
В данном примере произошло кошмарное предположение о сути задачи. А именно, Sinclair решил, что прользователь что-то рассказал о своей бизнес-задаче на этапе разработки программы. Это неверно и потому весь вал последующих рассуждений можно выбрасывать в мусорку, как основанный на неверных предпосылках.
S>Весь этот кладезь информации был заменен одной универсальной фразой.
Весь этот кладезь информации отсутствует.
S>Попробуем поспекулировать на эту тему и угадать, что иименно было выплеснуто из ванны.
Ты не один старался или это мы, Николай II? Увы, не угадал.
S>А куда же делась многостраничная сетка ? Ой, оказывается она нам не понадобилась. И это не случайно — она неудобна для выполнения поставленных перед пользователем задач.
Конечно не случайно — ведь пример был выбран такой чтобы она не понадобилась.
Sinclair, раз уже ты сказал "А", я хочу узнать у тебя про "Б": готов ли ты обсудить архитектурные решения, если я опишу задачу?
Здравствуйте, Andrbig, Вы писали: A>Ребята, вот вам пример того, как делать НЕ НАДО — вещать выводы, не разобравшись в ситуации.
Ок, давай подробнее. Я всегда для критики открыт. A>Пойду расскажу нашим пользователям, какого ты мнения об их мозге — именно они предложили данный способ работы.
Да запросто. А что, твои пользователи — великие специалисты по usability? Да они просто слаще редьки ничего не ели, от того и выражают свои потребности "хотя бы так". A> Кстати, про пользователей — откуда уверенность, что у них нет ни записей, ни полей?
Из опыта. Из очень большого опыта. Объясни мне, в какой области бизнеса есть записи и поля? A>У наших пользователей есть записи (они называются позициями), есть поля и это им понятно и привычно. Заменить что-то абстрактно — да, этого нет, есть задачи заменить что-то конкретно. Но об этом дальше — в бизнес-сценарии.
A>Вот мы добрались и до бизнес-сценария. Опытный проектировщик предложил идентифицировать бизнес-сценарий и под него написать UI. Видимо обилие опыта заслонило проектировщику тот маленький факт, что бизнес-сценарий может быть просто неизвестен на момент разработки программы.
Гм. Есть такое — называется "недопроектирование". Как можно писать софт, который решает неизвестно какую задачу? В каком виде было сформулировано ТЗ? "Освоить полтора миллиона долларов IT-бюджета" что ли?
S>>В данном примере, как всегда, произошла кошмарная потеря информации. А именно, Andbrig легким манием руки выкинул самое важное из того, что ему рассказал бедный пользователь: A>В данном примере произошло кошмарное предположение о сути задачи. А именно, Sinclair решил, что прользователь что-то рассказал о своей бизнес-задаче на этапе разработки программы. Это неверно и потому весь вал последующих рассуждений можно выбрасывать в мусорку, как основанный на неверных предпосылках.
А, то есть общения с пользователями Andrbig вообще избежал? Ну это, конечно, гарантированный способ добиться успеха. A>Весь этот кладезь информации отсутствует.
Значит, нужно его получить. Никто за вас это готовить не будет. 50% успеха — это выяснить, что именно нужно пользователям. Еще 50% — это умение быстро исправить все написанное после того, как оказалось что пользователям нужно совсем другое S>>Попробуем поспекулировать на эту тему и угадать, что иименно было выплеснуто из ванны. A>Ты не один старался или это мы, Николай II? Увы, не угадал.
Да я и не собирался угадать. Я просто хотел показать, какова разница в результатах, если начинать "от грида и комбобокса" и если начинать от бизнес-сценария. S>>А куда же делась многостраничная сетка ? Ой, оказывается она нам не понадобилась. И это не случайно — она неудобна для выполнения поставленных перед пользователем задач. A>Конечно не случайно — ведь пример был выбран такой чтобы она не понадобилась.
A>Sinclair, раз уже ты сказал "А", я хочу узнать у тебя про "Б": готов ли ты обсудить архитектурные решения, если я опишу задачу?
Да, готов. Может быть не сразу — у меня еще и работа есть
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Владек, Вы писали:
В>В каждый момент времени в этом гриде видно одну страницу записей (ну пусть 30-40 штук), пользователь за раз может охватить 7-9 записей. И не важно сколько вообще записей в гриде, для пользователя эти числа не меняются — значите есть возможность изменить способ подгрузки записей из базы и тем самым сократить объем используемой памяти.
Более того. Если пользователь не идиот, то ищет он по критериям. А раз так, то лучше сделать удобный поиск. А просмотр всех записей только на крайняк. И тут уж пусть сам думает что ему лучше много метров памяти и долгие часы листания или один запрос.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, RuneLord, Вы писали:
RL>Выводить все 10000 договоров — это преотличнейшее юзабилити, пускай юзера, вместо того чтобы пасьянсы расскладывать, тренируют свои глаза бегая по гриду из 10000 строк. Правильно работать надо, а не фигней страдать.
Правильно — это как, воинственный ты наш? Например, юзеру надо что-то найти, он открывает поисковую форму (или переключается в нее, если она уже открыта), попадает мышью в нужное поле, вводит там строку поиска, жмет кнопку "Искать". Программа находит 5000 элементов. Он снова переходит в поисковую форму, дополняет поиск (а это может быть пара букв), снова жмет, программа находит, он снова переключается — и так до тех пор, пока не будет найдено приемлимое число.
Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.
"Правильно работать" для сервера и программиста не всегда совпадает с "удобно работать" для юзера, увы.
RL>Объясните откуда такое бредовое требование все и сразу?
То что ты его не понимаешь не значит что оно бредовое.
_>>Тот же MSDN выдает только первые 500 найденных результатов
A>Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?
Получать результат и выводить его — это не всегда одно и то же
Здравствуйте, Andrbig, Вы писали:
A>Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?
Вообще-то смысла в поисках в результате нет вообще. Есть смысл в уточнении запроса. А "поиск в результате" легко эмулируется путем добавления подзапроса (по AND).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Artem_, Вы писали:
_A_>Например у нас _A_>Есть база из договоров и ее надо просмтаривать, так есть контекстное меню в котором выбираются различные действия с ними. Специфика такая что пляшем от договоров, поэтому основная работа ведется именно с этим окном.
Ребат, вы меня извините, но ваша программа никуда не годна если она заставляет пользователя просматривать тысячи записей.
Зачем пользователю читать все подряд? Ему же найти что-то нужно. Так? А раз так, то дайте ему сделать это удобно, а не перебором.
Если же ему нужно просто просматривать тысячи договоров по очереди, то зачем список? Ведь он их все равно по одному смотреть будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrbig, Вы писали:
A>>Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?
VD>Вообще-то смысла в поисках в результате нет вообще. Есть смысл в уточнении запроса. А "поиск в результате" легко эмулируется путем добавления подзапроса (по AND).
Ну и я о том же. "Поиск в результатах" в том виде как он есть сейчас — фигня.
Здравствуйте, VladD2, Вы писали: VD>Ты конечно волен делать и так. Но я бы такого работника выгнал, так как мне не нужны не эффективные работники.
А кто сказал, что я бы пошел к тебе работать? При таком отношении, лучше работать в другом месте в более комфортных условиях. Хотя чем черт не шутит возможно и придется
Здравствуйте, Andrbig, Вы писали:
S>>Да, готов. Может быть не сразу — у меня еще и работа есть A>Ok, отлично. Я заведу ветку в алгоритмах, здесь же дам ссылку. Только тоже не сразу — и у меня еще есть работа.
В алгоритмах это оффтопик. ИМХО лучше в проектирование или вобще в юзабилити.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VGn, Вы писали: VGn>Наш чувак . Даёшь гриды с полным содержимым БД .
Если бы мы загрузили все содержимое базы данных, памяти бы на машине не хватило
А начитать список договоров, дело необходимое, их просматривать нужно и искать среди них ...
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, VGn, Вы писали: VGn>>Наш чувак . Даёшь гриды с полным содержимым БД . _A_>Если бы мы загрузили все содержимое базы данных, памяти бы на машине не хватило _A_>А начитать список договоров, дело необходимое, их просматривать нужно и искать среди них ...
Искать их нужно, но зачем же грузить всё в память? Делаешь текстбокс и листвью под ним. При наборе текста в текстбоксе, если там введено 2 или более символов идёт запрос к базе, из которого заполняется листвью. Чего же проще?
Re[3]: Usability длинных списков
От:
Аноним
Дата:
25.04.06 05:41
Оценка:
Здравствуйте, anton_t, Вы писали:
_>Здравствуйте, _Artem_, Вы писали:
_A_>>Здравствуйте, VGn, Вы писали: VGn>>>Наш чувак . Даёшь гриды с полным содержимым БД . _A_>>Если бы мы загрузили все содержимое базы данных, памяти бы на машине не хватило _A_>>А начитать список договоров, дело необходимое, их просматривать нужно и искать среди них ...
_>Искать их нужно, но зачем же грузить всё в память? Делаешь текстбокс и листвью под ним. При наборе текста в текстбоксе, если там введено 2 или более символов идёт запрос к базе, из которого заполняется листвью. Чего же проще?
Свой результ (profx@inbox.ru) куда уходит память в общем смысле
память 128
90-110 система
операционная конечччно
10-40 ворд + ексел + почта
начинается свап смысла запускать net приложения нет но РАБОТАЕТ и ниче
формы много штук по 5000 записей
256 катит нормально
20-40 программа на нете (причем в процессе примерно 50 форм и 25 отчетов с обработкой более не видел и с гридами)
40-60 для нета (ядро + либы + самое главное native либы они подружаются точнее компилируются в процесе
но можете сделать ngen'om и увидите как и что кушает память любой нормальным менеджером памяти
т.е 110+40+40+60=250 как раз 256
из всего перечисленного только от 256 стоит работать клиенту
что касается скорости очень влияет сами понимаете почему антивирус + дефрагментация диска на подгрузку либов и нета
Здравствуйте, anton_t, Вы писали:
_>Искать их нужно, но зачем же грузить всё в память? Делаешь текстбокс и листвью под ним. При наборе текста в текстбоксе, если там введено 2 или более символов идёт запрос к базе, из которого заполняется листвью. Чего же проще?
А то, что нужно выводить их в гриде, что тут непонятного? ListView не подойдет. Нужно выводить весть список договоров!
VGn>>Наш чувак . Даёшь гриды с полным содержимым БД . _A_>Если бы мы загрузили все содержимое базы данных, памяти бы на машине не хватило _A_>А начитать список договоров, дело необходимое, их просматривать нужно и искать среди них ...
Ни один нормальный человек не нуждается в ручном пролистывании 10000 строк в гриде.
Надо логичным образом ограничивать выборку.
А для того чтобы искать, всю таблицу в грид грузить не надо.
Здравствуйте, VGn, Вы писали: VGn>Вы нормально можете объяснить за каким х** ВЕСЬ? VGn>Религия такая?
А что 10000 записей по Вашему много?
Уже есть сложившийся интерфейс программы, хотим его переписать под .Net.
Здравствуйте, VGn, Вы писали: VGn>Ни один нормальный человек не нуждается в ручном пролистывании 10000 строк в гриде. VGn>Надо логичным образом ограничивать выборку.
Почему Вы так решили? Мне кажется существует много различных областей где нужно просматривать и больший объем информации ...
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, VGn, Вы писали: VGn>>Ни один нормальный человек не нуждается в ручном пролистывании 10000 строк в гриде. VGn>>Надо логичным образом ограничивать выборку. _A_>Почему Вы так решили? Мне кажется существует много различных областей где нужно просматривать и больший объем информации ...
В каждый момент времени в этом гриде видно одну страницу записей (ну пусть 30-40 штук), пользователь за раз может охватить 7-9 записей. И не важно сколько вообще записей в гриде, для пользователя эти числа не меняются — значите есть возможность изменить способ подгрузки записей из базы и тем самым сократить объем используемой памяти.
10000 строк — это примерно 300 страниц печатного текста
нужно ли Вам в короткий момент времени видеть 300 страниц текста?
или редактировать за раз эти 300 страниц?
Здравствуйте, RuneLord, Вы писали:
RL>Объясните откуда такое бредовое требование все и сразу?
Я понимаю человека, кто написал исходное письмо — ну подписал неудачно ТЗ, есть до сих пор заказчики такие, которые упертые и хотят видеть все 10 млн записей сразу. Зачем — сказать никто не может внятно, "хочу и все". Приходиться искать обходные маневры
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Usability длинных списков
От:
Аноним
Дата:
26.04.06 12:38
Оценка:
Здравствуйте, denisio_mcp, Вы писали:
_>Здравствуйте, RuneLord, Вы писали:
RL>>Объясните откуда такое бредовое требование все и сразу?
_>Я понимаю человека, кто написал исходное письмо — ну подписал неудачно ТЗ, есть до сих пор заказчики такие, которые упертые и хотят видеть все 10 млн записей сразу. Зачем — сказать никто не может внятно, "хочу и все". Приходиться искать обходные маневры
ребята вы че !!! я же все написал скоко памяти нет ест !!! (prox@inbox.ru)
что касается 10000 это нормально и даже очень нормально так удобнее список просматривать чем всякие там фильтры
10000 мало в примерах приводится как минумум в трех пакетах компонентов
на 1 000 000 (миллион записей) примеры и память есть ну не более 20МБ поищите посмотрите
и не мудрствуйте !!!!
_>Я понимаю человека, кто написал исходное письмо — ну подписал неудачно ТЗ, есть до сих пор заказчики такие, которые упертые и хотят видеть все 10 млн записей сразу. Зачем — сказать никто не может внятно, "хочу и все". Приходиться искать обходные маневры
Здравствуйте, RuneLord, Вы писали:
RL>На пример?
Например у нас
Есть база из договоров и ее надо просмтаривать, так есть контекстное меню в котором выбираются различные действия с ними. Специфика такая что пляшем от договоров, поэтому основная работа ведется именно с этим окном.
Здравствуйте, _Artem_, Вы писали: _A_>Есть база из договоров и ее надо просмтаривать, так есть контекстное меню в котором выбираются различные действия с ними. Специфика такая что пляшем от договоров, поэтому основная работа ведется именно с этим окном.
И что? Есть какая-то задача, требующая наличия именно >10000 договоров в одном окне? Или все-таки вас заставили прикрутить к этому окну фильтры, чтобы пользователи не утонули в этом списке?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>И что? Есть какая-то задача, требующая наличия именно >10000 договоров в одном окне? Или все-таки вас заставили прикрутить к этому окну фильтры, чтобы пользователи не утонули в этом списке?
Фильтр есть, но и никто не пользуется. Есть поиск по номеру договора, и по любой колонке вообще.
Здравствуйте, _Artem_, Вы писали: _A_>Фильтр есть, но и никто не пользуется. Есть поиск по номеру договора, и по любой колонке вообще.
То есть список, фактически, совершенно не нужен. Реальная задача пользователя — найти требуемый договор. При этом спорю, что если попытаться расшифровать понятие "требуемый", то там явно выделяется поиск по номеру, поиск по клиенту, и все остальные типы поиска. Что подсказывает способ реализации удобного UI: оптимизировать его под эти специфические задачи.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Usability длинных списков
От:
Аноним
Дата:
27.04.06 05:52
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _Artem_, Вы писали: _A_>>Фильтр есть, но и никто не пользуется. Есть поиск по номеру договора, и по любой колонке вообще. S>То есть список, фактически, совершенно не нужен. Реальная задача пользователя — найти требуемый договор. При этом спорю, что если попытаться расшифровать понятие "требуемый", то там явно выделяется поиск по номеру, поиск по клиенту, и все остальные типы поиска. Что подсказывает способ реализации удобного UI: оптимизировать его под эти специфические задачи.
Здравствуйте, _Artem_, Вы писали:
_A_>А начитать список договоров, дело необходимое, их просматривать нужно и искать среди них ...
10 000 договоров просматривать по доному? И кто способен на такой подвиг?
Я как пользователь хотел бы от систем подобной вашей хороший поиск. Чтобы мне были выданы 1-10 довговоро отвечающих неким критериям. И уж на них то памяти хватит из любого положения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Artem_, Вы писали:
_A_>А то, что нужно выводить их в гриде, что тут непонятного? ListView не подойдет. Нужно выводить весть список договоров!
А зачем весь то? Ну, ты сам попробй просмотреть 10 000 довговорв! Озвереш ведь!!!
Найди где-нить системы вроде Референта/Консультанта/Гаранта и погляди на их поиск.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Artem_, Вы писали:
VGn>>Вы нормально можете объяснить за каким х** ВЕСЬ? VGn>>Религия такая? _A_>А что 10000 записей по Вашему много?
Ага. Невероятно. На неделю просмотра для среднего человека.
И я согласен с товарищем, кроме как религией вывод 10 000 записей на экран объяснить нельзя ни чем.
_A_>Уже есть сложившийся интерфейс программы, хотим его переписать под .Net.
На фиг такой интерфейс. Не пререгладывайте ISAM-ные привычки на клиент-серверные решения. Делайте запрос вычисляющий количество документов и выводите эту информацию. А список огрничивайте сотней записей, ну, максимум 1000-ей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Artem_, Вы писали:
_A_>Почему Вы так решили? Мне кажется существует много различных областей где нужно просматривать и больший объем информации ...
Примеры можно привести? Я вот и сам бухгалтерией занимаюсь, и не мало решений делал/видел в этой области. И уверен, что просматривать более 20 записей смысла нет. А раз так, то есть туча решений от подлистывания инфромации (а-ля Гугль), до уточнения запросов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Память и .Net
От:
Аноним
Дата:
27.04.06 20:10
Оценка:
А у меня 20000 строк отображается, а в них — 6 полей %). Это было очень жесткое требование -- отображать все записи.
Соответственно, вот тесты. Все проведены на одном компьютере с WinXP. Все данные округлены +/- 5.
1. 128 МБ RAM практически равноценен 256 МБ RAM и 758 МБ RAM ввиду того, что без загруженной программы системой используется только 67 МБ RAM
С закрытым НД -- 35 МБ
С открываем НД -- 45 МБ
Ищем не встечающуюся строку -- 45 МБ
Закрываем НД -- 45 МБ
Минимизируем приложение -- 700 кБ
Теперь снова показываем форму -- 4 МБ
Открываем НД — 14 МБ
Ищем не встечающуюся строку -- 14 МБ
Минимизируем приложение -- 730 кБ
И так делее...
2. 64 МБ RAM !!! Системой занята вся память.
С закрытым НД -- 5 МБ
С открываем НД -- 30 МБ
Ищем не встечающуюся строку -- 30 МБ
Закрываем НД -- 45 МБ
Минимизируем приложение -- 700 кБ
Теперь снова показываем форму -- 5 МБ
Открываем НД — 15 МБ
Ищем не встечающуюся строку -- 15 МБ
Минимизируем приложение -- 600 кБ
И так делее...
Из всего этого делаем вывод, что фактически требуется не более 5 метров на интерфейс и 10 метров на работу с БД (грубо, но понятно)
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, Sinclair, Вы писали: S>>И что? Есть какая-то задача, требующая наличия именно >10000 договоров в одном окне? Или все-таки вас заставили прикрутить к этому окну фильтры, чтобы пользователи не утонули в этом списке? _A_>Фильтр есть, но и никто не пользуется. Есть поиск по номеру договора, и по любой колонке вообще.
ну если юзеры так уперто не хотят пользоваться поиском — то тогда не грузить все в грид, а подгружать в процессе пролистывания...
ЗЫ. Оттого, что хочется загнать 10000 записей в память и съедается много памяти — это не вина .NET...
Re[7]: Usability длинных списков
От:
Аноним
Дата:
27.04.06 22:28
Оценка:
_A_>>Уже есть сложившийся интерфейс программы, хотим его переписать под .Net.
А стоит ли ?
Может как в анекдоте про программера:
-Пап, а почему солнышко каждый день на востоке встаёт ?
-Проверял сынок ? Точно на востоке встаёт ?
-Да, точно.
-Ну тогда ничего не трогай сынок, ничего не меняй.
Здравствуйте, VladD2, Вы писали:
VD>10 000 договоров просматривать по доному? И кто способен на такой подвиг?
VD>Я как пользователь хотел бы от систем подобной вашей хороший поиск. Чтобы мне были выданы 1-10 довговоро отвечающих неким критериям. И уж на них то памяти хватит из любого положения.
Требуется ввод информации по этим договорам, каждый месяц. Затем требуется проверка введенной в другом месте информации. Грубо говоря, есть сеть филлиалов, в которой вводится информация по этим договорам, после чего данные передаются в центр, где их проверяют и выставляют клиентам. Поэтому и требуется грид.
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, anton_t, Вы писали:
_>>Искать их нужно, но зачем же грузить всё в память? Делаешь текстбокс и листвью под ним. При наборе текста в текстбоксе, если там введено 2 или более символов идёт запрос к базе, из которого заполняется листвью. Чего же проще? _A_>А то, что нужно выводить их в гриде, что тут непонятного? ListView не подойдет. Нужно выводить весть список договоров!
Можно точно так же их выводить в гриде. Зачем пользователю СРАЗУ 10000 записей?
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, VladD2, Вы писали:
VD>>10 000 договоров просматривать по доному? И кто способен на такой подвиг?
VD>>Я как пользователь хотел бы от систем подобной вашей хороший поиск. Чтобы мне были выданы 1-10 довговоро отвечающих неким критериям. И уж на них то памяти хватит из любого положения. _A_>Требуется ввод информации по этим договорам, каждый месяц. Затем требуется проверка введенной в другом месте информации. Грубо говоря, есть сеть филлиалов, в которой вводится информация по этим договорам, после чего данные передаются в центр, где их проверяют и выставляют клиентам. Поэтому и требуется грид.
А почему не сделать пэйджинг (как в гугле)? Уже, кстати, советовали.
Здравствуйте, Andrbig, Вы писали:
A>Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.
Ну во-первых для этого не надо держать весь список в памяти. Посмотрите на Google Suggest... Он что по-вашему, держит все сочетания слов со статистикой использования в памяти (JScript, медленный интернет...)? Если нужен скроллинг, то существует страничный доступ... Другой вопрос, что, конечно, программисту проще не париться и залить все 10000 строк сразу... А когда у клиента их будет миллион, то программист скажет, что на это он, конечно, не рассчитывал, но, конечно, подумает что тут можно сделать... И сделает чтобы они чуть поменьше в памяти занимали, дождавшись, когда их будет 10 миллионов.
Здравствуйте, Max.Subpixel, Вы писали:
MS>Здравствуйте, Andrbig, Вы писали:
A>>Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.
MS>Ну во-первых для этого не надо держать весь список в памяти. Посмотрите на Google Suggest... Он что по-вашему, держит все сочетания слов со статистикой использования в памяти (JScript, медленный интернет...)? Если нужен скроллинг, то существует страничный доступ... Другой вопрос, что, конечно, программисту проще не париться и залить все 10000 строк сразу... А когда у клиента их будет миллион, то программист скажет, что на это он, конечно, не рассчитывал, но, конечно, подумает что тут можно сделать... И сделает чтобы они чуть поменьше в памяти занимали, дождавшись, когда их будет 10 миллионов.
Я и не говорил, что список надо перебирать глазами. Я говорил о фильтрации.
OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции.
Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться.
Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз.
Что удобнее юзеру и где меньше возможностей запутаться?
Здравствуйте, _Artem_, Вы писали:
_A_>Требуется ввод информации по этим договорам, каждый месяц. Затем требуется проверка введенной в другом месте информации. Грубо говоря, есть сеть филлиалов, в которой вводится информация по этим договорам, после чего данные передаются в центр, где их проверяют и выставляют клиентам. Поэтому и требуется грид.
И за месяц появляется по 10 000 договоров?
Если, нет, то и выводи договоры за месяц. Думаю их уже будет разумное количество.
Если же их и в этом случае будет много, то дай возможность фильтровать договоры по датам (с — по). Если программа будет запоминать этот фильтр между сеансами ты еще поможешь людям видеть что они сделали, а что нет.
Ну, и вообще если речь идет о последовательном контроле, то грид на фиг не упал. Выводи один договор и сделай две кнопки "следующий договор" и "предыдущий договор".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _Artem_, Вы писали:
VGn>>>Вы нормально можете объяснить за каким х** ВЕСЬ? VGn>>>Религия такая? _A_>>А что 10000 записей по Вашему много?
VD>Ага. Невероятно. На неделю просмотра для среднего человека.
VD>И я согласен с товарищем, кроме как религией вывод 10 000 записей на экран объяснить нельзя ни чем.
_A_>>Уже есть сложившийся интерфейс программы, хотим его переписать под .Net.
VD>На фиг такой интерфейс. Не пререгладывайте ISAM-ные привычки на клиент-серверные решения. Делайте запрос вычисляющий количество документов и выводите эту информацию. А список огрничивайте сотней записей, ну, максимум 1000-ей.
Тот же MSDN выдает только первые 500 найденных результатов
Здравствуйте, Andrbig, Вы писали:
A>Здравствуйте, Max.Subpixel, Вы писали:
A>Я и не говорил, что список надо перебирать глазами. Я говорил о фильтрации.
Я тоже об этом говорил — для фильтрации не надо поднимать в память все объекты...
A>OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции.
A>Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться.
A>Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз.
A>Что удобнее юзеру и где меньше возможностей запутаться?
Я что-то вообще не пойму о чем речь. Что удобнее??
Можно как угодно сделать и не поднимать ВСЕ объекты разом в воздух. КАК УГОДНО
Здравствуйте, RuneLord, Вы писали:
RL>Выводить все 10000 договоров — это преотличнейшее юзабилити, пускай юзера, вместо того чтобы пасьянсы расскладывать, тренируют свои глаза бегая по гриду из 10000 строк. Правильно работать надо, а не фигней страдать.
RL>Объясните откуда такое бредовое требование все и сразу?
Обычно это результат долгого общения с ISAM СУБД вроде BBASE, Paradox. Там частенько применялись "активизации индекса" или как их там назвать. При этом можно было перебирать записи в соотвествии с индексом и даже искать по первым буквам. Люди переходя на серверные приложения с ISAM СУБД просто по привычке пытаются использовать старый опыт. А он уже никуда не годится.
Ну, а в этом случае ко всему еще прибавились накладные расходы нового грида работающего с памятью в невиртуальном режиме довольно вольготно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Память и .Net
От:
Аноним
Дата:
29.04.06 20:24
Оценка:
2 Andrbig
Да по моему пока не нужно спорить с народом, причины этого лежат глыбже
Как-нить спишемся, поговорим.
Здравствуйте, RuneLord, Вы писали:
RL>Выводить все 10000 договоров — это преотличнейшее юзабилити, пускай юзера, вместо того чтобы пасьянсы расскладывать, тренируют свои глаза бегая по гриду из 10000 строк. Правильно работать надо, а не фигней страдать.
RL>Объясните откуда такое бредовое требование все и сразу?
А что делать, если никакое регулярное выражение для поиска нужной строки юзер подобрать не может
Вот и маются бедолаги прибегая к своим критериям поиска во всем потоке данных.
и солнце б утром не вставало, когда бы не было меня
Re[6]: Память и .Net
От:
Аноним
Дата:
01.05.06 12:02
Оценка:
Здравствуйте, Andrbig, Вы писали: A> Правильно — это как, воинственный ты наш? Например, юзеру надо что-то найти, он открывает поисковую форму (или переключается в нее, если она уже открыта), попадает мышью в нужное поле, вводит там строку поиска, жмет кнопку "Искать". Программа находит 5000 элементов. Он снова переходит в поисковую форму, дополняет поиск (а это может быть пара букв), снова жмет, программа находит, он снова переключается — и так до тех пор, пока не будет найдено приемлимое число.
A> Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.
1. Принять стёб за воинственность? Извините
2. В предложении "Правильно работать надо, а не фигней страдать" после слова "правильно" имелась ввиду запятая , но и с таким вариантом я согласен.
3. По-поводу примера, есть у нас программулина (на клиппере еще писанная) с таким интерфейсом, которая делает задачу попроще: просто становится на первую строчку начинающуся с введенного текста. Так вот в списке из 10000 строк для меня очевидно, что одной буквы будет не достаточно чтобы найти то что надо, понадобится несколько больше, и вот то что программулина фигней страдает после каждого нажатия жутко раздражает. Я бы предпочел чтобы действия по поиску или тому подобному начиналась по моей команде, т.е. я ввожу текст и жму enter — ИМХО лучшее юзабилити, чем автомат после каждой буквы. Как показывает наш опыт, поиск по одной букве нужен только людям, которые не знают чего они ищут. По-моему очевидно, модификация сценария с enter'ом является как раз средним между описанными вами. Будем считать количество кликов и нажатий клавиш и их существенность (клавиша ввода не зря такая большая)?
4. Польностью согласен с A> "Правильно работать" для сервера и программиста не всегда совпадает с "удобно работать" для юзера, увы.
И тут как раз работать со списком в 10000 строк сразу — это удобство для программера, а никак не для юзера.
5. Даже для описанного вами сценария не проглядывается необходимость иметь все и сразу.
6. RL>>Объясните откуда такое бредовое требование все и сразу? A> То что ты его не понимаешь не значит что оно бредовое.
Вот я и стараюсь понять, чтобы оно для меня перестало быть бредом.
Теперь ко второму посту: A> OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции. A> Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться. A> Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз. A> Что удобнее юзеру и где меньше возможностей запутаться?
1. Мне интересно, вы подгоняете задачи под условия "10000 строк все и сразу" или приводите реальные задачи?
2. Мне как юзеру в этой задаче нужно выделить скажем 10 строчку, глазами проскролить с шифтом до 8752 строки??? А там точно не надо пропустить с 5632 строки по 5676? Я что сумашедший? Да я просто выкину такую программу, если автор сего творения решил сделать супер универсальный интерфейс, вместо того чтобы посмотреть какие бывают юзкейсы и для каждого сделать соотвествующий. Вы что, сравнивая очень очень плохой интерфес с просто очень плохим, обосновываете необходмость в списке из 10000 строк?
Здравствуйте, 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>А если не знашь, то нужно не искать, а сосредоточиться на формулировании вопроса. Можно еще у других спросить.
У меня народ активно применяет регулярные выражения и то бывает в затыке.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Andrbig, Вы писали:
A>Вот мы добрались и до бизнес-сценария. Опытный проектировщик предложил идентифицировать бизнес-сценарий и под него написать UI. Видимо обилие опыта заслонило проектировщику тот маленький факт, что бизнес-сценарий может быть просто неизвестен на момент разработки программы.
Если заказчик/пользователь не может объяснить зачем ему эта функциональность и какие задачи он собирается решать с ее помощью то смысла реализовывать эту функциональность нет никакого (кроме как сбить побольше денег с заказчика или показать начальству что мы вот работаем).
Здравствуйте, Andre, Вы писали:
A>Если заказчик/пользователь не может объяснить зачем ему эта функциональность и какие задачи он собирается решать с ее помощью то смысла реализовывать эту функциональность нет никакого (кроме как сбить побольше денег с заказчика или показать начальству что мы вот работаем).
Это в идеальном мире. А в реальном — часто бывает, что заказчик/пользователь не может внятно объяснить < ... >. И с этим надо как-то жить. Потому что заказчик может быть большой и богатый, а кушать хочется. И хотя при грамотной огранизации работы над проектом, обычный программист с "проблемой заказчика" не столкнется, грамотная огранизация бывает только в идеальном мире. А в реальном...
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Это в идеальном мире. А в реальном — часто бывает, что заказчик/пользователь не может внятно объяснить < ... >. И с этим надо как-то жить. Потому что заказчик может быть большой и богатый, а кушать хочется. И хотя при грамотной огранизации работы над проектом, обычный программист с "проблемой заказчика" не столкнется, грамотная огранизация бывает только в идеальном мире. А в реальном...
Если заказчик не может внятно объяснить что ему нужно, пусть опишет письменно Обычно на этом этапе уже большой отсев идей. Далее нужно задавать уточняющие/наводящие вопросы. Дать время пусть думает если нужно. Иногда через месяц ничего уже не нужно Если сопротивляется, значит все таки что то в этом есть. Придется предлагать наводящие идеи по ходу уточняя. Здесь можем прийти или к "внятному" описанию или все таки решению что это не нужно.
Да, это не проблема разработчика. Такие вещи вообще не должны его волновать и такие задания не должны доходить до него. Выдав в таком случае задание на разработку (хотя как тут сформулировать требования к задаче ) получим соответственно "грид с 10000 записями" и 99.9% что это будет переделано. Да, бывают исключения в виде форс-мажоров, богатых дядек и т.д.. Из приведенных выше обрывочных описаний у меня не сложилось впечатление что это такой исключительный случай.
p.s. Я наверное зажрался, работая в последнее время в комфортных условиях, когда какая то фича делается не потому что так кому то захотелось, а это входит в план, описано в требованиях, проработано и согласовано с заказчиком аналитиками.
>>Если заказчик не может внятно объяснить что ему нужно
Беседовать с заказчиком должен не разработчик, который только от "станка" отошел, а психолог. Опытный психолог. У разработчика и клиента разный уровень восриятия. Первый мыслит на уровне API, другой на уровне эмоций, каких-то своих ассоциаций и амбиций.
>>Обычно на этом этапе уже большой отсев идей.
Это плохо. Нужно помогать рождаться идеям. Из них можно извлечь много путного и для других проектов. Идеи на полу валяются. Их нужно уметь ценить.
>>Иногда через месяц ничего уже не нужно
Ну вот. Упустили клиента и радости полные штаны...
>>Да, это не проблема разработчика. Такие вещи вообще не должны его волновать и такие задания не должны доходить до него.
Не волновать такие вещи могут разработчика в одном единственном случае: от этого не зависит его заработная плата.
>>Я наверное зажрался, работая в последнее время в комфортных условиях, когда какая то фича делается не потому что так кому то захотелось, а это входит в план, описано в требованиях, проработано и согласовано с заказчиком аналитиками.
Зажрались, батенька Сам сейчас весь в XP ушел. Ибо по другому никак
Здравствуйте, Andre, Вы писали:
A>Если заказчик не может внятно объяснить что ему нужно, пусть опишет письменно Обычно на этом этапе уже большой отсев идей.
См. пункт второй — "И хотя при грамотной организации работы над проектом..." — а ты сейчас именно эту организации и описываешь. Она, конечно, бывает в природе, но чаще все-таки ее не бывает.
A>p.s. Я наверное зажрался, работая в последнее время в комфортных условиях, когда какая то фича делается не потому что так кому то захотелось, а это входит в план, описано в требованиях, проработано и согласовано с заказчиком аналитиками.
Наверное
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Память и .Net
От:
Аноним
Дата:
03.05.06 06:02
Оценка:
Господа, а чего спорить-то? Всё зависит от конкретного случая.
Из моего скромного опыта, превыборка гораздо эффективнее (при числе строк до 20 000). Во-первых, в противном случае приходится вводить ещё один слой абстракции как на клиенте, так и на сервере. Во-вторых, гораздо лучше масштабируемость, снижается общая нагрузка на сервер и сеть. Заодно — меньше вероятность коллизий. (напоминаю, объём данных — константа, говорим о числе пользователей... порядка полусотни активно работающих с серваком на Cel2.4/512 Для действительно больших объёмов всё как раз наоборот...).
Насчёт производительности... Запрос 10 338 строк в 5 таблиц с кучей джойнов с холодного старта занимает 3,5 сек (на server-side — 1,5-2 сек). Повторный запуск — 3 сек. Ворксет после активной работы разрастается до 45 МБ, что, впрочем, мешает чисто психологически...
Это — в дебаге и из-под студии. В реальности производительность процентов на пятнадцать-двадцать выше...
А вот с отображением надо думать... Как насчёт введения древовидного каталогизатора + поиск?
Эмпирическое изучение граблей высоких энергий несколько затруднено…
Здравствуйте, Sinclair, Вы писали:
S>Да, готов. Может быть не сразу — у меня еще и работа есть
Ok, отлично. Я заведу ветку в алгоритмах, здесь же дам ссылку. Только тоже не сразу — и у меня еще есть работа.
Продожение следует...
Re[12]: Usability длинных списков
От:
Аноним
Дата:
04.05.06 12:43
Оценка:
Поддержу Andrbig'а. Требуются большие списки и очень часто.
Основной пример — психологический. Если пользователю от 40 лет и выше, то он в свое время наверняка работал с FoxPro программами, которые выводили все в виде длинных списков. В связи с этим у многих сформирован следующий стереотип: если я чего-то не вижу на экране монитора, то этого нет. Бороться с этим очень-очень сложно.
? Ой, оказывается она нам не понадобилась. И это не случайно — она неудобна для выполнения поставленных перед пользователем задач.
1.1.4 stable rev. 510
. Даёшь гриды с полным содержимым БД 
. 
Увы, не угадал.
