Семь хотелок

В этом форуме Вы можете высказать пожелания к новым версиям программы: какая функциональность должна появиться, что в программе лишнее, чего не хватает, что хочется видеть в другом ракурсе и т.д. Мы обязательно рассмотрим все Ваши предложения и советы по улучшению программы.

Модератор: Анастасия

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

Я вполне понимаю что-такое составные операции - сталкивался с этим при внесении данных в КэшОрге
Есть такой у меня вариант - выводить название группы, а не конкретной статьи, если все элементы принадлежат одной группе статей (в вашем примере это будет "Питание"). Если расход сложный и содержит разнородные позиции, то можно находить общую для всех элементов группу статей более высокого уровня. Ну либо просто выводить значение "Смешанное".
Ну и будет в итого почти всегда "продукты" или "смешанное". Это Вам сильно поможет (особенно "смешанное"???). А "продукты" можно и примечании написать, это не так долго.
При этом в этом столбце для переводов можно указывать куда (откуда) был сделан перевод (хоть это и одно и тоже по значению, но то же по смыслу - "Назначение" операции)
Так откуда или куда? Одни захотят откуда, другие куда, и все будут путаться :shock: . Зачем?
Поиск по дереву при вводе (например при вводе группы в карточке редактирования статьи) - не просто позиционирование на нужной ветви, но отсечение не подходящих под фильтр элементов и отображение только тех, кто подходит и на на всех уровнях
Поиск есть, причем по произвольной подстроке во всех больших справочниках (статьи доходов/расходов, счета, организации и контакты). Родительская группа выводится в столбце "Группа" (и само собой, в карточке). Чтобы поиск был во всем дереве, нужно выделить группу "Все". Для поиска по произвольной группе, нужно выделить эту группу в дереве.

Поиск по названию группы также есть, по первым символам, плюс выпадает само дерево, Вы видите его структуру, можете выбрать группу мышкой. Динамически обрезать дерево - слишком сложно и не стоит того. Также можно создавать новый элемент (статью, напримир) прямо в нужной группе, тогда это поле заполнится автоматически.
- После внесения операции перемещать на нее кусор в списке операций
Так и происходит.
- Окно внесения операции
-- Отключить создание новой строки по нажатию кнопки "Вниз" (очень часто при внесении чеков с большим кол-вом элементов стрелками пролистываю вверх-вниз и после того, как ухожу вниз, созадается еще одна строка в режиме редактирования и тут же выбирается первый элемент из выпадающего списка. Duble-Esc конечно позволяет устранить это, но если случайных новых строк не возникало было бы удобнее. Все же на мой взгляд дабл-ентер или инс позволяют сознательно создавать строки и тянуться до них удобнее)
Если расход большой, лучше растянуть карточку на комфортную высоту и использовать колесико мыши для прокрутки. Иногда, действительно, лишнее нажатие на клавишу вниз создает неудобства, но зато ее использование позволяет быстрее вводить данные. Например, мне зачастую достаточно ввести первые символы названия статьи, чтобы программа уже подставила все, что нужно (статью целиком, количество, цену, сумму, место покупки). Тогда я нажимаю вниз и перехожу к новой записи, так расходы вводятся за считанные секунды. А в Вашем случае придется несколько раз нажать Enter, чтобы пробежать по всем полям строки и перейти на следующую. Что такое Double Enter вообще слабо понимаю :(. Вообще есть стандарты работы в гридах (с гридами) и мы стараемся их придерживаться.
-- При редактировании строки в гриде случается так, что случайно проскакиваешь поле - если бы по Shift-Enter можно было бы вернуться в предыдущее поле было бы супер (по аналогии с Shift+Tab)
Гораздо удобнее использовать клавиши "вправо" и "влево", на мой взгляд, чем Shift-Enter, они вполне удобно расположены.
-- По Ins из любого места на форме переходить в грид и создавать новую строку
-- Быстрые клавиши для полей "Дата"(Alt+D), "Общее примечание"(Alt+N)
-- Все это можно сделать опциональным
-- Баг: при нажатии кнопки Del в режиме редактирования полей элемента (кроме статьи и места покупки) предлагается удалить запись, вместо удаления символа
Посмотрим...

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Ну и будет в итого почти всегда "продукты" или "смешанное". Это Вам сильно поможет (особенно "смешанное"???).
Предполагал, что вы именно так и ответите :)
Мне это действительно поможет (и, полагаю, не только мне, судя по желаниям людей), поскольку с одной стороны я ввожу так, что очень редко получалось бы "Смешанное". С другой - ориентироваться все равно стало бы гораздо проще (одно дело когда есть безликие строки с суммами, и совсем другое, когда написано "Продукты", "Транспорт", "Образовани", "Хозрасходы" и т.д.). И у меня был опыт работы в таком режиме в другой программе - помогало :)
А "продукты" можно и примечании написать, это не так долго.
В примечаниях можно писать - так и приходится делать. Но получается бессмысленное дублирование информации, с одной стороны, а сдругой - в отсутствие быстрых клавиш перехода по форме и истории примечаний не так уж это и быстро.
При этом в этом столбце для переводов можно указывать куда (откуда) был сделан перевод (хоть это и одно и тоже по значению, но то же по смыслу - "Назначение" операции)
Так откуда или куда? Одни захотят откуда, другие куда, и все будут путаться . Зачем?
Если перевод положительный для текущего счета, то по смыслу получается "Откуда", если отрицательный, то - "Куда". Но это я написал просто для пояснения, а оказалось только запутал :)
Путаницы здесь нет - все очевидно:
Перевод осуществляется между двумя счетами. В столбце "Счет" отражается текущий счет, а в стобце "Назначение" тот счет, на который(с которого) был произведен перевод. Однозначно и без вариантов.

Про поиск по дереву я знаю. Хотелось динамического обрезания именно в карточках редактирования. Но если сложно, то конечно нет смысла заморачиваться.
После внесения операции перемещать на нее кусор в списке операций
Так и происходит.
Специально проверил - у меня так не происходит.
Пример:
Курсор спозиционирован на самом верхней стороке - операция от 6 апреля.
Нажимаю Ins, ввожу операцию месячной давности (6 марта). Нажимаю Enter.
Операция сохранилась, а курсор в списке как стоял на последней операции от 6 апреля, так и стоит.

Если курсор на операции месячной давности, а ввожу сегодняшнюю, то тоже не происходит позиционирования

Если расход большой, лучше растянуть карточку на комфортную высоту и использовать колесико мыши для прокрутки. Иногда, действительно, лишнее нажатие на клавишу вниз создает неудобства, но зато ее использование позволяет быстрее вводить данные. Например, мне зачастую достаточно ввести первые символы названия статьи, чтобы программа уже подставила все, что нужно (статью целиком, количество, цену, сумму, место покупки). Тогда я нажимаю вниз и перехожу к новой записи, так расходы вводятся за считанные секунды.
Согласен, я тоже делаю подобным образом. Но я бы предпочел, чтобы на это была назначена клавиша Ins (она уже назначена, впринципе), а "Вниз"/"Вверх" просто подтверждали ввод и перемещали курсор по списку без добавления новой строки . Почему? потому что это и логично, и более удобно с точки зрения нахождения рук в основной позиции - чтобы дотянуться до Ins достаточно слегка отклонить кисть вправо и мизинцем нажать кнопку. Для того, чтобы нажать "Вниз" приходится полностью всю руку переносить на курсор.
А в Вашем случае придется несколько раз нажать Enter, чтобы пробежать по всем полям строки и перейти на следующую.
Описал выше
Что такое Double Enter вообще слабо понимаю.
Double Enter - это то, что я описывал ранее как "двойное нажатие клавиши Enter в последней ячейке строки". Первое нажатие просто подтверждает ввод данных в ячейке (так, как происходит сейчас), второе (когда мы уже не в режиме редактирования ячейки) создает новую строку.
Гораздо удобнее использовать клавиши "вправо" и "влево", на мой взгляд, чем Shift-Enter, они вполне удобно расположены.
Они конечно удобно расположены, но проблема та же - чтобы нажать шифт+ентер не нужно руки убирать из основной позиции, а чтобы клавиши курсора давить - нужно. Я постоянно об этом говорю, а вы все время пропускаете этот момент :)

Я понимаю, что все это вопрос мнений, вкусов и привычек, поэтому и говорю об опциональности. Тогда можно было бы гибко настроить под себя. К тому же это не принципиально иной способ - основные моменты уже реализованы, доделать нужно всего ничего
Посмотрим...
И на этом спасибо :)

Дмитрий
Разработчик
Разработчик
Сообщения: 1698
Зарегистрирован: Ср ноя 21, 2007 6:18 am
Контактная информация:

Сообщение Дмитрий »

Предполагал, что вы именно так и ответите
Мне это действительно поможет (и, полагаю, не только мне, судя по желаниям людей), поскольку с одной стороны я ввожу так, что очень редко получалось бы "Смешанное". С другой - ориентироваться все равно стало бы гораздо проще (одно дело когда есть безликие строки с суммами, и совсем другое, когда написано "Продукты", "Транспорт", "Образовани", "Хозрасходы" и т.д.). И у меня был опыт работы в таком режиме в другой программе - помогало
Согласитесь, с нашей стороны было бы неправильно копировать функционал другой программы только потому, что отдельные пользователи (не буду показывать пальцем ;)) привыкли так работать. Я, например, каждый день заношу расходы на транспорт и хлеб, поэтому в этом случае у меня в этом столбце постоянно было бы "Смешанное". Другое дело, что там можно было бы через запятую перечислить все статьи расхода, но едва ли это будет читабельно.
Про поиск по дереву я знаю. Хотелось динамического обрезания именно в карточках редактирования. Но если сложно, то конечно нет смысла заморачиваться.
Динамическая фильтрация по подстроке фактически убивает всяческую древовидную структуру, потому что нам либо приходится рисовать родителя группы, название которой содержит набранную подстроку, что немного смущает, потому что название родителя не обязательно содержит эту подстроку, либо разрушать древовидную структуру, что менее наглядно. Опять же, новичкам удобнее кликнуть мышкой в дереве, опытные пользователи могут запомнить, с чего начинается название группы ;)
Специально проверил - у меня так не происходит.
Пример:
Курсор спозиционирован на самом верхней стороке - операция от 6 апреля.
Нажимаю Ins, ввожу операцию месячной давности (6 марта). Нажимаю Enter.
Операция сохранилась, а курсор в списке как стоял на последней операции от 6 апреля, так и стоит.

Если курсор на операции месячной давности, а ввожу сегодняшнюю, то тоже не происходит позиционирования
Есть такая проблема, происходит она потому, что в сводном списке записи разных типов. Честно говоря, при написании сводного списка мы не планировали, что оттуда будут создаваться новые записи, поэтому момент позиционирования не реализовали.
Согласен, я тоже делаю подобным образом. Но я бы предпочел, чтобы на это была назначена клавиша Ins (она уже назначена, впринципе), а "Вниз"/"Вверх" просто подтверждали ввод и перемещали курсор по списку без добавления новой строки . Почему? потому что это и логично, и более удобно с точки зрения нахождения рук в основной позиции - чтобы дотянуться до Ins достаточно слегка отклонить кисть вправо и мизинцем нажать кнопку. Для того, чтобы нажать "Вниз" приходится полностью всю руку переносить на курсор.
Я бы поспорил с тем, что это логично. Есть стандартные клавиши для работы с гридами, и "Вниз" на последней строке добавляет новую строку.
Double Enter - это то, что я описывал ранее как "двойное нажатие клавиши Enter в последней ячейке строки". Первое нажатие просто подтверждает ввод данных в ячейке (так, как происходит сейчас), второе (когда мы уже не в режиме редактирования ячейки) создает новую строку.
Я помню ваше пожелание в его начальном виде, добавление строки по двойному энтеру не было реализовано намеренно, потому что показалось нам достаточно неочевидным и неинтуитивным. Опять же, это сугубо личная точка зрения.
Они конечно удобно расположены, но проблема та же - чтобы нажать шифт+ентер не нужно руки убирать из основной позиции, а чтобы клавиши курсора давить - нужно. Я постоянно об этом говорю, а вы все время пропускаете этот момент
Уговорили :)

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Я тут много пишу по поводу быстрых клавиш. безусловно все это очень неоднозначано. Поэтому просто излагаю свои мысли - может быть что-то вам покажется интересным и это будет реализовано в программе.
Окно внесения операции
Быстрые клавиши для полей
Alt+D - Дата (Date)
Alt+A - Счет (Account)
Alt+U - Пользователь (User)
Alt+O - Скидка (discOunt)
Alt+S - Место покупки (Shop)
Alt+С - Общее примечание (Comment)
Alt+N, Ins - Создать новую строку в таблице (Next item) (в принципе, если будет что-то типа Alt+N, тогда Двойной Ентер в конце строки не нужен)

Есть еще одно предложение, которое вряд ли найдет отклик в чьих-то душах в силу своей неоднозначости и специфичности :). Но в нем есть своя прелесть, поэтому и излагаю. Есть такой замечательный редактор VI, берущий свое начало в юникс-системах, и там концепция нахождения рук в основной позиции (над символьной частью клавиатуры) получила, пожалуй, наилучшую реализацию :), по скольку даже движение вверх-вниз-влево-вправо там можно производить с помощью символьных клавиш. И это натолкнуло меня на мысль, а почему бы не сделать аналогичные "курсорные" клавиши но с альтом (опционально). Ведь все равно, как ни крути, сейчас к курсору приходится прибегать для того, чтобы выбрать нужный вариант из отфильтрованного по первым буквам списка. А, сделав подобные сочетания, этого можно избежать. Надежды у меня мало, конечно... Разве что вам самим понравится эта идя :)
Alt+H - Влево
Alt+J - Вниз
Alt+K - Вверх
Alt+L - Вправо

По скоьку в столбце "Ед.изм" все равно ничего изменить нельзя, может быть его сделать неактивным. Т.е. чтобы курсор не позиционировлся на нем, а проскакивал на следующий столбец. Тогда мы сможем избежать лишнего действия.

Что вы чаще меняете в окне внесения информации? "Дата", "Счет", "Пользователь", "Место покупки"
В моем случае "Дата", "Место покупки". значительно реже "Счет". "Пользователь" не приходилось менять.
Вопрос поднимаю к тому, что может быть полю "место покупки" место после поля "дата"?
Хотя все зависит от того, кто как вбивает. Мой знакомый вносит все расходы двумя-тремя составными операциями - в таком случае ему "Место покупки не особно нужно". Я вношу смысловые группы отдельными составными расходами (чек из магазина, либо покупки на одном рынке, либо комм. услуги) - мне удобно выбирать организацию в поле место покупки, а сейчас оно расположено несколько не "по пути".

Еще раз повторюсь, что это скорее мысли вслух, нежели пожелания (хотя хотелось бы в итоге), поскольку таки вещи как бюджет видятся более важными.

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Развею немного тишину уже столь долго царящую на форуме :)

Предлагаю рассмотреть возможность дублировать операцию - пункт в меню (контекстном) "Создать на основе ...". С помощью которого будет открываться окно редактирования операции с такими же данными как у исходной проводки.
Шаблоны расходы доходы не всегда нужны. Т.к. бывает нужно сделать три-четыре похожих проводки, и потом они больше не понадобятся - поэтому нет смысла делать шаблон. К тому же отстутствуют шаблоны для переводов и обмена.

Дмитрий
Разработчик
Разработчик
Сообщения: 1698
Зарегистрирован: Ср ноя 21, 2007 6:18 am
Контактная информация:

Сообщение Дмитрий »

Предлагаю рассмотреть возможность дублировать операцию - пункт в меню (контекстном) "Создать на основе ...". С помощью которого будет открываться окно редактирования операции с такими же данными как у исходной проводки.
Со временем это будет реализовано.
Шаблоны расходы доходы не всегда нужны. Т.к. бывает нужно сделать три-четыре похожих проводки, и потом они больше не понадобятся - поэтому нет смысла делать шаблон. К тому же отстутствуют шаблоны для переводов и обмена.
Шаблоны переводов и обменов будут. Неоспоримое преимущество шаблонов перед операциями, которые можно дублировать, в том, что шаблонов мало, и их проще искать. Иногда между покупками проходит довольно много времени (у нас, например, это поход в хозяйственный магазин), в то же время список покупок обычно один и тот же (стиральные порошки и т.п.). Искать такие расходы в списке расходов, чтобы продублировать, довольно утомительно, а в шаблонах они всегда на виду.

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Со временем это будет реализовано.
Это радует :)
Шаблоны переводов и обменов будут. Неоспоримое преимущество шаблонов перед операциями, которые можно дублировать, в том, что шаблонов мало, и их проще искать
Согласен. Но "Создать на основе" тоже будет востребованная вещь.
Кстати, этот пункт, по идее, можно добавить и в контекстное меню в списке шаблонов (и назначить горячую клавишу :) )
Искать такие расходы в списке расходов, чтобы продублировать, довольно утомительно, а в шаблонах они всегда на виду.
Со временем, когда появится фильтрация, это должно стать более простой задачей

Дмитрий
Разработчик
Разработчик
Сообщения: 1698
Зарегистрирован: Ср ноя 21, 2007 6:18 am
Контактная информация:

Сообщение Дмитрий »

Согласен. Но "Создать на основе" тоже будет востребованная вещь.
Кстати, этот пункт, по идее, можно добавить и в контекстное меню в списке шаблонов (и назначить горячую клавишу )
Это будет сделано во всех списках.

toster
Пользователь
Пользователь
Сообщения: 26
Зарегистрирован: Чт дек 18, 2008 10:36 am

Сообщение toster »

Анастасия писал(а):
Интенесно, что, пожалуй, почти все, кто более-менее пространно излагал "хотелки" так или иначе хотят видеть колонку "статья" в сводном списке
Все хотят этого по той же причине, что и Вы. Потому что, возможно, не совсем понимают, что такое составные расходы и доходы. Представьте, что Вы создали составной расход по результатам похода в магазин ;) на 200 рублей. В сводном списке отображается вид операции (расход), сумма (200), примечание и прочие общие вещи. Но какая статья, по Вашему, должна там отображаться, если в этом расходе было, например, 5 статей (хлеб, молоко, мука, сок, макароны)??? Как можно ее (статью) выбрать однозначно?
Там где статья не может быть указана по причине того, что расход составной так и писать в списке - составной. Тогда сводный список и станет для всех тем что надо. Так например реализовано в линуксовом kmymoney2. На данный момент одна из лучших програм для домашней бухгалтерии. Жаль что она только под никсы.

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

В другой ветке уже ответила, сделаем все-таки более наглядное отображение составного расхода:). Ждите.

toster
Пользователь
Пользователь
Сообщения: 26
Зарегистрирован: Чт дек 18, 2008 10:36 am

Сообщение toster »

спасибо. жду :)

Ответить