Понятно, что «1 000 001» выглядит лучше, чем «1000001».

Кто-нибудь заморачивался с оформлением при вводе и выводе? Как решали? (Например, в HTML).

Все, вроде, через редактирование самой строки делают (локальное форматирование), но как можно поручиться, что там не будет пробелов вместо nbsp? Второй проход делать самому? Да и overriding пользовательского ввода мне не нравится.

Лучше всего, конечно, через гарнитуру бы порешать как-то. Правила в ней установить. Типа лигатур что-то. Но на лету с готовым шрифтом такое не делать?

Ну в Java есть класс DecimalFormat, там можно настраивать как хочешь. Я не советую nbsp ставить, это излишнее усложнение задачи, ставь просто пробелы.

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

vsb>Ну в Java есть класс DecimalFormat, там можно настраивать как хочешь.

Ну, то есть подменять текст. Я это назвал «через редактирование самой строки». Нет ли иных способов?

Здравствуйте, Shtole, Вы писали:
S>Ну, то есть подменять текст. Я это назвал «через редактирование самой строки». Нет ли иных способов?
Отказаться от редактирования строки, научиться мыслить в терминах "преобразование числа в строку в соответствии с определёнными культурными предпочтениями и техническими особенностями".
Когда число уже преобразовано в строку, оборудовать его культурой поздно.

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

S>>Ну, то есть подменять текст. Я это назвал «через редактирование самой строки». Нет ли иных способов?
S>Отказаться от редактирования строки, научиться мыслить в терминах "преобразование числа в строку в соответствии с определёнными культурными предпочтениями и техническими особенностями".
S>Когда число уже преобразовано в строку, оборудовать его культурой поздно.

Очень глубокий ответ, очень. Но я его не понял.

Вот у нас поле ввода.

Вот юзер хочет ввести число: 1 000 000 001 (или 1 000 000 002). Он жмакает по цифровой клавиатуре и видит: 10000000001.

Вот юзер, конечно, думает: а не нажал ли я лишнего? И начинает считать нули, выделяя текст/расставляя группы пробелами, которые потом стирает/водя грязным ногтём по экрану/иным способом в рамках фантазии.

Это проблема. Юзер должен сразу видеть, что он вводит.

Как выглядит решение «в терминах "преобразование числа в строку в соответствии с определёнными культурными предпочтениями и техническими особенностями"»?

А чтобы стало веселее, я пошёл домой за ружьём представим себе, что это поле ввода калькулятора, куда вводятся выражения:

1 000 000 001 + 1
1 000 000 001 / pi
sin(1 000 000 001)

Как видите, в этом юз-кейсе:

1. Проблема стоит особенно остро (в львиной доле случаев вводятся числа, иногда большие);
2. Мы не можем ограничиться вводом символов, составляющих число и не можем просто взять специальный контрол «поле ввода числа»;
3. Вставка пробелов и прочих разделителей чревата конфликтами с грамматикой языка.

Что касается «культурных предпочтений». Идеально было бы брать «разделитель групп» из настроек операционной системы. Но, например, браузер вам этого не даст (ибо отпечатки). Браузер даст только: а) название култур-мултур, б) интерфейс, который отформатирует число в соответствии с этой культурой. То есть, как ни настраивай юзер операционную систему, браузер всё равно сведёт всё к наибольшему общему делителю данной культуры (что сильно обесценивает саму идею).

Вывод напрашивается такой: ну и к чёрту эти культурные особенности, это тот случай, когда должна работать глобализация. То есть, пусть у нас всегда группы разделяются расстоянием, ну, максимум, с учётом LTR/RTL.

Если я не прав, то как надо? Это первый вопрос.

Второй: ну, допустим, я прав. Как это реализовать? Естественно, в голову приходят лигатуры, как образец готового решения. Логику можно упихать в шрифт, типа «цифра до и три цифры после — увеличиваем кернинг». Решение хорошо тем, что будет работать везде, и в HTML, и в Qt, и в Скайтере. Но это же надо как-то шрифт на лету подменять.

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

S>Кто-нибудь заморачивался с оформлением при вводе и выводе? Как решали? (Например, в HTML).

Ага, еще лет 30 назад заморочились. Любой серъезный UI тулкит имеет поле ввода с маской, решающее эту задачу. Для HTML, правда, не встречал компонентов, но уверен, что если погуглить, найдутся.

S>Лучше всего, конечно, через гарнитуру бы порешать как-то.

Почему лучше? Пробел это лишь частный случай разделителя.

Здравствуйте, Shtole, Вы писали:
S>Очень глубокий ответ, очень. Но я его не понял.
S>Вот у нас поле ввода.
Это — совсем другой сценарий, чем просто ввод и вывод. Если рассматривать ввод и вывод отдельно, то всё просто: при вводе игнорируем пробелы, при выводе вставляем туда, куда нужно.
S>Вот юзер хочет ввести число: 1 000 000 001 (или 1 000 000 002). Он жмакает по цифровой клавиатуре и видит: 10000000001.
S>Вот юзер, конечно, думает: а не нажал ли я лишнего? И начинает считать нули, выделяя текст/расставляя группы пробелами, которые потом стирает/водя грязным ногтём по экрану/иным способом в рамках фантазии.
S>Это проблема. Юзер должен сразу видеть, что он вводит.
S>Как выглядит решение «в терминах "преобразование числа в строку в соответствии с определёнными культурными предпочтениями и техническими особенностями"»?
S>А чтобы стало веселее, я пошёл домой за ружьём представим себе, что это поле ввода калькулятора, куда вводятся выражения:

S>

S>1 000 000 001 + 1
S>1 000 000 001 / pi
S>sin(1 000 000 001)
S>

S>Как видите, в этом юз-кейсе:

S>1. Проблема стоит особенно остро (в львиной доле случаев вводятся числа, иногда большие);
S>2. Мы не можем ограничиться вводом символов, составляющих число и не можем просто взять специальный контрол «поле ввода числа»;
S>3. Вставка пробелов и прочих разделителей чревата конфликтами с грамматикой языка.
По п3 — всё зависит от грамматики. В рамках калькулятора нет никакой проблемы игнорировать пробелы внутри чисел — это даст возможность переформатировать лексемы на лету.

S>Что касается «культурных предпочтений». Идеально было бы брать «разделитель групп» из настроек операционной системы. Но, например, браузер вам этого не даст (ибо отпечатки). Браузер даст только: а) название култур-мултур, б) интерфейс, который отформатирует число в соответствии с этой культурой. То есть, как ни настраивай юзер операционную систему, браузер всё равно сведёт всё к наибольшему общему делителю данной культуры (что сильно обесценивает саму идею).
Это уже проходит по пункту "технические средства". Браузер несколько ограничивает фантазию UX-дизайна.

S>Если я не прав, то как надо? Это первый вопрос.
Пытливый ум завсегда найдёт выход из положения. Нам, собственно, нужно уметь а) разобрать строку б) скомпоновать строку.
В рамках разбора, чтобы не ограничивать пользователя только корректными выражениями, мы будем делить весь ввод на "числа и всё остальное". Всё остальное — не трогаем, числа — переформатируем.
При разборе чисел мы будем просто игнорировать разделитель групп; узнать, что является разделителем, можно при помощи formatToParts.
Ну, а с форматированием всё хорошо — есть тот самый интерфейс.

Я не уверен, что всё это хорошо заработает в браузере в рамках текстового поля ввода — возможны тонкости с таймингом разбора/подстановки/восстановления положения курсора.
Когда у вас введены цифры 100000 и вы нажимаете 0, то отображение должно смениться с 100 000| на 1 000 000|, причём так, чтобы курсор остался на нужном месте — иначе может так оказаться, что курсор временно прыгнул в начало строки, пользователь успел ввести что-то ещё, и тут мы наконец переставили курсор "на место".
Запасной вариант — сделать ввод формул на чистом canvas.

S>Второй: ну, допустим, я прав. Как это реализовать? Естественно, в голову приходят лигатуры, как образец готового решения. Логику можно упихать в шрифт, типа «цифра до и три цифры после — увеличиваем кернинг». Решение хорошо тем, что будет работать везде, и в HTML, и в Qt, и в Скайтере. Но это же надо как-то шрифт на лету подменять.
Нет, это не заработает. Лигатуры работают слева направо, а нам надо чтобы они работали справа налево. Иначе вы получите отображение 123 456 78 вместо 12 345 678.

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

S>Это — совсем другой сценарий

Я просто сам пока не понимаю до конца границы проблемы, не говоря уж о возможных решениях

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

W>Ага, еще лет 30 назад заморочились. Любой серъезный UI тулкит имеет поле ввода с маской, решающее эту задачу. Для HTML, правда, не встречал компонентов, но уверен, что если погуглить, найдутся.

Между нами говоря, поле ввода с маской создаёт проблем больше, чем решает.

У вас «Спектрума» в детстве не было?

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

S>Между нами говоря, поле ввода с маской создаёт проблем больше, чем решает.

Например?

S>У вас «Спектрума» в детстве не было?

Был, а что?

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

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

S>Если рассматривать ввод и вывод отдельно, то всё просто: при вводе игнорируем пробелы

1. Как юзер узнает, что можно вводить пробелы? Он может мучиться и считать нули, не зная, что пробелы допустимы.
2. Как быть с виртуальной клавиатурой, в частности, со всеми мобилами? Отображать на ней пробел? Как-то

Мякотка в том, что пробел в п.2 мог бы быть ответом на п.1, но тогда мимо пролетят пользователи с аппаратной клавиатурой. Плюс придётся поломать стандартный layout, всё как любят юзеры!

Кстати, на клавиатурах банкоматов бывает кнопка «000». Но как универсальное решение это не прокатит, опять же, из-за писишников.

S>при выводе вставляем туда, куда нужно.

А потом юзер копирует и вставляет в поле с маской. И что произойдёт дальше — зависеть будет от автора поля с маской, но юзер во всех проблемах будет винить вас.

S>Это уже проходит по пункту "технические средства". Браузер несколько ограничивает фантазию UX-дизайна.

Хотелось бы понять все возможные ограничения, и то, насколько они обходимы.

Пока что я думаю, может фон под каждой чётной группой подтемнять слегка? На уровне елезаметности.

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

S>>Между нами говоря, поле ввода с маской создаёт проблем больше, чем решает.
W>Например?

Например, я вставляю из буфера число в каком-то контексте (обрамлённое буквами или с элементами разметки), чтобы убрать лишнее непосредственно в этом поле перед вводом. Поле с маской вынудит меня редактировать буфер путём открытия простого редактора (лайфхак: самый простой однострочный редактор в Винде — Win+R). Особенно приятно бывает, когда содержимое буфера было нужно ещё для чего-то другого и в ходе наших действий необратимо потерялось.

Есть и другие.

S>>У вас «Спектрума» в детстве не было?
W>Был, а что?

Ну, вот его редактор не дружил с переходом из одного правильного состояния в другое правильное через промежуточное неправильное. Там, правда, копипаста не было. И к лучшему, наверно

Здравствуйте, Shtole, Вы писали:
S>1. Как юзер узнает, что можно вводить пробелы? Он может мучиться и считать нули, не зная, что пробелы допустимы.
Попробует и убедится.
S>2. Как быть с виртуальной клавиатурой, в частности, со всеми мобилами? Отображать на ней пробел? Как-то
Тут решением является нормальный элемент управления, который корректно разбирает числа.
S>Мякотка в том, что пробел в п.2 мог бы быть ответом на п.1, но тогда мимо пролетят пользователи с аппаратной клавиатурой. Плюс придётся поломать стандартный layout, всё как любят юзеры!

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

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

S>>1. Как юзер узнает, что можно вводить пробелы? Он может мучиться и считать нули, не зная, что пробелы допустимы.
S>Попробует и убедится.

Я думаю, очень малая доля так сделает. Но полупрозрачного зеркала и десяти человек, которым нечем заняться, у меня под рукой нет, так что обосновать не могу )

S>>2. Как быть с виртуальной клавиатурой, в частности, со всеми мобилами? Отображать на ней пробел? Как-то
S>Тут решением является нормальный элемент управления, который корректно разбирает числа.
S>>Мякотка в том, что пробел в п.2 мог бы быть ответом на п.1, но тогда мимо пролетят пользователи с аппаратной клавиатурой. Плюс придётся поломать стандартный layout, всё как любят юзеры!

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

Я согласен, что их не надо их применять, но они часть реального мира и их существование (в других программах) нельзя игнорировать.

Говоря профессиональным языком, «это часть совместного user experience, которую мы не контролируем».

S>>Пока что я думаю, может фон под каждой чётной группой подтемнять слегка? На уровне елезаметности.
S>Можно.

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

S>Например, я вставляю из буфера число в каком-то контексте (обрамлённое буквами или с элементами разметки), чтобы убрать лишнее непосредственно в этом поле перед вводом. Поле с маской вынудит меня редактировать буфер путём открытия простого редактора (лайфхак: самый простой однострочный редактор в Винде — Win+R).

Честно, никогда не сталкивался с таким сценарием. Обычно поле с маской вынуждает меня более внимательно копировать.
Но и решение с промежуточным редактором вполне нормальное, на мой взгляд. Лучше иметь один такой редактор на всю систему, чем повторять его в каждом поле каждого приложения, с неизбежными вариациями и путаницей пользователей.

S>Есть и другие.

Можем обсудить и их.

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

W>Честно, никогда не сталкивался с таким сценарием. Обычно поле с маской вынуждает меня более внимательно копировать.

<b>222</b>-<b>33</b>-<b>222</b>

Ну, скопируйте «внимательно». Если источник такой. (Код). Реальнейший пример, я не выдумываю. Как, по-вашему, я пришёл к советам про Win+R?

Или даже просто (это 5 разных вариантов, и я знаю больше таких же РЕАЛЬНЫХ):

222-33-222
222–33–222
222—33—222
222 33 222
222 33 222

…если поле хочет строго цифры. Уж с этим-то точно каждый сталкивался.

Сюда же — любые интеркультурные копипасты (разные разделители, не только групп, но и дробной части), которые требут редактирования.

Сюда же — особенности выделения в разных программах. (Лайфхак: если в браузере Firefox выделить текст мышкой, а потом зажать Shift и понажимать стрелки, можно подкорректировать выделение с точностью до символа по ходу направления выделения мышкой. И опять же: как я к этому пришёл бы, если бы дело было только во внимательности?)

Поэтому, одной внимательностью тут не обойтись.

W>Но и решение с промежуточным редактором вполне нормальное, на мой взгляд. Лучше иметь один такой редактор на всю систему, чем повторять его в каждом поле каждого приложения, с неизбежными вариациями и путаницей пользователей.

Вместо всего этого надо просто сигнализировать о неверном вводе и не давать его завершить. Лишать юзера возможностей редактирования по месту назначения не надо.

S>>Есть и другие.

W>Можем обсудить и их.

Да пожалуйста. Когда программист сталкивается с первыми ласточками (см. выше), он начинает дорабатывать своё поле напильником. Например, творчески обрабатывать содержимое буфера перед вставкой (удалять лишнее). Поскольку универсального рабочего алгоритма нет и быть не может, вставка при этом начинает происходить в 100% случаев, но не на 100% безошибочно, а это уже по-настоящему страшно.

Опять же, ничего не выдумываю. Я сталкиваюсь с этим ужасом достаточно часто, чтобы из опыта эти ситуации поделить на две группы: хорошо, когда длина ввода фиксирована (код карты, Л/С конкретной компании), это видно и глазками, и парсеру. А ведь бывает, что и нет. И вот это уже полная задница.

Вообще, суть — сломанное редактирование, которое может понадобиться — одна и та же. А вылезать может миллионом способов.

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

S>Понятно, что «1 000 001» выглядит лучше, чем «1000001».

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

Гугли, как с ним работать и преобразовывать число в строку, в соответствии с локалью, в том языке, на котором пишешь.

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

S>>Понятно, что «1 000 001» выглядит лучше, чем «1000001».

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

Это и есть

>Все, вроде, через редактирование самой строки делают (локальное форматирование), но как можно поручиться, что там не будет пробелов вместо nbsp? Второй проход делать самому? Да и overriding пользовательского ввода мне не нравится.

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

>>Все, вроде, через редактирование самой строки делают (локальное форматирование)

Форматирование при вводе?

>>, но как можно поручиться, что там не будет пробелов вместо nbsp? Второй проход делать самому? Да и overriding пользовательского ввода мне не нравится.

Для этой цели и свой велосипед несложный получится. И там будет всё, как тебе нужно.

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

AN>Для этой цели и свой велосипед несложный получится. И там будет всё, как тебе нужно.

Вопрос-то был не о сложности, а о юзабельности