Сообщество
Логин
Пароль
Забыли пароль?     Регистрация
Ещё проектики
Рабочее время
Минималистичный счётчик рабочего времени онлайн
Общение / Веб версия / Внесение запланированных доходов и расходов датой ...

Внесение запланированных доходов и расходов датой отличной от запланированой

NO NAME
23 октября 2014 12:57
У меня есть запланированный на 25 число периодический (каждый месяц) доход. Но по факту так случилось, что деньги пришли 23 числа. Если нажать "внести" на запланированном доходе в таблице лимитов, то будет заведена транзакция запланированным числом (25 а не фактическим 23), как мне её внести этот доход 23-им число?
Admin
 
23 октября 2014 13:04
Пока просто отредактировать дату внесённой операции.
Задача вносить сегодняшним числом, уже стоит. При внесении будем у пользователя спрашивать.
Ilyan
23 октября 2014 14:20
Admin Пишет:
Задача вносить сегодняшним числом, уже стоит.
А стоит ли задача позволить пользователю при внесении операции, подкорректировать сумму, счет, категорию, теги, комментарий и установить точную дату и время?
Admin
 
23 октября 2014 14:38
Пока не видно в этом нужды. Если такое сложное редактирование требуется - его можно сделать и после внесения.

На данный момент "оптимальным" видится решение просто спрашивать "сегодня" или "не сегодня".
NO NAME
23 октября 2014 14:44
А ведь так бывает довольно часто. Например дали зарплату не в то число которое запланировал, или дали не на карту а наличкой. Дали зарплату в срок, но из-за больничного сумма другая. Это всё житейские моменты которых перманентно не много но в целом за год таких случаев накапливается довольно много.
Admin
 
23 октября 2014 14:54
Редактирование всех параметров внесённой операции отстоит всего на 1 клик. Пока не видно смысла ради нес-ких кликов в год дублировать форму ввода в сценарий внесения операции.

Будут люди просить - будем думать. Пока (и уже несколько раз) просили _только_ сегодняшнюю дату.
Ilyan
23 октября 2014 15:00
Admin Пишет:
такое сложное редактирование
Это не сложное редактирование - это уже давно существующая, самая обычная предзаполненная форма редактирования. Либо "основная" форма личного кабинета, либо всплывающая, как в отчетах.

Примеры:

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

Ок, вы скажете, что если так много всего меняется, то лучше использовать шаблон?

Тогда, ежемесячная АВТОМАТИЧЕСКАЯ оплата какого-либо счета. Почти то же самое, кроме счета. Даже дата может измениться, если попадает на нерабочий день.


Каждый раз я удивляюсь, как вы на ровном месте придумываете какое-то новое поведение, меню...
Ведь есть же журнал операций - и все прекрасно знают, как им пользоваться: клик на категорию - редактировать операцию, "Удалить" - удалить операцию. Включая будущие, черно-белые операции.
И вот в журнал операций добавляются новые объекты: ПОВТОРЫ планируемых операций, которые выглядят почти также, как и будущие (черно-белые).

Но при этом, клик на категорию открывает редактирование планируемой операции, а не ПОВТОРА, и "Удалить" тоже удаляет планируемую операцию, а не ПОВТОРА.

Где логика? Зачем тогда вообще класть повторы в журнал операций?
Ilyan
23 октября 2014 15:04
Admin Пишет:
отстоит всего на 1 клик
Нет, на 1 клик, на 3 секунды крутящегося колеса и на перемещение мышки к добавленной операции.
NO NAME
23 октября 2014 15:07
Ситуация когда даты и счета списания/зачисления не совпадают это не раз в году. Такое бывает сплошь и рядом.
Почему бы как вариант при нажатии кнопки ввести не открывать форму ввода где можно поменять дату, счёт, категорию.

P.S.
Система не отслеживает ситуацию когда транзакция порожденная вводом запланированной операции удаляется. Получается что транзакции нет (например её по ошибке ввели два месяца назад и потом удалили), а в таблице лимитов зафиксировано что операция введена.
Ilyan
23 октября 2014 15:10
Вы почитайте статьи про юзабилити. Про то, как сокращение времени ожидания на 0.1 увеличивает продажи на вполне ощутимые проценты. Вы тут конечно, ничего не продаете, никто от вас из-за этото не уйдет, да и новых клиентов не потереяете.

Но вы делаете продукт с более плохим user experience, чем могли бы. Кстати, это то что постоянно недооценивают противники Apple, сравнивая какие-то сантиметры и гигагерцы.
NO NAME
23 октября 2014 15:19
Хоть продукцию Apple и не люблю (субъективные причины), но не могу не согласиться с Ilyan по поводу user experience в их продуктах.
Сам долгое время отвечал за пользовательский интерфейс системы подготовки данных скады, пришлось перечитать горы макулатуры от мелкософта, HP и IBM по поводу правил построения UI.

Хорошо я понимаю, что если сумма изменилась, то мне потом нужно найти операцию и поменять, но например параллельно со мною систему использует жена. У пожилых родителей дополнительная операция возникает вообще оправданное непонимание.
Admin
 
23 октября 2014 16:04
Ilyan Пишет:
Но вы делаете продукт с более плохим user experience, чем могли бы.
Это правда, только не "чем могли бы", а "чем он мог бы быть".
Мы делаем то, что можем в силу своих способностей. Сейчас ваш вариант кажется худшим по юзабилити, т.к. предполагает в нагрузку к простому "сегодня / не сегодня", большую форму редактирования, которая может быть кому-нибудь когда-нибудь будет нужна.

Если об этом будут просить люди, то мы узнаем, что вы правы и будем улучшать юзабилити.
Ilyan
23 октября 2014 16:18
Admin Пишет:
в нагрузку
Не в нагрузку - я предлагаю открывать форму редактирования ПОВТОРА вместо формы редактирования ПЛАНИРУЕМОЙ операции (при клика не категорию).

"кому-нибудь когда-нибудь" - это например, мне, ВСЕГДА. Все планируемые траты, которые я бы добавил, были бы ежемесячными, а я для ВСЕХ ежемесячных трат указываю в комментарии месяц. И пользователь Kamdis утверждает, что "ведь так бывает довольно часто".

Хотя что мы спорим - у вас есть история изменений, вы можете сами посмотреть как часто, и что именно пользователи меняют в операции в течении 1-2 минут после добавления. Надо только отличить обычную операцию от добавленного повтора.
Ilyan
23 октября 2014 16:27
И более того, мое решение даже проще, потому что во ВСЕХ случаях требует МЕНЬШЕГО количества кликов/действий.

Пользователь хочет занести операцию

1. С запланированной датой.
У вас: нажать на "Внести", потом что-то выбрать во всплывшем окне, у меня - просто нажать на "Внести".

2. С сегодняшеней датой.
У вас: нажать на "Внести", потом что-то выбрать во всплывшем окне, у меня - просто нажать на "Внести сегодня".

3. С дополнительным редактированием.
У вас: нажать на "Внести", подождать несколько секунд, найти и кликнуть на операцию..., у меня - прость кликнуть на операцию.


Где нагрузка-то? О чем вы?
Ilyan
23 октября 2014 16:28
* вместо 2 кнопок "Внести" и "Внести сегодня" я предлагал и другие решения, но во всех случаях операция, не требующая редактирования вносится одним кликом.
Admin
 
23 октября 2014 16:45
Ilyan Пишет:
Где нагрузка-то? О чем вы?
Возможно тогда вашу идею просто не поняли со слов.
Было бы проще, если была бы картинка поясняющая ваш сценарий.

Не понятно насчёт клика на категорию. "Повтор" в терминологии сервиса это ещё не существующая операция, она отражается только для наглядности и вычисления планируемых остатков. Делать её редактируемой пока не представляется возможным. Редактировать можно только следующую планируемую операцию, которую можно вносить.
Ilyan
23 октября 2014 16:54
Это как кликнуть на шаблон - никакой операции еще нигде нет, но поля формы редактирования заполняются. После заполнения всех обязательных полей операцию можно сохранить.

В случае повтора - то же самое: после клика на категорию, форма полностью заполнится, пользователь исправит то, что ему нужно и нажмет "Зафиксировать". Только тогда операция сохранится, а планируемая операция продвинется на 1 шаг.

Отличие от шаблона - нужна кнопка "Отмена" - если пользователь ее нажмет, ничего не сохраняем и сбрасываем форму.
Admin
 
23 октября 2014 17:30
Всё равно нет уверенности, что правильно вас поняли. Вроде как вы предлагаете раздвоить функцию "внести" на две части и повесить их на "внести" и на "редактирование".

Совершенно не очевидная и запутывающая логика. Как по вашему пользователь должен догадаться, что это примерно то же самое, только по разному и для чего это нужно? К тому же смешивается логика обычного редактирования, шаблонов и планируемых трат. Очень не хорошо.
Admin
 
23 октября 2014 17:53
Ilyan Пишет:
Хотя что мы спорим - у вас есть история изменений, вы можете сами посмотреть как часто, и что именно пользователи меняют в операции в течении 1-2 минут после добавления.
Идея правильная, спасибо. Так и сделаем, когда накопится статистика.
Ilyan
23 октября 2014 17:55
Ок, попробую еще раз, подробно.

Сначала определения.

ПЛАНИРУЕМАЯ ОПЕРАЦИЯ - операция добавленная, как планируемая.
Повторяющаяся ПЛАНИРУЕМАЯ ОПЕРАЦИЯ "генерирует" ПОВТОРЫ.
Планируемую операцию можно редактировать, удалять, но НЕЛЬЗЯ сделать фактической.
Повтор сейчас можно только сделать фактическим.

Планируемая операция - лишь генератор повторов. И именно повторы видны в журнале операций и учитываются в бюджете.

В панели планируемых операций мы видим не повторы, а сами планируемые операции.
Поэтому там логично их редактировать и удалять.

В журнале операций мы видим не саму планируемую операцию, а ее повторы.
Поэтому там логично их делать фактическими.

...
Ilyan
23 октября 2014 18:05
Далее, что собой представляет повтор?

Повтор - это полностью заполненный одноразовый шаблон операции. Поскольку он заполнен полностью, на его основе удобно содать фактическую операцию в один клик - "Внести". После этого повтор-шаблон исчезает, а породившая его планируемая операция "продвигается".

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

Но иногда возникает необходимость редактирования полей перед созданием фактической операции. Я предлагаю делать это так - по клику на категорию повтора заполнить поля главной формы и позволить пользователю их изменить. После нажатия на "Зафиксировать" создается фактическая операция. После этого повтор-шаблон исчезает, а породившая его планируемая операция "продвигается".
Admin
 
23 октября 2014 18:15
Увы, всё это кажется слишком сложным.
Такие вещи надо обсуждать на графических прототипах, отражающих различные пользовательские сценарии.
NO NAME
23 октября 2014 18:34
Кстати вариант с "внести на сегодня" можно посмотреть реализацию на дзенмани, прекрасно реализовано. Наводишь мышку, получаешь две надписи, "Внести на сегодня" и "Внести с правками". При нажатии "Внести на сегодня" заводится планируемая транзакция, но на текущую дату. Ну а нажатие на "Внести с правками" открывает полноценное окно редактирования.
Admin
 
23 октября 2014 18:49
Kamdis Пишет:
Наводишь мышку, получаешь две надписи, "Внести на сегодня" и "Внести с правками"
Да, решение хорошее.
Ilyan
23 октября 2014 19:29
Kamdis Пишет:
Ну а нажатие на "Внести с правками" открывает полноценное окно редактирования.
Так я ведь то же самое предлагаю, только нажать на категорию - потому что в дребеденьгах повсеместно именно это нажатие открывает окно редактирования :)
Admin
 
23 октября 2014 19:42
Ilyan Пишет:
именно это нажатие открывает окно редактирования
Но не окно "внесения с правками". Это же совершенно разные действия.
Ilyan
23 октября 2014 19:50
Admin Пишет:
Это же совершенно разные действия.
Опять двадцать пять :)

Как вы навываете то, что происходит, когда пользователь кликает на шаблон?
Частичное заполнение формы для "внесения с правками"?

Если форма -та же самая, кнопка "Зафиксировать" - та же самая, результат - то же самый (зафиксированная операция), то что тут "совершенно разного"?
Admin
 
23 октября 2014 19:59
Admin Пишет:
Хотя что мы спорим - у вас есть история изменений, вы можете сами посмотреть как часто, и что именно пользователи меняют в операции в течении 1-2 минут после добавления.
И даже вот что. Благодаря этой хорошей идее, возможно для начала поступим так. Без всяких вопросов, по клику на "внести":
1. Для будущей операции, вносим текущей датой.
2. Для просроченной операции, вносим прошлым числом. Из предположения, что чаще всего это означает, что трата была совершена во время, просто пользователь забыл/не смог во время её внести.

После чего, когда соберётся статистика (ну и отзывы людей), посмотрим сколько реальных трат меняли после внесения дату и другие параметры. Тогда-то и станет ясно стоит ли городить огород.
Ilyan
23 октября 2014 20:15
А я пожалуй, открою тему, похожую на эту :)

https://www.drebedengi.ru...=7400
Admin
 
23 октября 2014 20:17
Вы лучше через 3 месяца напомните собрать обещанную статистику и обнародовать её.
Ilyan
23 октября 2014 20:17
Admin Пишет:
После чего, когда соберётся статистика
А вы сможете отличить создание обычной операции от повтора планируемой?
Anna
24 октября 2014 10:35
Admin Пишет:
может быть кому-нибудь когда-нибудь будет нужна.
Я просто дополнительный голос свой оставлю и скажу, что таких трат много.
Коммуналка разной суммой и иногда с разных счетов (а у многих это не 2 квитанции, как у меня, а пять).
Доход от вкладов и кэшбэк. Примерная сумма обычно известна, но точная становится ясна только в момент начисления.
Траты на погашения кредитов обычно известны, а вот сумма возврата денег на кредитку не так очевидна.

В итоге большинство из запланированных доходов/расходов у меня должны быть отредактированы как минимум по сумме. А иногда и по счёту.
Admin
 
24 октября 2014 10:42
Anna Пишет:
Я просто дополнительный голос свой оставлю и скажу, что таких трат много.
Вот и хорошо, значит мы это скоро увидим и примем меры.
Ilyan
24 октября 2014 10:49
Admin Пишет:
мы это скоро увидим
Ну да, "напомните через 3 месяца" - по местным меркам это скоро. :)
Admin
 
27 октября 2014 16:18
Прикручено автоматическое внесение будущих планируемых трат текущей датой.
Чтобы отвечать на сообщения - зарегистрируйтесь и войдите в личный кабинет.