Есть форма ввода квитанций.
На форме есть поле период платежа.
Не могу придумать формат данных.
Т.е. может быть квитанция на оплату ЖКХ за январь месяц.
тогда вроде напрашивается комбобокс со списком месяцов и комбобокс с годами. но это как то неюзабельно, имхо.
Теоретически за один месяц может быть несколько квитанций.

Что посоветуете?

Здравствуйте, Аноним, Вы писали:

А>Что посоветуете?

textbox с форматом [yy]yy/[m]m

Здравствуйте, Аноним, Вы писали:

А>Т.е. может быть квитанция на оплату ЖКХ за январь месяц.

Может быть только за один месяц или больше?

А>Теоретически за один месяц может быть несколько квитанций.

Не понял, что именно эта форма вводит.

Здравствуйте, Аноним, Вы писали:

А>тогда вроде напрашивается комбобокс со списком месяцов и комбобокс с годами. но это как то неюзабельно, имхо.
А>Теоретически за один месяц может быть несколько квитанций.
А пользователь-то у нас кто?
Например, оператору приема платежей будет тяжко с комбобоксами.
При личном использовании, возможно, месяц/год и вовсе не нужен — достаточно периодичности платежа и даты оплаты.

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, Аноним, Вы писали:

А>>Т.е. может быть квитанция на оплату ЖКХ за январь месяц.

R3>Может быть только за один месяц или больше?

да, может

А>>Теоретически за один месяц может быть несколько квитанций.

R3>Не понял, что именно эта форма вводит.

форма ввода квитанций и платежей по разным видам услуг (жкх, электр, инет, тв)

Здравствуйте, adontz, Вы писали:

A>textbox с форматом [yy]yy/[m]m

+1, только формат должен быть YYYY-MM, согласно ISO 8601.

Здравствуйте, Аноним, Вы писали:

А>форма ввода квитанций и платежей по разным видам услуг (жкх, электр, инет, тв)

А квитанции существуют в бумажном виде?

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, Аноним, Вы писали:

А>>форма ввода квитанций и платежей по разным видам услуг (жкх, электр, инет, тв)

R3>А квитанции существуют в бумажном виде?

да.

Здравствуйте, Аноним, Вы писали:

R3>>А квитанции существуют в бумажном виде?
А>да.

Тогда возможно:
* печатать квитанции со штрих-кодом, который потом распознаётся и данные заносятся автоматически (почти никакого ручного труда, если использовать потоковый сканер);
* печатать квитанции так, чтобы их можно было бы распознать (нужен человек, контролирующий качество распознавания).

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, Аноним, Вы писали:

R3>>>А квитанции существуют в бумажном виде?
А>>да.

R3>Тогда возможно:
R3>* печатать квитанции со штрих-кодом, который потом распознаётся и данные заносятся автоматически (почти никакого ручного труда, если использовать потоковый сканер);
R3>* печатать квитанции так, чтобы их можно было бы распознать (нужен человек, контролирующий качество распознавания).

Спасибо!

Здравствуйте, Аноним, Вы писали:

А>Есть форма ввода квитанций.
А>На форме есть поле период платежа.
А>Не могу придумать формат данных.
А>Т.е. может быть квитанция на оплату ЖКХ за январь месяц.
А>тогда вроде напрашивается комбобокс со списком месяцов и комбобокс с годами. но это как то неюзабельно, имхо.
А>Теоретически за один месяц может быть несколько квитанций.

А>Что посоветуете?
Ни в коем случае не делать комбобоксы. Если нет возможности избежать ввода вообще (через сканирование квитанций, как тут уже посоветовали), сделайте простой текстовый ввод. Дайте возможность исправлять ошибки. Убедитесь, что легко вводятся самые частые вещи (например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.)
Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало.
Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.

Здравствуйте, Sinclair, Вы писали:

S> А>Есть форма ввода квитанций.
S> А>На форме есть поле период платежа.
S> А>Не могу придумать формат данных.
S> А>Т.е. может быть квитанция на оплату ЖКХ за январь месяц.
S> А>тогда вроде напрашивается комбобокс со списком месяцов и комбобокс с годами. но это как то неюзабельно, имхо.
S> А>Теоретически за один месяц может быть несколько квитанций.

S> А>Что посоветуете?

S> Ни в коем случае не делать комбобоксы. Если нет возможности избежать ввода вообще (через сканирование квитанций, как тут уже посоветовали), сделайте простой текстовый ввод. Дайте возможность исправлять ошибки. Убедитесь, что легко вводятся самые частые вещи (например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.)
S> Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало.
S> Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.
А что потом будет в базе?

Здравствуйте, AlexNek, Вы писали:
AN>А что потом будет в базе?
А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"

Здравствуйте, Sinclair, Вы писали:

S> AN>А что потом будет в базе?

S> А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"
Что то берут меня большие сомнения что при таком вводе удастся что то нормализовать.

Здравствуйте, AlexNek, Вы писали:

S>> А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"
AN>Что то берут меня большие сомнения что при таком вводе удастся что то нормализовать.
Обоснования?
Для интересу попробуйте запустить Outlook, нажать "новая встреча" и попробовать ввести разную ерунду в поле даты. Окажется, что выбор из выпадающего календаря — не самый быстрый способ ввести "послезавтра".

Язык ввода, который я предлагаю, будет обладать гарантированно примитивной грамматикой, и реализовать его нет никаких проблем.
Зато появляется масса приятных последствий — в том числе и возможность просто Paste периода в поле ввода — вместо мучительного щёлкания мышкой в drop down fields.
Кстати, дроп-дауны в винде поддерживают и клавиатурный ввод, но для его корректной работы нужно полностью вводить префикс. То есть, чтобы ввести март 2011, придётся так и набирать м-а-р-т-Tab-2-0-1-1. Для февраля или сентября, понятно, попроще — ф-Tab-2-0-1-1. И невозможно сделать Paste сразу в два дроп-дауна.

Здравствуйте, Sinclair, Вы писали:

S> S>> А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"

S> AN>Что то берут меня большие сомнения что при таком вводе удастся что то нормализовать.

S> Обоснования?
что введется при наборе "йцукен", например?
S> Для интересу попробуйте запустить Outlook, нажать "новая встреча" и попробовать ввести разную ерунду в поле даты. Окажется, что выбор из выпадающего календаря — не самый быстрый способ ввести "послезавтра".
Дело в том что возникает конфликт между скоростью и требованием не давать пользователю вводить неправильные данные

S> Язык ввода, который я предлагаю, будет обладать гарантированно примитивной грамматикой, и реализовать его нет никаких проблем.
см. выше

Здравствуйте, AlexNek, Вы писали:

S>> Обоснования?
AN>что введется при наборе "йцукен", например?
Ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести что-то осмысленное.

S>> Для интересу попробуйте запустить Outlook, нажать "новая встреча" и попробовать ввести разную ерунду в поле даты. Окажется, что выбор из выпадающего календаря — не самый быстрый способ ввести "послезавтра".
AN>Дело в том что возникает конфликт между скоростью и требованием не давать пользователю вводить неправильные данные
Конфликт надуман. Ввод осуществляется интерактивно. Это означает, что можно взаимодействовать с пользователем массой нормальных способов, не заставляя его прогибаться под удобство разработчика.

Здравствуйте, Sinclair, Вы писали:

S>Язык ввода, который я предлагаю, будет обладать гарантированно примитивной грамматикой, и реализовать его нет никаких проблем.

т.е. вы предлагаете просто регэкспом получать месяц и если есть год?

Здравствуйте, Sinclair, Вы писали:

S> S>> Обоснования?

S> AN>что введется при наборе "йцукен", например?

S> Ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести что-то осмысленное.
угу, а дата нужна будет уже при вводе следующего поля. И получаем умный контрол который автоматом правит ввод пользователя, уже проходили...

S> S>> Для интересу попробуйте запустить Outlook, нажать "новая встреча" и попробовать ввести разную ерунду в поле даты. Окажется, что выбор из выпадающего календаря — не самый быстрый способ ввести "послезавтра".

S> AN>Дело в том что возникает конфликт между скоростью и требованием не давать пользователю вводить неправильные данные

S> Конфликт надуман.
Что введется в результате ввода 05.07, 05/07, 29.02?
S> Ввод осуществляется интерактивно. Это означает, что можно взаимодействовать с пользователем массой нормальных способов, не заставляя его прогибаться под удобство разработчика.
Дело не в удобстве разработчика, а в концепте.

Здравствуйте, AlexNek, Вы писали:

S>> Ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести что-то осмысленное.
AN>угу, а дата нужна будет уже при вводе следующего поля.
Зачем?
AN>И получаем умный контрол который автоматом правит ввод пользователя, уже проходили...
Проходили и проходим. Между прочим, Outlook является одним из самых популярных почтовых клиентов в мире. Вы его уже запустили?

S>> Конфликт надуман.
AN>Что введется в результате ввода 05.07, 05/07, 29.02?
ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести месяц в принятом формате.
Поймите, задача не стоит в интерпретации произвольной строки. Задача стоит в разработке удобного текстового микроязыка, который был бы удобен пользователю. Всё, что не укладывается в этот язык — ошибка ввода.

AN>Дело не в удобстве разработчика, а в концепте.
Совершенно верно. Концепт "разделить объект ввода на несколько компонентов" — ужасен и неудобен.
Аналогичная проблема с адресом. Причём в 99% приложений адрес нужен только для того, чтобы напечатать его на накладной — т.е. вообще плевать на то, где там дом, а где улица.

Некоторые программисты (не буду показывать пальцем) разделяют на компоненты даже телефонный номер.

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