Здравствуйте, AlexNek, Вы писали:
AN>Я пока заметил только это "Пишет, вроде бы, очевидные вещи", надо будет поискать остальное. Для меня подобное впечатление оставил Н.Вирт.
Я не могу заставить вас читать его.
AN>И последнего крика моды от меня никто не требует. Мне просто это интересно в некоторой степени, так как хочется узнать, что то новое.
Когнитивная психология — это не последний крик моды. Тафти приводит примеры удачных информационных дизайнов образца 18го века, и примеры неудачных 20го.
S>> Дело не в том, что можно представлять данные в виде графиков. Там очень много того, как именно нужно представлять табличные данные в таблицах. Или как представлять графики. AN>Первичный просмотр этого не выявил
Значит, вы просматривали невнимательно или не ту из его книг.
AN>Ну так вся задача вроде уже есть (вы ее сами сформулировали) просто появляются дополнительные условия.
Эти условия не берутся с потолка. Почему только одна из границ не может быть больше 10? Почему 10, не 12?
AN>Так задача вроде уже есть, хотелось удобный способ изменения многих переменных или одной. (на примере таблицы)
На примере таблицы удобный способ реализован в Excel.
В жизни задача не формулируется в терминах формы и её полей. Подумайте о таком сценарии: управление автомобилем.
Трогание с места на машине с механикой требует согласованного управления тремя параметрами: усилием торможения, коэффициентом сцепления, и оборотами двигателя.
Трогание с места на машине с автоматом требует управления одним параметром: сначала усилием торможения, потом оборотами. В зависимости от модели машины "внутри" у неё есть ещё много "переменных". Если бы автокомпании проектировали UI в "data-driven" парадигме, то на приборной панели была бы куча ручек, а разработчики бы объясняли, что не могут найти удобный способ "выделения группы параметров, которые хочется согласованно изменить".
Очевидно, что решение, пригодное для управления Приусом, не будет подходить для "общего случая одиннадцати параметров".
S>> В сторону выяснения того, для чего и что пользователь делает. AN>Только не понимаю что это может дать? Ну знаю я что число пять пользователь вводит для того чтобы указать число рабочих дней в неделе и что допустимые значения от 1 до 7 и что данная форма ему нужна для планирования работы персонала.
Этого мало. Надо знать, из чего вообще состоит "планирование работы персонала". Насколько часто выполняются различные действия. Если это число настраивается один раз в жизни на уровне всей системы, то не стоит заставлять вводить его для каждого сотрудника. Может быть, надо дать возможность использовать несколько календарей вместо количества дней в неделе (как в MS Project). Может быть, надо дать возможность вводить рабочие периоды, не кратные 7 дням (смены 2 дня через 3 дня), потому что без этого кадровичке приходится руками забивать разное количество дней каждую неделю.
AN>Есть некое устройство, точнее различных типов может быть довольно много и фиг знает какие еще появятся потом. Устройство в зависимости от конфигурации и внутреннего состояния может выдавать совершенно различный набор данных. Эти данные нужно отображать и какую то часть из них редактировать и передавать наза в устройство.
AN>Хотя решение конкретной задачи меня не очень интересует, больше интересует решение в "общем виде".
Общее решение годится только для прототипа. Снова подумайте об автомобиле. Как вы полагаете, PropertyGrid хорошо бы подошёл для управления автомобилем? А ведь с точки зрения теории управления там как раз "какие-то данные" передаются в одну сторону, и какие-то — в другую.
AN>Еще ни разу в голову не пришло прокладывать авто маршрут по карте. Это же вначале нужно найти мухосранск, а затем и дорогу как туда добираться.
А, простите, как вы прокладываете маршрут?
Лично я вбиваю начальную и конечную точки (кстати, безо всяких отдельных полей для номера дома и индекса), и прошу построить мне маршрут.
Дальше я смотрю на него и исправляю на карте. Потому что я вижу на карте более-менее интересные места, которые стоит посетить по дороге, и перетаскиваю к ним фрагменты маршрута.
Кроме того, если у меня есть несколько промежуточных точек, то только по карте можно понять, в каком порядке имеет смысл их посещать. Вот вы, к примеру, наизусть помните, что идёт первым по дороге из Рима в Милан — Пиза или Генуя?
S>> Запустите контрольную панель в Win7. Запустите любой диалог настроек в Eclipse. AN>Семерку можно будет глянуть на работе, а Eclipse я черти знает когда по нужде пользовался. AN>Имеется в виду строка фильтр? AN>
Да, вот это вот "type filter text" позволяет найти нужную настройку, не перелопачивая всё дерево. AN>Хотя контрольная панель в виндах весьма сильно отличается от настроек стандартного приложения
Это от того, что проектировщики "настроек стандартного приложения" вдохновлялись контрольной панелью из win95.
Сейчас "стандартный UI" — это уже семёрка.
AN>А отчего в конфликте должны быть победители, как я помню, обычно конфликт решается на компромиссах.
Компромисс — это решение, при котором проигрывают обе стороны.
AN>Никто и не заставлял их трахаться с "тремя дроп-даунами". А вводили они действительно 1.5. но в некоторых случая система воспринимала это как 5.1 при этом никаким колдовством лечить не получалось (это не был обычный едит контрол в вин-форме)
Я вас не понимаю. Кто разрабатывал эту "заколдованную систему"? Сторонние люди?
AN>Есть задачи которые можно решать локально, а есть те которые обязаны быть решены глобально. Локализацию мы относим к глобальным. Если не будет всех требуемым механизмов для локализации, то может наступить момент когда потребуется довольно серьезная переделка кода, этого и хочется избежать. Допустим, если в концепте предусмотрена исключительно выдача локализованных строк, то добавить в него, что то еще может быть непростой задачей.
Ок, понял. Да, в этом смысле текстовые языки ввода могут оказаться труднее в локализации, чем набор тупых по-компонентных контролов. Хотя и там могут быть неожиданности. Скажем, контрол ввода даты, рассчитанный на григорианский календарь, встрянет для тайской локализации. Потому что вопрос не только в переводе, но и в культуре.
AN>Все равно не совсем понятно, есть допустим один и тот пользовательский юзкэйс реализованный скажем, в виде диалога(1) и проперти грид(2). Есть одна группа пользователей хорошо знакомая с использованием проперти грид, и есть другая которая его в глаза не видела. Одной нравится вариант 1 и абсолютно не нравится вариант 2, другой группе все в точности наоборот. Группы считаем 50 на 50 по численности. Какой вариант выбирать?
Нужно провести usability-тест и посмотреть success rate для каждого из UI. Пронаблюдать за тем, какие ошибки совершает каждая из групп в каждом из UI. Затем сложить результаты и посмотреть, кто победит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Real 3L0, Вы писали:
R3>А на русском нет?
Нет и не будет. А зачем вам на русском? Это же не художественная литература. Там и так всё понятно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexNek, Вы писали:
AN>Спасибки. AN>То есть похоже список ключевых слов собирается автоматом из зависимого окна?
Поиск делается не в окне, а во всём дереве настроек.
AN>Сделать установку языка для поиска. А то знаешь какое то слово на одном языке а как его перевели
Ну, это вторичный сценарий. Большинство пользователей (99%) работают всю жизнь на одном языке.
Для покрытия ещё 0.99% случаев достаточно сделать так, чтобы поиск на английском работал всегда, независимо от локали.
Требовать от пользователя указывать язык — избыточно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> AN>Спасибки. S> AN>То есть похоже список ключевых слов собирается автоматом из зависимого окна?
S> Поиск делается не в окне, а во всём дереве настроек.
Мне было интересно откуда берутся ключевые слова для одной "настройки".
Или забиваются "автоматом" или берутся "из окна".
S> AN>Сделать установку языка для поиска. А то знаешь какое то слово на одном языке а как его перевели
S> Ну, это вторичный сценарий. Большинство пользователей (99%) работают всю жизнь на одном языке. S> Для покрытия ещё 0.99% случаев достаточно сделать так, чтобы поиск на английском работал всегда, независимо от локали.
Правильнее было по количеству поддерживаемых и установленных для приложения языков S> Требовать от пользователя указывать язык — избыточно.
По умолчанию стоит локаль, но есть возможность выбора.
Здравствуйте, Sinclair, Вы писали:
S> AN>Я пока заметил только это "Пишет, вроде бы, очевидные вещи", надо будет поискать остальное. Для меня подобное впечатление оставил Н.Вирт.
S> Я не могу заставить вас читать его.
Я это прекрасно пониманию, просто говорю свои впечатления.
Нашел еще одну книгу, немного интересней, но все равно, она как бы "чужая".
При этом не со всем я согласен. Вот он ругает "девочку — график", а я до сих пор помню что пик графика приходился на 1980 год, а не будь там девочки, а бы даже не запомнил что там вообще подобный график есть.
S> AN>И последнего крика моды от меня никто не требует. Мне просто это интересно в некоторой степени, так как хочется узнать, что то новое.
S> Когнитивная психология — это не последний крик моды. Тафти приводит примеры удачных информационных дизайнов образца 18го века, и примеры неудачных 20го.
Возможно я несколько неудачно выразился, но скажем, допустим так: если нужно сделать страничку веб-сайта, то от меня не будут требовать результата сопоставимого с работой профессионального дизайнера
S> S>> Дело не в том, что можно представлять данные в виде графиков. Там очень много того, как именно нужно представлять табличные данные в таблицах. Или как представлять графики.
S> AN>Первичный просмотр этого не выявил
S> Значит, вы просматривали невнимательно или не ту из его книг.
мне пока удалось найти только одну
S> AN>Ну так вся задача вроде уже есть (вы ее сами сформулировали) просто появляются дополнительные условия.
S> Эти условия не берутся с потолка. Почему только одна из границ не может быть больше 10? Почему 10, не 12?
Это был просто как пример дополнительных условий. Можно расширить >=0 и =< x
S> AN>Так задача вроде уже есть, хотелось удобный способ изменения многих переменных или одной. (на примере таблицы)
S> На примере таблицы удобный способ реализован в Excel.
Видимо, мне не удалось его найти, то что вы написали у меня не работает.
S> В жизни задача не формулируется в терминах формы и её полей.
Ну в жизни, с подружкой также не через дисплей и клавиатуру общаешься. S> Подумайте о таком сценарии: управление автомобилем. S> Трогание с места на машине с механикой требует согласованного управления тремя параметрами: усилием торможения, коэффициентом сцепления, и оборотами двигателя.
Первое вроде редко требуется. S> Трогание с места на машине с автоматом требует управления одним параметром: сначала усилием торможения, потом оборотами. В зависимости от модели машины "внутри" у неё есть ещё много "переменных".
Могу даже сказать, что в сумме набегает весьма внушительное число и есть люди занимающиеся исключительно только ими. При этом часто в качестве интерфейса они имеют notepad (+ mathcad). (За все места конечно не могу сказать, только то что видел) S> Если бы автокомпании проектировали UI в "data-driven" парадигме, то на приборной панели была бы куча ручек, а разработчики бы объясняли, что не могут найти удобный способ "выделения группы параметров, которые хочется согласованно изменить".
Вроде до сих пор хороший способ для "ручной коробки передач" и не не найден, хорошо еще помню первые часы занятий в автошколе.
Просто был сделан специализированный интерфейс. Для обычного пользователя то не так уж и много параметров доступно. И становление этого интерфейса заняло не пару тройку лет. S> Очевидно, что решение, пригодное для управления Приусом, не будет подходить для "общего случая одиннадцати параметров".
Но не зная общего можно было вполне и не решить частную задачу.
S> S>> В сторону выяснения того, для чего и что пользователь делает.
S> AN>Только не понимаю что это может дать? Ну знаю я что число пять пользователь вводит для того чтобы указать число рабочих дней в неделе и что допустимые значения от 1 до 7 и что данная форма ему нужна для планирования работы персонала.
S> Этого мало. Надо знать, из чего вообще состоит "планирование работы персонала". Насколько часто выполняются различные действия. Если это число настраивается один раз в жизни на уровне всей системы, то не стоит заставлять вводить его для каждого сотрудника. Может быть, надо дать возможность использовать несколько календарей вместо количества дней в неделе (как в MS Project). Может быть, надо дать возможность вводить рабочие периоды, не кратные 7 дням (смены 2 дня через 3 дня), потому что без этого кадровичке приходится руками забивать разное количество дней каждую неделю.
Часто подобная информация далеко не очевидна. Как и варианты выясняются тогда, когда нельзя сделать того что хочется.
S> AN>Есть некое устройство, точнее различных типов может быть довольно много и фиг знает какие еще появятся потом. Устройство в зависимости от конфигурации и внутреннего состояния может выдавать совершенно различный набор данных. Эти данные нужно отображать и какую то часть из них редактировать и передавать наза в устройство.
S> AN>Хотя решение конкретной задачи меня не очень интересует, больше интересует решение в "общем виде".
S> Общее решение годится только для прототипа. Снова подумайте об автомобиле. Как вы полагаете, PropertyGrid хорошо бы подошёл для управления автомобилем? А ведь с точки зрения теории управления там как раз "какие-то данные" передаются в одну сторону, и какие-то — в другую.
Ну для автомобиля не думаю что вообще, что то подойдет из компьютерных интерфейсов.
Хотя примерно ход мыслей понятен. S> AN>Еще ни разу в голову не пришло прокладывать авто маршрут по карте. Это же вначале нужно найти мухосранск, а затем и дорогу как туда добираться.
S> А, простите, как вы прокладываете маршрут?
Очень просто, беру нави и загоняюю адрес. Гоогле при этом весьма далеко.
"Обзорных маршрутов", практически нет. Если хочу чего глянуть, смотрю вначале имеет ли смысл ехать, затем также забиваю конечный адрес или координаты. Часто просто смотрю в нави, что есть в ближайших окрестностях. S> Лично я вбиваю начальную и конечную точки (кстати, безо всяких отдельных полей для номера дома и индекса), и прошу построить мне маршрут. S> Дальше я смотрю на него и исправляю на карте. Потому что я вижу на карте более-менее интересные места, которые стоит посетить по дороге, и перетаскиваю к ним фрагменты маршрута.
Не спорю, что это удобней, но что мне потом с этой картой делать? Выписать ключевые точки и занести их в навигационное устройство? S> Кроме того, если у меня есть несколько промежуточных точек, то только по карте можно понять, в каком порядке имеет смысл их посещать. Вот вы, к примеру, наизусть помните, что идёт первым по дороге из Рима в Милан — Пиза или Генуя?
Не требуется, заношу милан в качестве конечного пункта и пизу, генуя как промежуточные + требование кратчайшего пути. Хотя конечно надо проверить.
S> AN>Хотя контрольная панель в виндах весьма сильно отличается от настроек стандартного приложения
S> S> Это от того, что проектировщики "настроек стандартного приложения" вдохновлялись контрольной панелью из win95.
Вроде она также далека. S> Сейчас "стандартный UI" — это уже семёрка.
возможно, но у нас она стоит только на тестовых машинах.
S> AN>А отчего в конфликте должны быть победители, как я помню, обычно конфликт решается на компромиссах.
S> Компромисс — это решение, при котором проигрывают обе стороны.
Ну это смотря с какой стороны посмотреть. Я бы предпочел жить в мирной обстановке с соседом, потеряв при этом десяток яблонь, как и он потеряв при этом еще чего.
Можно было взять десяток наемников и охранять яблони, но это было бы нецелесообразно.
S> AN>Никто и не заставлял их трахаться с "тремя дроп-даунами". А вводили они действительно 1.5. но в некоторых случая система воспринимала это как 5.1 при этом никаким колдовством лечить не получалось (это не был обычный едит контрол в вин-форме)
S> Я вас не понимаю. Кто разрабатывал эту "заколдованную систему"? Сторонние люди?
Не все в руках человека. Данные "шли по дороге" которую мы контролировать не могли в принципе (как и отказаться) и там они и "портились". Не помню уже всех подробностей. Помню только, что много человек было "поднято по тревоге", так как проблема была у "важного" заказчика. На тот момент никому не удалось найти решение, пришлось использовать другой подход.
S> AN>Есть задачи которые можно решать локально, а есть те которые обязаны быть решены глобально. Локализацию мы относим к глобальным. Если не будет всех требуемым механизмов для локализации, то может наступить момент когда потребуется довольно серьезная переделка кода, этого и хочется избежать. Допустим, если в концепте предусмотрена исключительно выдача локализованных строк, то добавить в него, что то еще может быть непростой задачей.
S> Ок, понял. Да, в этом смысле текстовые языки ввода могут оказаться труднее в локализации, чем набор тупых по-компонентных контролов. Хотя и там могут быть неожиданности. Скажем, контрол ввода даты, рассчитанный на григорианский календарь, встрянет для тайской локализации. Потому что вопрос не только в переводе, но и в культуре.
Ну тогда тайцы в пролете , для китая еще можно было подумать
S> AN>Все равно не совсем понятно, есть допустим один и тот пользовательский юзкэйс реализованный скажем, в виде диалога(1) и проперти грид(2). Есть одна группа пользователей хорошо знакомая с использованием проперти грид, и есть другая которая его в глаза не видела. Одной нравится вариант 1 и абсолютно не нравится вариант 2, другой группе все в точности наоборот. Группы считаем 50 на 50 по численности. Какой вариант выбирать?
S> Нужно провести usability-тест и посмотреть success rate для каждого из UI. Пронаблюдать за тем, какие ошибки совершает каждая из групп в каждом из UI. Затем сложить результаты и посмотреть, кто победит. Тогда это будет подкидывание монетки.
каждая группа будет "ненавидеть" то что не по душе. Да и откуда возьмется необходимое число людей для достоверной выборки?
То есть все то вроде правильно, но как это сделать на практике, пока идей нет.
Здравствуйте, Sinclair, Вы писали:
S> Когнитивная психология — это не последний крик моды. Тафти приводит примеры удачных информационных дизайнов образца 18го века, и примеры неудачных 20го.
Здравствуйте, AlexNek, Вы писали:
AN>При этом не со всем я согласен. Вот он ругает "девочку — график", а я до сих пор помню что пик графика приходился на 1980 год, а не будь там девочки, а бы даже не запомнил что там вообще подобный график есть.
При этом пик не соответствует ничему реальному. Читайте его разбор катастрофы Колумбии.
AN>Возможно я несколько неудачно выразился, но скажем, допустим так: если нужно сделать страничку веб-сайта, то от меня не будут требовать результата сопоставимого с работой профессионального дизайнера
Это понятно. Но это не повод не прочитать книгу Кирсанова чтобы иметь хотя бы общее представление о том, как и зачем принимаются дизайнерские решения.
S>> Значит, вы просматривали невнимательно или не ту из его книг. AN>мне пока удалось найти только одну
Я дал ссылки на четыре.
S>> Эти условия не берутся с потолка. Почему только одна из границ не может быть больше 10? Почему 10, не 12? AN>Это был просто как пример дополнительных условий. Можно расширить >=0 и =< x
Я выделил важное. Мне неинтересно решать задачу "а что, если у лошади будет пять ног".
S>> На примере таблицы удобный способ реализован в Excel. AN>Видимо, мне не удалось его найти, то что вы написали у меня не работает.
То есть Ctrl-D у вас не копирует верхнюю строчку выделения во все ниже неё, а Ctrl-R не копирует первый столбец текущего выделения направо? У вас не получается сделать копию ячейки через Ctrl-C, а потом выделить целый диапазон (не обязательно сплошной — при помощи Ctrl-Click) и нажать Ctrl-V?
S>> В жизни задача не формулируется в терминах формы и её полей. AN>Ну в жизни, с подружкой также не через дисплей и клавиатуру общаешься.
Отличный ход мысли. Вы совершенно правы.
S>> Подумайте о таком сценарии: управление автомобилем. S>> Трогание с места на машине с механикой требует согласованного управления тремя параметрами: усилием торможения, коэффициентом сцепления, и оборотами двигателя.
Хорошо, отбросим третий параметр. Даже два уже дают достаточно поводов для развлечений.
AN>Могу даже сказать, что в сумме набегает весьма внушительное число и есть люди занимающиеся исключительно только ими. При этом часто в качестве интерфейса они имеют notepad (+ mathcad). (За все места конечно не могу сказать, только то что видел)
В качестве интерфейса имеем руль и две педали. Никакими маткадами в машине даже и не пахнет. БМВ как-то попробовали запустить цифровую систему управления второстепенными настройками, вроде музыки и климата. В результате — слово из шести букв, вторая — "и".
AN>Вроде до сих пор хороший способ для "ручной коробки передач" и не не найден, хорошо еще помню первые часы занятий в автошколе.
Хороший способ найден — это автоматическая коробка передач. У вас, как инженера, нет технических ограничений автопрома. Всё автоматизируемо.
AN>Но не зная общего можно было вполне и не решить частную задачу.
Вы полагаете, инженеры Тойоты сначала решили общую задачу управления множеством параметров, а потом вывели из общего решения частное?
S>> Этого мало. Надо знать, из чего вообще состоит "планирование работы персонала". Насколько часто выполняются различные действия. Если это число настраивается один раз в жизни на уровне всей системы, то не стоит заставлять вводить его для каждого сотрудника. Может быть, надо дать возможность использовать несколько календарей вместо количества дней в неделе (как в MS Project). Может быть, надо дать возможность вводить рабочие периоды, не кратные 7 дням (смены 2 дня через 3 дня), потому что без этого кадровичке приходится руками забивать разное количество дней каждую неделю. AN>Часто подобная информация далеко не очевидна. Как и варианты выясняются тогда, когда нельзя сделать того что хочется.
Эта информация вообще никогда не бывает очевидной. Более того, мой опыт подсказывает, что именно то, что считается очевидным, чаще всего оказывается неверным. Если подумать, то этому есть причина — то, что неочевидно, мы проверяем. Очевидные же вещи остаются непроверенными, поэтому именно там и живут заблуждения.
AN>Ну для автомобиля не думаю что вообще, что то подойдет из компьютерных интерфейсов.
Конечно. Из компьютерных интерфейсов можете сравнить способ подключиться к WiFi в Windows XP и в MacOS.
AN>Очень просто, беру нави и загоняюю адрес. Гоогле при этом весьма далеко.
Ну, это когда вас интересует маршрут "отсюда и дотуда", и у вас под рукой нет гугла.
AN>Не спорю, что это удобней, но что мне потом с этой картой делать? Выписать ключевые точки и занести их в навигационное устройство?
Ну, мне так и придётся делать — потому, что навигационное устройство, которое я возьму напрокат, вряд ли умеет импортировать карту из Гугла. Но это проблема не гугла, а того устройства.
Точно так же, как отсутствие возможности закачать авиарейс в виде iCalendar-инвайта — это косяк авиакомпаний, а не протокола ActiveSync. Лично мне бы это сэкономило массу усилий по забиванию рейсов в Outlook. (В телефон бы я вообще не стал затрудняться). В свою очередь, забивание рейсов в Outlook избавляет меня от проблем типа "забыл в какой день вылет", с которыми сталкиваются мои коллеги, и от суеты по вытаскиванию распечатки билета из рюкзака на бегу, когда я пытаюсь найти гейт, из которого вылетает мой следующий рейс.
S>> Сейчас "стандартный UI" — это уже семёрка. AN>возможно, но у нас она стоит только на тестовых машинах.
а, то есть вы всё же рассчитываете на неё как на target платформу. В таком случае крайне полезно изучить "территорию противника". Проектировать под win7 в стиле win95 — это как-то непопацански.
S>> Компромисс — это решение, при котором проигрывают обе стороны. AN>Ну это смотря с какой стороны посмотреть. Я бы предпочел жить в мирной обстановке с соседом, потеряв при этом десяток яблонь, как и он потеряв при этом еще чего. AN>Можно было взять десяток наемников и охранять яблони, но это было бы нецелесообразно.
AN>каждая группа будет "ненавидеть" то что не по душе. Да и откуда возьмется необходимое число людей для достоверной выборки?
Ну вы же откуда-то узнали про то, что кто-то ненавидит грид, а кто-то любит?
Или вы опять рассматриваете сферического коня в вакууме?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, Sinclair, Вы писали:
S>> AN>Спасибки. S>> AN>То есть похоже список ключевых слов собирается автоматом из зависимого окна?
S>> Поиск делается не в окне, а во всём дереве настроек. AN>Мне было интересно откуда берутся ключевые слова для одной "настройки". AN>Или забиваются "автоматом" или берутся "из окна".
S>> AN>Сделать установку языка для поиска. А то знаешь какое то слово на одном языке а как его перевели
S>> Ну, это вторичный сценарий. Большинство пользователей (99%) работают всю жизнь на одном языке. S>> Для покрытия ещё 0.99% случаев достаточно сделать так, чтобы поиск на английском работал всегда, независимо от локали. AN>Правильнее было по количеству поддерживаемых и установленных для приложения языков
В принцие-да. Но реальная ситуация в современном IT-мире такова, что пользователь знает два языка — английский и родной. Ситуация, когда пользователь знает название настройки на немецком, но сел за французскую версию UI — крайняя экзотика. AN>По умолчанию стоит локаль, но есть возможность выбора.
Непонятно, зачем. Неужели имеет физический смысл искать слово "width" в русской локали или "ширина" — в английской?
Лишний контрол — лишние сомнения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
...
спасибо за ответ, но есть большая вероятность того что в ближайшие пару дней мне не удастся ответить, так что звиняйте если что.
Мне бы такой подошёл. Только чтобы слэш не надо было вручную вводить. И чтоб подсказка поясняла — где год, а где месяц.
А если в этой форме обычно вводят платежи за прошлый месяц, то можно период заранее заполнить.
А для пользователей, предпочитающих выбирать мышкой из вариантов, можно рядом таки создать комбо-бокс с полными названиями периодов, и синхронизировать в обе стороны с текстом.
Здравствуйте, Sinclair, Вы писали:
S>Ни в коем случае не делать комбобоксы … сделайте простой текстовый ввод … S>Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.
Мышой по комбикам: Открыть месяца
Выбрать месяц
Открыть года
Выбрать год
Если с клавиатуры и комбиками, то: Встать на месяц
Начинать набирать имя (1-3 нажатия, пусть примерно два)
Встать на год
Начинать набирать год (примерно 2 нажатия)
Если с текстовым полем, то: Встать на поле
Начинать набирать имя месяца (1-3 нажатия, пусть примерно два)
Набрать разделитель месяца и года
Начинать набирать год (примерно 2 нажатия) То есть не видно, в чём выигрыш-то?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Sinclair, Вы писали:
S>>Ни в коем случае не делать комбобоксы … сделайте простой текстовый ввод … S>>Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.
_FR>Мышой по комбикам: _FR> _FR>Открыть месяца _FR>Выбрать месяц _FR>Открыть года _FR>Выбрать год _FR>
У вас сколько годов будет в списке? Вообще, про работу мышкой можете забыть — ей удобно делать только одиночный клик и драг-н-дроп. Всё остальное удобнее делать с клавиатуры.
_FR>Если с клавиатуры и комбиками, то: _FR> _FR>Встать на месяц _FR>Начинать набирать имя (1-3 нажатия, пусть примерно два) _FR>Встать на год _FR>Начинать набирать год (примерно 2 нажатия) _FR>
Я думаю, что первые две цифры у всех годов будут одинаковыми
_FR>Если с текстовым полем, то: _FR> _FR>Встать на поле _FR>Начинать набирать имя месяца (1-3 нажатия, пусть примерно два) _FR>Набрать разделитель месяца и года _FR>Начинать набирать год (примерно 2 нажатия) _FR>
Неправильно
Правильно — вот так: я набираю "май", у меня автоподставляется "май 2011" — дальше сразу tab и поехали. Если надо заплатить с января, то я набираю "я" — дальше сразу таб и поехали. _FR> То есть не видно, в чём выигрыш-то?
В тщательном подсчёте
В данном сценарии может оказаться, что один комбо с набором периодов платежа удобнее всего — просто потому, что самые частые периоды это текущий (уже выбран) и предыдущий (выбирается одним нажатием кнопки "вниз").
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>Ни в коем случае не делать комбобоксы … сделайте простой текстовый ввод … S>>>Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны. _FR>>Мышой по комбикам: S>У вас сколько годов будет в списке?
Например, сто, раз уж договорились, что "первые две цифры у всех годов будут одинаковыми". По умолчанию выделен текущий.
S>Вообще, про работу мышкой можете забыть — ей удобно делать только одиночный клик и драг-н-дроп. Всё остальное удобнее делать с клавиатуры.
Тут не согласен. Несомненно, "тётенькам", привыкшим вколачивать что либо в компьютер посредством старого досовского софта конечно сложно "понять" мышь :о) Но вообще в данном конкретном случае, речь именно об одиночных кликах вообще-то. Максимум: о скроле. Колдунств с мышью не требуется: как например при выборе дат в календаре семёрки — что бы переключиться на текущий же месяц но прошлого года требуется клика четыре или даже пять кликов сделать :о(
_FR>>Если с клавиатуры и комбиками, то: S>Я думаю, что первые две цифры у всех годов будут одинаковыми
Именно поэтому я сказал, что "Начинать набирать год (примерно 2 нажатия)", то есть в комбике с годом в точности две последние цифры.
_FR>>Если с текстовым полем, то: S>Неправильно S>Правильно — вот так: я набираю "май", у меня автоподставляется "май 2011" — дальше сразу tab и поехали. Если надо заплатить с января, то я набираю "я" — дальше сразу таб и поехали.
Тоже самое можно сделать и в случае коммбобоксов. Основной выигрышь, я смотрю, в том, что набрав только "с" можно сразу получить "сентябрь прошлого года"? так это и в случае комбобоксов можно реализовать, если выделять, например (тут подумать надо как лучше (*), но то, что в принципе возможно, сомнений нет).
_FR>> То есть не видно, в чём выигрыш-то? S>В тщательном подсчёте S>В данном сценарии может оказаться, что один комбо с набором периодов платежа удобнее всего — просто потому, что самые частые периоды это текущий (уже выбран) и предыдущий (выбирается одним нажатием кнопки "вниз").
Ага, поэтому несколько более общий случай интереснее.
Комбики кажутся понятнее — сложно с выбором ошибиться + и комбобокс можно сделать редактируемым с суггестом. Тогда и (*) можно разрулить, оставив по-умолчанию комбик с годом пустым и, если он таковым и остался, высчитать самостоятельно или инициализировать при переходе табом от месяца.
Другой несомненный плюс — возможность Paste сразу и месяца и года, но и это решаемо: видел как-то следующую примерно реализацию. Формочка с набором контролов, в которые оператору нужно ввести данные. Первым среди контролов идёт текстбокс, в котором в строковом виде пользователь может ввести содержимое почти всех контролов, например "+ле 34/105 с *1000" + Tab заносит в контролы адрес "ул. Ленина" (отыскивается like-ом в справочнике) дом 34 квартира 105 за сентябрь тыща рублёв. Это действительно "смарт", то есть для профи быстрый набор и для эстетов сразу видно во что распарсилось (если где не распарсилось, рядом с соответствующими контролами можно нарисовать "помидоры" — иконки DataErrorProvider-а).
Help will always be given at Hogwarts to those who ask for it.
_FR>Например, сто, раз уж договорились, что "первые две цифры у всех годов будут одинаковыми". По умолчанию выделен текущий.
Выбрать мышкой один из ста годов в дроп-дауне — это то ещё упражнение.
_FR>Тут не согласен. Несомненно, "тётенькам", привыкшим вколачивать что либо в компьютер посредством старого досовского софта конечно сложно "понять" мышь :о) Но вообще в данном конкретном случае, речь именно об одиночных кликах вообще-то. Максимум: о скроле. Колдунств с мышью не требуется: как например при выборе дат в календаре семёрки — что бы переключиться на текущий же месяц но прошлого года требуется клика четыре или даже пять кликов сделать :о(
Выпадающие календари — вообще зло. Но в семёрке хотя бы сделали попадание в зоны кликов реалистичным. Вообще, не все клики одинаковы.
1. Когда не знаешь куда кликать — клик стоит в 10 раз дороже привычного клика.
2. Стоимость клика обратно пропорциональна диаметру зоны клика. (Вот эти вот "вверх-вниз" рядом с номером года в календаре XP — это ужос-ужос)
3. Стоимость клика снижается, если он — в одном из углов экрана. (Обратите внимание, что кнопка Start в семёрке работает даже если нажать левее и ниже неё — именно по этой причине)
_FR>Именно поэтому я сказал, что "Начинать набирать год (примерно 2 нажатия)", то есть в комбике с годом в точности две последние цифры.
Это какая-то непонятная мне фантазия. Стандартный дроп-даун ожидает при вводе содержимое айтема слева направо. Поэтому для выбора 2010 года нужно набрать 2-0-1, а не 1-0. Комбобокс богаче по возможностям — там хотя бы можно показать пользователю текущее положение курсора. Тем не менее, я пока с трудом себе представляю вот такое вот автозаполнение "из середины налево".
Так что пока я вижу ровно 4 нажатия для заполнения года.
_FR>Тоже самое можно сделать и в случае коммбобоксов. Основной выигрышь, я смотрю, в том, что набрав только "с" можно сразу получить "сентябрь прошлого года"? так это и в случае комбобоксов можно реализовать, если выделять, например (тут подумать надо как лучше (*), но то, что в принципе возможно, сомнений нет).
Для нескольких контролов всё осложняется задачей придумать согласованное поведение. Да ещё и так, чтобы пользователь его понял.
_FR>Ага, поэтому несколько более общий случай интереснее.
В несколько более общем случае несколько контролов начнут сосать ещё сильнее.
_FR>Комбики кажутся понятнее — сложно с выбором ошибиться + и комбобокс можно сделать редактируемым с суггестом. Тогда и (*) можно разрулить, оставив по-умолчанию комбик с годом пустым и, если он таковым и остался, высчитать самостоятельно или инициализировать при переходе табом от месяца.
Проблема в том, что понятность повышается ровно для одного сценария, и нет кривой обучения — скорость не улучшается для опытного пользователя.
_FR>Другой несомненный плюс — возможность Paste сразу и месяца и года, но и это решаемо: видел как-то следующую примерно реализацию. Формочка с набором контролов, в которые оператору нужно ввести данные. Первым среди контролов идёт текстбокс, в котором в строковом виде пользователь может ввести содержимое почти всех контролов, например "+ле 34/105 с *1000" + Tab заносит в контролы адрес "ул. Ленина" (отыскивается like-ом в справочнике) дом 34 квартира 105 за сентябрь тыща рублёв. Это действительно "смарт", то есть для профи быстрый набор и для эстетов сразу видно во что распарсилось (если где не распарсилось, рядом с соответствующими контролами можно нарисовать "помидоры" — иконки DataErrorProvider-а).
Это — грамотное решение. Непонятно только, зачем тогда вообще все контролы. Ну, то есть я понимаю, что это от безысходности.
Если бы была возможность, лучше сделать всё в редакторе. Если не распарсилось — помидоры и подчёркивания рисуются прямо в тексте. Туда же можно ткнуть мышой/клавиатурой и уточнить то, что нужно уточнить. В качестве примера опять же посмотрите в любую современную IDE — paste кода тут же подвергается синтаксической раскраске, ошибки компиляции подсвечиваются, и в полную силу работает intellisence.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_FR>>Например, сто, раз уж договорились, что "первые две цифры у всех годов будут одинаковыми". По умолчанию выделен текущий. S>Выбрать мышкой один из ста годов в дроп-дауне — это то ещё упражнение.
Вам часто приходится заполнять платёжки за последние сто лет? В таком ракурсе говорить что-либо об удобстве заполнения формы на текущий год как-то безсмысленно а ближайшие несколько лет (от текущего и ниже) — очень даже возможно.
_FR>>Тут не согласен. Несомненно, "тётенькам", привыкшим вколачивать что либо в компьютер посредством старого досовского софта конечно сложно "понять" мышь :о) Но вообще в данном конкретном случае, речь именно об одиночных кликах вообще-то. Максимум: о скроле. Колдунств с мышью не требуется: как например при выборе дат в календаре семёрки — что бы переключиться на текущий же месяц но прошлого года требуется клика четыре или даже пять кликов сделать :о( S>Выпадающие календари — вообще зло. Но в семёрке хотя бы сделали попадание в зоны кликов реалистичным. Вообще, не все клики одинаковы.
Проблема-то в том (вы семёркой-то пользуетесь? попробовали сделать то, что я описал?) что в календаре нельзя (как было в XP) с самостоятельно ввести число/месяц/год с клавиатуры, только последовательным выбиранием, то есть вместо того что бы один раз кликнуть на стрелке ап-дауна нужно несколько раз кликнуть в календаре, но к текущей теме это никакого отношения не имеет.
S>1. Когда не знаешь куда кликать — клик стоит в 10 раз дороже привычного клика.
Куда кликакть в комбобоксе известно обычно всем. Объясните, если посчитаете возможным, куда вы клоните?
S>2. Стоимость клика обратно пропорциональна диаметру зоны клика. (Вот эти вот "вверх-вниз" рядом с номером года в календаре XP — это ужос-ужос)
Это про ап-даун? Я эти стрелки воспринимал всегда как подсказка что можно стрелочками с клавы скролиться. в семёрке с клавиатуры нельзя переключить календарь на прошлый год. К тому же, для корриктировки она значительно удобнее постановки фокуса внутрь текстового поля, позиционирования курсора, выделения, набирания.
S>3. Стоимость клика снижается, если он — в одном из углов экрана. (Обратите внимание, что кнопка Start в семёрке работает даже если нажать левее и ниже неё — именно по этой причине)
Если уж говорить о кнопке старт, то она работает несколько иначе: если вы двигаете мышь из центра экрана к кнопке, то клик сработает только когда мышь окажется внутри круга кнопки +- 1 пиксель (при этом кнопка "загорается"), а вот при убирании указателя из области кнопки наружу кликнуть можно где-то в пределах десяти уже пикселей. Что это объясняет я не знаю.
Не могли бы, право слово, вы изъясняться чётче, а то у меня чувство, что я общаюсь с дельфийским оракулом Если это ваш ход к тому что бы отбить желание с вами общаться, то не смею мешать, как говориться
_FR>>Именно поэтому я сказал, что "Начинать набирать год (примерно 2 нажатия)", то есть в комбике с годом в точности две последние цифры. S>Это какая-то непонятная мне фантазия. Стандартный дроп-даун ожидает при вводе содержимое айтема слева направо. Поэтому для выбора 2010 года нужно набрать 2-0-1, а не 1-0. Комбобокс богаче по возможностям — там хотя бы можно показать пользователю текущее положение курсора. Тем не менее, я пока с трудом себе представляю вот такое вот автозаполнение "из середины налево".
S>Так что пока я вижу ровно 4 нажатия для заполнения года.
Я вижу аж два объяснения того, что я сказал:
1. В комбобоксе написано не "2010", а просто "10"
2. Отлавливание нажатий в комбике и самостоятельное выделение.
_FR>>Тоже самое можно сделать и в случае коммбобоксов. Основной выигрышь, я смотрю, в том, что набрав только "с" можно сразу получить "сентябрь прошлого года"? так это и в случае комбобоксов можно реализовать, если выделять, например (тут подумать надо как лучше (*), но то, что в принципе возможно, сомнений нет). S>Для нескольких контролов всё осложняется задачей придумать согласованное поведение. Да ещё и так, чтобы пользователь его понял.
То есть вы отрицаете возможность придумать понятное согласованное поведение двух контролов?
_FR>>Ага, поэтому несколько более общий случай интереснее. S>В несколько более общем случае несколько контролов начнут сосать ещё сильнее.
Вы слишком извратно поняли мои слова насчёт общности, было бы продуктивнее прежде чем выдать подобную ничего не объясняющую (ибо понять, что значит "сосут" и что именно "сосут" и у кого "сосут" не представляется возможным) ремарку всё-таки попросить уточнить, если вам интересно конечно же. Если не интересно, то можно от ремарки и воздержаться, оки?
_FR>>Комбики кажутся понятнее — сложно с выбором ошибиться + и комбобокс можно сделать редактируемым с суггестом. Тогда и (*) можно разрулить, оставив по-умолчанию комбик с годом пустым и, если он таковым и остался, высчитать самостоятельно или инициализировать при переходе табом от месяца. S>Проблема в том, что понятность повышается ровно для одного сценария, и нет кривой обучения — скорость не улучшается для опытного пользователя.
То есть по-вашему пустой текстбокс с лейблом "Дата" гораздо понятнее? Не заглянув в документацию/диалоговый хелп догадаться о том, в каком формате ожидается ввод невозможно (я-то знаю, что ввод умный и поймёт многое, но пользователь-то откуда это узнает?).
_FR>>Другой несомненный плюс — возможность Paste сразу и месяца и года, но и это решаемо: видел как-то следующую примерно реализацию. Формочка с набором контролов, в которые оператору нужно ввести данные. Первым среди контролов идёт текстбокс, в котором в строковом виде пользователь может ввести содержимое почти всех контролов, например "+ле 34/105 с *1000" + Tab заносит в контролы адрес "ул. Ленина" (отыскивается like-ом в справочнике) дом 34 квартира 105 за сентябрь тыща рублёв. Это действительно "смарт", то есть для профи быстрый набор и для эстетов сразу видно во что распарсилось (если где не распарсилось, рядом с соответствующими контролами можно нарисовать "помидоры" — иконки DataErrorProvider-а). S>Это — грамотное решение. Непонятно только, зачем тогда вообще все контролы. Ну, то есть я понимаю, что это от безысходности.
Это для того, что бы при просмотре и изменении, а не внесении новой информации было бы удобнее. Делать же различный интерфейс для добавления (в виде одного текстового поля) и редактирования с набором контролов мне кажется странным? Вы не согласны?
S>Если бы была возможность, лучше сделать всё в редакторе. Если не распарсилось — помидоры и подчёркивания рисуются прямо в тексте. Туда же можно ткнуть мышой/клавиатурой и уточнить то, что нужно уточнить. В качестве примера опять же посмотрите в любую современную IDE — paste кода тут же подвергается синтаксической раскраске, ошибки компиляции подсвечиваются, и в полную силу работает intellisence.
Разность в том, что человек заносит лишь часть информации, а получает полную информацию (то что он недоввёл "раскрывается"). Если после убирания фокуса с такого текстбокса, например, всё раскрывать и в текстбоксе показывать полную информацию, то так мы придём к тому, что ни один элемент управления кроме текстбокса не нужен вообще — достаточно навороченного текстового редактора. Правильно я понял вашу позицию? Или где та грань, отделяющая необходимость списков/комбиков/ап-даунов/пикеров от достаточности текстового редактора?
Help will always be given at Hogwarts to those who ask for it.
_FR>Проблема-то в том (вы семёркой-то пользуетесь? попробовали сделать то, что я описал?) что в календаре нельзя (как было в XP) с самостоятельно ввести число/месяц/год с клавиатуры, только последовательным выбиранием, то есть вместо того что бы один раз кликнуть на стрелке ап-дауна нужно несколько раз кликнуть в календаре, но к текущей теме это никакого отношения не имеет.
Я пользуюсь семёркой. Не очень понимаю, чего именно нельзя сделать с клавиатуры. Если вы про тот календарь, который всплывает при клике в часы, то там всё выбирается и клавиатурой в том числе. Особенной деградации с XP нету.
_FR>Куда кликакть в комбобоксе известно обычно всем. Объясните, если посчитаете возможным, куда вы клоните?
В семёрочном календаре совершенно неочевидно, что можно вообще кликать в месяц/год.
_FR>Это про ап-даун? Я эти стрелки воспринимал всегда как подсказка что можно стрелочками с клавы скролиться. в семёрке с клавиатуры нельзя переключить календарь на прошлый год.
В семёрке вообще убрали инпут с номера года. По поводу клавиатуры — Ctrl-Up нажмите. _FR>К тому же, для корриктировки она значительно удобнее постановки фокуса внутрь текстового поля, позиционирования курсора, выделения, набирания.
Тем не менее, попасть в текстовое поле можно табом, а для попадания в up/down нужно быть опытным снайпером.
_FR>Если уж говорить о кнопке старт, то она работает несколько иначе: если вы двигаете мышь из центра экрана к кнопке, то клик сработает только когда мышь окажется внутри круга кнопки +- 1 пиксель (при этом кнопка "загорается"), а вот при убирании указателя из области кнопки наружу кликнуть можно где-то в пределах десяти уже пикселей. Что это объясняет я не знаю.
Это неправда. Активная зона кнопки никак не зависит от направляения движения. Её хорошо видно — при нахождении в зоне кнопка светится.
Форма этой зоны представляет собой неправильную фигуру: слева и снизу она прямоугольная и прижата к краям экрана, сверху справа — круглая.
_FR>Не могли бы, право слово, вы изъясняться чётче, а то у меня чувство, что я общаюсь с дельфийским оракулом Если это ваш ход к тому что бы отбить желание с вами общаться, то не смею мешать, как говориться
А что именно я невнятно излагаю?
_FR>Я вижу аж два объяснения того, что я сказал: _FR>1. В комбобоксе написано не "2010", а просто "10"
Да, такое решение сработает. _FR>2. Отлавливание нажатий в комбике и самостоятельное выделение.
Можно попробовать. Хотя есть очевидные проблемы типа неопределеннности: если я набрал 20, то что нужно дозаполнить — первые две и получить 2020, или последние две и получить 2000?
Если мы это разрешим, то в итоге мы приходим к чему-то типа того, что я предлагал — есть текстовый язык, распознающий всякие разные паттерны. Комбовость бокса является аналогом интеллисенса.
_FR>То есть вы отрицаете возможность придумать понятное согласованное поведение двух контролов?
Нет, почему. Просто разгадка поведения двух контролов сразу представляет собой квест (собственно, большинство загадок в квестах именно такие). Квест хорош во время отдыха, а не во время работы.
_FR>Вы слишком извратно поняли мои слова насчёт общности, было бы продуктивнее прежде чем выдать подобную ничего не объясняющую (ибо понять, что значит "сосут" и что именно "сосут" и у кого "сосут" не представляется возможным) ремарку всё-таки попросить уточнить, если вам интересно конечно же. Если не интересно, то можно от ремарки и воздержаться, оки?
Поясняю: чем больше контролов, которые ведут себя неочевидно согласованным образом, тем сложнее понять, что вообще происходит, что произойдёт, если я изменю один из контролов, и в каком порядке нужно их менять, чтобы получить нужный результат.
Самый простой пример — аутлук автоматически передвигает конец митинга, если передвинуть начало — так, чтобы сохранить длительность. При этом перемещение конца митинга на начало не влияет. Поэтому важно редактировать контролы митинга в правильном порядке. Каждый пользователь в начале карьеры наступает несколько раз на эти грабли. И это только два контрола, с очень простой связью между ними.
_FR>То есть по-вашему пустой текстбокс с лейблом "Дата" гораздо понятнее?
Почему же пустой?
_FR>Это для того, что бы при просмотре и изменении, а не внесении новой информации было бы удобнее. Делать же различный интерфейс для добавления (в виде одного текстового поля) и редактирования с набором контролов мне кажется странным? Вы не согласны?
Согласен. Удобнее иметь ровно один интерфейс.
_FR>Разность в том, что человек заносит лишь часть информации, а получает полную информацию (то что он недоввёл "раскрывается"). Если после убирания фокуса с такого текстбокса, например, всё раскрывать и в текстбоксе показывать полную информацию, то так мы придём к тому, что ни один элемент управления кроме текстбокса не нужен вообще — достаточно навороченного текстового редактора. Правильно я понял вашу позицию? Или где та грань, отделяющая необходимость списков/комбиков/ап-даунов/пикеров от достаточности текстового редактора?
Имхо, надо оценивать конкретные сценарии. А также количество вариантов вводимой информации.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Ввод периода платежа
От:
Аноним
Дата:
19.05.11 16:52
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Есть форма ввода квитанций. А>>На форме есть поле период платежа. А>>Не могу придумать формат данных. А>>Т.е. может быть квитанция на оплату ЖКХ за январь месяц. А>>тогда вроде напрашивается комбобокс со списком месяцов и комбобокс с годами. но это как то неюзабельно, имхо. А>>Теоретически за один месяц может быть несколько квитанций.
А>>Что посоветуете? S>Ни в коем случае не делать комбобоксы. Если нет возможности избежать ввода вообще (через сканирование квитанций, как тут уже посоветовали), сделайте простой текстовый ввод. Дайте возможность исправлять ошибки. Убедитесь, что легко вводятся самые частые вещи (например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.) S>Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало. S>Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.
а как базе хранить период оплаты?
особенно если может быть несколько квитанций за месяц?
если в БД формат будет датой, то какой день месяца подставлять?
Здравствуйте, Аноним, Вы писали: А>а как базе хранить период оплаты?
Откуда же я знаю. Всё зависит от задачи. А>особенно если может быть несколько квитанций за месяц? А>если в БД формат будет датой, то какой день месяца подставлять?
Всё зависит от задачи. Какие отчёты нужно строить по этой базе?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Ввод периода платежа
От:
Аноним
Дата:
20.05.11 14:59
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Аноним, Вы писали: А>>а как базе хранить период оплаты? S>Откуда же я знаю. Всё зависит от задачи. А>>особенно если может быть несколько квитанций за месяц? А>>если в БД формат будет датой, то какой день месяца подставлять? S>Всё зависит от задачи. Какие отчёты нужно строить по этой базе?
очень простые — баланс(дебет-кредит) за месяц по типу квитанции
В таком ракурсе говорить что-либо об удобстве заполнения формы на текущий год как-то безсмысленно 
