Я помаленьку продвигаюсь с новой версией AbilityCash. В новой версии будет новый формат файла (старые данные перенесутся), данные будут храниться в
SQLite - базе данных, ставшей фактическим стандартом для мобильных устройств и
широко применяющейся на десктопах. Если файл данных не закрыт паролем, его можно будет открыть любой программой, поддерживающей SQLite, например,
DB Browser for SQLite. Защищенный паролем файл не сможет открыть никто, не знающий пароль. Даже я (больше не смогу восстанавливать пароли). Забытый пароль будет означать невозможность открыть данные.
Еще из новостей: если сейчас валюты можно создавать максимум с 4-мя знаками после запятой, то в новой версии можно будет создать валюту максимум с 15-ю знаками после запятой. Это пригодится пользователям, которые учитывают паи ПИФ (если такие еще есть в условиях кризиса). Пользователи, владеющие Bitcoin тоже должны оценить это нововведение.
И вот возникло у меня желание заодно сделать еще одну переделку. Однако, нет уверенности, что такая переделка пойдет на пользу. Прежде чем делать, хочу предложить обсудить нововведение.
Итак, диалог ввода/редактирования операции. Допустим, мы вводим операцию перевода с одного счета на другой в разных валютах. В этом случае AbilityCash предложит нам заполнить три поля:
- Сумма списания
- Сумма зачисления
- Курс пересчета
При этом, там еще будет переключатель (radio-button), который будет делать одно из этих полей недоступным для ввода. Как бы понятно, для чего там стоит этот переключатель: с его помощью выбирается поле, которое будет автоматически вычисляться по мере изменения одного из других полей. Это решение функционально полное, однако оно не нравится тем, что (а) совершенно не очевидно поведение программы и ее реакция на переключатели, (б) ввод операции перевода занимает больше времени, чем могло бы потому что нужно переключаться между клавиатурой и мышкой чтоб выбрать вычисляемое поле.
Итак, идея довольно проста: убрать переключатель и сделать все три поля для ввода всегда доступными для ввода. Тогда при изменении любого поля программа будет пересчитывать следующее поле, а при изменении поля "Курс пересчета", будет пересчитываться поле "Сумма зачисления".
Если в базе данных забит курс между, скажем, рублем и долларом (например, 63 рубля за доллар), то при добавлении новой операции, как только мы выберем два счета в рублях и долларах, в диалоге тут же появится:
- Сумма списания: 0,00 USD
- Сумма зачисления: 0,00 RUR
- Курс пересчета: 63,00 RUR за 1 USD
Далее, вводим в первое поле 100 и получаем:
- Сумма списания: 100,00 USD
- Сумма зачисления: 6300,00 RUR
- Курс пересчета: 63,00 RUR за 1 USD
Допустим, сумма зачисления не совпадает с той, которая посчиталась по курсу базы данных, и мы исправляем 6300 RUR в 6400:
- Сумма списания: 100,00 USD
- Сумма зачисления: 6400,00 RUR
- Курс пересчета: 64,00 RUR за 1 USD
Ну а если исправить курс пересчета, написать, скажем 65, то получим:
- Сумма списания: 98,46 USD
- Сумма зачисления: 6400,00 RUR
- Курс пересчета: 65,00 RUR за 1 USD
Вроде бы все получается довольно удобно. За исключением одной единственной ситуации: когда у пользователя есть сумма списания и курс пересчета. В этом случае пользователю придется вначале ввести курс пересчета и только потом сумму списания. Только в этом случае программа верно сможет посчитать сумму зачисления. Хотя, есть еще один вариант: вначале ввести сумму списания, а потом в поле суммы зачисления ввести выражение: (сумма списания / курс пересчета).
Такое поведение программы выглядит более ожидаемым пользователями, в отличие от существующего. Однако, вот проблема из предыдущего абзаца заставила меня сомневаться в удачности такого решения. Буду признателен за мнения по этому вопросу. Может быть, есть какой-то другой вариант?
Да, оговорюсь сразу: делать еще одну настройку в программе "новое/старое поведение диалога редактирования операции" я совсем не хочу: там и так код довольно тяжелый, все усложнения ни к чему, либо все оставлю как есть, либо просто внедрю новое решение.
Спасибо.
Голосую за существующую версию (+ предложения по оптимизации)
Макс
05/03/2015 10:45
#
На мой взгляд, предлагаемый вариант усложнит ввод операций перевода. Хотя, возможно, это вопрос привычки.
По поводу претензий к существующему решению - на мой взгляд, можно добавить в диалог несколько элементов, объясняющих поведение переключателя:
а) в "заблокированном" поле ввода на фоне(?) добавить надпись вида "Рассчитывается автоматически" (формулировки взяты " с потолка" для иллюстрации идеи). Или выделять это поле цветом;
б) для изменения состояния переключателя добавить горячие клавиши (и прописать их рядом с описаниями полей), например: "Сумма списания (Alt-1)" и т.д. - снимается вопрос о переходе с мыши на клавиатуру и обратно;
в) добавить рядом с переключателем (например, слева от описания полей) кнопку вызова контекстной помощи с большим знаком вопроса, при нажатии/наведении на которую всплывало бы окно с кратким описанием поведения переключателя.
Ну почему же усложнит?
Dervish
05/03/2015 17:07
#
Как я сейчас ввожу операцию перевода в разных валютах? Очень просто: в большинстве случаев мне известка сумма списания и сумма зачисления. Я просто не задумываясь ввожу эти суммы в соответствующие поля и потом могу лишь полюбопытствовать, какой получился курс пересчета.
Что изменится? Да ничего, я точно так же буду вводить те же суммы не особо задумываясь и точно так же смогу посмотреть на итоговый курс пересчета.
Изменения появятся только в случае, если из входных данных у меня есть одна сумма (списания или зачисления) и курс пересчета. Вот тогда существующая реализация сразу вгоняет меня (разработчика!) в ступор. Вначале я пытаюсь вспомнить, заблокированное поле, оно будет автоматически вычисляться или оно становится константным и вычисляться будет второе незаблокированное? Потом, когда я вспомню как оно работает, я начинаю думать, какой радиобаттон отметить, чтоб рассчитывалось нужное мне поле. Мне приходится переключиться на мышку, отметить нужно поле, потом проставить фокус ввода на поле ввода. И только тогда начинать вводить суммы.
В предложенном новом варианте (с учетом рекомендаций Дим(м)) я просто ввожу две суммы в соответствующие поля и получаю нужный результат. Мне не нужно вспоминать, что означает радиобаттон, не нужно выбирать, какой отметить, не нужно переключаться между мышкой и клавиатурой. Просто нужно ввести две суммы, переход между полями по обычному Tab.
По здравому размышлению - меняю свою оценку
Макс
05/03/2015 18:07
#
Действительно, с усложнением я перегнул. Меньше элементов интерфейса - проще работать.
Тем не менее, выделение рассчитываемого в данный момент поля - цветом, фоном, как угодно - считаю абсолютно необходимым.
Может, вычислять автоматически LRU поле?
Дим(м)
05/03/2015 12:11
#
Извините, не нашёл удачного перевода для least recently used.
Идея в том, что программа будет пересчитывать поле, которое "не меняли дольше всего".
Для первого редактируемого поля я бы использовал такие правила:
а) если значения всех трёх полей отличны от 0, пересчитываем, как вы и описали выше (пересчитывается следующее поле, при редактировании курса пересчитывается сумма зачисления)
б) если в одном из двух других полей 0, пересчитывается оно
в) если 0 в обоих других полях, пересчитывать нечего
Когда пользователь редактирует значение какого-то второго поля, пересчитывается то поле, которое он ещё не трогал (третье).
Если же он решит отредактировать и третье, пересчитываем поле, отредактированное самом первым (т.е. least recently used).
Это, как мне кажется, вполне изящно решит ситуацию с сумма списания + курс.
Да и поведение здесь вполне ожидаемое: пользователь вводит данные не просто так - поэтому программа пытается сохранить введённые им значения как можно дольше.
Идея понятна, спасибо.
Dervish
05/03/2015 16:53
#
Кстати, она решает ту проблему, которая была присуща моему варианту решения.
Два маленьких вопроса:
1. Если операция вызывается на редактирование (и пока еще ничего не правили), то работаем по правилу (а)? То есть, рассчитываем следующее поле (или первое, если правим курс)?
2. Может быть рассчитываемое поле следует как-то выделить? Например, цветом или как-то еще?
Рассчитываемое поле нужно обязательно выделить (-)
Amundsen
05/03/2015 16:58
#
И как сделать так, чтобы это выделение было понятно. Чтобы было ясно, что это поле выделено не потому, скажем, что в нем ошибка, а потому, что оно будет вычисляться.
ИМХО это не так важно
Amundsen
05/03/2015 17:30
#
т.к. привыкнуть можно к любому варианту. Но само выделение необходимо для ориентации.
Можно оставить так как сейчас, т.е. выделение серым цветом. Можно знак "равно" присобачить. Можно поле подсвечивать фоном. Можно конкурс на эту тему объявить .
Помимо "как выделить" есть ещё аспект "когда выделить"
Дим(м)
06/03/2015 12:08
#
Как я понимаю, выделение нужно для того, чтобы заранее (?) показать, какое из полей будет пересчитываться. Т.е. применять его надо сразу, как только какое-то из трёх полей получает фокус.
Что касается "как", я бы, например, сделал какое-нибудь незначительное изменение шрифта в пересчитываем поле. Например, сделал его наклонным и тёмно-серым вместо чёрного.
Идея в том, что к этому полю нужно меньше привлекать внимания. А не больше, как в случае когда оно будет выделяться цветом.
С редактированием всё несколько сложнее
Дим(м)
06/03/2015 12:17
#
Как мне кажется, операции перевода, чаще всего, вводят именно суммами списания и зачисления.
Т.е. при редактировании, пожалуй, стоило бы сначала пересчитывать курс. Чтобы избежать необходимости запоминать и восстанавливать сумму зачисления каждый раз, когда нужно исправить сумму списания.
Быть может, и сценарий (а) стоит изменить тем же образом?
При редактировании любой из сумм пересчитываем курс, при редактировании курса пересчитываем сумму зачисления.
Абсолютно идеального решения тут всё равно нет. Какая-то из возможных ситуаций ввода будет доставлять неудобства. Например, в моём варианте это - "нужно исправить курс и сохранить сумму зачисления".
Остаётся только выбрать наименьшее из всех зол.
С редактированием действительно сложно
Amundsen
06/03/2015 12:53
#
т.к. с ним регулярно сталкиваешься при добавлении новой операции дублированием имеющейся. Нынешняя реализация с радиобаттоном не вызывает здесь никаких затруднений.
Может предусмотреть фиксацию вычисляемого поля введением туда знака "равно" при наборе?
Можно поступить кардинально.
Dervish
06/03/2015 18:36
#
Я тут общался с дизайнерами и задал им вопрос. Мне сказали, что три взаимосвязанных поля ввода, это очень-очень-очень плохая идея. Сказали, что нужно ограничиться двумя полями. Вариант: Таб-контрол с тремя закладками, по два поля ввода в каждом.
Но тут меня посетила мысль: а так ли часто лично я ввожу курс пересчета? И понял для себя, что если я делаю операцию перевода в разных валютах, то либо просто указываю суммы списания и зачисления. Либо могу обойтись формулой. Например, если я помню, что продал сто двадцать долларов по курсу 65, то так и могу написать: 120*65.
Поэтому вопрос: может быть вообще оставить только поля для ввода суммы списания и суммы зачисления? А поле для курса оставить, но сделать его просто обычной текстовой меткой и любое изменение сумм будет приводить просто к пересчету курса?
Аналогично для операций прихода и расхода, когда включена работа с количеством, можно вводить сумму прихода/расхода и количество, а цену за единицу просто сделать вычисляемой?
Можно и не так кардинально...
Amundsen
06/03/2015 19:15
#
...оставив текущую реализацию радиобаттоном, установив его по дефолту на курсе/цене
Ну то есть вообще ничего не переделывать. (-)
Dervish
06/03/2015 19:19
#
Лучшее - враг хорошего :)
Amundsen
06/03/2015 19:41
#
Я встречал такие поля (цена количество сумма), в которых одно из полей вычислялось по мере ввода. И я согласен с дизайнерами, что затея эта плохая. Хотя возможно там просто хромала логика (и вычисляемое поле там не подсвечивалось).
Но с другой стороны, ЕМНИП в абилити я поначалу тоже путался с радиобаттоном, но сейчас это решение кажется очевидным.
Еще здесь важно не упустить момент с округлением: сейчас при вводе количества и цены сумма округляется, но при сохранении в базу ошибка округления учитывается в цене. Хотелось бы сохранить эту логику.
На мой взгляд, блокировка одного из полей должна быть
Vidocq
07/03/2015 12:03
#
и блокироваться, в развитие предложения, автоматически будет то поле, в котором на момент заполнения второго нет данных (стоит ноль или оно пустое - даже без нуля).
Если надо будет изменить заблокированное (рассчитанное) поле, значит придется удалить инфу в одном из заполненных.
А то, если делать доступными все три поля - как-то логика (та что в голве
) не вполне нормально начинает работать.
Заблокированное поле можно конечно подсветить - для улучшения восприятия, как замена чекбокса.
Вот..
шило на мыло
Daniil
05/03/2015 19:59
#
сейчас приходится держать в уме один алгоритм работы программы. если переделать, то придется держать в голове другой (новый) алгоритм обработки данных, причем более запутанный. 4 примера это вроде немного и понятно, но когда их прочел понял, что их придется держать в голове при каждом вводе проводки с валютой. совсем не охота ни зубрить, ни вспоминать, ни обращаться к методу "тыка".
не нравится браться за мышку? так и не надо ее трогать. я только что с помощью "таб" активировал радиобаттон, потом нажал "стрелочку" - все переключается. потом опять "таб" и можно вводить данные.
комбинация "таб" + "шифт" работает для движения назад.
единственно, что мне не нравится, форма радиобаттон - сделать бы вместо шарика крестик. было бы нагляднее.
шарик обычно воспринимается как "включено". "крестик" понятнее будет в данном случае.
еще - мне лично было бы удобнее (работаю мышкой) что бы выбор "выполнена/выполнена и заблокирована...." был бы на пути к кнопке "ОК", т.е. внизу формы, т.к. решение что делать с проводкой принимаю в конце заполнения формы ввода, перед нажатием "ОК".
Как раз меньше нужно будет держать в голове.
Dervish
05/03/2015 20:51
#
Всего один принцип: введи два значения и третье вычислится само. Все! Реализация алгоритма нужна для меня, чтоб корректно работало. Пользователям это не нужно. Пользователю нужно лишь ввести два любых значения из трех возможных. Это очень просто.
ну тогда и совет не нужен, зачем спрашивать...
Daniil
06/03/2015 17:22
#
введи 2 получи третье...
шаблонов нет и что бы выйти из этой ситуации приходится дублированием заниматься.
дублируешь и все поля забиты данными. а дальше, если новый алгоритм, не вводить, а редактировать........ ой....... 3 поля забиты и надо что-то с этим делать....
прикольно: лезу в сбербанконлайн и вижу (к примеру) 100 долларов (туда\сюда).
приходит СМС - 100.01...
да плевать на этот цент, но, баланс не идет! подгонять одно под другое надо. округлять...
вроде уже к тому, что есть привыкли.
как подгонять если баттоны убрать....
Вам конечно виднее, как разработчику.
пожалуйста, учтите, что юзвери используют дублирование.
Приходно-расходные статьи
kasum1301
06/03/2015 20:43
#
В настоящее время при отключенном режиме "Разделять по виду операции" приходы и расходы по одной и той же статье в отчетах идут раздельно в списаниях и поступлениях. В этом, кажется, большого смысла нет. Нельзя ли вместо этого в алгоритме расчета оборотов вычислять алгебраическую сумму приходов и расходов по статье и результат, в зависимости от его знака, помещать либо в списания, либо в поступления? Было бы очень удобно и практически решало бы проблему сторно. Спасибо.
В общем, по итогам обсуждения,...
Dervish
07/03/2015 15:46
#
...будем считать, что лучше все оставить как есть и не трогать. Пока.
Защита паролем...
Vidocq
13/03/2015 20:57
#
Защищенный паролем файл не сможет открыть никто, не знающий пароль. Даже я (больше не смогу восстанавливать пароли). Забытый пароль будет означать невозможность открыть данные.
А вот это правильно!
И чтоб не ниже AES-256
, а для параноиков Serpent.
