logo
logo

Форум Упрощение ввода (и вновь..)

создать новую тему раскрыть все
Упрощение ввода (и вновь..) Алексей 06/10/2005 19:53 #написать ответ
Есть такое предложение об упрощении ввода:
Разрешить использование «персональных» полей ввода для разных ветвей одного и того же дерева статей.  
Поясняю. Сейчас в окне «добавить операцию» (секция - Счета, реквизиты) каждое поле ввода принадлежит одному конкретному классификатору: напр. «Статья», «Клиент» и т.д. Я предлагаю использовать несколько полей ввода для одного классификатора: помимо общего поля «Статья», мне бы хотелось иметь поля <B>подстатей</B> «Авто», «Продукты» и т.д. (выбирается самостоятельно до какого-то разумного предела)  
Вот бы! А?!
Для этого можно Loki 07/10/2005 18:41 #написать ответ
и нужно ветвить статьи: чем мельче будет каждая ветка, тем геморройнее вводить данные, но тем точнее учет
А чем Алексей 07/10/2005 18:43 #написать ответ
это поможет?
Вероятно, я вас неправильно понял + Loki 07/10/2005 18:57 #написать ответ
Как это должно выглядеть?
Я имел Алексей 10/10/2005 21:05 #написать ответ
ввиду следующее: при вводе операции получить прямой доступ в виде отдельного поля к разным ветвям одного дерева статей. Конечно, вводя информацию не в каждое, а только в нужное. Если пользователь делает выбор в другом поле, то предыдущий выбор обнуляется. Т.е. в операции не будет одновременного выбора нескольких разныхстатей. В некоторых случаях, при сложной, ветвистой иерархии, таким образом можно упростить ввод. Как я думал. Но, видимо, это усложняет восприятие интерфейса, по крайней мере у новичка. А если это будет опционально, то и не напряжно. И, конечно, все дело в визуальном представлении.  
Стало ясно еще меньше прежнего:) Loki 11/10/2005 10:58 #написать ответ
&gt;Если пользователь делает выбор в другом поле, то предыдущий выбор обнуляется.  
А сейчас разве происходит не так?
 
Или вы имеете ввиду, что дерево статей должно отображаться полностью в дополнительном поле?
Я имею Алексей 11/10/2005 12:21 #написать ответ
в виду, что поле открывается уже в нужной группе (ветви), название которой есть имя этого поля. И для такого поля совсем не нужно все остальное дерево, так как есть поле, которое раскрывает его все - это обычное поле классификатора, которым мы все сейчас и пользуемся.  
Об упрощении ввода Denis ® 11/10/2005 12:34 #написать ответ
Возможно, Вы имеете в виду возможность ввода в поле название статьи с клавиатуры, и чтобы конец этого названия автоматически подставлялся (а при наличии нескольких значений удовлетворяющих вводу предлагался выпадающий список с выбором этих нескольких значений)?
У Вас Алексей 11/10/2005 13:15 #написать ответ
есть классификатор "Статьи"? Думаю - да. У Вас есть статья "Продукты питания" (или что-то типа)? Скорее всего - да. Если нет - просто представьте. У некоторого пользователя есть БОЛЬШОЕ (длинное, ветвистое, могучее) дерево классификатора "Статьи". Вот чтобы начать ввод именно со статьи "Продукты питания" нужно ткнуться в поле классификатора "Статьи" который содержит группу статей "Продукты питания" (в окне "добавить операцию") и отмотать вниз весь большой, могучий корневой список дерева классификатора, чтобы увидеть наконец на букву "П" эту самую группу статей "Продукты питания". Поработав с ней, у некоторого пользователя появляется необходимость ввести пару операций по группе статей "Авто". Опять тыкаемся в поле "Статьи", раскрывается кишкообразное окошко (потому что длинное) и мотаем теперь все на верх. И так далее.  
Думаю, сейчас посыпятся инструкции по оптимизации сознания во время ввода типа: "перед вводом операций, отсортируйте их в уме по алфавиту".
Или, конечно, будет совет сворачивать отработанные группы статей, чтобы сократить длину дерева.
А ведь я привел пример переключения только между корневыми группами. А если нужно перепархивать с ветки на ветку второго или более высокого уровня? Тут замумукаешся. Вот я и предлагаю, для таких неудобных или далеких статей, или целых групп, вывести доп. поле ввода. Блин, ну чего тут непонятного?
Либо я тупой, либо одно из двух Loki 11/10/2005 22:13 #написать ответ
Алексей, вашими объяснениями и своими молитвами я, наконец, понял суть проблемы. Решение же, традиционно, ускользнуло:
&gt;предлагаю, для таких неудобных или далеких статей, или целых групп, вывести доп. поле ввода
 
Перечитал раз восемь... на ночь буду перечитывать еще... но все равно мне кажется что разгадываем шарады.
Вы предлагаете, держать где-то поблизости надавно использованные значения классификаторов? Угадал?
Это не трэд.... Андрей 12/10/2005 16:13 #написать ответ
.... это "Гы, lol, аффтар песшы исчо - готично!"
)))))))))))))))))))))))))
Значит не угадал... Loki 12/10/2005 16:35 #написать ответ
Черт с вами - давайте следующую подсказку
 
- Василий Иванович, кто такой "дурак"?
- Дурак, это тот, кто не может объяснить другому так, чтобы ему это было понятно. Понял?
- Нет.

Позвольте мне? :) Дим(м) 14/10/2005 00:08 #написать ответ
Идея Алексея, видимо, состоит в следующем. Если, например, в базе есть классификатор Статьи со следующей структурой:
- Продукты
--- Молоко
--- Хлеб
- Авто
--- Бензин
--- Масло
 
то на диалоге редактирования операции должно быть два поля для выбора Статьи! В одном из них будут варианты Молоко и Хлеб, в другом - Бензин и Масло. Соответственно, при выборе значения в одном из этих полей второе должно автоматически очищаться (не может ведь у операции быть 2 Статьи сразу).
 
Но лично мне кажется, что этот вариант плох, как с точки зрения его реализации (до какого уровня прикажете дробить поля? только верхние? я если бы я еще парочку подстатей хотел вынести для быстрого доступа?). Очевидно, здесь нужно какое-то ограничение на кол-во таких дубликатов полей. А также нужен какой-то способ позволяющий для каждого из них задать, какую же именно ветку в нем надо показывать и т.д.
Кроме того, это, мягко скажем, довольно неординарное решение 100% вызовет вопросы у всех, кроме того, кто его придумал и того, кто его реализовал. Взять для примера одни только попытки объяснения сути предлагаемого решения в этом топике.
 
Мне все же кажется, что возможность вводить текст в поля классификаторов с автоматическим поиском подходящих вариантов по всем ветвям дерева и показ их в виде выпадающего списка - это более изящное и не менее мощное решение для ускорения ввода. Например, для описанного выше дерева статей, чтобы выбрать статью Молоко достаточно будет нажать всего 2 клавиши: `м` и `о`! Аналогично, Масло выбирается клавишами `м` и `а`. А все остальные статьи - вообще нажатием одной первой буквы.
Кстати, про Масло.. Дим(м) 14/10/2005 00:09 #написать ответ
Очевидно, статья с таким же названием может быть и в Продуктах. Соответственно, этот самый выпадающий список с найденными подходящими вариантами, должен также указывать и расположение в дереве каждого элемента. Например, так:
Продукты &gt; <B>Макароны</B>
Продукты &gt; <B>Масло</B>
Авто &gt; <B>Масло</B>
Продукты &gt; <B>Маслята</B>
(выделение жирным здесь важно, т.к. позволяет сфокусировать внимание на наиболее существенной части информации)
 
Или же так:
<B>Макароны</B>  (Продукты)
<B>Масло</B>     (Продукты)
<B>Масло</B>         (Авто)
<B>Маслята</B>   (Продукты)
(в скобках, конечно же, отображается полный путь к соотв. элементу в дереве; хорошо бы при этом также этот текст в скобках сделать каким-нть серым - чтобы он не сильно бросался в глаза и не захламлял общей картины)
Эх, немного не так я это рисовал.. Дим(м) 14/10/2005 00:12 #написать ответ
А ведь я выравнивал скобки по правому краю И отступ от основного значения делал побольше. Так и думал, что надо было подчеркивания использовать Может, на этот раз получится получше:
<B>Макароны</B>________(Продукты)  
<B>Масло</B>___________(Продукты)  
<B>Масло</B>_______________(Авто)  
<B>Маслята</B>_________(Продукты)
Ещё вариант IF 14/10/2005 09:45 #написать ответ
На самом деле, Dervish уже кажется не единожды давал понять что нечто подобное будет реализовано, а пока что приходиться только размышлять и делать предположения...
 
В указанном вами методе (если местоположение к-л статьи приписывать в скобках) будет не совсем правильным с точки зрения унификации общения с программой, потому как повится еще одно (отдельное) видение всего дерева и придёться ещё раз приспосабливаться.
Было бы, ИМХО, удобней сделать алгоритмы (с вариантами) поиска аналогичный использованным в небезызвестной программы Total Commander, а именно:
Например - при работе с деревом статей/счетов используется методика поиска по буквам - т.е. если набрали на кливиатуре букву "А", то фокус переместился на первую ветвь, например "Авто". Если это не та ветвь, которая необходима, то F3 или стрелки вверх/вниз (к примеру) и фокус перескакивает дальше... или можно просто набрать сразу несколько букв "АК" и после такого ввода факус будет скакать уже только по ветвям начинающихся с "АК". при всём при этом общее пользование ветвями происходит аналогично работе с папками (т.е. Enter или стрелка вправо  - раскрывает ветвь и переносит фокус на внутрение подветки, а Backspc или влево- возврат на уровень выше). После перенесения фокуса процесс поиска подветви повторяется.
Мне кажется Loki 14/10/2005 12:15 #написать ответ
что при этом навигация несколько усложниться и выигрыша не будет: во-первых надо будет помнить название всех родительских ветвей, во-вторых их надо будет раскрывать. Так что мне кажется надо какой-то другой способ использовать.
От чего же ? Алексей 14/10/2005 12:37 #написать ответ
Мне идея, предложенная Дим(м)ом кажется весьма привлекательной. Зачем запоминать что-то кроме того, что ты и так знаешь? Например, я сейчас забиваю расход на масло – используя поле классификатора, пишу в нем первые буквы того, на что потратился. Все варианты масел вывалятся в списке. Не думаю, что в этом случае нужно вырисовывать само дерево. По моему, весьма просто! К тому же сейчас поле классификатора используется как дубль кнопки раскрытия дерева, и выполнить в нем прямой ввод текста для выбора соответствующей статьи было бы логично.
но это же гораздо привычней IF 14/10/2005 12:59 #написать ответ
Разве нет? когда вы работаете с програмой с клавиауры в её текущем состоянии всё равно приходится сворачивать и разворачиват и прокручивать метры веток и листиков, а можно будет просто ускорить процесс поиса нужной категории. Стрелки и сейчас работают именно так как я вроде описывал, нехватает перехода фокуса по нажатию букв.
 
&gt;&gt;помнить название всех родительских ветвей
ну, я так понимаю человек сам создававший дерево имеет предтавлении где может лежать то, что он ищет и как он мог это назвать (ну хотя бы примерно) =))
 
Вариант с появляющимся полем ввода возможен, но я просто уже привык рыскать без всплывающих списков ИМХО они отвлекают. А если можно было выбирать... %-))
А может нагляднее было бы если бы Loki 14/10/2005 18:50 #написать ответ
при вводе текста фильтровались и отображались только те ветви, которые содержат данный текст?
Ввел букву, а внизу выпали возможные варианты, ввел вторую - количество вариантов уменьшилось и т.д. То есть можно либо выбрать вариант в списке, либо полностью ввести руками (точнее, логично было бы если бы подставился последний оставшийся вариант).
А в вашем варианте придется периодически прыгать к навигационным стралкам чтобы раскрывать ветви и перемещаться по ним.
Эта идея мне кажется оптимальной - (-) Андрей 14/10/2005 19:00 #написать ответ
Так а зачем же все самому? :) Дим(м) 14/10/2005 22:02 #написать ответ
Пускай программа сама ищет по всему дереву сразу. Т.е. я ввел три буквы - она нашла первую подходящую ветвь и установила на нее курсор. Я нажал стрелку вниз - она нашла следующую (не обязательно у того же самого родителя!) и поставила курсор на нее. И т.д.
Фактически, при таком подходе отличие от описанного мною выше варианта будет только в том, что в выпадающем списке не будет уменьшаться число элементов (оно наоборот будет увеличиваться по мере того, как все новые и новые узлы дерева будут раскрываться).
На мой взгляд, такое поведение, хотя и будет большим шагом вперед, все же не очень удачно с т.зр. usability. Во-первых, когда ты видишь в списке всего 3 варианта, сориентироваться гораздо проще, чем когда их всегда будет около десятка (т.е. я за фильтрацию). А во-вторых, при очень "густых" деревьях и теперешнем способе их отображения не всегда будет просто сориентироваться, а где же именно мы сейчас находимся - скорее всего, бОльшая часть родительских узлов (если не все) не будут видны. И чтобы определить текущий контекст, придется тянуться за мышкой, целиться в скролбар и тащить его вверх.
 
В общем, я считаю наиболее удачным с т.зр. юзабилити именно последний предложенный мною вариант (с путем к узлу в скобках). Первый несколько проигрывает тем, что названия узлов не выровнены по левому краю - соответственно, приходится "бегать глазами", когда просматриваешь список.
Попробуй это на google.com! Дим(м) 22/10/2005 14:42 #написать ответ
А вот как поиск вариантов реализован у профессионала поиска:
http://www.google.com/webhp?complete=1&amp;hl=en
(работает для английского языка)
 
Что-то очень похожее я как раз и имел в виду.
Поиск на Google Denis ® 24/10/2005 21:48 #написать ответ
Присоединюсь, реализации такого поиска мне не хватает в AbilityCash.
 
И лучше если такой механизм будет реализован не только в поиске по статьям, но и во всех классификаторах.
Теперь понял:) Loki 14/10/2005 11:20 #написать ответ
А то уже начал сомневаться в своей вменяемости
Спасибо!
Извините,... Dervish 07/10/2005 19:13 #написать ответ
...я не понял вашего вопроса (предложения).
 
Если речь идёт о подстатьях, то почему бы их не создать у отдельного родителя?
 
И вообще, как в одной операции могут быть указаны и «Авто» и «Продукты»? Какой в этом смысл?
 
И, самое главное, как это прикажете анализировать? Вот, например, стоится график по статьям и указан фильтр по статьям же. Какие операции выбирать, а какие нет?
И вы меня Алексей 11/10/2005 13:19 #написать ответ
извините. Чтобы не повторяться, взгляните, пожалуйста, на мои овтеты другим.
Взглянул. (+) Dervish 17/10/2005 13:38 #написать ответ
Думаю, что делать два поля для ввода статей не нужно, что это будет неправильно.
 
Обратите внимание, сколько пришлось потратить усилий для того чтобы объяснить людям что именно вы хотите и для чего это нужно. Мне хотелось бы сделать программу интуитивно понятной. А ваше предложение, судя по необходимости такого объяснения не отличается интуитивной простотой.
 
Кроме того, как я понимаю, речь идёт не только о статьях, чтобы всё было логичным, аналогичную возможность нужно дать для любого классификатора. И как программа должна определять количество полей для каждого классификатора? Понимаю, что единственная возможность, это через дополнительные настройки. Поймал себя на мысли, что не могу себе даже представить как именно это лучше делать.
 
В общем, считаю реализацию такой возможности неправильной. А тему считаю закрытой.
Есть еще такая тема Алексей 14/10/2005 13:21 #написать ответ
Нужно добавить на вкладку «Операции» поляну, на подобие развернутого отображения счетов. Эта поляна должна быть вертикальной во всю вкладку и отображать дерево статей или любого другого классификатора. Такую поляну нужно сделать легко скрываемой/раскрываемой, так как она будет забирать место у строк операций и не всегда будет нужна. А использовать ее во время ввода списка операций. В таком случае большая часть дерева или оно все (у кого как) будет непосредственно перед глазами. Все, что нужно – кликнуть по статье и получить окно ввода, в котором ввести только сумму.
Такой велосипед с успехом ездит во многих проектах, а я его с удовольствием использовал в программе, о которой у меня остались одни только теплые воспоминания - CashFly.
Очевидно, такой способ ввода интересен только тем, кто всегда имеет под рукой мыша. Но этих маргиналов великое множество!
 
Думаю, вариант о котором говорил Дим(м) – очень подходит для клавиатурного ввода, а поляна с деревом классификатора – для мышиного. Они оба мне кажутся очень привлекательными. Но я все же всегда имею под рукой мышь.
Опять же,... Dervish 17/10/2005 13:41 #написать ответ
...о каком именно классификаторе мы говорим? О статьях? Об агентах? О проектах?
 
Сколько классификаторов в вашей базе данных? В моей - три.
 
Сколько окон с классификаторами делать на странице операций? Сколько кликов нужно для того, чтобы добавить одну операцию если на закладке операций три окошка с классификаторами?
Согласен с Вами Алексей 17/10/2005 14:23 #написать ответ
такое поле, конечно, будет показывать любой имеющийся в базе классификатор. Какой нужен – такой и кажет. Но не более одного. Это же упрощение обычного (несложного) ввода, который составляет большинство записей в базе. А если нужно указывать несколько классификаторов, то и здесь ведь экономия налицо – начало то уже положено.
Но если мы говорим о том, что пользователь постоянно вводит несколько классификаторов – то это уже Вы решаете с помощью Ваших шаблонов, на которые я очень надеюсь.
У меня в одной базе 2 классификатора, в другой – 3.
Кстати, еще идея:
А что если у полей фильтра операций в журнале поставить галочку «использовать при вводе»?  Я говорю про: «Показывать операции:». Когда в поле классификатора на вкладке операций есть выбор, (напр. Клиент: Пупкин В.В.) и журнал фильтруется по этому классификатору – то при вводе этот клиент будет подставляться по умолчанию. Это как со счетами – какой выбран, того и вводимые операции.
И всё-таки мне не нравится... Dervish 26/10/2005 19:59 #написать ответ
...идея с двумя полями ввода для одного классификатора, извините.
 
А вот насчёт подстановки значений фильтров во вводимую операцию, так, собственно и планировалось. Обратите внимание: счета-то она подставляет... Должна и другие фильтры. Это недоработка, будет исправляться.
Хорошо, а Алексей 27/10/2005 12:34 #написать ответ
как насчет развернутого вида классификатора? Я имею ввиду примерно такое отображение, как у счетов на странице операций, только более вытянутое.  
Определять, какой классификатор должен быть развернут и, собственно, его разворачивать нужно прямо в окне ввода операций.  
Управлять этим можно с помощью галочки рядом с полем классификатора.  
Развернутым может быть только один классификатор, состояние которого сохраняется. (т.е. одновременно развернуть сразу несколько классификаторов невозможно, хотя это уже дело эргономики и возможности экрана)
Алексей, Edmonton 09/12/2005 15:51 #написать ответ
Думается мне, об этом же идет речь в ветке форума &lt;Диалог "ДобавитьИзменить операци&gt;...
 
Хотя дальше концепции не заходит...
Вообще, реализуемо, но... Dervish 12/12/2005 12:21 #написать ответ
...непонятно как именно раскрывать классификаторы. Неясен именно интерфейс.
Хотя,... Dervish 12/12/2005 12:23 #написать ответ
...если на диалоге для раскрытия классификатора нужен будет один клик, то... То, извините, а чем это будет отличаться от того, что сделано сейчас? По-моему ничем.
 
Может быть вернуться к этому вопросу после того, как будет проработано правильное сохранение настроек диалога?
Подразумевается, Алексей 12/12/2005 14:23 #написать ответ
что состояние развернутого классификатора сохраняется и повторный клик в дальнейшем не нужен.
Вся эта затея имеет смысл только при максимально возможном размере поля классификатора. А в текущем варианте, даже когда размер поля выбора классификатора будет сохраняться, его расположение не оптимально и все равно не позволит видеть список так, как в "специальном" поле.
 
Конечно, это попытки притянуть за уши CashFlyевский способ к Ability Cash.
 
Но все это меркнет по сравнению с вариантом, о котором говорит Дим(м):
 
А вот как поиск вариантов реализован у профессионала поиска:
http://www.google.com/webhp?complete=1&hl=en
 
Думаю, Это самый быстрый и простой ввод. (после варината Cash Fly
 
"Google-вариант" не затрагивает интрефейс, но подразумевает любовь пользователя к клавиатуре;
"Cash Fly-вариант" - прост, нагляден, быстр и весьма удобен, но, видимо, затрагивает фундаментальный подход автора к интерфейсу.
 
После многих раздумий (и чтений пейджера на ночь) я все же склоняюсь к Google-варианту.  
Чего и Вам желаю!
Мне тоже больше... Dervish 12/12/2005 16:05 #написать ответ
...нравится Google-вариант. Оригинально. Красиво. Удобно.