logo
logo

Форум Кнопки Вперед - Назад

создать новую тему раскрыть все
Кнопки Вперед - Назад Дим(м) 03/09/2004 20:35 #написать ответ
Хотелось бы, чтобы кнопки Назад - Вперед при "Улучшенном выборе диапазона дат" не занимали столько места под полем с периодом. Например, их можно было бы сделать в виде стрелок по обе стороны от самого поля. Или же разместить стрелки вверх-вниз справа от полей Начиная и Заканчивая.
 
При их теперешнем расположении никак не получается "уравновесить" панели За период и Показывать операции: включаешь поле группировки - появляется пустое место слева, включаешь управление диапазоном - справа возникает дырка, разворачиваешь фильтры - опять слева пустое место.
 
А еще мешает, что в настройках страницы сохраняются непосредственные значения дат. И в итоге период не сдвигается автоматически. И периодически приходится корректировать его вручную, не забывая при этом снова сохранить настройки страницы.
Может, я недоглядел чего, и можно как-то сделать, чтобы и страница была настроена и период сам сдвигался?
Наверное фильтры... Dervish 04/09/2004 01:04 #написать ответ
на странице операций будут немного переделываться, поэтому пока ещё немного рано "уравновешивать". Кроме того, думаю, что идеального равновесия всё равно не будет.
 
Так ли часто приходится корректировать сохранённый диапазон дат?
Может я тоже чего не доизучил Владимир 04/09/2004 11:58 #написать ответ
Но я например привык, что фильтр дат у меня - один день, а именно сегодня. Как можно сделать, чтобы при открытии программы у меня первичным считался именно текущий период, а не конкретный диапазон дат? То есть, если стоит "День", то диапазон дат ставится в сегодня. Если "Неделя", то диапазон дат - текущая неделя и т.д. Может это настройка какая есть, типа "При открытии выставлять диапазон дат в текущий период"?
Понимаете ли,... Dervish 04/09/2004 12:18 #написать ответ
есть некоторая сложность, из-за которой возникают трудности при сохранении периода как периода, а не диапазона дат.
 
Представьте, что выбран период в 2 месяца. Сегодня 4-е сентября. Запускаем программу и?... Какой период она должна выбрать? Сентябрь и октябрь? Или Август и сенбярь?
 
Первый период (сентябрь и октябрь) мне интуитивно представляется более ожидаемым (а потому правильным).
 
А второй (август и сентябрь) - удобнее, поскольку он показывает большее количество уже выполненных операций.
 
Или ещё пример: выбран период в год. Что устанавливать при запуске, текущий календарный 2004 год или год с октября 2003 до сентября 2004 года?
 
Первый вариант логичнее, но жутко неудобный в начале года, в январе, поскольку вы не будете видеть недавно выполненные операции.
 
Собственно, вот причина из-за которой я пока сделал сохранение двух дат.
Субъективные ответы Владимир 04/09/2004 15:39 #написать ответ
Позволю дать некоторые субъективные комментарии:
 
1. Периоды в "Две недели" и "Два месяца" нестандартные. Поэтому можем придумывать свои правила. Я бы использовал правило приоритета прошлого. То есть в примере с двумя месяцами выбирать Август-Сентябрь. Но это не принципиально.
 
2. Период=год, по-моему подпадает под стандарт и аналогично другим периодам должен означать календарный год (1.01-31.12) (неделя=календарная неделя, месяц=календарный месяц). См. например, как сделано в CashFly.
 
Если ваши сомнения по поводу смены концепции сохранения/выбора дат на period-based касались только этих двух пунктов, то это хорошо. И, хотя я считаю ответ на пример с годом очевидным, но даже придумав любые другие правила по всем спорным вопросам, главное заключается в смене концепции, так как в текущей версии решение мне кажется очень не удобным.
 
Поясню: главный (ежедневный) сценарий работы с программой для меня заключается в следующем:
1. Открыл программу (должен автоматически выбраться текуший период, в котором присутствует как минимум сегодня).
2. Жмем Добавить операцию. Неким быстрым образом заполняем все необходимые атрибуты. Типовые (наиболее часто используемые) значения хорошо бы вводить с наименьшими трудозатратами или вообще автоматически.
3. Повторяем пункт 2 сколько надо.
4. Беглым взглядом проверяем в статус баре обороты и остатки дня ( в общем случае периода). При необходимости, смотрим более подробные отчеты (редко).
5. Закрываем программу.
 
Именно наиболее быстрое (легкое) выполнение этого сценария я и пытаюсь оптимизировать во всех своих пожеланиях. Так как сценарий уже отработан исторически в течение многих лет.
 
Но все сказанное выше остается скромным мнением одного пользователя, который присматривается к вашей программе и которому не хватает только нескольких мелочей, чтобы заявить - программа Dervish идеал и я бросаю всех конкурентов.
Вообще, надо подумать, но... Dervish 05/09/2004 00:01 #написать ответ
лично меня уже сейчас немного напрягает "двойной стандарт" в предложенном вами подходе: для части периодов используется календарь, а другую часть, пусть и нестандартную, мы реализуем так, как нам удобно... Лучше, конечно же, чтобы был единый подход.
По-моему подход един Владимир 05/09/2004 14:59 #написать ответ
Период = календарный период
По-моему подход един 2 Владимир 05/09/2004 17:10 #написать ответ
Поясню чуть подробнее:
Единый подход заключается в следующем определении: "период для определенной точки во времени = календарный период, содержащий эту точку. В частности текущий период это календарный период содержащий сегодняшний день". Для периодов "День", "Неделя", "Месяц", "Год" это определение дает единственный верный вариант. Для периодов "N дней", "N недель" и т.д. указанное определение допускает N верных вариантов. Все N вариантов верны в рамках ЕДИНОГО подхода. Именно поэтому я сказал, что мое личное предпочтение выбору варианта "приоритета прошлого" непринципиально. Любой другой из N вариантов не нарушает единой концепции.
 
P.S. А вообще я бы совсем не использовал периоды из категории "N стандартных периодов".
Конкретное ТЗ Владимир 06/09/2004 22:30 #написать ответ
Кстати на досуге я поразмышлял над конкретным воплощением наиболее гибкой, но при этом удобной системой контролов для выбора диапазона дат. Вот мои мысли, если интересно:
Преамбула: понятие периода базируется на определении, данном в предыдущем сообщении. А именно:
"период для определенной точки во времени = календарный период, содержащий эту точку. В частности текущий период это календарный период содержащий сегодняшний день".
 
Вариант 1: только "period based". Имеем комбобокс "Период" (можно назвать "Масштаб периода") и кнопки "Вперед"/"Назад". При запуске программы автоматом выставляется текущий период в сохраненом масштабе. Пользователь может менять масштаб периода и листать периоды кнопками в заданном масштабе. Контролы выбора дат всегда заблокированы (disabled) и несут информационный характер, показывая границы выбранного периода.
 
Вариант 2: "Смешанный". Дополнительно к набору контролов варианта 1 имеем checkbox "Фиксированный диапазон". Когда галочки нет, поведение аналогично Варианту 1. Когда галочка ставится - становятся доступными (enabled) контролы выбора диапазона и пользователь может выбрать произвольный диапазон, который и сохраняется.
 
В смешанном варианте есть еще нюансы, но сообщение уже итак большое. Если Вы согласитесь что-то менять в механизме выбора дат, тогда с радостью поделюсь дополнительными комментариями.
Я готов перерабатывать выбор дат. Dervish 07/09/2004 23:48 #написать ответ
Только не знаю, как это сделать лучше. То что есть, это, имхо, несомненный прогресс по сравнению с первой версией. Но явно недостаточно. А кое где и откровенно неудобно.
 
Надо думать и готов обсуждать.
Послал подробное предложение на почту Владимир 12/09/2004 14:59 #написать ответ
Надеюсь, что будет воспринято. Хотя многое взято из уже существующих продуктов.
Спасибо,... Dervish 14/09/2004 02:25 #написать ответ
я посмотрю и отвечу тоже по e-mail-у.
Кстати, мне кажется, что... Dervish 07/09/2004 23:50 #написать ответ
лучше подходить не с точки зрения гибкости и/или корректности выбора периода дат.
 
Главных, имхо, два критерия: интуитивная понятность и лёгкость в использовании.
Бесспорно Владимир 12/09/2004 15:05 #написать ответ
Только к интуитивной понятности и легкости использования нужно еще добавить какую никакую функциональность . А то можно сделать очень просто и понятно, но мало полезно.
А если серьезно, то легкость использования безусловно важный фактор, только он не единственный; как всегда, приходится искать компромиссы между множеством порой несовместимых параметров.
Missing period Владимир 05/09/2004 17:14 #написать ответ
Кстати для полного счастья не хватает периода - "Все". То есть все операции, не зависимо от даты.
А, может, попробовать так? Дим(м) 05/09/2004 18:12 #написать ответ
А что если сохранять не период, а смещения его начала и конца от текущей даты? Т.е. сохранять не значение "месяц", а пару значений: "0 месяцев назад", "1 месяц вперед".
Соответственно, тогда задавать для этих величин "масштаб" (дни, недели, месяцы..) и отсчитывать их соответственно этому масштабу.
 
При этом ничто не помешает завести какие-нибудь специальные значения типа "начало текущего полугодия"...
Может и так... Dervish 07/09/2004 23:51 #написать ответ
я просто не знаю. Наверное надо, чтобы эти идеи просто "отлежались" в голове. Пока не знаю.