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

А>т.е. вы предлагаете просто регэкспом получать месяц и если есть год?
Я предлагаю
1. сначала продумать язык с полной грамматикой.
2. выбрать способ реализации парсера. Может быть — на регекспах; может быть — нет. Это вопрос частный.
3. реализовать автодополнение, чтобы оператор во время ввода видел, что получается в результате.

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

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

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

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

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

Для какого следующего поля?

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

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

Ну и в чем проблема?

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

Читать, например, тут: http://productblog.37signals.com/products/2007/06/the_quickest_wa.html

Их календарь позволяет вводить даты в следующем виде:

Время
9am
6:30pm

Дата
January 7
Oct 29
7/12

Дата и время
July 15 2pm
9/12 8pm

Range
August 3 — August 16
Jan 24 — Feb 6
8/10 — 8/25

Это все сложно распарсить и положить в базу? Нет. Сложно показать пользователю, как надо вводить даты? Нет. Сложно выводить подсказки в процессе набора даты? Нет.

В чем проблема?

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

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

S> AN>угу, а дата нужна будет уже при вводе следующего поля.

S> Зачем?
потому как если введена пятница, нужно ответить будет ли кто в субботу работать, в остальных случаях поле реадонлу (невидимо). Чисто как пример...

S> AN>И получаем умный контрол который автоматом правит ввод пользователя, уже проходили...

S> Проходили и проходим. Между прочим, Outlook является одним из самых популярных почтовых клиентов в мире. Вы его уже запустили?
Сорри, Outlook не имеемс.

S> S>> Конфликт надуман.

S> AN>Что введется в результате ввода 05.07, 05/07, 29.02?

S> ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести месяц в принятом формате.
почему ничего не введется? Это ведь вроде соответствует вашему "языку".
S> Поймите, задача не стоит в интерпретации произвольной строки. Задача стоит в разработке удобного текстового микроязыка, который был бы удобен пользователю. Всё, что не укладывается в этот язык — ошибка ввода.
А что укладывается в язык, но является ошибкой ввода?

S> AN>Дело не в удобстве разработчика, а в концепте.

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

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

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

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

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

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

> AN>угу, а дата нужна будет уже при вводе следующего поля. И получаем умный контрол который автоматом правит ввод пользователя, уже проходили...

> Для какого следующего поля?
Неважно, можно придумать массу примеров.

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

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

> Ну и в чем проблема?
Скорость обычно подразумевает исключительно ввод с клавиатуры, при этом не всегда возможно запретить ввод неправильных данных. (ну типа 29.02 можно ввести при этом подходе)

> S>> Конфликт надуман.

> AN>Что введется в результате ввода 05.07, 05/07, 29.02?

> S>> Ввод осуществляется интерактивно. Это означает, что можно взаимодействовать с пользователем массой нормальных способов, не заставляя его прогибаться под удобство разработчика.

> AN>Дело не в удобстве разработчика, а в концепте.

> Читать, например, тут: http://productblog.37signals.com/products/2007/06/the_quickest_wa.html

> Их календарь позволяет вводить даты в следующем виде:

> Это все сложно распарсить и положить в базу? Нет. Сложно показать пользователю, как надо вводить даты? Нет. Сложно выводить подсказки в процессе набора даты? Нет.

> В чем проблема?
В том, что это красиво выглядит на бумаге и в отдельно взятом регионе.
Простой пример. Что введется после набора 7/12?

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

S>3. реализовать автодополнение, чтобы оператор во время ввода видел, что получается в результате.

Можно подробней про вашу идею?
т.е. чтобы когда он ввел "ию" у него всплывало
"июнь 2011
июль 2011"?

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

А>Можно подробней про вашу идею?
А>т.е. чтобы когда он ввел "ию" у него всплывало
А>"июнь 2011
А>июль 2011"?
Да, это было бы лучше всего.

Здравствуйте, AlexNek, Вы писали:
S>> Зачем?
AN>потому как если введена пятница, нужно ответить будет ли кто в субботу работать, в остальных случаях поле реадонлу (невидимо). Чисто как пример...
Поймите, для разных задач — разные решения. Вы сейчас пытаетесь придумать другую задачу.
Кстати, для этой другой задачи тоже может найтись очень хорошее полутекстовое или чисто текстовое решение.

S>> Проходили и проходим. Между прочим, Outlook является одним из самых популярных почтовых клиентов в мире. Вы его уже запустили?
AN>Сорри, Outlook не имеемс.
Ну и зря. Как же вы проектируете интерфейсы, не глядя в то, что разработано до вас?

AN>почему ничего не введется? Это ведь вроде соответствует вашему "языку".
Вроде не соответствует.

AN>А что укладывается в язык, но является ошибкой ввода?
Тогда дайте определение "ошибки ввода". Я не понимаю, о чём вы говорите. Если вы об ошибках типа "июнь" вместо "июля" — тут ничего не поделаешь, и никакие дропдауны не спасут.

AN>Я имел в виду другой.
AN>- Пользователь не имеет возможности ввести неправильные данные
AN>- Поле ввода не имеет права изменять введенные данные.
Первый из этих постулатов при дословном следовании приводит к совершенно чудовищным интерфейсам. Например, контрол ввода даты, валидирующий ввод на каждом нажатии. Задача исправить 1.04.1977 на 31.03.1977 превращается в натуральный квест, сопровождаемый отвратительным писком. Потому, что "умный" контрол знает, что в апреле нет 31го числа, и не даёт его ввести. В итоге нужно сначала исправить месяц, потом вернуться в число. Зато да — пользователь не имеет возможности ввести неправильные данные.

Второй постулат более-менее верен. По крайней мере, неследование ему может привести к нехорошим результатам — например, к отправке не того, чего ожидал пользователь. Но благодаря интерактивности всегда можно сгладить его ограничения. Попробуйте запустить браузер и начать набирать rsd в адресной строке. Ручаюсь, ваш браузер предложит автодополнение, которое, вообще говоря, нарушает этот постулат.

S>> Аналогичная проблема с адресом. Причём в 99% приложений адрес нужен только для того, чтобы напечатать его на накладной — т.е. вообще плевать на то, где там дом, а где улица.
AN>Не всегда, например требуется расположить номер дома с выравниваем вправо или почтовый индекс нужно в другом месте напечатать.
Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться. Дом с выравниванием вправо вообще не так уж трудно реализовать.
Вообще, всегда можно добиться многого, если думать головой. К сожалению, многие программисты перекладывают решение своих задач на пользователя.

S>> Некоторые программисты (не буду показывать пальцем) разделяют на компоненты даже телефонный номер.
AN>все бывает, если нет ввода по маскам.
Ввод по маске тоже немногим лучше. Лакмусовая бумажка: если работает Paste, значит контрол работает правильно.

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

S>Здравствуйте, AlexNek, Вы писали:
S>>> Зачем?
AN>>потому как если введена пятница, нужно ответить будет ли кто в субботу работать, в остальных случаях поле реадонлу (невидимо). Чисто как пример...
S>Поймите, для разных задач — разные решения. Вы сейчас пытаетесь придумать другую задачу.
S>Кстати, для этой другой задачи тоже может найтись очень хорошее полутекстовое или чисто текстовое решение.
Вроде одна и таже задача — ввод данных в форму. Или?

S>>> Проходили и проходим. Между прочим, Outlook является одним из самых популярных почтовых клиентов в мире. Вы его уже запустили?
AN>>Сорри, Outlook не имеемс.
S>Ну и зря. Как же вы проектируете интерфейсы, не глядя в то, что разработано до вас?
Для этого лучше смотреть что нравится. Да и нафига мне оутлук, когда другой клиент почты мне гораздо удобнее и приятней.

AN>>почему ничего не введется? Это ведь вроде соответствует вашему "языку".
S>Вроде не соответствует.
А разве год не должен быть добавляться?

AN>>А что укладывается в язык, но является ошибкой ввода?
S>Тогда дайте определение "ошибки ввода". Я не понимаю, о чём вы говорите. Если вы об ошибках типа "июнь" вместо "июля" — тут ничего не поделаешь, и никакие дропдауны не спасут.
ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.

AN>>Я имел в виду другой.
AN>>- Пользователь не имеет возможности ввести неправильные данные
AN>>- Поле ввода не имеет права изменять введенные данные.
S>Первый из этих постулатов при дословном следовании приводит к совершенно чудовищным интерфейсам. Например, контрол ввода даты, валидирующий ввод на каждом нажатии. Задача исправить 1.04.1977 на 31.03.1977 превращается в натуральный квест, сопровождаемый отвратительным писком. Потому, что "умный" контрол знает, что в апреле нет 31го числа, и не даёт его ввести. В итоге нужно сначала исправить месяц, потом вернуться в число. Зато да — пользователь не имеет возможности ввести неправильные данные.
В случае дат решается специализированным редатором, в которым достаточно сложно опеспечить быстрый ввод (из-за этого и говорил о конфликте)

S>Второй постулат более-менее верен. По крайней мере, неследование ему может привести к нехорошим результатам — например, к отправке не того, чего ожидал пользователь. Но благодаря интерактивности всегда можно сгладить его ограничения. Попробуйте запустить браузер и начать набирать rsd в адресной строке. Ручаюсь, ваш браузер предложит автодополнение, которое, вообще говоря, нарушает этот постулат.
Там же сказано "введенные данные", т.е. не во время ввода, а после. Типа как микрософт в МСДН сделала. (По поиску находишь английский тект, а она тебя выбрасывает на язык по расположению интернет провайдера)

S>>> Аналогичная проблема с адресом. Причём в 99% приложений адрес нужен только для того, чтобы напечатать его на накладной — т.е. вообще плевать на то, где там дом, а где улица.
AN>>Не всегда, например требуется расположить номер дома с выравниваем вправо или почтовый индекс нужно в другом месте напечатать.
S>Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться.
Стараться вообще не нужно, достаточно набрать на один символ больше или меньше
S>Дом с выравниванием вправо вообще не так уж трудно реализовать.
Да если он только цифра и стоит всегда в одном месте.
S>Вообще, всегда можно добиться многого, если думать головой. К сожалению, многие программисты перекладывают решение своих задач на пользователя.
Доволно часто программисты просто не знают что нужно пользователя.

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

AN>Вроде одна и таже задача — ввод данных в форму. Или?
Разные данные, разные формы. Разные требования к этим данным.

S>>Ну и зря. Как же вы проектируете интерфейсы, не глядя в то, что разработано до вас?
AN>Для этого лучше смотреть что нравится. Да и нафига мне оутлук, когда другой клиент почты мне гораздо удобнее и приятней.
Аутлук — один из мировых передовиков юзабилити. Кстати, как и упомянутые рядом 37signals.
Впрочем, это не так важно. Посмотрите на другой близкий пример — google maps. Попробуйте представить, насколько "удобнее" бы он был, если бы требовал вводить адреса по компонентам.

AN>А разве год не должен быть добавляться?
К чему добавляться? Язык, который я описал — текстовые месяцы, числовой год. Никаких точек и знаков деления в нём не предусмотрено.

AN>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.
Ужас какой. А почему вы получаете 5е января? Может быть, потому, что у пользователя стоит US locale?
Если вас это сильно беспокоило, надо было обеспечить поддержку локали приложения, независимой от системной.
Вот, кстати, поставил я себе официальную программу Декларация 2010 от нашей налоговой. Её проектировали милые люди — требуется, чтобы в системной локали стояла запятая в качестве десятичного разделителя, и русский формат дат. И этим людям кто-то платит зарплату за мой счёт.

AN>В случае дат решается специализированным редатором, в которым достаточно сложно опеспечить быстрый ввод (из-за этого и говорил о конфликте)
Для случая дат есть множество замечательных решений, которые прекрасно совместимы с быстрым вводом.


S>>Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться.
AN>Стараться вообще не нужно, достаточно набрать на один символ больше или меньше
А на что вам интерактивность? Если вы видите, что индекс не вполне корректный — подчеркните его красненьким, предложите варианты.

AN>Доволно часто программисты просто не знают что нужно пользователя.
Да, в этом, собственно, корень всех зол. Программисты искренне думают, что пользователю надо выбрать год рождения из списка вариантов. В то время, как пользователю надо всего лишь арендовать автомобиль, и в его системе ценностей выбор четырёхзначного числа из списка в 90 позиций занимает последнее место.

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

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

AN>>Вроде одна и таже задача — ввод данных в форму. Или?
S>Разные данные, разные формы. Разные требования к этим данным.
То бишь рассматриваем исключительно конкретную задачу? А именно ввод даты в форму все поля которой незавимы от состояния друг друга.

S>>>Ну и зря. Как же вы проектируете интерфейсы, не глядя в то, что разработано до вас?
AN>>Для этого лучше смотреть что нравится. Да и нафига мне оутлук, когда другой клиент почты мне гораздо удобнее и приятней.
S>Аутлук — один из мировых передовиков юзабилити. Кстати, как и упомянутые рядом 37signals.
S>Впрочем, это не так важно. Посмотрите на другой близкий пример — google maps. Попробуйте представить, насколько "удобнее" бы он был, если бы требовал вводить адреса по компонентам.

А где я агитировал разбивать ввод на компоненты?
А про гугл — см. "Разные данные, разные формы. Разные требования к этим данным."
AN>>А разве год не должен быть добавляться?
S>К чему добавляться? Язык, который я описал — текстовые месяцы, числовой год. Никаких точек и знаков деления в нём не предусмотрено.
Что то я видимо пропустил, никогда не приходила идея вводить месяцы буквами, обычно весь дополнительный ввод идет через цифровую клавиатуру
AN>>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.
S>Ужас какой. А почему вы получаете 5е января? Может быть, потому, что у пользователя стоит US locale?
S>Если вас это сильно беспокоило, надо было обеспечить поддержку локали приложения, независимой от системной.
Все было именно так, но затык все равно оставался.

S>Вот, кстати, поставил я себе официальную программу Декларация 2010 от нашей налоговой. Её проектировали милые люди — требуется, чтобы в системной локали стояла запятая в качестве десятичного разделителя, и русский формат дат. И этим людям кто-то платит зарплату за мой счёт.
Кстати excel от этого недалеко ушел.
И могу назвать программу хуже которой я еще не видел по юзабилити — SAP

AN>>В случае дат решается специализированным редатором, в которым достаточно сложно опеспечить быстрый ввод (из-за этого и говорил о конфликте)
S>Для случая дат есть множество замечательных решений, которые прекрасно совместимы с быстрым вводом.
Сейчас не нужно, но просто интересно, можно подробней?

S>>>Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться.
AN>>Стараться вообще не нужно, достаточно набрать на один символ больше или меньше
S>А на что вам интерактивность? Если вы видите, что индекс не вполне корректный — подчеркните его красненьким, предложите варианты.
Интерактивный парсер совмещенный с редактором? А какой ввод формата адреса будет известно заранее? И разработаны все парсеры

AN>>Доволно часто программисты просто не знают что нужно пользователя.
S>Да, в этом, собственно, корень всех зол. Программисты искренне думают, что пользователю надо выбрать год рождения из списка вариантов. В то время, как пользователю надо всего лишь арендовать автомобиль, и в его системе ценностей выбор четырёхзначного числа из списка в 90 позиций занимает последнее место.
Лучше разрешить ввод всех данных, а потом заниматься перегрузкой только правильных с сообщением об ошибке?
Не помню уж где было. Вводишь данные, нажимаешь ок, получаешь назад сообщение — "пароль должен быть больше 6 символов" и пустую форму

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

AN>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.

Вот с этой ошибкой надо адресно бороться, повсеместно насаждая ISO 8601 (также известный под псевдонимом ГОСТ ИСО 8601, ранее — ГОСТ 7.64-90). Год в начале, потом месяц, потом день. И чтобы у всех навсегда в мозгах отпечаталось, что старшие разряды — слева, младшие — справа.

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

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

AN>>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.

C>Вот с этой ошибкой надо адресно бороться, повсеместно насаждая ISO 8601 (также известный под псевдонимом ГОСТ ИСО 8601, ранее — ГОСТ 7.64-90). Год в начале, потом месяц, потом день. И чтобы у всех навсегда в мозгах отпечаталось, что старшие разряды — слева, младшие — справа.
Сомневаюсь я в этом однако.
Как там Кибиты уже прижились?

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

AN>То бишь рассматриваем исключительно конкретную задачу? А именно ввод даты в форму все поля которой незавимы от состояния друг друга.
Рассматриваем задачу "ввод периода платежа". Цитирую:

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

AN>Что то я видимо пропустил, никогда не приходила идея вводить месяцы буквами, обычно весь дополнительный ввод идет через цифровую клавиатуру

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

Хотя здесь, в принципе, можно и цифрами.

AN>Все было именно так, но затык все равно оставался.
Ужас.

AN>Кстати excel от этого недалеко ушел.
Кстати, у екселя как раз всё очень-очень хорошо. Более прогибающейся под настройки пользователя программы ещё поискать.
С угадыванием форматов у него, конечно же, лучше всего в локали US/English. Но и на русском работает вполне ничего себе.
Попробуйте набрать в екселе "май 2011"

S>>Для случая дат есть множество замечательных решений, которые прекрасно совместимы с быстрым вводом.
AN>Сейчас не нужно, но просто интересно, можно подробней?
Например 37signals. Для починки проблем 01/04 можно транслировать всё в формат с текстовым именем месяца.

AN>Интерактивный парсер совмещенный с редактором? А какой ввод формата адреса будет известно заранее? И разработаны все парсеры
Ну да. Прочитайте Хайнлайна, Астронавт Джонс. Там дяденька на полном серъёзе писал про то, как в компьютер космического корабля поправки курса надо было забивать в двоичном коде, переводя их по таблицам из десятичного кода.
Уже в семидесятых годах это было смешно читать. Ваше недоверие мне очень ту книжку напоминает. Да, компютер вполне способен распознать ввод. Язык SQL, скажем, посложнее языка описания современных почтовых адресов.
Посмотрите обратно на maps.google.com — там реализован тупейший вариант, но и он работает бесконечно лучше комбобоксов с названиями городов и отдельных полей для номера дома.

AN>Лучше разрешить ввод всех данных, а потом заниматься перегрузкой только правильных с сообщением об ошибке?
Лучше думать головой. В частности, для массового ввода текст — очень хорош.

AN>Не помню уж где было. Вводишь данные, нажимаешь ок, получаешь назад сообщение — "пароль должен быть больше 6 символов" и пустую форму
Зачем вы приводите мне плохие примеры? Думайте о хороших.

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

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

AN>>То бишь рассматриваем исключительно конкретную задачу? А именно ввод даты в форму все поля которой незавимы от состояния друг друга.
S>Рассматриваем задачу "ввод периода платежа". Цитирую:

S>

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

Привык я задачи обощать
AN>>Что то я видимо пропустил, никогда не приходила идея вводить месяцы буквами, обычно весь дополнительный ввод идет через цифровую клавиатуру
S>

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

S>Хотя здесь, в принципе, можно и цифрами.
в апреле 2011 "апрель" = апрель 2011 — именно это я и имел ввиду, говоря о добавке года.

AN>>Все было именно так, но затык все равно оставался.
S>Ужас.

AN>>Кстати excel от этого недалеко ушел.
S>Кстати, у екселя как раз всё очень-очень хорошо. Более прогибающейся под настройки пользователя программы ещё поискать.
S>С угадыванием форматов у него, конечно же, лучше всего в локали US/English. Но и на русском работает вполне ничего себе.
S>Попробуйте набрать в екселе "май 2011"
получил "май 2011"
Наберите вначале цифры в локали с ".", а затем попробуйте исправить в локали с ","

S>>>Для случая дат есть множество замечательных решений, которые прекрасно совместимы с быстрым вводом.
AN>>Сейчас не нужно, но просто интересно, можно подробней?
S>Например 37signals. Для починки проблем 01/04 можно транслировать всё в формат с текстовым именем месяца.
нельзя, все данные поступали в цифрах.

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

AN>Привык я задачи обощать
Напрасно. Общее решение любой задачи ввода данных — PropertyGrid. Для реальных UI, ориентированных на людей, непригоден.

S>>Хотя здесь, в принципе, можно и цифрами.
AN>в апреле 2011 "апрель" = апрель 2011 — именно это я и имел ввиду, говоря о добавке года.
Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".
S>>Попробуйте набрать в екселе "май 2011"
AN>получил "май 2011"
Посмотрите вовнутрь. Если там не 1.05.2011, то, скорее всего, у вас английская локаль. В ней можно попробовать набрать May 2011.

AN>Наберите вначале цифры в локали с ".", а затем попробуйте исправить в локали с ","
Регулярно редактирую документы Excel в разных локалях. Никаких проблем нет — точки волшебным образом превращаются в запятые, запятые в точку с запятой, а VLOOKUP — в ВПР.

AN>нельзя, все данные поступали в цифрах.
Всё можно, если не придумывать себе искусственных ограничений.

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

AN>>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.
C>Вот с этой ошибкой надо адресно бороться, повсеместно насаждая ISO 8601 (также известный под псевдонимом ГОСТ ИСО 8601, ранее — ГОСТ 7.64-90). Год в начале, потом месяц, потом день. И чтобы у всех навсегда в мозгах отпечаталось, что старшие разряды — слева, младшие — справа.

Человек важнее любого ГОСТа. (Тем более, что ГОСТ — это не всегда хорошо.)
Пока вы думаете по другому — у вас не будет хороших продуктов.

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

S> AN>Привык я задачи обощать

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

S> S>>Хотя здесь, в принципе, можно и цифрами.

S> AN>в апреле 2011 "апрель" = апрель 2011 — именно это я и имел ввиду, говоря о добавке года.

S> Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".
Это не произвольная строка. 05/07/2011 вполне легальная строка для даты и екзель так и делает. (Добавляет год)

S> S>>Попробуйте набрать в екселе "май 2011"

S> AN>получил "май 2011"

S> Посмотрите вовнутрь. Если там не 1.05.2011, то, скорее всего, у вас английская локаль. В ней можно попробовать набрать May 2011.
Именно это я и хотел сказать

S> AN>Наберите вначале цифры в локали с ".", а затем попробуйте исправить в локали с ","

S> Регулярно редактирую документы Excel в разных локалях. Никаких проблем нет — точки волшебным образом превращаются в запятые, запятые в точку с запятой, а VLOOKUP — в ВПР.
ну значит я уже забыл как точно воспроизвести , но у меня проблемы были. А уж перевод функций это просто катастрофа. Я то помню все используемые имена на английском. (Вроде я делал в настройках локали с запятыми точки.)

S> AN>нельзя, все данные поступали в цифрах.

S> Всё можно, если не придумывать себе искусственных ограничений.
Клиенты бы загрызли, да и в ТЗ записано.

Здравствуйте, AlexNek, Вы писали:
AN>А про PropertyGrid действительно интересно мне лично он очень нравиться, а вот людям далеким от компа нет. Никак не дойдет где заблуждаюсь.
Вы просто работаете на другой работе.
Любой UI должен быть построен не вокруг данных, а вокруг действий.
Точнее, так: есть две задачи в UI:
1. Отображать что-то
2. Давать пользователю совершать действия
Хорошие UI cовмещают и то и другое.
Property Grid очень плохо отображают практически любые данные. Читать Tufte по поводу того, как и что нужно отображать.
Кроме этого, он очень плохо подходит для практически любых задач, поскольку в нём реализован (и то не очень хорошо) только один глагол — "изменить один атрибут некоторого объекта". В жизни таких задач не бывает.
Попробуйте представить себе несложный use-case — например "оплата сотового телефона", и оптимизируйте его до идеала.

S>> Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".
AN>Это не произвольная строка. 05/07/2011 вполне легальная строка для даты и екзель так и делает. (Добавляет год)
В задаче речь про даты не шла. Речь шла о вводе периода платежа. Период — это, к примеру "март 2011". А не "пятое июля".
AN>Именно это я и хотел сказать
Надеюсь, вы поняли, что хотел сказать я.

S>> Регулярно редактирую документы Excel в разных локалях. Никаких проблем нет — точки волшебным образом превращаются в запятые, запятые в точку с запятой, а VLOOKUP — в ВПР.
AN>ну значит я уже забыл как точно воспроизвести , но у меня проблемы были. А уж перевод функций это просто катастрофа. Я то помню все используемые имена на английском. (Вроде я делал в настройках локали с запятыми точки.)
Нет никакой катастрофы. Ексель эти вещи делает очень хорошо, и уже существенно больше десяти лет. Как говорят наши заокеанские коллеги — "это не ракетостроение".

S>> Всё можно, если не придумывать себе искусственных ограничений.
AN>Клиенты бы загрызли, да и в ТЗ записано.
Вы слишком плохо думаете о клиентах, и слишком хорошо — о ТЗ. Ничего, это пройдёт

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

S> AN>А про PropertyGrid действительно интересно мне лично он очень нравиться, а вот людям далеким от компа нет. Никак не дойдет где заблуждаюсь.

S> Вы просто работаете на другой работе.
В смысле?
S> Любой UI должен быть построен не вокруг данных, а вокруг действий.
S> Точнее, так: есть две задачи в UI:
S> 1. Отображать что-то
S> 2. Давать пользователю совершать действия
S> Хорошие UI cовмещают и то и другое.
S> Property Grid очень плохо отображают практически любые данные. Читать Tufte по поводу того, как и что нужно отображать.
Нашел это, но про property grid там ничего нет
здесь
здесь
S> Кроме этого, он очень плохо подходит для практически любых задач, поскольку в нём реализован (и то не очень хорошо) только один глагол — "изменить один атрибут некоторого объекта". В жизни таких задач не бывает.
Пока не было ни одной задачи где бы он не подошел. И почему только один?
S> Попробуйте представить себе несложный use-case — например "оплата сотового телефона", и оптимизируйте его до идеала.
При чем здесь property grid?
— Идешь в магазин, покупаешь карточку, вводишь номер.
Или
— Заключаешь договор с оператором и он снимает денюжку прямо о счета.

S> S>> Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".

S> AN>Это не произвольная строка. 05/07/2011 вполне легальная строка для даты и екзель так и делает. (Добавляет год)

S> В задаче речь про даты не шла. Речь шла о вводе периода платежа. Период — это, к примеру "март 2011". А не "пятое июля".
Но период это и 1.3.2011-5.10.2011.

S> AN>Именно это я и хотел сказать

S> Надеюсь, вы поняли, что хотел сказать я.
То что экзель может конвертировать название месяца в дату, при определенных условиях?

S> S>> Регулярно редактирую документы Excel в разных локалях. Никаких проблем нет — точки волшебным образом превращаются в запятые, запятые в точку с запятой, а VLOOKUP — в ВПР.

S> AN>ну значит я уже забыл как точно воспроизвести , но у меня проблемы были. А уж перевод функций это просто катастрофа. Я то помню все используемые имена на английском. (Вроде я делал в настройках локали с запятыми точки.)

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

S> S>> Всё можно, если не придумывать себе искусственных ограничений.
Их не нужно придумывать они есть.
S> AN>Клиенты бы загрызли, да и в ТЗ записано.

S> Вы слишком плохо думаете о клиентах, и слишком хорошо — о ТЗ. Ничего, это пройдёт
И сколько еще нужно ждать?

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

S>> Вы просто работаете на другой работе.
AN>В смысле?
Вы — программист. Другие люди — нет.

AN>Нашел это, но про property grid там ничего нет
Вот именно.
AN>здесь
AN>здесь
Ага, этот тот самый.
http://store.artlebedev.ru/books/lebedevs-choice/envisioning-information/
http://store.artlebedev.ru/books/lebedevs-choice/beautiful-evidence/
http://store.artlebedev.ru/books/lebedevs-choice/the-visual-display-of-quantitative-information/
http://store.artlebedev.ru/books/lebedevs-choice/visual-explanations/
Но можно заказать на Амазоне — выйдет сильно дешевле.

S>> Кроме этого, он очень плохо подходит для практически любых задач, поскольку в нём реализован (и то не очень хорошо) только один глагол — "изменить один атрибут некоторого объекта". В жизни таких задач не бывает.
AN>Пока не было ни одной задачи где бы он не подошел. И почему только один?
Потому что в нём нет никаких средств по согласованному изменению нескольких атрибутов.

AN>При чем здесь property grid?
AN>- Идешь в магазин, покупаешь карточку, вводишь номер.
AN>Или
AN>- Заключаешь договор с оператором и он снимает денюжку прямо о счета.
Совершенно верно. Как видите, property grid здесь ни при чём. А вы говорите — нет ни одной задачи, где бы он не подошёл.

S>> В задаче речь про даты не шла. Речь шла о вводе периода платежа. Период — это, к примеру "март 2011". А не "пятое июля".
AN>Но период это и 1.3.2011-5.10.2011.
Вы опять уходите от решения задачи. Задачи вводить произвольный период не стояло. Если двигаться дальше по вашему пути, то мы получим просто проклятие для оператора: неудобный, замедляющий работу контрол, который требует вводить две даты там, где нужно просто выбрать месяц.

То, что ексель прекрасно парсит текст при вводе даты. Несмотря на то, что он даже не знает заранее — а дата ли там.
AN>Насколько я помню, у меня были большие проблемы с запятой и точкой. А также постоянно при попытке найти нужную функцию.
Надо полагать, вы пользуетесь екселем от случая к случаю, и постоянно в разных локалях. У регулярных пользователей локаль ровно одна, а user experience в пределах одной локали прекрасно воспроизводим.
Работать в нескольких локалях тоже можно, но это несколько сложнее.

S>> Вы слишком плохо думаете о клиентах, и слишком хорошо — о ТЗ. Ничего, это пройдёт
AN>И сколько еще нужно ждать?
Ждать ничего не нужно. Нужно работать над собой. Читать различные источники, смотреть на опыт передовиков, экспериментировать, много думать.